[Mono-list] prototype XSLT debugging patch ...
atsushi at ximian.com
Mon Nov 27 22:16:19 EST 2006
Here is the (improved?) patch based on yours. To enable template
stack frame information:
stdout: write template call to stdout.
stderr: write template call to stderr.
error: enable stack frame in XsltException.
This patch is almost different from yours, as it includes fixes on
public API exposure, PascalCasing, etc. etc.
Does it look good?
Michael Meeks wrote:
> Hi Atsushi,
> On Sat, 2006-11-25 at 12:37 +0900, Atsushi Eno wrote:
>> Ok, now I understand what you originally wanted. I was thinking that
>> you want either trimmed information to hide stack trace details, or
>> want working XSLT debugger which is not realistic at this state
>> (as I'm not working on sys.xml and primarily working on web service
>> related stuff, except for important bug fixes).
> Sure - hopefully it's a fairly simple thing I want.
>> Your patch shows interesting error information and I'd love to
>> get this functionality in svn. But I don't think it should be
>> "always" shown to users.
> Totally agreed - particularly it prolly hurts people debugging the
> actual XSLT impl. itself :-)
>> An immediate concern example is that
>> since XSLT could be designed to work recursively, this detailed
>> information could be hundreds of lines. Also this patch ends up
>> to hide exact problematic code location. So I think something
>> like environment variable should be used to "enable" this
>> detailed report.
> Yep - can you take this on ? also - (for me) it'd be fine to just do:
> $ MONO_XSLT_DEBUG=1 mono foo.exe
> and instead of trying to make the exception more verbose itself, just
> dump the output to System.Console a frame at a time - that would also
> rather shrinks the patch and make it more useful.
> Can you suggest a good name for the env. var ? or what would be
> immeasurably better would be if you could rescue something useful from
> my hack and commit it yourself ? ;-)
> FWIW - someone else helped me find the cause of the problem - which (it
> appears) is tied to Mono emitting 'WriteFullEndElement' very frequently,
> where (apparently) Microsoft ~never emit it (for the same data set). Of
> course, that could be related to some other deeper oddness
> somewhere :-), but it is strange nonetheless.
> Anyhow - thanks again,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Mono-list