One example using the tutorial would be in around lines 22 - 28 where there are a couple of call-templates. Just using step over on line 22 (From: <xsl:call-template name="formatEmail">) I wouldn't be surprised if it were to resume on line 23 (the parameter for the template call) or line 25 (the end of the template call); I'd expect though within that template just using step overs I'd not step into the called template itself but would instead remain within the logic of the initial match template. What actually happens is that by using only step overs, one goes from line 22 to line 23 to line 45, thus stepping into the formatEmail template. It's the identical behavior to step into, and in fact I haven't been able to find any examples where step over and step into behave differently with the XSLT debugger.
The original XSLT code I was working with is called svg2gfx.xslt and you're welcome to play around with it, too. It wants SVG for its input, and I was just testing it with the various Mozilla samples (non-interactive ones only, ones like butterfly, chem 1, polygons 1, lion, tiger, etc.). What I discovered is that the XSLT debugger stopped working completely after the script grew beyond a certain size (not sure exactly what, probably a bit fewer than 1000 lines or so); it may or may not get to the first breakpoint, but after that trying to step through will just make it hang. Quitting Komodo IDE afterwards results in a "The application xsltdbgp quit unexpectedly." error message regardless of whether or not one detaches the debugger prior to quitting.
As for the robustness, xsltdbgp is a C program, so I can
see that there's an opportunity for memory corruption
after a long-running process. If you can reproduce it
that would be very helpful.
It could very well be some sort of memory corruption error. It doesn't need to be running for a long time, though, it just seems to need a large XSLT file.
It does seem to be pretty erratic, though. Yesterday I couldn't get it to work at all as the bug would show up every time. Now I can't seem to make it trigger the bug at all. I have upgraded from OS X 10.5 to OS X 10.6 though in between; perhaps that's the reason for the improved behavior. I'll keep tinkering with it.
... or if you don't want to send in your code, can you reproduce the behavior with the xslt_sample.xsl in the Komodo sample project?
http://docs.activestate.com/komodo/5.1/tutorial/tourlet_debug_xslt.html
In particular, tell us on which line you trigger the Step Over and where you expect it to break next.
One example using the tutorial would be in around lines 22 - 28 where there are a couple of call-templates. Just using step over on line 22 (
From: <xsl:call-template name="formatEmail">) I wouldn't be surprised if it were to resume on line 23 (the parameter for the template call) or line 25 (the end of the template call); I'd expect though within that template just using step overs I'd not step into the called template itself but would instead remain within the logic of the initial match template. What actually happens is that by using only step overs, one goes from line 22 to line 23 to line 45, thus stepping into the formatEmail template. It's the identical behavior to step into, and in fact I haven't been able to find any examples where step over and step into behave differently with the XSLT debugger.The original XSLT code I was working with is called svg2gfx.xslt and you're welcome to play around with it, too. It wants SVG for its input, and I was just testing it with the various Mozilla samples (non-interactive ones only, ones like butterfly, chem 1, polygons 1, lion, tiger, etc.). What I discovered is that the XSLT debugger stopped working completely after the script grew beyond a certain size (not sure exactly what, probably a bit fewer than 1000 lines or so); it may or may not get to the first breakpoint, but after that trying to step through will just make it hang. Quitting Komodo IDE afterwards results in a "The application xsltdbgp quit unexpectedly." error message regardless of whether or not one detaches the debugger prior to quitting.
It's at http://bugs.activestate.com/show_bug.cgi?id=84398
As for the robustness, xsltdbgp is a C program, so I can
see that there's an opportunity for memory corruption
after a long-running process. If you can reproduce it
that would be very helpful.
- Eric
It could very well be some sort of memory corruption error. It doesn't need to be running for a long time, though, it just seems to need a large XSLT file.
It does seem to be pretty erratic, though. Yesterday I couldn't get it to work at all as the bug would show up every time. Now I can't seem to make it trigger the bug at all. I have upgraded from OS X 10.5 to OS X 10.6 though in between; perhaps that's the reason for the improved behavior. I'll keep tinkering with it.
Thanks for logging the bug. As listed though it only refers to call-template; I'd argue that apply-templates should also be step-overable.