[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Jesper,
oXygen sets a trace listener on Saxon to be able to offer the "Stop Transformation" action that allows users to stop a transformation at any time. That causes more method calls as Saxon will call the listener on all instructions and the transformation requires more stack memory. For example I was able to run your transformation setting the stack for oXygen to 10MB.
In the current development code of oXygen we found another way to implement the "Stop Transformation" action, without setting a trace listener on Saxon and your stylesheet works without problems with the default stack memory.
Jesper Tverskov wrote:
Re: [xsl] Maximum recursion depth exceeded
Subject: Re: [xsl] Maximum recursion depth exceeded From: George Cristian Bina <george@xxxxxxxxxxxxx> Date: Tue, 07 Jul 2009 11:36:43 +0300 |
Hi Jesper,
oXygen sets a trace listener on Saxon to be able to offer the "Stop Transformation" action that allows users to stop a transformation at any time. That causes more method calls as Saxon will call the listener on all instructions and the transformation requires more stack memory. For example I was able to run your transformation setting the stack for oXygen to 10MB.
In the current development code of oXygen we found another way to implement the "Stop Transformation" action, without setting a trace listener on Saxon and your stylesheet works without problems with the default stack memory.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Jesper Tverskov 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.
_ _ _ _ _
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.
When run outside an IDE, optimization is enabled.
You could try using smaller input sets while within the IDE environment, but this is part of the cost of using a high-level language with a clever optimizer."
_ _ _ _ _
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?
Cheers, Jesper Tverskov
http://www.xmlkurser.dk http://www.xmlplease.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Maximum recursion depth e, Dimitre Novatchev | Thread | Re: [xsl] Maximum recursion depth e, bryan rasmussen |
Re: [xsl] Maximum recursion depth e, bryan rasmussen | Date | Re: [xsl] Maximum recursion depth e, bryan rasmussen |
Month |