Re: Maximum recursion depth exceeded

On Tue, Jul 7, 2009 at 8:39 AM, Jesper Tverskov<jesper@xxxxxxxxxxx> wrote:
> Hi list
>
> When preparing for my article, "Google's Writely and XSLT for web
> pages", http://www.xmlplease.com/writely2xhtml, basically a
> writely2xhtml transformation, using David Carlisle's htmlparse.xsl,
> http://dpcarlisle.blogspot.com/2007/04/htmlparse-updated.html, to do
> an important part of the job, I have experienced an interesting
> problem.
>
> The transformation goes well with Saxon at the command line and from
> inside .net but fails from inside XML Editors like Oxygen and Stylus
> Studio. It also fails from inside XMLSpy using AltovaXML.
>
> The XML editors return an error message saying something like "Maximum
> recursion depth exceeded" or "too many nested function calls". I have
> filed this "bug" at the three XML Editors.
>
I don't know if you can say it is a bug that maximum recursion depth
was exceeded, that is just an implementation limitation that should be
noted.

> _ _ _ _ _
>
>
> Tony Lavinio in the Stylus Studio Forum has given this great explanation:
>
> "The difference is most likely coming from the optimizer.
>
> When you run Saxon within Stylus Studio (or Oxygen), in order to provide
> debugging support we disable the optimizer. The Saxon optimizer will
> reorder code, eliminate variables, and push expressions up or down the
> stack. It also controls tail-call recursion.
>
> If we didn't disable the optimizer while within the IDE, there is no
> way you could follow the code, since the executable path doesn't really
> look like the source document anymore.

Maybe it should give you the opportunity to disable debugging. so if
disable debugging enable optimizer. Sounds like that's something they
should handle. :)


>
> It is interesting to note that my test documents failing in the XML
> Editors still work when made 10 times longer at command line and from
> inside .net.
>
> Now my question to the XSL list:
>
> Is the above problem the one and only exception or do we have other
> situations where a transformation in an XML Editor is likely to fail
> even when the same transformation works well at the command line or
> from inside .net or java?
>

Well I guess the thing is -

how many 'ways' are there to implement transformations in .NET and
Java (Saxon obviously only uses one particular way)
which editors wrap what command line tools
which editors allow you to swap out processors.
Do the processors behave differently in a commandline version...

I'm probably being unclear here but let me give as an example .NET.

.NET has an api for doing transformations, you have different ways to
send XML input to the transformation that you programmatically
determine.
In a commandline app using the .NET apis you would, as a general rule,
have the writer of the app determine what functionalities of the api
to use and how to feed it XML input.

System.XML.XSL doesn't behave differently in a commandline app, the
commandline app - just like an XML Editing application - has to make
decisions as to what to do with the various functionalities that it
has available to it - for example does it allow the document
function(), probably and so would the editor but an online transformer
that took user XSLTs might not, does it allow validation of the input
XML - probably turned off by default but maybe can do that based on
command line parameter whereas the XML editor might have it turned on
all the time and require you to go through hell to turn it off...

So the commandline tools functionality does not directly map to the
underlying capabilities of System.XML.XSL just as the editor doesn't.
Actually now I'm starting to run on here but I think the question
above:
" Is the above problem the one and only exception or do we have other
 situations where a transformation in an XML Editor is likely to fail
 even when the same transformation works well at the command line or
 from inside .net or java?
"

is wrong in some way, probably someone smarter than me could identify
better what I am seeing as a logical divide..

anyway, recursion problems are likely to be a problem in .NET / C#, as
far as I know currently the only .NET language that can compile and
optimize for tail recursion is F#..

Mvh,
Bryan Rasmussen