Re: [xslt] Request for comments on :Request for break point API suggestions

[Daniel Veillard <veillard redhat com>]

On Wed, Sep 19, 2001 at 09:29:54PM +1000, Keith Isdale wrote:
> 
> Below is the discussion I've had with Daniel. He asked my to post this and 
> reference to xsldbg-0.4.2 (What was intended only for him since I was 
> uncertain that the code was "properly" GPL'd) Since then I've created a set 
> of diff and tars for libxml and libxslt for a propotype that enable 
> breakpoints in libxslt. Also I've updated my debugger which I believe to be 
> correct as far as licensing goes (Hopefully I've got the beast under control 
> :-)  at least it far better than xsldbg-0.4.2 ) . I'll let the code speak for 
> itself. The reference below to transform_shell.c now refer for transform.c in 
> libxslt. 

  In general I'm supportive of the effort. I would like to see a small API
defined that I would implement in libxslt allowing gebuggers to plug in
the transformation engine and get/set data.

> Compiling :
> 	Either apply each diff in keiths_diffs.tar  to a clean copy of libxml and 
> libxslt (using a  patch -p1  )

  The diffs are useless. It seems they contain the full code, Applying or
even looking at 1MBytes of diff is not possible. You *need* to isolate your
change for me to consider looking into them.

> ln summary on the breakpoint problem, at present the way that I've detected
>  breakpoints previously is via finding a template match. Then user can step
>  to next instruction, stepout of the current instruction  or run to next
>  template. This is different to what xemacs xsl-process.el expects (normal
>  debugger behavior). It is able to set/delete/enable/disable a breakpoint at
>  a specific file and line number. I would also suggest that the application
>  would need to confirm that libxslt it arrived at the right place. But that
>  can be solved using a "pwd".  I think there is a problem with macro

  Rather than focusing on the debugger interface itself, I would prefer to
discuss the required APIs precisely to set/delete/enable/disable breakpoints
and also to walk the stacks (of templates and variables/params).

> Since there is very litte code in my xsldbg.c that not in xsltproc is suggest
>  that xsltProc be modified to support debugger "add ons" see API_Report.txt
>  "add ons"

  Hum, this might be a bit artificial. I would prefer 2 distincts programs
one for processing and one for debug.

> Since a large portion of debugXSL.c is from debugXML.c I request public 
>  access for these functions as descibed in attatched Public_access.txt

  Do you have a list of the functions needed ? I could export them from libxml2,
and would rather do it sooner than later since we are trying to freeze APIs 
for the Gnome-2.0 release.

> I've listed many changes here. As must as I want to cause a "once off" change
>  to libxslt I am starting to wonder if this many changes is an unacceptable
>  risk for  libxslt.  Maybe these changes should be "staggered" ie adding the
>  breakpoint changes and then thinking about the changes to xsltproc.c,
>  debugXML.c and debugXML.h

  A progressive approach is definitely better, the first step being to
analyze the kind of APIs we really want and their scope.

  I didn't had time yet to review the rest of the comments provided. I
invite people interested to comment on them.

Daniel


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