On 24 March 2014 20:28, Graydon <graydon(_at_)marost(_dot_)ca> wrote:
On Mon, Mar 24, 2014 at 08:05:40PM +0000, Andrew Welch scripsit:
On 24 March 2014 18:42, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
On 24 Mar 2014, at 17:31, Eliot Kimber <ekimber(_at_)contrext(_dot_)com>
wrote:
For whatever reason I find using interactive debugging unhelpful for
debugging XSLT processing (but I couldn't code a line of Java without it).
That's my experience too, I have never been sure why the difference.
That's interesting... I use oXygen daily and get on well with its
debugger - the click back feature (where you click on a node in the
result and it highlights the line in the xslt and context node in the
source xml that created it) is a killer feature (I don't know if it's
common or unique to oxygen). Equally, putting break points in the
xslt and then clicking around the call stack to see how you got there
can be a quick way of diagnosing issues.
That is all true and it's wonderful when it's practically available.
My experience is that it simply takes too long to be useful with "real"
(that is, the multi-thousand-template, here's a several tens of MB of
input document, horrid conversion stylesheets I was most recently
dealing with) input. Two orders of magnitude slower than non-debug
execution, and a definitive answer to "but where did it die?" could be
had by other, if more effortful, means.
I also have the pleasure of debugging other people's 10,000+ line
spidery mess of call templates, and I've never had an issue with
speed... I'm guessing the transform you were working already took a
long time?
--
Andrew Welch
http://andrewjwelch.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--