Hi Atsushi, On Fri, 2006-11-24 at 13:36 +0900, Atsushi Eno wrote: > > So - my question is - how do people debug 55k lines of XSLT ? :-) >> and - more to the point, when something fails how do we get a decent >> 'stack trace' from the XSLT code ? [ I tried adding some 'Call >> Template' tracing debug - as you see, but quickly get swamped ]. > > People doesn't debug XSLT in such way. People just reduce extra > transformation parts, reduce imputs and trim down to doubtful blocks.
This is a method I call "binary chop" - it works well when you're writing new code, and introduce a small number (preferably 1) of bugs :-), and when the code is easy to understand & partition, but when there are a potentially arbitrary number of vicious problems and interactions, and the code is not easy to reduce reliably, it's not such a powerful tool. Is this how you fix all your problems ? there is no verbose debug output you use or better tracing logic ? > > What I would -love- would be a simple piece of code that just dumped > > the file/line information to the console (or Debug. or whatever) and > > re-threw the exception, perhaps in 'XslTemplate.Evaluate' or something > > (?) [ we get a good number of frames of that ]. > > In such case you could just use mono-xmltool to debug your XSLT. Well - unfortunately, that's not really feasible - the XML that the XSLT produces is concealed away and produced by pre-processing a ton of random other files into each other (AFAICS on demand by the XSLT) ;-) so it is rather hard just to pull out the XML [ though of course this is a good suggestion ]. > Or just wrap around the entire transformation with "try" and "catch > XsltException", and get LineNumber and LinePosition from there. > Actually its Message property indicates them, so you don't have to > retrieve those numbers. Well - the problem here is that the exception / evilness is thrown by code run -from- the XSLT code, not the code itself - so the real exception is some random "Stack Empty during .pop()" type thing. Of course the -real- problem is that the XSLT script has (somehow) managed to produce more element closes than opens :-) getting a trace of where we were in those 55k lines when that happened -might- help find where we go wrong. > Any omitted information wouldn't result in better debugging. That is not > what we call "good diagnostics". I find that hard to parse. However, since you appear reluctant to help, I will try and dive in and implement something to emit more of the omitted information :-) perhaps that will help me find the root problems more quickly. Regards, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list