[Mono-list] prototype XSLT debugging patch ...

[Atsushi Eno]

Hi Michael,

Here is the (improved?) patch based on yours. To enable template
stack frame information:

MONO_XSLT_STACK_FRAME=
	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?

Atsushi Eno

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,
> 
> 		Michael.
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xslt-frame.patch
Url: http://lists.ximian.com/pipermail/mono-list/attachments/20061128/514b6f84/attachment-0001.pl