Well, it's not quite a null set. I can write C, and I have some knowledge of XML. My problem is being able to spare the cycles. I am using libxml for my own free software project and I would rather spend my free cycles on that than on the supporting infrastructure.
I may have to change my mind though, as I appear to be at the limits of the current stability of libxml. It looks like my choices are contribute to libxml or rewrite what I have in another language (none of the other libraries for ruby are anything like fast enough). Right now I'm thinking that my project's long term future might be with a rewrite in D. However I am prepared to spend a little time looking at the issues in libxml, and I have a question about the entire philosophy of the old reference counting memory management implementation, and the new mark-sweep based approach. 1) The reference-counting implementation allowed multiple ruby references to the same C structures: is this also true of the newer approach? 2) Is there a fundamental need for more than one ruby object to reference any libxml C object? 3) I am not that familiar with the Ruby memory management model but would the following rather different approach be feasible: when a ruby objects is created the C object is given a reference to it, and when the ruby object is garbage collected the corresponding C object loses its reference and is then conditionally freed (if none of the associated nodes have remaining references)? I am beginning to think, admittedly with little real evidence and a high likelihood of being wrong, that the fundamental stability problem arises more because of the fact that we allow the C objects to be shared by multiple ruby objects than anything else. Comments, answers? __ Marc On Tue, 2008-05-27 at 11:43 -0400, Dan Janowski wrote: > The intersection is a null set. The best hope may be rubinius where > the extensions can be written in ruby. Fixing the memory model for > nodes and documents made a big difference, but the problems that are > lingering are elusive and compounded by ruby's obsficating GC. I put a > lot of time into it, but the maintenance is clearly more demanding > than I, or any one person, can provide. So here we are. > > On 5/27/08, Sean Chittenden <[EMAIL PROTECTED]> wrote: > I shifted out of libxml to the (much) slower REXML and > an ad-hoc > over-the-network Java based XSD validation system. I > would love to get > libxml-ruby working again. A lot of my projects will > depend on it. > > Dan, how can other people help? Is there someone who > can coordinate > other people's efforts in the right direction? > > > Sean's Posit #6: The group of people who need fast XML > processing and the group of people know C are almost > completely orthogonal technical groups. > > Ruby (or more specifically rails) has turned into a kind of > open source refuge for .net developers who lack much clue, so > the signal to noise ratio for most ruby projects is... > atypical and out of line. > > What the project needs are people who can actually program in > C, understand XML and are in a position to spend cycles on > this problem. As is, there aren't many who have these two > essentially non-overlapping skills and rarer still, people who > have cycles to spend on the thankless job of library > development. -sc > > -- > Sean Chittenden > [EMAIL PROTECTED] > > > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel > > > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
