Hi, Sorry I have been off the radar, some personal crap has been keeping me occupied.
The memory model changes have been largely effective and creates a good one to one coupling between ruby object and libxml entities. The issue that sean is talking about is no longer the case. I have removed Reference counting everywhere I have been and multiple recall of an entity will return the same ruby object. I do not believe the libxml2 library is at all the problem. My greatest frustration has been the the GC and debugging and memory tracking. Basically the GC sucks and the way it is written and that it lacks any instrumentation for debugging makes for nothing but trouble. I have worked with Marc directly on a number of faults and have been largely successful, but the time cost is high, and I cannot make this my life's work. There are components that have not been evaled or rewritten yet and the problems that people are be experiencing may be the result of mixing those features. May or may not, since I have not looked. I have contemplated abandoning support, but I would rather not. Being the only coder makes it harder as ultimately every bug is my problem. But that is not the issue, ruby 1.8 is. I have considered moving to rubinius to see if their compatibilty api is better than the original. But that may yield nothing as it could work fine there. 1.9 I have not considered, but valgrind is sort of a white elephant since the GC screws things up without a trace before the real problem occurs. I am open to suggestions, but I can't do this part on my own. Dan On Wed, 5 Mar 2008 12:43:01 -0800 Sean Chittenden <[EMAIL PROTECTED]> wrote: > > Seeing that no one else has responded > > I don't know if it's been nixed or not, but the is_shadow concept is > fundamentally broken in any sophisticated workload. Every operation > needs to return a copy. I initially did the shadow bits for speed > reasons (object thrash), which satisfied my workload requirements at > the time, but it's proven to be a really bad idea in practice. If I > had cycles/interest in rewriting things, I'd take aim at anything > that returns a wrapped xml object and would return a copy of the > object instead. What I believe is happening is the GC is coming > along, invalidating portions of the XML document structure, and > leaves a dangling pointer. I don't know if that's what Dan fixed in > the latest rev or not, but that's the only design thing that I'm > aware of that _needs_ to get addressed. Is this still feasible? -sc _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
