Thanks for the update. Any progress on exposing libxml2's ability to create a DOM from HTML?
- Mark. Ross Bamford wrote: > Hi, > > I've made a start on 0.4 development, in a new DEV_0_4 branch in CVS. I've > started out by trying to address the memory handling problems centered > around XML::Node, which is used pretty much throughout the library, and so > far the tests, and my own experiments, suggest a promising start. > > The main effect of the changes so far is: > > * Totally reworked node allocation and wrapping, we still don't copy > nodes > unless required, but we now track how many ruby_xml_nodes wrap a given > xmlNode. This is currently done using _private data - I know someone > asked > about exposing that member for app use but I can't see where else to > store > the data needed by the binding. Also, this will break compatibility > with > libxsl-ruby 0.3.x, but that's to be expected anyway - once this > branch > is > moving a bit more I'll introduce a parallel branch into libxsl-ruby. > > * Changed the way nodes are handled WRT. their documents and parent > nodes, > to better fit with libxml2's memory model for the tree. We leave > memory > management with the library as much as possible, only stepping in > where > we > need to. This should fix up myriad problems that occur when copying > nodes > between documents and adding new nodes. It's slightly less efficient > now, > but once it's more stable we can probably streamline things a bit. > > * Thread safety: After going through the code and making the changes > I've > made, > I'm now a lot happier that the binding is thread safe - as long as > libxml2 > is compiled using the --with-threads option. Note though that this > doesn't > apply to custom parser error handlers - it's up to you to be > thread-safe > there. Later on I'd like to devise some specific tests for threadsafe > > use. > > * Error handler procs - won't get GC'd while you're not looking any > more (oops :->). This was causing a seemingly-random segfault. > > I need people to look over the changes, try the new stuff out, play with > it, and generally try to break it - let me know if it works/doesn't work, > could be done better, or whatever. I'm hoping to really attack the bugs we > know about, and root out those we don't, but I won't be able to do it > without feedback as the work progresses... > > Cheers, > _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
