Re: [xslt] str:tokenize behavior

On Sat, May 03, 2003 at 03:06:04PM -0600, Vakoc, Mark wrote:
> >  Okay I finally addressed this in what I think is the correct way.
> > 1/ this is expected to be a node set, so it should allocated as such
> > 2/ the problem of freeing the tree is independant and addressed by
> >  allocating and freeing it with new APIs
> I thought I would give you a quick update on my progress with this.
> Thus far I have experienced zero problems with the new method.  I have
> approximately half of my twenty or so extensions that return node-sets
> converted to the new approach.  So far it has introduced no issues in my
> testing.  Of note is that my testing thus far is functional and I have
> not performed any memory leak testing.
> It is taking some time to convert my functions b/c testing them is not
> always easy and the new method cannot be implemented using the single
> macro I used before to create a (every changing) RTF object so I have to
> manually change more of the code (mainly when adding actual nodes to the
> nodeset instead of the 'container').

  okay, the key objective is to avoid memory leaks, that was the only
approach I could reasonably use, and it requires the help of the XSLT
processor, XPath itself is not sufficient anymore.

> But basically so far I am very pleased with this approach.  I had to
> make some minor changes to get stuff to build on win32 like adding the
> RVT functions to libxslt.def.src and such.  Also some conversions from
> void* to other types need casts.  I will submit the simple patches when
> everything is ironed out.

  Okay good to know.

> Great work.  I will let you know the final results when I complete
> implementation and testing.

  Well I had to push the release anyway before travelling around
so your patch won't be in 1.0.30 but at least I assume the core
APIs are functionnal as-is, pushing now rather than in 2 weeks will
allow more feedback :-)


Daniel Veillard      | Red Hat Network  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]