But since you went ahead with swapping XML => LibXML, that probably
best anyway. I wonder about one thing though, is backward
compatibility best preserved with:
XML = LibXML
or as you have it:
module XML
include LibXML
end
Use an environment variable at require time and the module assigns.
On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <[EMAIL PROTECTED]> wrote:
>>> But since you went ahead with swapping XML => LibXML, that probably
>>> best anyway. I wonder about one thing though, is backward
>>> compatibility best preserved with:
>>> XML = LibXML
>>> or as you have it:
>>> mod
Curious where the code for the benchmark results on the libxml home page
lives?
Thanks
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxm
Use of XML was actually a conscious choice on my part. Ditch the
puritanical or egalitarian thoughts. Odds of two XML parsing libraries
loaded into the same instance is rare. I imagined there would be little
to no contention for the XML namespace because everyone would've treated
it as holy.
On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <[EMAIL PROTECTED]> wrote:
But since you went ahead with swapping XML => LibXML, that probably
best anyway. I wonder about one thing though, is backward
compatibility best preserved with:
XML = LibXML
or as you have it:
module XML
include L
Since I wanted to time the latest libxml-ruby bindings versus Rexml and
Hpricot, I went looking for pre-written benchmarks.
When using the benchmarks, I realized that libxml's DOM traversal api
was awful. Two main issues:
* node.each would stop at text nodes, thus giving back incorrect resul
(Sorry if this double posts, my email version didn't seem to get
thru.)
On Jul 15, 3:26 pm, Charlie Savage <[EMAIL PROTECTED]> wrote:
> Its a clever idea. But I'm not convinced because I really don't like the
> extra include. Why exactly would I want to mixin libxml into my own classes
> or modu
It strikes me as a bit funny that "good practice" seems cleaver :-)
Hah, it all in they eyes of the beholder I suppose.
Um, are you really tied to this idea? Going through and changing everything
again sounds really uninteresting.
Please?
Ok done. And for libxslt-ruby.
I'm going to cut a
I've just uploaded libxml-ruby 0.8.0 to RubyForge.
Changes include:
* Fixed bug in returning attributes from XPath results
* Fixed DOM traversal methods
* Changed Node#children to return an array of nodes
* Fixed bug in returning attributes from XPath results
* Refactored XPath support, prov
I've just uploaded libxml-ruby 0.8.0 to RubyForge.
Changes include:
* Fix memory errors when reusing a stylehseet
* Added support for setting xsl::param values
* Updated RDocs.
* Moved to LibXSLT namespace
So give it a whirl.
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_
Hi Trans,
Don't forget to update the RDocs for libxml-ruby (or I can do it if you
give me permissions).
Thanks,
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge
2008/7/15 Charlie Savage <[EMAIL PROTECTED]>:
>
>
>> On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <[EMAIL PROTECTED]>
>> wrote:
>
> But since you went ahead with swapping XML => LibXML, that probably
> best anyway. I wonder about one thing though, is backward
> compatibility be
A couple benchmarks for fun. These are checked in under the benchmarks
directory
1. http://depixelate.com/2008/4/23/ruby-xml-parsing-benchmarks
user system totalreal
libxml0.032000 0.00 0.032000 ( 0.031000)
Hpricot 0.64 0.031000 0.671000 (
13 matches
Mail list logo
