Re: [xslt] Debugging large stylesheets with xsldbg

[Daniel Veillard <veillard redhat com>]

On Wed, Oct 31, 2001 at 03:49:46AM +0000, k_isdale@tpg.com.au wrote:
> Hi all,
> 
> I been running xsldbg over docbook.xsl. With no 
[...]
> Also I found some unintentional assumptions I  
> made :-( . 
>   1) Assumed that the root template specfied 
> would be executed at some point
>   2) Assumed the user would know what the 
> template names that could be used for the root 
> template

  yep, in a lot of cases, the root is simply processed
by the default rule (i.e. to run apply-templates on the children
nodes).

>   3) Assumed there would be a reasonable number 
> of variables, templates and stylesheet files
>   4) There would only a few breakpoints set at 
> any time. This was wrong because docbook.xsl have 
> over 500 templates and I allow the user to set 
> breakpoints on all templates! 

  DocBook is an excellent scalability test :-). I think
the next level is TEI from what I heard !

> 
> Problem 1) 
>  Solution: I've added a new function that allow 
> the xsldbg.c know if any breakpoints have been 
> found at all. If not then breakpoints are set on 
> all templates found for the next attempt of 
> debugging.
> 
> /** 
>  * xslDebuggerReached :
>  * @reached : true if debugger has received 
> control
>  *
>  * Set flag that debugger has received control to 
> value of @reached
>  * returns true if any breakpoint was reached 
> previously
>  */
> int xslDebuggerReached(int reached);
> 
> 
> Problem 2)
>   Solution  If the root template is not found 
> then I print out a list of template names and the 
> program aborts.

  hum, it smells like something wrong to do.

> Problem 3)
>  Solution : Add ability to print the names of 
> matching a query of template names, global 
> variables names, stylesheet file names. I think 
> this could be added at a later time, and should 
> be a module by itself breakpoints/search.[ch].  
> But if anyone has time to look at this great. I 
> imagine this could be done by writing functions 
> to walk though the list of all; template names, 
> variables names, stylesheet file names (mostly 
> just wrappers over existing hash table 
> functions ).
> 
> Problem 4)
>  Solution : Change data structure of used by 
> breakpoints to a linked list. This would put no 
> restrictions on the number of breakpoints that 
> could be set. 
> 
> Question : Is performance an issue for debugging ?

  yes if the debugger is too slow, people won't use it.
I will give an example. Gdb allows to interrupt a running
program when a given memory range is accessed. The problem
is taht it makes execution so slow usually that it is
not usable. A degradation of performances is normal,
and accepted but only to a given point (i.e. how desesperate
the user is :-)

> If so would making a breakpoint hash table might 
> be a better solution . Where the "key" for each 
> entry in the hash table is calculated by a strcat 
> of the string version of the line number and 
> stylesheet url. This would mean that for before 
> every statement executed the "key" for that 
> statement woukd need to be calculate and then 
> looked up in the breakpoint hash table. This 
> solution would increase the complexity of the 
> breakpoint API and increase the probability of 
> bugs :(

  You need to test. The libxml hash tables
are used heavilly for validation for example,
and so far they perform well.

> It would be much appreciate for people to give 
> feedback on xsldbg /comment on the breakpoint 
> API. It's hard to find bugs in your own 
> interfaces/code.
> 
> It my intention to make this a valuable tool in 
> its own right. Not just a means to step though 
> xml/xsl code. 
> 
> Comments?

  I need to look more at it, now that I have made
the release I will try to dedicate some time to it.

> Daniel: Have you got list of the interfaces for 
> the functions being exported out of xsltproc. Or 
> a mockup of what you have in mind.

  Well I have it in mind. Would take longer to write it
here than to do it directly. should not take long.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/