Re: [xslt] Debugging large stylesheets with xsldbg
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Cc: k_isdale tpg com au
- Subject: Re: [xslt] Debugging large stylesheets with xsldbg
- Date: Wed, 31 Oct 2001 04:09:31 -0500
On Wed, Oct 31, 2001 at 03:49:46AM +0000, email@example.com 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
yep, in a lot of cases, the root is simply processed
by the default rule (i.e. to run apply-templates on the children
> 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
> * xslDebuggerReached :
> * @reached : true if debugger has received
> * Set flag that debugger has received control to
> value of @reached
> * returns true if any breakpoint was reached
> 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
> It my intention to make this a valuable tool in
> its own right. Not just a means to step though
> xml/xsl code.
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 Veillard | Red Hat Network https://rhn.redhat.com/
firstname.lastname@example.org | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev