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,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
