From cfis at savagexi.com  Tue Jul  1 02:23:45 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 01 Jul 2008 00:23:45 -0600
Subject: [libxml-devel] Validating xml in a string
In-Reply-To: <cfcae284-8989-4733-b55a-bb45f4382424@79g2000hsk.googlegroups.com>
References: <ff92d6540804220306j37da47c4j2d8a8b2c8fb2b511@mail.gmail.com>
	<DB4D8ED9-062B-4DAC-BE16-78D84C75BF63@octopod.info>
	<cfcae284-8989-4733-b55a-bb45f4382424@79g2000hsk.googlegroups.com>
Message-ID: <4869CD71.3010407@savagexi.com>

> I have the same problem as dwTwiLighT, even, when i use parse method
> before.
=

>>> I want to check if xml received by my application (made with RoR and
>>> libxml-ruby) via POST request is well-formed.
>>> This is the source code of that part:
>>>        p = XML::Parser.new
>>>        p.string = params[:xml]
>>>        if p.context.well_formed?
>>>          doc = p.parse


Despite the documentation, its actually p.parser_context and not 
p.context.  I've updated the svn code to go with parser.context for the 
next release.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080701/39b369c9/attachment.bin>

From cfis at savagexi.com  Tue Jul  1 03:07:42 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 01 Jul 2008 01:07:42 -0600
Subject: [libxml-devel] patch for memory leak
In-Reply-To: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>
Message-ID: <4869D7BE.1020706@savagexi.com>

Hi Tom,


> I found a memory leak when the value of an attribute is accessed.  Fix 
> is simple, in function ruby_xml_attr_value in ruby_xml_attr.c, need to 
> call xmlFree:
> 
> 356,357c356,360
> 
> <     if (value != NULL)
> 
> <       return(rb_str_new2((const char*)value));
> 
> ---
> 
>>     if (value != NULL) {
> 
>>       VALUE retVal = rb_str_new2((const char*)value);
> 
>>       xmlFree(value);
> 
>>       return(retVal);
> 

Thanks for the patch.  I've applied it, and found about 6 other places 
similar issues were happening.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080701/6753ed8a/attachment-0001.bin>

From cfis at savagexi.com  Tue Jul  1 03:19:13 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 01 Jul 2008 01:19:13 -0600
Subject: [libxml-devel] parsing document containing doctype with
 saxparser causes null pointer given
In-Reply-To: <a642a0b3-d931-48ac-bee5-8c778dc8df72@e39g2000hsf.googlegroups.com>
References: <a642a0b3-d931-48ac-bee5-8c778dc8df72@e39g2000hsf.googlegroups.com>
Message-ID: <4869DA71.4050102@savagexi.com>

> Wenn i try to parse a Document that has a doctype declaration with the
> saxparser i get the following message:
> 
> /Library/Ruby/Gems/1.8/gems/rails-2.0.2/lib/commands/runner.rb:45:
> (eval):95:in `parse': NULL pointer given (ArgumentError)
> 	from (eval):95
> 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `eval'
> 	from /Library/Ruby/Gems/1.8/gems/rails-2.0.2/lib/commands/runner.rb:
> 45
> 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
> 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in
> `require'
> 	from ../../../script/runner:3
> 
> This is the document (inner contents removed)
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE ONIXmessage SYSTEM "http://www.editeur.org/onix/2.1/short/
> onix-international.dtd">
> <ONIXmessage release="2.1">
> </ONIXmessage>

This seems to work for me.  My test:


   xp = XML::SaxParser.new
   xp.string = <<-EOS
       <?xml version="1.0" encoding="UTF-8"?>
   	  <!DOCTYPE ONIXmessage SYSTEM 
"http://www.editeur.org/onix/2.1/short/onix-international.dtd">
       <ONIXmessage release="2.1">
	    </ONIXmessage>
     EOS
   xp.parse

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080701/6609cb02/attachment.bin>

From tbagby at kosmix.com  Wed Jul  2 15:04:18 2008
From: tbagby at kosmix.com (Tom Bagby)
Date: Wed, 2 Jul 2008 12:04:18 -0700
Subject: [libxml-devel] patch for memory leak
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>
	<4869D7BE.1020706@savagexi.com>
Message-ID: <A1BEF2BA31861B47890617C4349A678102863279@corp0.corp.kosmix.com>

I also found a bunch of similar leaks, plus one different kind which was leaking on every xpath find.  I communicated once with Dan Janowski and sent him this set of patches, then never heard back from him again, so not sure what happened.  Here are the leaks I fixed, if you have others, please make a diff and post them!  I could really use it!

-----Original Message-----
From: libxml-devel-bounces at rubyforge.org on behalf of Charlie Savage
Sent: Tue 7/1/2008 12:07 AM
To: libxml-devel at rubyforge.org
Subject: Re: [libxml-devel] patch for memory leak
 
Hi Tom,


> I found a memory leak when the value of an attribute is accessed.  Fix 
> is simple, in function ruby_xml_attr_value in ruby_xml_attr.c, need to 
> call xmlFree:
> 
> 356,357c356,360
> 
> <     if (value != NULL)
> 
> <       return(rb_str_new2((const char*)value));
> 
> ---
> 
>>     if (value != NULL) {
> 
>>       VALUE retVal = rb_str_new2((const char*)value);
> 
>>       xmlFree(value);
> 
>>       return(retVal);
> 

Thanks for the patch.  I've applied it, and found about 6 other places 
similar issues were happening.

Charlie



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5841 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080702/d29d5f36/attachment.bin>

From tbagby at kosmix.com  Wed Jul  2 15:13:14 2008
From: tbagby at kosmix.com (Tom Bagby)
Date: Wed, 2 Jul 2008 12:13:14 -0700
Subject: [libxml-devel] patch for memory leak
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>
	<4869D7BE.1020706@savagexi.com>
Message-ID: <A1BEF2BA31861B47890617C4349A67810286327A@corp0.corp.kosmix.com>

When you posted that you had applied the patch, I updated and nothing came down so I was confused.  I see that you have been very busy, awesome!  Anyway, some of those patches that I just sent are still applicable.

Should it be possible to build the gem on Windows with VC6 with what's checked into svn now?

Thanks so much,
Tom


-----Original Message-----
From: libxml-devel-bounces at rubyforge.org on behalf of Charlie Savage
Sent: Tue 7/1/2008 12:07 AM
To: libxml-devel at rubyforge.org
Subject: Re: [libxml-devel] patch for memory leak
 
Hi Tom,


> I found a memory leak when the value of an attribute is accessed.  Fix 
> is simple, in function ruby_xml_attr_value in ruby_xml_attr.c, need to 
> call xmlFree:
> 
> 356,357c356,360
> 
> <     if (value != NULL)
> 
> <       return(rb_str_new2((const char*)value));
> 
> ---
> 
>>     if (value != NULL) {
> 
>>       VALUE retVal = rb_str_new2((const char*)value);
> 
>>       xmlFree(value);
> 
>>       return(retVal);
> 

Thanks for the patch.  I've applied it, and found about 6 other places 
similar issues were happening.

Charlie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3109 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080702/167117d9/attachment.bin>

From cfis at savagexi.com  Wed Jul  2 18:25:52 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 02 Jul 2008 16:25:52 -0600
Subject: [libxml-devel] patch for memory leak
In-Reply-To: <A1BEF2BA31861B47890617C4349A67810286327A@corp0.corp.kosmix.com>
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>	<4869D7BE.1020706@savagexi.com>
	<A1BEF2BA31861B47890617C4349A67810286327A@corp0.corp.kosmix.com>
Message-ID: <486C0070.1080908@savagexi.com>

Hi Tom,

Tom Bagby wrote:
> When you posted that you had applied the patch, I updated and nothing came down so I was confused.  I see that you have been very busy, awesome!  Anyway, some of those patches that I just sent are still applicable.

SVN is updated but I haven't wrapped up a new gem yet.  More about that 
in an upcoming email.

> 
> Should it be possible to build the gem on Windows with VC6 with what's checked into svn now?

Yes.  There is a VC2005 project already, if you have that installed. 
I'll also add a precompiled Windows Gem.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080702/574451bd/attachment-0001.bin>

From cfis at savagexi.com  Wed Jul  2 18:27:08 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 02 Jul 2008 16:27:08 -0600
Subject: [libxml-devel] patch for memory leak
In-Reply-To: <A1BEF2BA31861B47890617C4349A678102863279@corp0.corp.kosmix.com>
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>	<4869D7BE.1020706@savagexi.com>
	<A1BEF2BA31861B47890617C4349A678102863279@corp0.corp.kosmix.com>
Message-ID: <486C00BC.3020706@savagexi.com>

Hi Tom,

> I also found a bunch of similar leaks, plus one different kind which was leaking on every xpath find.  I communicated once with Dan Janowski and sent him this set of patches, then never heard back from him again, so not sure what happened.  Here are the leaks I fixed, if you have others, please make a diff and post them!  I could really use it!

Do you just want to be added as a committer?  I don't actually have the 
rights to do that, but I'm sure Dan or trans could do it.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080702/4ded1bfa/attachment.bin>

From sean at chittenden.org  Wed Jul  2 21:18:30 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 2 Jul 2008 18:18:30 -0700
Subject: [libxml-devel] patch for memory leak
In-Reply-To: <486C00BC.3020706@savagexi.com>
References: <A1BEF2BA31861B47890617C4349A678102804148@corp0.corp.kosmix.com>	<4869D7BE.1020706@savagexi.com>
	<A1BEF2BA31861B47890617C4349A678102863279@corp0.corp.kosmix.com>
	<486C00BC.3020706@savagexi.com>
Message-ID: <E14B98B0-4D82-4A98-A633-641E5EC1AFE9@chittenden.org>

>> I also found a bunch of similar leaks, plus one different kind  
>> which was leaking on every xpath find.  I communicated once with  
>> Dan Janowski and sent him this set of patches, then never heard  
>> back from him again, so not sure what happened.  Here are the leaks  
>> I fixed, if you have others, please make a diff and post them!  I  
>> could really use it!
>
> Do you just want to be added as a committer?  I don't actually have  
> the rights to do that, but I'm sure Dan or trans could do it.


Off list, send me your sf.net login information and I'll add you to  
the ranks.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul  2 22:25:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 02 Jul 2008 20:25:29 -0600
Subject: [libxml-devel] Pushing libxml forward - a new 0.6.0 release
Message-ID: <486C3899.8020106@savagexi.com>

libxml-devel at rubyforge.org

Hi everyone,

As you might have guessed by the recent email traffic, I've dived into 
the libxml (and libxslt) ruby bindings since I need them MapBuzz.

Thanks to Sean for developing the bindings and Dan for reworking the 
memory model.  From what I can tell, the library is actually is pretty 
good shape, there just a few little gotchas left that people are running 
into.

So to get things moving again, I took the liberty to push out a new 
release of libxml-ruby, 0.6.0.  It fixes a number of memory issues and 
adds Windows support.  I am sure there are still remaining memory 
issues.  If everyone can update their gems and reports any bugs they run 
into, I'll give it a try and fixing them.

I also have a new version of libxslt-ruby, but first need commit rights 
to push a release.

Thanks,

Charlie

----------
Changes:

* Fixed memory allocation errors in Windows.  On Windows, it is 
essential that the same library that allocates memory must free it. 
Thus ALLOC calls must be matched to ruby_xfree calls, which they were 
not.  In addition, in one case Ruby was allocating memory to be freed by 
libxml.  On Windows, that's a segmentation fault.  On Linux it might 
fly, but still seems like a bad idea.

* Fixed segmentation fault in xml reader expand (same xml tree freed twice)

* Applied a number of patches from Tom Bagby, including fixes for xpath 
segmentation faults and fixes for various memory leaks

* Cleaned up a number of compiler warnings

* Renamed libxml_so.so to libxml_ruby.so (same for xslt).  That wasn't 
actually my original intention, but um, it kind of sort of happened.  It 
should not be noticeable from an end-user perspective.

* Added rake files for building with MingW

* Added rake files for packing gems.  Note that I did this outside the 
existing rake tasks because I didn't see how they were actually building 
the gems.

* Cleaned up the tests and added a few more based on bug reports from 
the Tracker and mailing list.

* Cleaned out the patch queue and went through about 1/2 the bug list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080702/51993172/attachment.bin>

From transfire at gmail.com  Thu Jul  3 13:10:02 2008
From: transfire at gmail.com (Trans)
Date: Thu, 3 Jul 2008 10:10:02 -0700 (PDT)
Subject: [libxml-devel] Back
Message-ID: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>

Hi all,

Sorry I've been out of the loop for a bit. I've been working on some
other projects.

I just emailed Charlie about working with him to get a new release
out. How do we want to handle this? Should we tag the current version
and allow the patches on trunk? Or create a branch and apply the
patches there first?

Before we do that though I was wondering what others thought about of
switching to Git?

T.

From cfis at savagexi.com  Thu Jul  3 13:15:58 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 03 Jul 2008 11:15:58 -0600
Subject: [libxml-devel] Back
In-Reply-To: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
Message-ID: <486D094E.5010506@savagexi.com>

Hi Trans,

> Sorry I've been out of the loop for a bit. I've been working on some
> other projects.
> 
> I just emailed Charlie about working with him to get a new release
> out. How do we want to handle this? Should we tag the current version
> and allow the patches on trunk? Or create a branch and apply the
> patches there first?

Yeah, I was bad, and didn't tag the release in SVN.  I can go back and 
do that, it would be a good idea.

There is going to have to be a 0.6.1 release fairly soon.  The 
extconf.rb file in 0.6.0 doesn't work for Linux in some cases. The issue 
is the find_library call was incorrect (I didn't go back and look when 
that happened, but it was prior to 0.6.0 release).  I've checked in a 
fix to SVN.  Also Tom provided me another couple of patches.

> 
> Before we do that though I was wondering what others thought about of
> switching to Git?

Well, I know git is the new cool think in town.  But I'm on Windows, and 
love TortoiseSvn, so I don't have any motivation to move to git (lousy 
windows support and no gui).  I suppose it was easy to have some git/svn 
integration thing or some such I could be ok, but just seems like extra 
work to me for little benefit (its not like there are very many 
committers anyway).

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080703/af87b784/attachment.bin>

From transfire at gmail.com  Thu Jul  3 13:45:31 2008
From: transfire at gmail.com (Trans)
Date: Thu, 3 Jul 2008 10:45:31 -0700 (PDT)
Subject: [libxml-devel] Back
In-Reply-To: <486D094E.5010506@savagexi.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
Message-ID: <4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>



On Jul 3, 1:15?pm, Charlie Savage <c... at savagexi.com> wrote:
> Hi Trans,
>
> > Sorry I've been out of the loop for a bit. I've been working on some
> > other projects.
>
> > I just emailed Charlie about working with him to get a new release
> > out. How do we want to handle this? Should we tag the current version
> > and allow the patches on trunk? Or create a branch and apply the
> > patches there first?
>
> Yeah, I was bad, and didn't tag the release in SVN. ?I can go back and
> do that, it would be a good idea.

Ah, Sean already gave you commit rights. Sorry, I didn't notice.

If you can go back a tag the prior release, that would be good, but
since you already committed there no reason to make a big fuss about
it (as long as everything is still working! ;) We can just move
forward from here.

> There is going to have to be a 0.6.1 release fairly soon. ?The
> extconf.rb file in 0.6.0 doesn't work for Linux in some cases. The issue
> is the find_library call was incorrect (I didn't go back and look when
> that happened, but it was prior to 0.6.0 release). ?I've checked in a
> fix to SVN. ?Also Tom provided me another couple of patches.

Hmmm... was it a Windows thing? It seemed to be working before.

> > Before we do that though I was wondering what others thought about of
> > switching to Git?
>
> Well, I know git is the new cool think in town. ?But I'm on Windows, and
> love TortoiseSvn, so I don't have any motivation to move to git (lousy
> windows support and no gui). ?I suppose it was easy to have some git/svn
> integration thing or some such I could be ok, but just seems like extra
> work to me for little benefit (its not like there are very many
> committers anyway).

That's fine. I'm basically neutral on the issue for now. I think it's
beyond the "new cool thing" at this point. It's the way the tide is
headed. But there is certainly is no rush.

T.

From sean at chittenden.org  Thu Jul  3 14:01:59 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 3 Jul 2008 11:01:59 -0700
Subject: [libxml-devel] Back
In-Reply-To: <4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
Message-ID: <65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>

>>> Before we do that though I was wondering what others thought about  
>>> of
>>> switching to Git?
>>
>> Well, I know git is the new cool think in town.  But I'm on  
>> Windows, and
>> love TortoiseSvn, so I don't have any motivation to move to git  
>> (lousy
>> windows support and no gui).  I suppose it was easy to have some  
>> git/svn
>> integration thing or some such I could be ok, but just seems like  
>> extra
>> work to me for little benefit (its not like there are very many
>> committers anyway).
>
> That's fine. I'm basically neutral on the issue for now. I think it's
> beyond the "new cool thing" at this point. It's the way the tide is
> headed. But there is certainly is no rush.

git is demon spawn - don't get sucked into the ill-thought-out fad.   
Mercurial, imho, is a better way to go and I would be a big proponent  
of migrating to mercurial if support was available for it on rubyforge  
(*sends an email asking if/when*).  -sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Thu Jul  3 14:52:05 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 3 Jul 2008 11:52:05 -0700
Subject: [libxml-devel] Pushing libxml forward - a new 0.6.0 release
In-Reply-To: <486C3899.8020106@savagexi.com>
References: <486C3899.8020106@savagexi.com>
Message-ID: <231C4076-06A0-4017-90B6-A7C6E79A1362@chittenden.org>

> As you might have guessed by the recent email traffic, I've dived  
> into the libxml (and libxslt) ruby bindings since I need them MapBuzz.

Charlie/MapBuzz FTW!  Economic incentive == progress.  Glad to hear  
you've been able to knock out these bugs.  :~]

-sc

--
Sean Chittenden
sean at chittenden.org




From noreply at rubyforge.org  Tue Jul  1 03:21:31 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 03:21:31 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-20117 ] Segfault when using
	XML::Reader.expand
Message-ID: <20080701072131.BC35018585A3@rubyforge.org>

Bugs item #20117, was opened at 2008-05-13 05:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=20117&group_id=494

Category: memory
Group: v0.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Gabriel Ebner (gebner)
>Assigned to: Charlie Savage (cfis)
Summary: Segfault when using XML::Reader.expand

Initial Comment:
The following program segfaults under libxml-ruby 0.5.4 (gem) and ruby 1.8.6 (debian sid / amd64):


require 'rubygems'
require 'xml/libxml'

reader = XML::Reader.new '<a><b/></a>'

2.times do reader.read end
reader.expand if reader.name == 'b'


(gdb) run bug.rb 
Starting program: /usr/bin/ruby bug.rb
[Thread debugging using libthread_db enabled]
[New Thread 0x7f81f824b6e0 (LWP 1298)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f81f824b6e0 (LWP 1298)]
classname (klass=257) at variable.c:150
150     variable.c: No such file or directory.
        in variable.c
(gdb) bt
#0  classname (klass=257) at variable.c:150
#1  0x00007f81f7e0094d in rb_class_path (klass=257) at variable.c:190
#2  0x00007f81f7e00a99 in rb_class2name (klass=257) at variable.c:301
#3  0x00007f81f7d8a13a in rb_check_type (x=257, t=34) at error.c:276
#4  0x00007f81f69f59b8 in ruby_xml_node_deregisterNode (node=0x24f6ba0) at ruby_xml_node.c:2264
#5  0x00007f81f676fe3a in xmlTextReaderFreeDoc (reader=0x2510ee0, cur=0x24f6ba0) at xmlreader.c:482
#6  0x00007f81f677046d in xmlFreeTextReader__internal_alias (reader=0x2510ee0) at xmlreader.c:2195
#7  0x00007f81f7daac81 in rb_gc_call_finalizer_at_exit () at gc.c:1928
#8  0x00007f81f7d90293 in ruby_finalize_1 () at eval.c:1553
#9  0x00007f81f7d98e51 in ruby_cleanup (ex=0) at eval.c:1590
#10 0x00007f81f7d98f69 in ruby_stop (ex=257) at eval.c:1645
#11 0x00007f81f7da46ff in ruby_run () at eval.c:1666
#12 0x0000000000400883 in main (argc=2, argv=0x7fff002691e8, envp=<value optimized out>) at main.c:48
(gdb) 


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 01:21

Message:
Hi Gabriel,

Yes exactly.  Fix is checked in.

Charlie

----------------------------------------------------------------------

Comment By: Gabriel Ebner (gebner)
Date: 2008-05-13 06:11

Message:
I think I have found the problem.  The xmlTextReader usually
deletes the old node when you call xmlTextReaderRead.  This
is why we're getting segfaults when freeing the node.

You can prevent this deletion by calling
xmlTextReaderPreserve, but this will still cause double
frees on the document.

But you can prevent this too by calling
xmlTextReaderCurrentDoc, which will incidentially prevent
the document from being freed automatically.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=20117&group_id=494

From noreply at rubyforge.org  Tue Jul  1 03:21:41 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 03:21:41 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-20117 ] Segfault when using
	XML::Reader.expand
Message-ID: <20080701072141.26F6415B801A@rubyforge.org>

Bugs item #20117, was opened at 2008-05-13 05:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=20117&group_id=494

Category: memory
Group: v0.5
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Gabriel Ebner (gebner)
Assigned to: Charlie Savage (cfis)
Summary: Segfault when using XML::Reader.expand

Initial Comment:
The following program segfaults under libxml-ruby 0.5.4 (gem) and ruby 1.8.6 (debian sid / amd64):


require 'rubygems'
require 'xml/libxml'

reader = XML::Reader.new '<a><b/></a>'

2.times do reader.read end
reader.expand if reader.name == 'b'


(gdb) run bug.rb 
Starting program: /usr/bin/ruby bug.rb
[Thread debugging using libthread_db enabled]
[New Thread 0x7f81f824b6e0 (LWP 1298)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f81f824b6e0 (LWP 1298)]
classname (klass=257) at variable.c:150
150     variable.c: No such file or directory.
        in variable.c
(gdb) bt
#0  classname (klass=257) at variable.c:150
#1  0x00007f81f7e0094d in rb_class_path (klass=257) at variable.c:190
#2  0x00007f81f7e00a99 in rb_class2name (klass=257) at variable.c:301
#3  0x00007f81f7d8a13a in rb_check_type (x=257, t=34) at error.c:276
#4  0x00007f81f69f59b8 in ruby_xml_node_deregisterNode (node=0x24f6ba0) at ruby_xml_node.c:2264
#5  0x00007f81f676fe3a in xmlTextReaderFreeDoc (reader=0x2510ee0, cur=0x24f6ba0) at xmlreader.c:482
#6  0x00007f81f677046d in xmlFreeTextReader__internal_alias (reader=0x2510ee0) at xmlreader.c:2195
#7  0x00007f81f7daac81 in rb_gc_call_finalizer_at_exit () at gc.c:1928
#8  0x00007f81f7d90293 in ruby_finalize_1 () at eval.c:1553
#9  0x00007f81f7d98e51 in ruby_cleanup (ex=0) at eval.c:1590
#10 0x00007f81f7d98f69 in ruby_stop (ex=257) at eval.c:1645
#11 0x00007f81f7da46ff in ruby_run () at eval.c:1666
#12 0x0000000000400883 in main (argc=2, argv=0x7fff002691e8, envp=<value optimized out>) at main.c:48
(gdb) 


----------------------------------------------------------------------

Comment By: Charlie Savage (cfis)
Date: 2008-07-01 01:21

Message:
Hi Gabriel,

Yes exactly.  Fix is checked in.

Charlie

----------------------------------------------------------------------

Comment By: Gabriel Ebner (gebner)
Date: 2008-05-13 06:11

Message:
I think I have found the problem.  The xmlTextReader usually
deletes the old node when you call xmlTextReaderRead.  This
is why we're getting segfaults when freeing the node.

You can prevent this deletion by calling
xmlTextReaderPreserve, but this will still cause double
frees on the document.

But you can prevent this too by calling
xmlTextReaderCurrentDoc, which will incidentially prevent
the document from being freed automatically.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=20117&group_id=494

From noreply at rubyforge.org  Tue Jul  1 03:24:57 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 03:24:57 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19738 ] malloc errors in libxml
Message-ID: <20080701072458.103B518585A3@rubyforge.org>

Bugs item #19738, was opened at 2008-04-23 18:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19738&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: malloc errors in libxml

Initial Comment:
I'm sure you folks already know about this, but I'm getting errors like this when using the current version of LibXML:

ruby(309) malloc: *** error for object 0x4fcf30: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
ruby(309) malloc: *** set a breakpoint in szone_error to debug
ruby(309) malloc: *** error for object 0x4bb5d0: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
ruby(309) malloc: *** set a breakpoint in szone_error to debug

I have not noticed that this is causing any incorrect output, however...

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 01:24

Message:
Could you provide a test case?  Also what operating system?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19738&group_id=494

From noreply at rubyforge.org  Tue Jul  1 03:53:29 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 03:53:29 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19259 ] Calling remove! on a node
	causes memory leaks.
Message-ID: <20080701075329.A34DE18585A7@rubyforge.org>

Bugs item #19259, was opened at 2008-04-02 00:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19259&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Joe Khoobyar (walltndr)
>Assigned to: Charlie Savage (cfis)
Summary: Calling remove! on a node causes memory leaks.

Initial Comment:
Nodes w/o a parent (i.e., due to calling remove!) will never be garbage collected because of a (typo?) mistaken &&
instead of || when checking the parent and the doc for NULL.  Calling remove! never sets the doc to NULL.  In fact,
you'd be hard pressed to find anywhere in libxml2 or libxml-ruby where the doc pointer is explicitly set to NULL.

See patch #19257 for the easy solution.

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 01:53

Message:
Applied - thanks Joe.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19259&group_id=494

From noreply at rubyforge.org  Tue Jul  1 04:45:03 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 04:45:03 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19258 ] Attribute nodes can be freed()
	twice.
Message-ID: <20080701084503.A497518585A3@rubyforge.org>

Bugs item #19258, was opened at 2008-04-02 00:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19258&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Joe Khoobyar (walltndr)
>Assigned to: Charlie Savage (cfis)
Summary: Attribute nodes can be freed() twice.

Initial Comment:
If an attribute node is already wrapped, and then is removed from the parent (i.e., by setting it to nil via the []= method), it will eventually get freed twice.  This is because xmlRemoveProp() always frees the node memory.  In these cases xmlUnlinkNode() must be called instead.

See patch 19256 for details, and the addition of a remove! method to XML::Attr

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 02:45

Message:
Patch applied - thanks Joe.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19258&group_id=494

From noreply at rubyforge.org  Tue Jul  1 04:46:14 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 04:46:14 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19242 ] xpath causes GC crash
Message-ID: <20080701084614.EC9F818585A3@rubyforge.org>

Bugs item #19242, was opened at 2008-04-01 15:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19242&group_id=494

Category: memory
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: xpath causes GC crash

Initial Comment:
Well, I debugged this one, but I don't know how to fix it right. The problem is this: in order to free an xpath object, the nodes it references need to be available. But ruby will happily free the document before freeing the xpath objects.

I think some kind of refcount might work, where the last xpath object calls xmlFreeDoc...

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 02:46

Message:
This is hopefully fixed by Joe's patch - so closing it.

----------------------------------------------------------------------

Comment By: Joe Khoobyar (walltndr)
Date: 2008-04-01 22:16

Message:
Oops. :)

I meant patch #19252

----------------------------------------------------------------------

Comment By: Joe Khoobyar (walltndr)
Date: 2008-04-01 22:14

Message:
I have a patch for this that is working fine on both OS X (Leopard) and 64-bit Linux.  See patch #1952

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19242&group_id=494

From noreply at rubyforge.org  Tue Jul  1 04:47:34 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 04:47:34 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19022 ] 0.5.3 Gem fails on Macintosh
	with "LoadError: no such file to load -- libxml_so"
Message-ID: <20080701084734.7046118585A7@rubyforge.org>

Bugs item #19022, was opened at 2008-03-21 17:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19022&group_id=494

Category: General
Group: v0.5
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Paul Legato (plegato)
>Assigned to: Charlie Savage (cfis)
>Summary: 0.5.3 Gem fails on Macintosh with "LoadError: no such file to load -- libxml_so"

Initial Comment:
Attempting to load gem version 0.5.3 fails on my Mac with the following:

LoadError: no such file to load -- libxml_so
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/libxml-ruby-0.5.3/lib/libxml.rb:4
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require'
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/libxml-ruby-0.5.3/lib/xml/libxml.rb:4


(Mac OS doesn't use .so files.)

It works fine if I uninstall the 0.5.3 gem and force-revert to 0.5.2.0.

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 02:47

Message:
So I've changed libxml to use libxml.so to be more consistent with other gems.  I'm going to close this for now - please reopen if you still have issues with the next release.

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2008-04-06 16:38

Message:
Please see the mailing list:

http://groups.google.com/group/libxml-devel/browse_thread/thread/9c1b4b2dfb2c83e9?hl=en#

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19022&group_id=494

From noreply at rubyforge.org  Tue Jul  1 04:55:16 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 04:55:16 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-17885 ] Calling parse() twice causes
	segfault
Message-ID: <20080701085516.4A47E18585B1@rubyforge.org>

Bugs item #17885, was opened at 2008-02-07 20:08
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=17885&group_id=494

Category: General
Group: v0.5
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Saurabh Nanda (saurabhnanda)
>Assigned to: Charlie Savage (cfis)
Summary: Calling parse() twice causes segfault

Initial Comment:
The following snipped of code is guaranteed to segfault:

require 'xml/libxml'
x=XML::Parser.string("<test>something</test>")
doc=x.parse
x.parse

If you run it using ruby on the command line it segfaults immediately, for eg.

$ ruby /tmp/segfault.rb

Or, if you copy paste it in irb, it segfaults as soon as you try to _exit_ irb.


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 02:55

Message:
This must be fixed.

class TC_XML_Parser2 < Test::Unit::TestCase
  def test_double_parse
    parser = XML::Parser.string("<test>something</test>")
    doc = parser.parse
    parser.parse
  end
end

Result:

  1) Error:
test_double_parse(TC_XML_Parser2):
XML::Parser::ParseError: Document didn't parse
    C:\Development\msys\src\rlibxml\test\tc_xml_parser9.rb:8:in `parse'
    C:\Development\msys\src\rlibxml\test\tc_xml_parser9.rb:8:in `test_double_parse'

1 tests, 0 assertions, 0 failures, 1 errors
Entity: line 1: parser error : Document is empty
<test>something</test>
                      ^

Program exited with code 1



Seems like reasonable behavior to me.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=17885&group_id=494

From noreply at rubyforge.org  Tue Jul  1 05:05:06 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 05:05:06 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-16214 ] SEGV when add the
	cloned/copied node
Message-ID: <20080701090506.A15CE18585A0@rubyforge.org>

Bugs item #16214, was opened at 2007-12-10 08:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=16214&group_id=494

Category: memory
Group: v0.5
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Dan Janowski (danj)
>Assigned to: Charlie Savage (cfis)
Summary: SEGV when add the cloned/copied node

Initial Comment:
Originally appeared on mail list by optyk (2007-11-27).

segv appears when use clone and copy methods,
what's interesting, with clone segv is thrown in div1.child_add(c)
line (see script)
but when use copy I get it in printf root statement, moreover copy
seems to work wrong only for text nodes, when use 't3' div everything
works fine

I get this error on 0.5.2.0, 0.5.2.1 and 0.5.2.2 (latest svn) version

it looks like fix is required in ruby-libxml code,

BTW. it looks also like ruby_xml_node_copy() in ruby_xml_node.c calls
xmlCopyNode() with wrong attributes, it should be 2 for shallow copy
and 1 for deep copy

-------------------- SCRIPT ---------------------
require 'xml/libxml'

str = <<-STR
<html>
   <body>
       <div class="textarea" id="t1"
style="STATIC">werwerwerwerwer                 </div>
       <div class="textarea" id="t2" style="STATIC">
           Quisque et diam dapibus nisi bibendum blandit.
       </div>
       <div class="textarea" id="t3" style="STATIC">
           <p>aaaaaaaaa</p>
       </div>
   </body>
</html>
STR


XML::Parser.default_keep_blanks = false
xp = XML::Parser.new
xp.string = str
doc = xp.parse

xpath = "//div[@id='t1']"
div1 = doc.find(xpath).to_a[0]
printf "xxx div1: #{div1}\n"

xpath = "//div[@id='t2']"
div2 = doc.find(xpath).to_a[0]
printf "xxx div2: #{div2}\n"


div2.each do |child|
   #c = child.clone
   c = child.copy(false)
   div1.child_add(c)
end

printf "xxx root: #{doc.root}\n"


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 03:05

Message:
Dan - this seems to work fine now, I imagine due to your changes.  I added it as a test case, and am now closing.

----------------------------------------------------------------------

Comment By: Dan Janowski (danj)
Date: 2007-12-10 08:37

Message:
keisuke fukuda submitted a patch for this problem which I have carefully examined. The given patcch fixes the problem by creating an unintended consequence, by always copying text nodes. However, the real cause of the problem is more subtle and has to do with merging of text nodes when the parent node already has an associated text node. Since we cannot have a text node that is mapped into ruby simply disappear, they do always need to be copied. However, a few additional conditions needed to be handled.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=16214&group_id=494

From noreply at rubyforge.org  Tue Jul  1 05:09:33 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 05:09:33 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-7018 ] Parsing an empty string causes
	Segfault / Bus Error
Message-ID: <20080701090933.BA66118585A0@rubyforge.org>

Bugs item #7018, was opened at 2006-12-02 14:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7018&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: Parsing an empty string causes Segfault / Bus Error

Initial Comment:
Running on Mac OS X with libxml-ruby 0.3.8.4, if you try to parse an empty string you get a segfault.



irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'xml/libxml'
=> true
irb(main):003:0> string = ''
=> ""
irb(main):004:0>       XML::Parser.string(string).parse
(irb):4: [BUG] Bus Error
ruby 1.8.4 (2005-12-24) [i686-darwin8.7.1]

Abort trap

Expected behaviour would be simlar to what a single space character gets:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'xml/libxml'
=> true
irb(main):003:0> string = ' '
=> " "
irb(main):004:0> XML::Parser.string(string).parse
Entity: line 1: parser error : Start tag expected, '<' not found
 
 ^
XML::Parser::ParseError: Document didn't parse
        from (irb):4:in `parse'
        from (irb):4
irb(main):005:0> 




----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 03:09

Message:
This now returns an error instead of segfaulting.

----------------------------------------------------------------------

Comment By: Saurabh Nanda (saurabhnanda)
Date: 2008-02-05 07:13

Message:
I see there's a patch submitted for this already. Has this been applied? I'm running libxml-ruby-0.5.2 and still facing this issue.

----------------------------------------------------------------------

Comment By: Todd Fisher (taf2)
Date: 2006-12-17 06:49

Message:
Here's a patch and test.  ctxt is null in the case of nil input...

Index: ext/xml/ruby_xml_parser.c
===================================================================
RCS file: /var/cvs/libxml/libxml/ext/xml/ruby_xml_parser.c,v
retrieving revision 1.5
diff -u -r1.5 ruby_xml_parser.c
--- ext/xml/ruby_xml_parser.c   20 Nov 2006 01:22:07 -0000      1.5
+++ ext/xml/ruby_xml_parser.c   17 Dec 2006 13:45:04 -0000
@@ -1123,7 +1123,9 @@
   case RUBY_LIBXML_SRC_TYPE_IO:
     Data_Get_Struct(rxp->ctxt, ruby_xml_parser_context, rxpc);
     if (xmlParseDocument(rxpc->ctxt) == -1) {
-      xmlFreeDoc(rxpc->ctxt->myDoc);
+      if (rxpc->ctxt && rxpc->ctxt->myDoc) {
+        xmlFreeDoc(rxpc->ctxt->myDoc);
+      }
       rb_raise(eXMLParserParseError, "Document didn't parse");
     }




require "libxml_test"
require 'test/unit'

class EmptyString < Test::Unit::TestCase
  def test_parse_empty_string
    begin
    string = ''
    XML::Parser.string(string).parse
    rescue => e
      assert e, "Document didn't parse"
    end
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7018&group_id=494

From noreply at rubyforge.org  Tue Jul  1 05:10:59 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 05:10:59 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-9135 ] dup and clone methods cause
	segfaults
Message-ID: <20080701091059.4819018585A0@rubyforge.org>

Bugs item #9135, was opened at 2007-03-08 12:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9135&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Marc Munro (dbdude)
>Assigned to: Charlie Savage (cfis)
Summary: dup and clone methods cause segfaults

Initial Comment:
Here is a session that segfaults:

marc:[xml]$ irb
irb(main):001:0> require "xml/libxml"
=> true
irb(main):002:0> x = XML::Node.new('wibble')
=> <wibble/>
irb(main):003:0> y = x.clone
/usr/lib/ruby/1.8/irb.rb:298: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i486-linux]

Aborted
marc:[xml]$


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 03:10

Message:
This now works as expected.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9135&group_id=494

From noreply at rubyforge.org  Tue Jul  1 05:11:35 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 05:11:35 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-8501 ] Building on Windows
Message-ID: <20080701091135.9314518585A7@rubyforge.org>

Bugs item #8501, was opened at 2007-02-08 02:31
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8501&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Charlie Savage (cfis)
>Assigned to: Charlie Savage (cfis)
Summary: Building on Windows

Initial Comment:
First, the bindings don't build using VC++2005 on windows.  Attached is a patch that fixes the problem.  Also, it correctly exports the Init_libxml_so function from the created DLL.

Second, Init_libxml_so should really be named Init_libxml - that would be standard practice when creating extensions and be more cross-platform compatible.


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 03:11

Message:
Fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8501&group_id=494

From noreply at rubyforge.org  Tue Jul  1 05:16:53 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  1 Jul 2008 05:16:53 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-7622 ] unknown XPath function causes
	SEGV
Message-ID: <20080701091654.159F418585A7@rubyforge.org>

Bugs item #7622, was opened at 2007-01-05 23:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7622&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Kouhei Sutou (kou)
>Assigned to: Charlie Savage (cfis)
Summary: unknown XPath function causes SEGV

Initial Comment:
A sample script:

require 'xml/libxml'
require 'tempfile'

xml = Tempfile.new("xxx")
xml.puts("<a/>")
xml.close

doc = XML::Document.file(xml.path)
begin
  p doc.find("//*[name(.)=normalize_space(' a ')]")
rescue XML::XPath::InvalidPath
  puts $!
  puts $@
end
p doc.find("//*[name(.)=normalize-space(' a ')]")


Result:
xmlXPathCompOpEval: function normalize_space not found
Unregistered function
xmlXPathCompiledEval: 3 objects left on the stack.
Invalid XPath expression for this document
/tmp/a.rb:10:in `find'
/tmp/a.rb:10
*** glibc detected *** corrupted double-linked list: 0xb7e824f8 ***
zsh: abort      ruby /tmp/a.rb

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-01 03:16

Message:
The error message remains the same, but this no longer causes a segfault.  Test case added.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7622&group_id=494

From ginormous at gmail.com  Thu Jul  3 14:53:44 2008
From: ginormous at gmail.com (scollett)
Date: Thu, 3 Jul 2008 11:53:44 -0700
Subject: [libxml-devel] Back
In-Reply-To: <65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
Message-ID: <90b736200807031153w44b3d23ej5301d0f32e633597@mail.gmail.com>

Eventually, some sort of distributed source code management would be
nice. I think it makes sense for open source projects for a lot of
reasons. That being said, I think it is more important to use a SCM
that is compatible with the environment of the current contributors.
The revival of the gem by the contributors has been great. Especially
for those of us that don't have the programming background to make
code contributions to the project (like myself).

-Stephanie

On Thu, Jul 3, 2008 at 11:01 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>>> Before we do that though I was wondering what others thought about of
>>>> switching to Git?
>>>
>>> Well, I know git is the new cool think in town.  But I'm on Windows, and
>>> love TortoiseSvn, so I don't have any motivation to move to git (lousy
>>> windows support and no gui).  I suppose it was easy to have some git/svn
>>> integration thing or some such I could be ok, but just seems like extra
>>> work to me for little benefit (its not like there are very many
>>> committers anyway).
>>
>> That's fine. I'm basically neutral on the issue for now. I think it's
>> beyond the "new cool thing" at this point. It's the way the tide is
>> headed. But there is certainly is no rush.
>
> git is demon spawn - don't get sucked into the ill-thought-out fad.
>  Mercurial, imho, is a better way to go and I would be a big proponent of
> migrating to mercurial if support was available for it on rubyforge (*sends
> an email asking if/when*).  -sc
>
> --
> Sean Chittenden
> sean at chittenden.org
>
>
>
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
>

From sean at chittenden.org  Thu Jul  3 15:14:35 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 3 Jul 2008 12:14:35 -0700
Subject: [libxml-devel] Back
In-Reply-To: <90b736200807031153w44b3d23ej5301d0f32e633597@mail.gmail.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
	<90b736200807031153w44b3d23ej5301d0f32e633597@mail.gmail.com>
Message-ID: <47DE3A4F-DAAE-4BD4-8400-4C44372BDF40@chittenden.org>

> Eventually, some sort of distributed source code management would be
> nice. I think it makes sense for open source projects for a lot of
> reasons. That being said, I think it is more important to use a SCM
> that is compatible with the environment of the current contributors.
> The revival of the gem by the contributors has been great. Especially
> for those of us that don't have the programming background to make
> code contributions to the project (like myself).

FYI, there is an RFE to get mercurial support into rubyforge.

http://rubyforge.org/tracker/index.php?func=detail&aid=12829&group_id=5&atid=104

-sc


*does happy dance*

http://www.youtube.com/watch?v=HZzhmJxJg5Q


--
Sean Chittenden
sean at chittenden.org




From danj at 3skel.com  Thu Jul  3 17:11:28 2008
From: danj at 3skel.com (Dan Janowski)
Date: Thu, 3 Jul 2008 17:11:28 -0400
Subject: [libxml-devel] Back
In-Reply-To: <65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
Message-ID: <9BF5B2E1-EC0E-4B4B-B030-FC753768CF91@3skel.com>


On Jul 3, 2008, at 14:01, Sean Chittenden wrote:

>>>> Before we do that though I was wondering what others thought  
>>>> about of
>>>> switching to Git?
>>>
>>> Well, I know git is the new cool think in town.  But I'm on  
>>> Windows, and
>>> love TortoiseSvn, so I don't have any motivation to move to git  
>>> (lousy
>>> windows support and no gui).  I suppose it was easy to have some  
>>> git/svn
>>> integration thing or some such I could be ok, but just seems like  
>>> extra
>>> work to me for little benefit (its not like there are very many
>>> committers anyway).
>>
>> That's fine. I'm basically neutral on the issue for now. I think it's
>> beyond the "new cool thing" at this point. It's the way the tide is
>> headed. But there is certainly is no rush.
>
> git is demon spawn - don't get sucked into the ill-thought-out fad.   
> Mercurial, imho, is a better way to go and I would be a big  
> proponent of migrating to mercurial if support was available for it  
> on rubyforge (*sends an email asking if/when*).  -sc
>

mercurial is excellent.

From transfire at gmail.com  Thu Jul  3 19:37:00 2008
From: transfire at gmail.com (Trans)
Date: Thu, 3 Jul 2008 16:37:00 -0700 (PDT)
Subject: [libxml-devel] Back
In-Reply-To: <65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
Message-ID: <7fb53c4a-c09c-4b00-89fe-a66c9b893243@c65g2000hsa.googlegroups.com>



On Jul 3, 2:01?pm, Sean Chittenden <s... at chittenden.org> wrote:

> git is demon spawn - don't get sucked into the ill-thought-out fad.

I think that's a bit overstated. From what I understand the primary
difference is the backend storage. Git stores an snapshot and Hg
stores a delta. Perhaps Mackall's design is better overall, but in
practice I'm not sure it makes a huge difference. I've read a number
of Git vs. Hg blogs and I see plenty of arguments going both ways.

The only reason I lean more toward Git is that it seems to the
momentum. I've had always been the kind of guy to go for the superior
tech, you know, but about a year ago I started to realize there's
value in going with the flow sometimes --which is why I switched my
project from Darcs to SVN actually. Ironic though, b/c soon thereafter
many started jumping from SVN to Git.

Anyhow, I don't think it's fair to call Git a fad. But I think Hg is
good choice too.

T.

From ast at atownley.org  Fri Jul  4 03:59:07 2008
From: ast at atownley.org (Andrew S. Townley)
Date: Fri, 04 Jul 2008 08:59:07 +0100
Subject: [libxml-devel] Back
In-Reply-To: <65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<65079E9E-AA4D-4978-AFE4-E1D75A5DE74B@chittenden.org>
Message-ID: <1215158347.7403.57.camel@linna>

On Thu, 2008-07-03 at 11:01 -0700, Sean Chittenden wrote:
> >>> Before we do that though I was wondering what others thought about  
> >>> of
> >>> switching to Git?
> >>
> >> Well, I know git is the new cool think in town.  But I'm on  
> >> Windows, and
> >> love TortoiseSvn, so I don't have any motivation to move to git  
> >> (lousy
> >> windows support and no gui).  I suppose it was easy to have some  
> >> git/svn
> >> integration thing or some such I could be ok, but just seems like  
> >> extra
> >> work to me for little benefit (its not like there are very many
> >> committers anyway).
> >
> > That's fine. I'm basically neutral on the issue for now. I think it's
> > beyond the "new cool thing" at this point. It's the way the tide is
> > headed. But there is certainly is no rush.
> 
> git is demon spawn - don't get sucked into the ill-thought-out fad.   
> Mercurial, imho, is a better way to go and I would be a big proponent  
> of migrating to mercurial if support was available for it on rubyforge  
> (*sends an email asking if/when*).  -sc

Trans,

I think the tide is really towards distributed version control because
it makes more sense for the distributed nature of open source projects.
I haven't used git at all, and I evaluated Mercurial a couple of years
ago, but I personally use bazaar for my VCS needs.  However, none of
these have been widely used enough to get the kind of GUI integration
tool support as things like CVS or SVN -- although tortoiseBZR and
tortoiseHg seem to have made some good strides lately.

I was recently asked about version control systems by a client, but I
had to advise them to go with SVN, simply because of the GUI support on
Windows.  It was their only platform used for development, and the
developers expected a high level of integration with their VCS.

git is interesting, and seems to work well for some people (esp. the
linux kernel developers), but I personally wouldn't yet recommend it for
general projects.  Maybe I just haven't seen convincing enough arguments
beyond "Linus wrote it" and "it's used by the Linux kernel team, X.org
and RoR". ;)

ast
-- 
Andrew S. Townley <ast at atownley.org>
http://atownley.org


From cfis at savagexi.com  Mon Jul  7 02:33:56 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 07 Jul 2008 00:33:56 -0600
Subject: [libxml-devel] Back
In-Reply-To: <4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
Message-ID: <4871B8D4.7050108@savagexi.com>



> If you can go back a tag the prior release, that would be good, but
> since you already committed there no reason to make a big fuss about
> it (as long as everything is still working! ;) We can just move
> forward from here.

Tagged.


Does anyone mind if I clean out the old branches in the repository?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080707/31a91e7a/attachment-0001.bin>

From cfis at savagexi.com  Mon Jul  7 02:54:39 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 07 Jul 2008 00:54:39 -0600
Subject: [libxml-devel] Libxsl 0.6.0 release
Message-ID: <4871BDAF.3090603@savagexi.com>

To go with the new libxml-ruby release, I've pushed up a libxslt-ruby 
release.

It includes two big changes.

* Windows support (both lots of memory fixes and binaries)

* New libxslt.rb ruby wrapper, so programs can simply say:

require 'libxslt'

* For all other platforms, I updated extconf.rb to tell gcc that 
libxslt-ruby depends on libxml-ruby being present.  To do this trick, I 
made a big assumption - that libxml-ruby is installed as a gem.  I did 
this because I couldn't figure out any other way to reliably determine 
where the libxml-ruby header files were on disk.  What do people think o 
of this?


Last, the project name on rubyforge is libxsl which is incorrect.  It 
should be libxslt since its wrapping the libxslt library 
(http://xmlsoft.org/XSLT/).  Is it possible to change names?

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080707/0d314372/attachment.bin>

From cfis at savagexi.com  Mon Jul  7 03:18:38 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 07 Jul 2008 01:18:38 -0600
Subject: [libxml-devel] Changing node equality
Message-ID: <4871C34E.3060908@savagexi.com>

This bug report is interesting:

http://rubyforge.org/tracker/index.php?func=detail&aid=19772&group_id=494&atid=1971

Basically, the code compares two nodes using the == operator, assuming 
that == means equal? (same object) and not eql? (equivalent object).

Right now libxml-ruby does the opposite by defining eql? (and thus ==) 
to be the comparison of two different node's raw xml (as a string). 
Needless to say, that can be an extremely slow operation for large 
documents.

In addition, I can't see how libxml-ruby's interpretation is even useful 
- why would you want to compare if two node's raw xml is the same?  For 
point of comparison, it looks like rexml does not override eql?

So, I'd like to change the libxml bindings by removing the overridden == 
operator, thus making == mean equal?

Objections?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080707/7611d37f/attachment.bin>

From noreply at rubyforge.org  Mon Jul  7 03:08:49 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  7 Jul 2008 03:08:49 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19772 ] Node#== incredibly slow!
Message-ID: <20080707070850.1665518581A8@rubyforge.org>

Bugs item #19772, was opened at 2008-04-25 08:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19772&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: Node#== incredibly slow!

Initial Comment:
When I replaced my REXML implementation of a time-critic routine with a Libxml implementation, the Libxml version took more than THREE TIMES LONGER than the REXML version! To investigate the reason, I reduced the implementation differences to a few core indivisibles and then ran ruby-prof, and discovered that Libxml was wasting huge amounts of time in Node#==

  86.97%   0.46%      7.54      0.04      0.00      7.50              962     Opmllibxml#goleftone                    
                               7.49      7.48      0.00      0.01          962/962     XML::Node#==
                               0.01      0.01      0.00      0.00          962/962     XML::Node#parent

My code says:

  def goleftone()
    parent = @curline.parent
    if parent == @top
      return false
    else
      @curline = parent
      return true
    end
  end

(In other words, I already have a node called @top, of which @curline points to an element at some depth; I repoint @curline to point at its own parent, unless its own parent *is* @top.)

I replaced my test, parent == @top, by a different test, using parent.name, and my routine went from 10.3 seconds to 2.2 seconds. Rather significant (though still not really very much faster than REXML).

Unfortunately, this change caused me to get repeated error messages of the following form:

ruby(1350) malloc: *** error for object 0x12cd520: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
ruby(1350) malloc: *** set a breakpoint in szone_error to debug

However, I believe that this latter is something you may already know about.


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-07 01:08

Message:
This is because libxml-ruby defines == to mean that two nodes have the same xml representation.  What you are after is Ruby's equal? method, not the eql? method (which == uses).



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19772&group_id=494

From noreply at rubyforge.org  Mon Jul  7 03:19:55 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  7 Jul 2008 03:19:55 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19738 ] malloc errors in libxml
Message-ID: <20080707071955.72D7D18581A8@rubyforge.org>

Bugs item #19738, was opened at 2008-04-23 18:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19738&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: malloc errors in libxml

Initial Comment:
I'm sure you folks already know about this, but I'm getting errors like this when using the current version of LibXML:

ruby(309) malloc: *** error for object 0x4fcf30: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
ruby(309) malloc: *** set a breakpoint in szone_error to debug
ruby(309) malloc: *** error for object 0x4bb5d0: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
ruby(309) malloc: *** set a breakpoint in szone_error to debug

I have not noticed that this is causing any incorrect output, however...

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-07 01:19

Message:
 

----------------------------------------------------------------------

Comment By: Charlie Savage (cfis)
Date: 2008-07-01 01:24

Message:
Could you provide a test case?  Also what operating system?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19738&group_id=494

From noreply at rubyforge.org  Mon Jul  7 04:28:47 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  7 Jul 2008 04:28:47 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-14618 ] XML::Attr.to_h fails with more
	than one attribute.
Message-ID: <20080707082848.3444318581B1@rubyforge.org>

Bugs item #14618, was opened at 2007-10-10 17:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=14618&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Dave Howell (snarke)
>Assigned to: Charlie Savage (cfis)
Summary: XML::Attr.to_h fails with more than one attribute.

Initial Comment:
I checked the most recently released version of libxml, and it's the same as the 3.8.4 that I've been working with. The following code . . .

    class XML::Attr 
      def to_h
        inject({}) do |h,a| h[a.name] = a.value end
      end
    end

needs to be replaced with 

    class XML::Attr 
      def to_h
        inject({}) do |h,a| h[a.name] = a.value; h end
      end
    end
 

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-07 02:28

Message:
This is now fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=14618&group_id=494

From sean at chittenden.org  Mon Jul  7 14:46:11 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Mon, 7 Jul 2008 11:46:11 -0700
Subject: [libxml-devel] Back
In-Reply-To: <4871B8D4.7050108@savagexi.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<4871B8D4.7050108@savagexi.com>
Message-ID: <7CAE470C-442D-4460-8CBD-8CC0FD666AD7@chittenden.org>

>> If you can go back a tag the prior release, that would be good, but
>> since you already committed there no reason to make a big fuss about
>> it (as long as everything is still working! ;) We can just move
>> forward from here.
>
> Tagged.
>
> Does anyone mind if I clean out the old branches in the repository?


Is there any reason to nuke 'em?  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Mon Jul  7 14:54:51 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 07 Jul 2008 12:54:51 -0600
Subject: [libxml-devel] Back
In-Reply-To: <7CAE470C-442D-4460-8CBD-8CC0FD666AD7@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>	<486D094E.5010506@savagexi.com>	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>	<4871B8D4.7050108@savagexi.com>
	<7CAE470C-442D-4460-8CBD-8CC0FD666AD7@chittenden.org>
Message-ID: <4872667B.1020401@savagexi.com>



Sean Chittenden wrote:
>>> If you can go back a tag the prior release, that would be good, but
>>> since you already committed there no reason to make a big fuss about
>>> it (as long as everything is still working! ;) We can just move
>>> forward from here.
>>
>> Tagged.
>>
>> Does anyone mind if I clean out the old branches in the repository?
> 
> 
> Is there any reason to nuke 'em?  -sc

I was thinking more along the lines of whether there is any reason to 
keep them.

My thinking in getting rid of them is the repository will have less 
clutter (less code) and check out times will be significantly reduced. 
Since they are now dead code, having them hang around just adds to the 
mental burden of getting up to speed with the library.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080707/b0f3bed1/attachment-0001.bin>

From sean at chittenden.org  Mon Jul  7 14:57:34 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Mon, 7 Jul 2008 11:57:34 -0700
Subject: [libxml-devel] Back
In-Reply-To: <4872667B.1020401@savagexi.com>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>	<486D094E.5010506@savagexi.com>	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>	<4871B8D4.7050108@savagexi.com>
	<7CAE470C-442D-4460-8CBD-8CC0FD666AD7@chittenden.org>
	<4872667B.1020401@savagexi.com>
Message-ID: <A278C778-E30D-49ED-9FF8-14B78B20579E@chittenden.org>

>> Is there any reason to nuke 'em?  -sc
>
> I was thinking more along the lines of whether there is any reason  
> to keep them.
>
> My thinking in getting rid of them is the repository will have less  
> clutter (less code) and check out times will be significantly  
> reduced. Since they are now dead code, having them hang around just  
> adds to the mental burden of getting up to speed with the library.


Oh yeah!  @#!$  Subversion.  :(  Hrm.  Tom says he's going to add  
mercurial support next to rubyforge so I'd hold onto 'em for the time  
being since that overhead will vanish upon import.  <:~]  -sc

--
Sean Chittenden
sean at chittenden.org




From danj at 3skel.com  Mon Jul  7 17:45:08 2008
From: danj at 3skel.com (Dan Janowski)
Date: Mon, 7 Jul 2008 17:45:08 -0400
Subject: [libxml-devel] Changing node equality
In-Reply-To: <4871C34E.3060908@savagexi.com>
References: <4871C34E.3060908@savagexi.com>
Message-ID: <CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>

I think this is a vestige of the old fact that there could be two ruby  
objects that referred to the same XML node. Since I removed that and  
now there is only a one-to-one relationship between the ruby peer and  
the XML node, if == is equivalent to equal? and equal? is object  
identity, then it makes sense to do as you say. Should eql? take on  
the code of the current ==?

Dan


On Jul 7, 2008, at 03:18, Charlie Savage wrote:
> This bug report is interesting:
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=19772&group_id=494&atid=1971
>
> Basically, the code compares two nodes using the == operator,  
> assuming that == means equal? (same object) and not eql? (equivalent  
> object).
>
> Right now libxml-ruby does the opposite by defining eql? (and thus  
> ==) to be the comparison of two different node's raw xml (as a  
> string). Needless to say, that can be an extremely slow operation  
> for large documents.
>
> In addition, I can't see how libxml-ruby's interpretation is even  
> useful - why would you want to compare if two node's raw xml is the  
> same?  For point of comparison, it looks like rexml does not  
> override eql?
>
> So, I'd like to change the libxml bindings by removing the  
> overridden == operator, thus making == mean equal?
>
> Objections?
>
> Charlie
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel


From cfis at savagexi.com  Mon Jul  7 23:20:08 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 07 Jul 2008 21:20:08 -0600
Subject: [libxml-devel] Changing node equality
In-Reply-To: <CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
References: <4871C34E.3060908@savagexi.com>
	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
Message-ID: <4872DCE8.8080400@savagexi.com>



Dan Janowski wrote:
> I think this is a vestige of the old fact that there could be two ruby 
> objects that referred to the same XML node. Since I removed that and now 
> there is only a one-to-one relationship between the ruby peer and the 
> XML node, if == is equivalent to equal? and equal? is object identity, 
> then it makes sense to do as you say. Should eql? take on the code of 
> the current ==?

Good point, the new memory model definitely changes things.  Currently, 
the == operator in libxml is an alias for eql?, so there is only one method.

I did a bit of research to understand general ruby conventions.  The 
best write ups I found are:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/572e8d8b01a7d24e/c5f532d868afab05
http://www.texperts.com/2007/10/16/navigating-the-equality-maze/

I like thinking about it this way (taken from one of the comments in the 
first post):

equal?       object identity test

   eql?       strict equality test, 1.eql?(1.0) is false
              (defaults to identity)

    ==        loose equality test, 1 == 1.0 is true
              (defaults to identity)

Usually == is the same as eql?, but not always (see the numeric classes 
for example).

In theory, you are supposed to override eql? for your own classes and 
perhaps ==.  If you do override eql? you are also supposed to override hash.

FOr libxml, I don't see how a custom eql? methods provides any benefits 
- why would you compare two xml nodes for equality, and if you did, what 
does that mean?  If the text content is the same, but the document is 
different, is that still equality?

The big downside is performance, all of a sudden code like this:

node1 == node2

becomes very slow.  In addition, lookups for hash tables or keys that 
contain nodes as keys also becomes slow.

So, I don't think defining eql? to do a text comparison while defining 
== to be object identity is a good idea because it would be inconsistent 
with existing ruby conventions and code.  So I propose we remove the 
overriden eql? method, thereby causing the == operator to default to an 
object identity test.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080707/63e4b0ed/attachment.bin>

From transfire at gmail.com  Tue Jul  8 06:11:22 2008
From: transfire at gmail.com (Trans)
Date: Tue, 8 Jul 2008 03:11:22 -0700 (PDT)
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <4871BDAF.3090603@savagexi.com>
References: <4871BDAF.3090603@savagexi.com>
Message-ID: <836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>


On Jul 7, 2:54?am, Charlie Savage <c... at savagexi.com> wrote:
> To go with the new libxml-ruby release, I've pushed up a libxslt-ruby
> release.

I'm glad to see libxslt library getting some loving, it was sorely in
need of it.

Some months ago we discussed this with regards to libxml. The same
applies to libxslt. That is, the name needs to transition to
"libxslt", dropping the "-ruby".

> It includes two big changes.
>
> * Windows support (both lots of memory fixes and binaries)
>
> * New libxslt.rb ruby wrapper, so programs can simply say:
>
> require 'libxslt'
>
> * For all other platforms, I updated extconf.rb to tell gcc that
> libxslt-ruby depends on libxml-ruby being present. ?To do this trick, I
> made a big assumption - that libxml-ruby is installed as a gem. ?I did
> this because I couldn't figure out any other way to reliably determine
> where the libxml-ruby header files were on disk. ?What do people think o
> of this?

I'll take a peak at it as soon as I finish up what I working on at the
moment (in a couple of days).

> Last, the project name on rubyforge is libxsl which is incorrect. ?It
> should be libxslt since its wrapping the libxslt library
> (http://xmlsoft.org/XSLT/). ?Is it possible to change names?

That would require creating a new rubyforge project. Do you think it's
worth the transition?

T.

From transfire at gmail.com  Tue Jul  8 06:15:05 2008
From: transfire at gmail.com (Trans)
Date: Tue, 8 Jul 2008 03:15:05 -0700 (PDT)
Subject: [libxml-devel] Changing node equality
In-Reply-To: <4872DCE8.8080400@savagexi.com>
References: <4871C34E.3060908@savagexi.com>
	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com> 
	<4872DCE8.8080400@savagexi.com>
Message-ID: <1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>



On Jul 7, 11:20?pm, Charlie Savage <c... at savagexi.com> wrote:
> Dan Janowski wrote:
> > I think this is a vestige of the old fact that there could be two ruby
> > objects that referred to the same XML node. Since I removed that and now
> > there is only a one-to-one relationship between the ruby peer and the
> > XML node, if == is equivalent to equal? and equal? is object identity,
> > then it makes sense to do as you say. Should eql? take on the code of
> > the current ==?
>
> Good point, the new memory model definitely changes things. ?Currently,
> the == operator in libxml is an alias for eql?, so there is only one method.
>
> I did a bit of research to understand general ruby conventions. ?The
> best write ups I found are:
>
> http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/57...http://www.texperts.com/2007/10/16/navigating-the-equality-maze/
>
> I like thinking about it this way (taken from one of the comments in the
> first post):
>
> equal? ? ? ? object identity test
>
> ? ?eql? ? ? ? strict equality test, 1.eql?(1.0) is false
> ? ? ? ? ? ? ? (defaults to identity)
>
> ? ? == ? ? ? ?loose equality test, 1 == 1.0 is true
> ? ? ? ? ? ? ? (defaults to identity)
>
> Usually == is the same as eql?, but not always (see the numeric classes
> for example).
>
> In theory, you are supposed to override eql? for your own classes and
> perhaps ==. ?If you do override eql? you are also supposed to override hash.
>
> FOr libxml, I don't see how a custom eql? methods provides any benefits
> - why would you compare two xml nodes for equality, and if you did, what
> does that mean? ?If the text content is the same, but the document is
> different, is that still equality?
>
> The big downside is performance, all of a sudden code like this:
>
> node1 == node2
>
> becomes very slow. ?In addition, lookups for hash tables or keys that
> contain nodes as keys also becomes slow.
>
> So, I don't think defining eql? to do a text comparison while defining
> == to be object identity is a good idea because it would be inconsistent
> with existing ruby conventions and code. ?So I propose we remove the
> overriden eql? method, thereby causing the == operator to default to an
> object identity test.

Hmmm... How does the C library itself handle comparison?

T.

From cfis at savagexi.com  Tue Jul  8 12:03:05 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 10:03:05 -0600
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>
References: <4871BDAF.3090603@savagexi.com>
	<836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>
Message-ID: <48738FB9.5060001@savagexi.com>



Trans wrote:
> 
> Some months ago we discussed this with regards to libxml. The same
> applies to libxslt. That is, the name needs to transition to
> "libxslt", dropping the "-ruby".

Hmm, I suppose we can call the gem that.  However, the .so file cannot 
be called that.  I started doing it that way, but what happened is that 
the gcc linker would grab libxslt.so the bindings instead of libxslt.so 
the library.  And I couldn't stand the libxslt_so.so name, thus back to 
libxslt_ruby.so which seemed reasonable.

>> * For all other platforms, I updated extconf.rb to tell gcc that
>> libxslt-ruby depends on libxml-ruby being present.  To do this trick, I
>> made a big assumption - that libxml-ruby is installed as a gem.  I did
>> this because I couldn't figure out any other way to reliably determine
>> where the libxml-ruby header files were on disk.  What do people think o
>> of this?
> 
> I'll take a peak at it as soon as I finish up what I working on at the
> moment (in a couple of days).

Sounds good.
> 
>> Last, the project name on rubyforge is libxsl which is incorrect.  It
>> should be libxslt since its wrapping the libxslt library
>> (http://xmlsoft.org/XSLT/).  Is it possible to change names?
> 
> That would require creating a new rubyforge project. Do you think it's
> worth the transition?

No, not really.  But it would be nice to be consistent.

As for renaming the gems from libxml-ruby to libxml and libxslt-ruby to 
libxslt, do you think that's worth it?  Seems like it would break 
upgrading (you'd have libxml-ruby and libxml installed, which one wins?).

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/1b196d5d/attachment-0001.bin>

From cfis at savagexi.com  Tue Jul  8 12:04:06 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 10:04:06 -0600
Subject: [libxml-devel] Changing node equality
In-Reply-To: <1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>
References: <4871C34E.3060908@savagexi.com>	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
	<4872DCE8.8080400@savagexi.com>
	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>
Message-ID: <48738FF6.8010300@savagexi.com>


> Hmmm... How does the C library itself handle comparison?

Well, in C the == is identity (comparing pointer addresses).  libxml 
does not provide an equality method that I see.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/ffa679d2/attachment.bin>

From cfis at savagexi.com  Tue Jul  8 12:26:37 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 10:26:37 -0600
Subject: [libxml-devel] Proposed API changes for working with child nodes
	and attributes
Message-ID: <4873953D.9010008@savagexi.com>

I've noticed two oddities in the libxml api - dealing with child 
elements and attributes.  In both cases, the returned value is a single 
item (an attribute or node) that then provides methods to get to the 
next item.

So:

some_node = doc.find('/foo')

child = some_node.children
while child
   ... do stuff
   child = child.next
end

There is also a bit of ruby syntactic sugar that defines an each method, 
so you can do:

some_node = doc.find('/foo')

some_node.children.each do |node|
   ... do stuff
end

Thus node.children is a XML::Node that acts both as a single node and 
also a collection.  The same is true for attributes.

For anyone who works with the DOM's built into browsers, or follows the 
W3C standards 
(\http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html), 
this is a bit weird and non-intuitive.

I'd prefer that node.children becomes node.first and node.children 
returns an array of child nodes.  We'd then add an each_child method to 
XML::Node (based on node.first and node.next) for quick and easy iteration.

some_node = doc.find('/foo')

child_nodes = some_node.children
child_nodes.class == "Array"

some_node.each_child do |node|
   ... do stuff
end


And for attributes, I vote that libxml copies REXML's interface:

http://www.germane-software.com/software/rexml/doc/classes/REXML/Attributes.html

Thoughts?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/b7bfbcad/attachment.bin>

From sean at chittenden.org  Tue Jul  8 12:51:58 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 8 Jul 2008 09:51:58 -0700
Subject: [libxml-devel] Proposed API changes for working with child
	nodes and attributes
In-Reply-To: <4873953D.9010008@savagexi.com>
References: <4873953D.9010008@savagexi.com>
Message-ID: <54FDFC37-62D3-4E84-B7EB-B15AF394F671@chittenden.org>

> I've noticed two oddities in the libxml api - dealing with child  
> elements and attributes.  In both cases, the returned value is a  
> single item (an attribute or node) that then provides methods to get  
> to the next item.
>
> So:
>
> some_node = doc.find('/foo')
>
> child = some_node.children
> while child
>  ... do stuff
>  child = child.next
> end
>
> There is also a bit of ruby syntactic sugar that defines an each  
> method, so you can do:
>
> some_node = doc.find('/foo')
>
> some_node.children.each do |node|
>  ... do stuff
> end
>
> Thus node.children is a XML::Node that acts both as a single node  
> and also a collection.  The same is true for attributes.

I wanted to revisit this at some point, I'm glad someone is doing it.

> For anyone who works with the DOM's built into browsers, or follows  
> the W3C standards (\http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html) 
> , this is a bit weird and non-intuitive.
>
> I'd prefer that node.children becomes node.first and node.children  
> returns an array of child nodes.  We'd then add an each_child method  
> to XML::Node (based on node.first and node.next) for quick and easy  
> iteration.
>
> some_node = doc.find('/foo')
>
> child_nodes = some_node.children
> child_nodes.class == "Array"
>
> some_node.each_child do |node|
>  ... do stuff
> end

I think if you go back to the original code from ~0.1, it had an  
interface like: doc.find('/foo').each {|node| p node }  which was  
convenient in some situations.  In general, I dislike most of the DOM  
interfaces available.

find() should return a set of nodes (I think that's what it does,  
actually) and the nodeset behaves like the union of a node and an  
array.  Chaining methods together needlessly to support a DOM  
interface of lists and atoms is a bit clunky and was something I  
attempted to avoid.

At this point, "*shrug* whatever."  I think the API for a developer  
should mask some of the libxml structure of nodesets/nodes because,  
frankly, it's a pain in the ass. Constantly coding around, "are you a  
list or a node?" is inefficient and that's largely the value of Ruby -  
efficiency of programming.

...I wonder if I still have my patch hanging around for that makes use  
of method_missing() to find nodes (pretty cool for XML configuration  
foo).

> And for attributes, I vote that libxml copies REXML's interface:
>
> http://www.germane-software.com/software/rexml/doc/classes/REXML/Attributes.html
>
> Thoughts?

Go for it - attribute support sucked hard.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Tue Jul  8 13:23:42 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 11:23:42 -0600
Subject: [libxml-devel] Proposed API changes for working with
 child	nodes and attributes
In-Reply-To: <54FDFC37-62D3-4E84-B7EB-B15AF394F671@chittenden.org>
References: <4873953D.9010008@savagexi.com>
	<54FDFC37-62D3-4E84-B7EB-B15AF394F671@chittenden.org>
Message-ID: <4873A29E.3050906@savagexi.com>

>> Thus node.children is a XML::Node that acts both as a single node and 
>> also a collection.  The same is true for attributes.
> 
> I wanted to revisit this at some point, I'm glad someone is doing it.

Ah good.

>> some_node = doc.find('/foo')
>>
>> child_nodes = some_node.children
>> child_nodes.class == "Array"
>>
>> some_node.each_child do |node|
>>  ... do stuff
>> end
> 
> I think if you go back to the original code from ~0.1, it had an 
> interface like: doc.find('/foo').each {|node| p node }  which was 
> convenient in some situations.  In general, I dislike most of the DOM 
> interfaces available.

Yup, agreed, they are clunky.

> find() should return a set of nodes (I think that's what it does, 
> actually) and the nodeset behaves like the union of a node and an 
> array. 

It does.  I'm tempted to reuse the nodeset, but its fairly tightly tied 
to the XPath code, so its not reusable currently.

  Chaining methods together needlessly to support a DOM interface
> of lists and atoms is a bit clunky and was something I attempted to avoid.

Agreed.

> At this point, "*shrug* whatever."  I think the API for a developer 
> should mask some of the libxml structure of nodesets/nodes because, 
> frankly, it's a pain in the ass. Constantly coding around, "are you a 
> list or a node?" is inefficient and that's largely the value of Ruby - 
> efficiency of programming.

Definitely.

> ...I wonder if I still have my patch hanging around for that makes use 
> of method_missing() to find nodes (pretty cool for XML configuration foo).

Ah, what's that do?

>> And for attributes, I vote that libxml copies REXML's interface:
>>
>> http://www.germane-software.com/software/rexml/doc/classes/REXML/Attributes.html 
>>
>> Thoughts?
> 
> Go for it - attribute support sucked hard.  -sc

Ok - that seems like a place to start.  Also, I've seen people confused 
by how namespaces and attributes work, so I'll add some tests for that.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/38a56737/attachment.bin>

From transfire at gmail.com  Tue Jul  8 13:30:01 2008
From: transfire at gmail.com (Trans)
Date: Tue, 8 Jul 2008 10:30:01 -0700 (PDT)
Subject: [libxml-devel] Changing node equality
In-Reply-To: <48738FF6.8010300@savagexi.com>
References: <4871C34E.3060908@savagexi.com>
	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com> 
	<4872DCE8.8080400@savagexi.com>
	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>
	<48738FF6.8010300@savagexi.com>
Message-ID: <80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>



On Jul 8, 12:04?pm, Charlie Savage <c... at savagexi.com> wrote:
> > Hmmm... How does the C library itself handle comparison?
>
> Well, in C the == is identity (comparing pointer addresses). ?libxml
> does not provide an equality method that I see.

So there is no way to compare on content, only identity. But is that
good for Ruby too? I wonder how changing #== to identity might effect
current users? Even so, I agree that comparing raw xml strings doesn't
makes sense, but comparing equivalence, as opposed to identity, can be
useful, ie. same tag names, same attributes (irregardless of order)
and same data. Otherwise it would seem like we are suggesting that XML
nodes should be immutable.

T.

From sean at chittenden.org  Tue Jul  8 13:37:07 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 8 Jul 2008 10:37:07 -0700
Subject: [libxml-devel] Proposed API changes for working with
	child	nodes and attributes
In-Reply-To: <4873A29E.3050906@savagexi.com>
References: <4873953D.9010008@savagexi.com>
	<54FDFC37-62D3-4E84-B7EB-B15AF394F671@chittenden.org>
	<4873A29E.3050906@savagexi.com>
Message-ID: <B6CE769D-7B83-4848-97D0-3D707F5FAE8A@chittenden.org>

>> ...I wonder if I still have my patch hanging around for that makes  
>> use of method_missing() to find nodes (pretty cool for XML  
>> configuration foo).
>
> Ah, what's that do?

config = XML::Document...
@version = config.version
bin = config.bin
config.path.each do |path|
   p path
end

For a document like:

<myAppConfig>
   <version>1.0</version>
   <bin>/bin/rm -rf /etc/shadow</bin>
   <path>/opt/linux/blows</path>
   <path>/usr/local/is/good</path>
   <path>/usr/bin</path>
</myAppConfig>

Which really, really kicked ass because it was simple and I was able  
to map XML to code easily.  If a node is missing, it grabs an  
attribute of the same name.  So functionally, the above and below XML  
docs return the same data to the application.

<myAppConfig version="1.0" bin="/bin/rm -rf /etc/shadow">
   <path>/opt/linux/blows</path>
   <path>/usr/local/is/good</path>
   <path>/usr/bin</path>
</myAppConfig>

Sprinkle a bit of relaxng, and you've got a winner, IMHO.

Purist arguments aside, this was very, very cool to write from a  
programmer's perspective.  Returning nil or throwing an exception was  
the hangup and why I never committed it, iirc (easy enough to recreate  
using ruby though).  -sc

--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Tue Jul  8 13:49:10 2008
From: transfire at gmail.com (Trans)
Date: Tue, 8 Jul 2008 10:49:10 -0700 (PDT)
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <48738FB9.5060001@savagexi.com>
References: <4871BDAF.3090603@savagexi.com>
	<836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>
	<48738FB9.5060001@savagexi.com>
Message-ID: <7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>



On Jul 8, 12:03?pm, Charlie Savage <c... at savagexi.com> wrote:
> Trans wrote:
>
> > Some months ago we discussed this with regards to libxml. The same
> > applies to libxslt. That is, the name needs to transition to
> > "libxslt", dropping the "-ruby".
>
> Hmm, I suppose we can call the gem that. ?However, the .so file cannot
> be called that. ?I started doing it that way, but what happened is that
> the gcc linker would grab libxslt.so the bindings instead of libxslt.so
> the library. ?And I couldn't stand the libxslt_so.so name, thus back to
> libxslt_ruby.so which seemed reasonable.

Yes, that's it a bit of annoyance, and there had been some talk about
changing it. "_ruby" is fine, though maybe "_binding" would be more
descriptive?

> >> * For all other platforms, I updated extconf.rb to tell gcc that
> >> libxslt-ruby depends on libxml-ruby being present. ?To do this trick, I
> >> made a big assumption - that libxml-ruby is installed as a gem. ?I did
> >> this because I couldn't figure out any other way to reliably determine
> >> where the libxml-ruby header files were on disk. ?What do people think o
> >> of this?
>
> > I'll take a peak at it as soon as I finish up what I working on at the
> > moment (in a couple of days).
>
> Sounds good.
>
>
>
> >> Last, the project name on rubyforge is libxsl which is incorrect. ?It
> >> should be libxslt since its wrapping the libxslt library
> >> (http://xmlsoft.org/XSLT/). ?Is it possible to change names?
>
> > That would require creating a new rubyforge project. Do you think it's
> > worth the transition?
>
> No, not really. ?But it would be nice to be consistent.

True. I am willing to transition. I suppose if Sean feels it's worth
it the we can move forward with it.

> As for renaming the gems from libxml-ruby to libxml and libxslt-ruby to
> libxslt, do you think that's worth it? ?Seems like it would break
> upgrading (you'd have libxml-ruby and libxml installed, which one wins?).

I think it is, b/c it creates consistency across the gem name, the
library directory name and the module name.

Indeed, there is a potential for library conflict (an example of the
weaknesses of Ruby's require system actually). We will just have to
make a special emphases to users about this transition. A good way to
handle it might be to release as libxml-ruby/libxslt-ruby and then
immediately release the same versions as libxml/libxslt in order to
facilitate a smooth a transition as possible.

T.

From sean at chittenden.org  Tue Jul  8 14:02:56 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 8 Jul 2008 11:02:56 -0700
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>
References: <4871BDAF.3090603@savagexi.com>
	<836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>
	<48738FB9.5060001@savagexi.com>
	<7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>
Message-ID: <09D803B1-AC1C-4B7A-9B7F-34B8FEB15D26@chittenden.org>

>>>> Last, the project name on rubyforge is libxsl which is  
>>>> incorrect.  It
>>>> should be libxslt since its wrapping the libxslt library
>>>> (http://xmlsoft.org/XSLT/).  Is it possible to change names?
>>
>>> That would require creating a new rubyforge project. Do you think  
>>> it's
>>> worth the transition?
>>
>> No, not really.  But it would be nice to be consistent.
>
> True. I am willing to transition. I suppose if Sean feels it's worth
> it the we can move forward with it.

I'm pretty indifferent.  The reason for 'libxsl' versus 'libxslt' was  
twofold.

1) The "T" is a verb (transformation), not a thing.  XML is a thing.   
XSL is a thing.  XSLT is an action done on an XML document using the  
XSL spec.  Or that's how I saw it at the time (remember, this is  
coming from the same group of folks that standardized "referer" vs.  
"referrer")

2) 'libxml'.length == 'libxsl'.length  It just looked more consistent  
when shown in a directory listing.  <:~)

>> As for renaming the gems from libxml-ruby to libxml and libxslt- 
>> ruby to
>> libxslt, do you think that's worth it?  Seems like it would break
>> upgrading (you'd have libxml-ruby and libxml installed, which one  
>> wins?).
>
> I think it is, b/c it creates consistency across the gem name, the
> library directory name and the module name.
>
> Indeed, there is a potential for library conflict (an example of the
> weaknesses of Ruby's require system actually). We will just have to
> make a special emphases to users about this transition. A good way to
> handle it might be to release as libxml-ruby/libxslt-ruby and then
> immediately release the same versions as libxml/libxslt in order to
> facilitate a smooth a transition as possible.


Break the compatibility now, get it over with.  There's renewed  
interest and development happening at the moment, so now is absolutely  
the right time.  Waiting will only make things more painful.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Tue Jul  8 14:37:05 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 12:37:05 -0600
Subject: [libxml-devel] Changing node equality
In-Reply-To: <80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>
References: <4871C34E.3060908@savagexi.com>	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
	<4872DCE8.8080400@savagexi.com>	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>	<48738FF6.8010300@savagexi.com>
	<80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>
Message-ID: <4873B3D1.8050306@savagexi.com>



Trans wrote:
> 
> On Jul 8, 12:04 pm, Charlie Savage <c... at savagexi.com> wrote:
>>> Hmmm... How does the C library itself handle comparison?
>> Well, in C the == is identity (comparing pointer addresses).  libxml
>> does not provide an equality method that I see.
> 
> So there is no way to compare on content, only identity. 

Well, its easy enough:

if node1.to_s == node2.to_s

Or

if node1.content == node2.content

to_s is like outerHTML and content is innerHTML (sort of).

But is that
> good for Ruby too? I wonder how changing #== to identity might effect
> current users? 

Best guess it gives them a nice performance boost, since I'm not seeing 
how comparing on content is useful

Even so, I agree that comparing raw xml strings doesn't
> makes sense, but comparing equivalence, as opposed to identity, can be
> useful, ie. same tag names, same attributes (irregardless of order)
> and same data. 

See above.

Otherwise it would seem like we are suggesting that XML
> nodes should be immutable.

Hmm, why do you say that?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/d364c825/attachment.bin>

From cfis at savagexi.com  Tue Jul  8 14:42:09 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 08 Jul 2008 12:42:09 -0600
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>
References: <4871BDAF.3090603@savagexi.com>	<836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>	<48738FB9.5060001@savagexi.com>
	<7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>
Message-ID: <4873B501.1000104@savagexi.com>



Trans wrote:
> 
> On Jul 8, 12:03 pm, Charlie Savage <c... at savagexi.com> wrote:
>> Trans wrote:
>>
> 
> Yes, that's it a bit of annoyance, and there had been some talk about
> changing it. "_ruby" is fine, though maybe "_binding" would be more
> descriptive?

Either way is fine - libxslt_ruby or libxslt_binding.  I don't feel 
strongly.

>>>> Last, the project name on rubyforge is libxsl which is incorrect.  It
>>>> should be libxslt since its wrapping the libxslt library
>>>> (http://xmlsoft.org/XSLT/).  Is it possible to change names?
>>> That would require creating a new rubyforge project. Do you think it's
>>> worth the transition?
>> No, not really.  But it would be nice to be consistent.
> 
> True. I am willing to transition. I suppose if Sean feels it's worth
> it the we can move forward with it.
> 
>> As for renaming the gems from libxml-ruby to libxml and libxslt-ruby to
>> libxslt, do you think that's worth it?  Seems like it would break
>> upgrading (you'd have libxml-ruby and libxml installed, which one wins?).
> 
> I think it is, b/c it creates consistency across the gem name, the
> library directory name and the module name.

Right now:

gem name: libxslt-ruby
library name: libxslt
module name:  XML::XSLT

> Indeed, there is a potential for library conflict (an example of the
> weaknesses of Ruby's require system actually). We will just have to
> make a special emphases to users about this transition. A good way to
> handle it might be to release as libxml-ruby/libxslt-ruby and then
> immediately release the same versions as libxml/libxslt in order to
> facilitate a smooth a transition as possible.

Hmm.  Changing the gem names is causing to cause problems because you 
might think you've upgraded to libxml version 7, but in fact you're 
still pulling in libxml-ruby version 2.  I see no way around that.

Maybe the thing to do is change the name for Ruby 1.9.  For libxml-ruby 
require a ruby version of less than 1.9, for libxml require a ruby 
version of 1.9 or greater.  If that is doable (not sure it is), then at 
least you can't have a conflict.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080708/0c2cd1b3/attachment.bin>

From sean at chittenden.org  Tue Jul  8 14:49:47 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 8 Jul 2008 11:49:47 -0700
Subject: [libxml-devel] Changing node equality
In-Reply-To: <4873B3D1.8050306@savagexi.com>
References: <4871C34E.3060908@savagexi.com>	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
	<4872DCE8.8080400@savagexi.com>	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>	<48738FF6.8010300@savagexi.com>
	<80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>
	<4873B3D1.8050306@savagexi.com>
Message-ID: <038B5C38-8519-4A98-93A0-05DC1FCAB678@chittenden.org>

>>>> Hmmm... How does the C library itself handle comparison?
>>> Well, in C the == is identity (comparing pointer addresses).  libxml
>>> does not provide an equality method that I see.
>> So there is no way to compare on content, only identity.
>
> Well, its easy enough:
>
> if node1.to_s == node2.to_s
>
> Or
>
> if node1.content == node2.content
>
> to_s is like outerHTML and content is innerHTML (sort of).

Actually, how about this (pseudo):

def ==(arg)
   if arg.kind_of? XML::Node
     return true if self.id == arg.id
   else
     return true if self.to_s == arg
   end
end

That way you don't have to create and throw away an object needlessly  
in most comparison cases.  -sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Tue Jul  8 14:51:10 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 8 Jul 2008 11:51:10 -0700
Subject: [libxml-devel] Libxsl 0.6.0 release
In-Reply-To: <4873B501.1000104@savagexi.com>
References: <4871BDAF.3090603@savagexi.com>	<836bfe9d-886b-4cb7-ac87-b814e1697a4f@56g2000hsm.googlegroups.com>	<48738FB9.5060001@savagexi.com>
	<7bd04db0-414f-4f2d-a009-7767c7488bcf@z66g2000hsc.googlegroups.com>
	<4873B501.1000104@savagexi.com>
Message-ID: <EA0B074F-5609-477B-811C-426523A4BFCE@chittenden.org>

> Hmm.  Changing the gem names is causing to cause problems because  
> you might think you've upgraded to libxml version 7, but in fact  
> you're still pulling in libxml-ruby version 2.  I see no way around  
> that.
>
> Maybe the thing to do is change the name for Ruby 1.9.  For libxml- 
> ruby require a ruby version of less than 1.9, for libxml require a  
> ruby version of 1.9 or greater.  If that is doable (not sure it is),  
> then at least you can't have a conflict.


Actually, that's a great idea.  Changing the install name for 1.9  
works since everyone will have to reinstall and that's something  
that's done at make/extconf.rb time not run time.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul  9 04:40:39 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 09 Jul 2008 02:40:39 -0600
Subject: [libxml-devel] [Fwd: [ruby-core:17694] Mark functions not called on
	exit]
Message-ID: <48747987.5040808@savagexi.com>

Hi everyone,

Going through the tests, I've run into one that causes segmentation 
faults (libxml-ruby/trunk/test/ets_copy_bug2.rb).

After puzzling over it for a bit, I realized the problem is that Mark 
functions for C objects are not being called when Ruby exits.  I've 
posted a note to ruby-core to verify this:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17694

In the meantime, curious if anyone has any ideas on how to solve the issue.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080709/7f611258/attachment.bin>

From cfis at savagexi.com  Wed Jul  9 04:41:10 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 09 Jul 2008 02:41:10 -0600
Subject: [libxml-devel] Changing node equality
In-Reply-To: <038B5C38-8519-4A98-93A0-05DC1FCAB678@chittenden.org>
References: <4871C34E.3060908@savagexi.com>	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>	<4872DCE8.8080400@savagexi.com>	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>	<48738FF6.8010300@savagexi.com>	<80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>	<4873B3D1.8050306@savagexi.com>
	<038B5C38-8519-4A98-93A0-05DC1FCAB678@chittenden.org>
Message-ID: <487479A6.8060104@savagexi.com>

> Actually, how about this (pseudo):
> 
> def ==(arg)
>   if arg.kind_of? XML::Node
>     return true if self.id == arg.id
>   else
>     return true if self.to_s == arg
>   end
> end

Deal - I'll do that.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080709/ae03588a/attachment.bin>

From transfire at gmail.com  Wed Jul  9 09:11:20 2008
From: transfire at gmail.com (Trans)
Date: Wed, 9 Jul 2008 06:11:20 -0700 (PDT)
Subject: [libxml-devel] Changing node equality
In-Reply-To: <4873B3D1.8050306@savagexi.com>
References: <4871C34E.3060908@savagexi.com>
	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com> 
	<4872DCE8.8080400@savagexi.com>
	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>
	<48738FF6.8010300@savagexi.com>
	<80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>
	<4873B3D1.8050306@savagexi.com>
Message-ID: <95d2127e-da83-47b8-93ca-f374500ed535@m73g2000hsh.googlegroups.com>



On Jul 8, 2:37?pm, Charlie Savage <c... at savagexi.com> wrote:
> Trans wrote:
>
> > On Jul 8, 12:04 pm, Charlie Savage <c... at savagexi.com> wrote:
> >>> Hmmm... How does the C library itself handle comparison?
> >> Well, in C the == is identity (comparing pointer addresses). ?libxml
> >> does not provide an equality method that I see.
>
> > So there is no way to compare on content, only identity.
>
> Well, its easy enough:
>
> if node1.to_s == node2.to_s
>
> Or
>
> if node1.content == node2.content
>
> to_s is like outerHTML and content is innerHTML (sort of).
>
> But is that
>
> > good for Ruby too? I wonder how changing #== to identity might effect
> > current users?
>
> Best guess it gives them a nice performance boost, since I'm not seeing
> how comparing on content is useful
>
> Even so, I agree that comparing raw xml strings doesn't
>
> > makes sense, but comparing equivalence, as opposed to identity, can be
> > useful, ie. same tag names, same attributes (irregardless of order)
> > and same data.
>
> See above.

Not the same thing. Comparing raw XML string is overly strict. For
example I would expect the following two snips to be "equal":

  <root><foo bar="10" baz="20">Hi</foo></root

and

  <root>
    <foo baz="20" bar="10">
      Hi
    </foo>
  </root>

These would not be equal by string comparison b/c the attribute bar
and baz are not in the same order (to say nothing of white space).

> Otherwise it would seem like we are suggesting that XML
>
> > nodes should be immutable.
>
> Hmm, why do you say that?

If equality is identity, then any node with the same content as
another may as well be the same node. Just like Ruby symbols.

T.

From noreply at rubyforge.org  Wed Jul  9 04:51:12 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 04:51:12 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-7537 ] XPath Unit Test does not test
	XPath
Message-ID: <20080709085112.B9A6815B8002@rubyforge.org>

Bugs item #7537, was opened at 2007-01-02 16:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7537&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: XPath Unit Test does not test XPath

Initial Comment:
The Unit test (tc_xml_xpath.rb) is quite lacking. It tests to see if ruby objects get created but it doesn't test to check if XPath actually works. The following code fails (segfault) with the latest libxml2 (2.6.27) and Ruby libxml (0.8.3.4)

#!/usr/bin/ruby
###############

require "xml/libxml"

str = '<ruby_array uga="booga" foo="bar"><fixnum>one</fixnum><fixnum>two</fixnu
xp = XML::Parser.string( str )

doc = xp.parse
p doc.class.name

xpt = doc.find('/ruby_array/fixnum').xpath
p xpt.class.name

set = xpt.set
p set.class.name

set.each{ |n| p n }

#


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 02:51

Message:
The tests aren't great, but are now a fair bit better.  Please free to expand on them if you have time.  Note the segmentation fault is fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7537&group_id=494

From noreply at rubyforge.org  Wed Jul  9 04:53:24 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 04:53:24 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-8370 ] The XML::Node::Set first()
	method behavior
Message-ID: <20080709085324.B3CA718581AE@rubyforge.org>

Bugs item #8370, was opened at 2007-02-01 13:04
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8370&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Doug Bryant (dougbryant)
>Assigned to: Charlie Savage (cfis)
Summary: The XML::Node::Set first() method behavior

Initial Comment:
With the 0.4 pre release, the following behavior is present:

If you find("//xpath_query") and the result is empty but still ask for the first element, it will return to you an XML::Node::Set

The desired behavior should mimic the ruby array, which returns nil

See below.

irb(main):032:0> doc = XML::Parser.string("<foo><bar><baz></baz></bar></foo>").parse
=> <?xml version="1.0"?>
<foo>
  <bar>
    <baz/>
  </bar>
</foo>

irb(main):033:0> doc.find("//baz")
=> <baz/>
irb(main):034:0> doc.find("//woot")
=>
irb(main):035:0> doc.find("//baz").class.name
=> "XML::Node::Set"
irb(main):036:0> doc.find("//baz").first.class.name
=> "XML::Node"
irb(main):037:0> doc.find("//woot").class.name
=> "XML::Node::Set"
irb(main):038:0> doc.find("//woot").first.class.name
=> "XML::Node::Set"
irb(main):039:0>

The Ruby behavior...
irb(main):039:0> [].first
=> nil



----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 02:53

Message:
This is fixed.

----------------------------------------------------------------------

Comment By: Kuba Podg?rski (kuba)
Date: 2007-07-25 08:05

Message:
What about version 0.3.8.4?
In line doc.find("//baz").first.class.name
i got error:
irb(main):020:0> doc.find("//baz").first.class.name
NoMethodError: undefined method `first' for #<XML::Node::Set:0xb7d0a134>

Thx.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8370&group_id=494

From noreply at rubyforge.org  Wed Jul  9 04:57:02 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 04:57:02 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-9883 ] call-seq for
	ruby_xml_document_validate_schema is incorrect
Message-ID: <20080709085702.C596318585B4@rubyforge.org>

Bugs item #9883, was opened at 2007-04-05 12:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9883&group_id=494

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: call-seq for ruby_xml_document_validate_schema is incorrect

Initial Comment:
Should be

document.validate_schema

not

document.validate

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 02:57

Message:
Thanks - fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9883&group_id=494

From noreply at rubyforge.org  Wed Jul  9 04:59:54 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 04:59:54 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-9158 ] XML::Schema.new("filename")
	always returns nil
Message-ID: <20080709085954.991C818585B2@rubyforge.org>

Bugs item #9158, was opened at 2007-03-09 16:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9158&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
>Summary: XML::Schema.new("filename") always returns nil

Initial Comment:
XML::Schema.new() returns nil no matter what XML schema file I ask it to parse.

When I look at ruby_xml_schema_init_from_url in ruby_xml_schema.c , the only return statement returns Qnil.

So I don't see any usefulness for this Ruby method.  Am I misunderstanding something fundamental here?

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 02:59

Message:
This has been fixed.

schema = XML::Schema.new(uri_to_schema)

Or:

schema = XML::Schema.from_string(schema_string)

Or:

schema = XML::Schema.document(document)




----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9158&group_id=494

From noreply at rubyforge.org  Wed Jul  9 05:01:37 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 05:01:37 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-14231 ] Cannot make assignment to
	attributes in a namespace.
Message-ID: <20080709090137.6BF3F15B8002@rubyforge.org>

Bugs item #14231, was opened at 2007-09-25 19:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=14231&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Dave Howell (snarke)
>Assigned to: Charlie Savage (cfis)
Summary: Cannot make assignment to attributes in a namespace.

Initial Comment:
I'm working with the XML files created by Apple's "Pages" page layout program, which makes extensive use of libxml-ruby's biggest weakness, namespaces. Here's a sample bit of code:

   irb(main):031:0* node
   => <sf:p sf:style="paragraph-style-6">Sample Text</sf:p>

I can see the attribute without difficulty:

   irb(main):032:0> node["style"]
   => "paragraph-style-6"
   irb(main):033:0> node.properties
   => style = paragraph-style-6

But it's impossible to change it:

   irb(main):034:0> node["style"]="paragraph-style-12"
   => "paragraph-style-12"
   irb(main):035:0> node
   => <sf:p sf:style="paragraph-style-6" style="paragraph-style-12">Sample Text</sf:p>

Or to delete it.

   irb(main):036:0> node["style"]=nil
   => nil
   irb(main):037:0> node
   => <sf:p sf:style="paragraph-style-6">Sample Text</sf:p>
   irb(main):038:0> node["style"]=nil
   => nil
   irb(main):039:0> node
   => <sf:p sf:style="paragraph-style-6">Sample Text</sf:p>

I do a fair amount of work in Ruby, but I don't know (and, frankly, have no intention to learn) C, or C++, or whichever dialect the libxml bindings are written in. But I did manage to create a partial solution.

It seems quite bizarre that the .properties method returns the first attribute instead of an array of attributes. It specifically returns the first attribute as an XML::Attr object. 

   irb(main):040:0> node.properties.name
   => "style"
   irb(main):041:0> node.properties.value
   => "paragraph-style-6"
   irb(main):042:0> node
   => <sf:p sf:style="paragraph-style-6">Sample Text</sf:p>

Note the difference between listing the node itself, and accessing the first attribute with .properties. The namespace qualifier gets dropped. Also, the Attr object has the .name and .value methods, but is missing the obvious .value= method.  So I added that, and made .value= smart enough to work correctly with an attribute's namespace.

   irb(main):047:0> node.properties.value="paragraph-style 12"
   => "paragraph-style 12"
   irb(main):048:0> node
   => <sf:p sf:style="paragraph-style 12">Sample Text</sf:p>

This only works on existing attributes with namespaces; you can't add new attributes with a namespace. I looked at trying to make the node["attribute"] form work this way as well, but it took me far too many hours to get the .properties.value= working, and the [""] form uses completely different code. 

I am attaching my modified ruby_xml_attr.c file. Somebody who actually knows this code, or at least C, ought to make sure there aren't problems in the code before anybody should consider letting it near the main code tree, if version 5.x hasn't already made it irrelevant. 


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 03:01

Message:
Thanks for the patch.

A new attributes class has been introduced that is similar to what REXML has.  Also, updating an attribute's value now also works for namespaced attributes.  Changes will be in an upcoming release.



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=14231&group_id=494

From noreply at rubyforge.org  Wed Jul  9 12:14:27 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 12:14:27 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-7529 ] Segfault on parser_context.doc
	access after XML parse error
Message-ID: <20080709161427.301A018585CD@rubyforge.org>

Bugs item #7529, was opened at 2007-01-02 05:14
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7529&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: Segfault on parser_context.doc access after XML parse error

Initial Comment:
(libxml-ruby 0.3.9.1
 ruby 1.8.5 (2006-08-25) [i686-linux], 
 Libxml2 2.6.23, 
 Fedora Core 5 [2.6.17-1.2174_FC5])

If the XML::Parser parser_context.doc is accessed and used following a parse error, a segfault will arise. This script reproduces this error for me:

#!/usr/local/bin/ruby
require 'xml/libxml'

#adding an error handler prevents the segfault
#XML::Parser.register_error_handler lambda { |*args| }

xp = XML::Parser.file(File.expand_path(
                        File.join(File.dirname(__FILE__), 'data.html')))

had_err = false
xp.parse rescue had_err = true

if had_err
  raise "got doc" if xp.parser_context.doc.root # SEGFAULT
else
  raise "didn't error"
end

puts "all ok"
__END__

Outputs:

<<parser errors elided>>

parse_error_doc_bug.rb:13: got doc (RuntimeError)
parse_error_doc_bug.rb:13: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i686-linux]

Aborted

I think the expected behaviour would be for parser_context.doc to be nil if the last parse had errors.


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 10:14

Message:
This looks like an internal data structure, so access to context.doc has been removed.  Is there anything you need it for.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=7529&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:36:21 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:36:21 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-8125 ] 0.3.8.4: XPath troubles with
	certain attributes and namespaces
Message-ID: <20080709173621.ECB6518585B7@rubyforge.org>

Bugs item #8125, was opened at 2007-01-24 17:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8125&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jeremy Echols (nerdmaster)
>Assigned to: Charlie Savage (cfis)
Summary: 0.3.8.4: XPath troubles with certain attributes and namespaces

Initial Comment:
I don't know if this is a libxml thing or a libxml-ruby thing, so I apologize if this is the wrong place to post the bug; I'm just not sure an easy way to figure out where the problem lies.

On to the problem.  As reported in bug #7537, the xpath testing is very sparse.  Worse than that, there is a clear problem with the xpath parser.  I'm attaching a patch of the xpath test case (test/tc_xml_xpath.rb) that should be helpful in showing specifically what's going wrong.  In a nutshell: I cannot select elements with "ns1:" as a namespace prefix for some reason (though other prefixes seem okay), and nodes with an "xmlns" attribute seem to be totally invisible (though other attributes I've run across seem fine).

My test patch includes a case for showing that rexml does these just fine, which makes me believe that this is a bug in libxml-ruby and not in the xml itself or my usage of xpath.


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:36

Message:
Thanks Jeremy,

Your tests have been incorporated into libxml and now work as expected (see test/tc_xml_xpath.rb).

Victor - Xpath support works correctly.

----------------------------------------------------------------------

Comment By: Vitor Rodrigues (bitor)
Date: 2007-06-13 16:16

Message:
are there any predictions for when will libxml have xpath support that works?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8125&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:37:38 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:37:38 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
Message-ID: <20080709173738.5B60E15B8002@rubyforge.org>

Bugs item #8337, was opened at 2007-01-31 10:47
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8337&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: Opening many files causes segfault on fbsd-amd64

Initial Comment:
I have a number of xml files I'm parsing, and it seems the libxml-ruby will cause a segfault if I open too many files too quickly.

For example, if your script test.rb is:
--
require 'xml/libxml'

(1..10000).each{|time|
  XML::Document.file('test.xml')
  p time if time % 100 == 0
}
--
and test.xml is
--
<?xml version="1.0"?>
<test/>
--
Then, on fbsd-amd64, you'll see
100
200
300
400
500
test.rb:5: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [amd64-freebsd6]

zsh: abort (core dumped)  ruby test.rb


It seems to error in the same place every time.  Interestingly, for so short an XML file, if you remove the if clause from the p statement, there won't be any errors, however longer XML files will still suffer this problem.  More interestingly, the problem can be avoided entirely by disabling the GC.

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:37

Message:
I assume this is now fixed with the new memory model.

----------------------------------------------------------------------

Comment By: Saurabh Nanda (saurabhnanda)
Date: 2008-02-05 07:19

Message:
Here's the error log. I don't know what'll happen to the formatting, though:


*** glibc detected *** /usr/local/bin/ruby: double free or corruption (out): 0x0000000012933740 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ef4e6e8a0]
/lib64/libc.so.6(cfree+0x8c)[0x3ef4e71fbc]
/usr/lib64/libxml2.so.2(xmlCharEncCloseFunc+0x51)[0x3f0202def1]
/usr/lib64/libxml2.so.2(xmlFreeParserInputBuffer+0x2d)[0x3f02057efd]
/usr/lib64/libxml2.so.2(xmlFreeInputStream+0x67)[0x3f020322a7]
/usr/lib64/libxml2.so.2(xmlFreeParserCtxt+0x19)[0x3f020322e9]
/home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so(ruby_xml_parser_context_free+0x11)[0x2aaab4b17721]
/usr/local/bin/ruby[0x42d1b2]
/usr/local/bin/ruby(ruby_xmalloc+0x67)[0x42d5c7]
/usr/local/bin/ruby[0x40e14d]
/usr/local/bin/ruby[0x4114fe]
/usr/local/bin/ruby[0x417a21]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby(rb_ary_each+0x23)[0x4808f3]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby[0x419e52]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x4177e2]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416d5e]
/usr/local/bin/ruby[0x415cb3]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby(rb_funcall2+0x32)[0x41b272]
/usr/local/bin/ruby[0x41cf58]
/usr/local/bin/ruby[0x41b136]
/usr/local/bin/ruby[0x4234b1]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x420104]
/usr/local/bin/ruby[0x4161fb]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby(rb_ary_each+0x23)[0x4808f3]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x4171c7]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x4166ce]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby[0x419e52]
======= Memory map: ========
00400000-004c2000 r-xp 00000000 08:05 12025858                           /usr/local/bin/ruby
006c2000-006c4000 rw-p 000c2000 08:05 12025858                           /usr/local/bin/ruby
006c4000-006e1000 rw-p 006c4000 00:00 0 
106ab000-133f4000 rw-p 106ab000 00:00 0 
3ef4600000-3ef461a000 r-xp 00000000 08:01 7972263                        /lib64/ld-2.5.so
3ef4819000-3ef481a000 r--p 00019000 08:01 7972263                        /lib64/ld-2.5.so
3ef481a000-3ef481b000 rw-p 0001a000 08:01 7972263                        /lib64/ld-2.5.so
3ef4a00000-3ef4a14000 r-xp 00000000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4a14000-3ef4c13000 ---p 00014000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4c13000-3ef4c14000 rw-p 00013000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4e00000-3ef4f44000 r-xp 00000000 08:01 7972264                        /lib64/libc-2.5.so
3ef4f44000-3ef5144000 ---p 00144000 08:01 7972264                        /lib64/libc-2.5.so
3ef5144000-3ef5148000 r--p 00144000 08:01 7972264                        /lib64/libc-2.5.so
3ef5148000-3ef5149000 rw-p 00148000 08:01 7972264                        /lib64/libc-2.5.so
3ef5149000-3ef514e000 rw-p 3ef5149000 00:00 0 
3ef5200000-3ef5282000 r-xp 00000000 08:01 7972270                        /lib64/libm-2.5.so
3ef5282000-3ef5481000 ---p 00082000 08:01 7972270                        /lib64/libm-2.5.so
3ef5481000-3ef5482000 r--p 00081000 08:01 7972270                        /lib64/libm-2.5.so
3ef5482000-3ef5483000 rw-p 00082000 08:01 7972270                        /lib64/libm-2.5.so
3ef5600000-3ef5602000 r-xp 00000000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5602000-3ef5802000 ---p 00002000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5802000-3ef5803000 r--p 00002000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5803000-3ef5804000 rw-p 00003000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5a00000-3ef5a15000 r-xp 00000000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5a15000-3ef5c14000 ---p 00015000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c14000-3ef5c15000 r--p 00014000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c15000-3ef5c16000 rw-p 00015000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c16000-3ef5c1a000 rw-p 3ef5c16000 00:00 0 
3ef5e00000-3ef5e35000 r-xp 00000000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef5e35000-3ef6034000 ---p 00035000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef6034000-3ef603c000 rw-p 00034000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef603c000-3ef603d000 rw-p 3ef603c000 00:00 0 
3ef9a00000-3ef9a0d000 r-xp 00000000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3ef9a0d000-3ef9c0c000 ---p 0000d000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3ef9c0c000-3ef9c0d000 rw-p 0000c000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3efb600000-3efb614000 r-xp 00000000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb614000-3efb813000 ---p 00014000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb813000-3efb814000 r--p 00013000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb814000-3efb815000 rw-p 00014000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb815000-3efb817000 rw-p 3efb815000 00:00 0 
3efe400000-3efe525000 r-xp 00000000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe525000-3efe724000 ---p 00125000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe724000-3efe743000 rw-p 00124000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe743000-3efe747000 rw-p 3efe743000 00:00 0 
3efe800000-3efe811000 r-xp 00000000 08:01 7972272                        /lib64/libresolv-2.5.so
3efe811000-3efea11000 ---p 00011000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea11000-3efea12000 r--p 00011000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea12000-3efea13000 rw-p 00012000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea13000-3efea15000 rw-p 3efea13000 00:00 0 
3efec00000-3efec07000 r-xp 00000000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3efec07000-3efee06000 ---p 00007000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3efee06000-3efee07000 rw-p 00006000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3eff400000-3eff402000 r-xp 00000000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff402000-3eff601000 ---p 00002000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff601000-3eff602000 rw-p 00001000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff800000-3eff884000 r-xp 00000000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3eff884000-3effa84000 ---p 00084000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3effa84000-3effa88000 rw-p 00084000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3effc00000-3effc23000 r-xp 00000000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3effc23000-3effe23000 ---p 00023000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3effe23000-3effe25000 rw-p 00023000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3f00400000-3f00429000 r-xp 00000000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00429000-3f00628000 ---p 00029000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00628000-3f0062a000 rw-p 00028000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00800000-3f00843000 r-xp 00000000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f00843000-3f00a43000 ---p 00043000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f00a43000-3f00a49000 rw-p 00043000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f02000000-3f02133000 r-xp 00000000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f02133000-3f02333000 ---p 00133000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f02333000-3f0233c000 rw-p 00133000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f0233c000-3f0233d000 rw-p 3f0233c000 00:00 0 
3f02800000-3f02805000 r-xp 00000000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02805000-3f02a04000 ---p 00005000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a04000-3f02a05000 r--p 00004000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a05000-3f02a06000 rw-p 00005000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a06000-3f02a34000 rw-p 3f02a06000 00:00 0 
3f07800000-3f0784f000 r-xp 00000000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f0784f000-3f07a4e000 ---p 0004f000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f07a4e000-3f07a5c000 rw-p 0004e000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f07a5c000-3f07a5d000 rw-p 3f07a5c000 00:00 0 
2aaaaaaab000-2aaaaaaaf000 rw-p 2aaaaaaab000 00:00 0 
2aaaaaad6000-2aaaaab3b000 rw-p 2aaaaaad6000 00:00 0 
2aaaaab3c000-2aaaaabec000 rw-p 2aaaaab3c000 00:00 0 
2aaaaabec000-2aaaaabf6000 r-xp 00000000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaabf6000-2aaaaadf6000 ---p 0000a000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaadf6000-2aaaaadf7000 rw-p 0000a000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaadf7000-2aaaaadfb000 r-xp 00000000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaadfb000-2aaaaaffb000 ---p 00004000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaaffb000-2aaaaaffc000 rw-p 00004000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaaffc000-2aaaab018000 r-xp 00000000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab018000-2aaaab217000 ---p 0001c000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab217000-2aaaab218000 rw-p 0001b000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab218000-2aaaab219000 rw-p 2aaaab218000 00:00 0 
2aaaab21a000-2aaaab357000 rw-p 2aaaab21a000 00:00 0 
2aaaab357000-2aaaab35f000 r-xp 00000000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab35f000-2aaaab55f000 ---p 00008000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab55f000-2aaaab560000 rw-p 00008000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab560000-2aaaab563000 r-xp 00000000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab563000-2aaaab762000 ---p 00003000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab762000-2aaaab763000 rw-p 00002000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab763000-2aaaab766000 r-xp 00000000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab766000-2aaaab965000 ---p 00003000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab965000-2aaaab966000 rw-p 00002000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab966000-2aaaab99f000 r-xp 00000000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaab99f000-2aaaabb9f000 ---p 00039000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaabb9f000-2aaaabba2000 rw-p 00039000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaabba2000-2aaaabba3000 r-xp 00000000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabba3000-2aaaabda2000 ---p 00001000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabda2000-2aaaabda3000 rw-p 00000000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabda3000-2aaaabfdd000 rw-p 2aaaabda3000 00:00 0 
2aaaabfdd000-2aaaabfdf000 r-xp 00000000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaabfdf000-2aaaac1de000 ---p 00002000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaac1de000-2aaaac1df000 rw-p 00001000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaac1df000-2aaaac1e4000 r-xp 00000000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac1e4000-2aaaac3e4000 ---p 00005000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac3e4000-2aaaac3e5000 rw-p 00005000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac3e5000-2aaaac3e9000 r-xp 00000000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac3e9000-2aaaac5e8000 ---p 00004000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac5e8000-2aaaac5e9000 rw-p 00003000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac5e9000-2aaaac9eb000 rw-p 2aaaac5e9000 00:00 0 
2aaaac9eb000-2aaaac9ef000 r-xp 00000000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaac9ef000-2aaaacbee000 ---p 00004000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaacbee000-2aaaacbef000 rw-p 00003000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaacbef000-2aaaacbf9000 r-xp 00000000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacbf9000-2aaaacdf9000 ---p 0000a000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacdf9000-2aaaacdfa000 rw-p 0000a000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacdfa000-2aaaace36000 r-xp 00000000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaace36000-2aaaad036000 ---p 0003c000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaad036000-2aaaad03a000 rw-p 0003c000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaad03a000-2aaaad03b000 rw-p 2aaaad03a000 00:00 0 
2aaaad03c000-2aaaad772000 rw-p 2aaaad03c000 00:00 0 
2aaaad772000-2aaaad783000 r-xp 00000000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad783000-2aaaad882000 ---p 00011000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad882000-2aaaad884000 rw-p 00010000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad884000-2aaaad8a7000 rw-p 2aaaad884000 00:00 0 
2aaaad8ae000-2aaaad986000 r-xp 00000000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaad986000-2aaaadb86000 ---p 000d8000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaadb86000-2aaaadb8b000 rw-p 000d8000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaadb8b000-2aaaadba9000 rw-p 2aaaadb8b000 00:00 0 
2aaaadba9000-2aaaaed60000 r-xp 00000000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaed60000-2aaaaee60000 ---p 011b7000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaee60000-2aaaaef01000 rw-p 011b7000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaef01000-2aaaaef15000 rw-p 2aaaaef01000 00:00 0 
2aaaaef15000-2aaaaf206000 r-xp 00000000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf206000-2aaaaf305000 ---p 002f1000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf305000-2aaaaf3b5000 rw-p 002f0000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf3b5000-2aaaaf3b7000 rw-p 2aaaaf3b5000 00:00 0 
2aaaaf3b7000-2aaab369a000 r-xp 00000000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab369a000-2aaab379a000 ---p 042e3000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab379a000-2aaab379c000 rw-p 042e3000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab379c000-2aaab37fb000 rw-p 2aaab379c000 00:00 0 
2aaab37fb000-2aaab37fc000 r-xp 00000000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab37fc000-2aaab39fb000 ---p 00001000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab39fb000-2aaab39fc000 rw-p 00000000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab39fc000-2aaab39ff000 r-xp 00000000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab39ff000-2aaab3bff000 ---p 00003000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab3bff000-2aaab3c00000 rw-p 00003000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab3c00000-2aaab3c04000 r-xp 00000000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3c04000-2aaab3e03000 ---p 00004000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3e03000-2aaab3e04000 rw-p 00003000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3e04000-2aaab4aff000 rw-p 2aaab3e04000 00:00 0 
2aaab4aff000-2aaab4b20000 r-xp 00000000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4b20000-2aaab4d20000 ---p 00021000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4d20000-2aaab4d22000 rw-p 00021000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4d4c000-2aaab4d56000 r-xp 00000000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4d56000-2aaab4f55000 ---p 0000a000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f55000-2aaab4f56000 r--p 00009000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f56000-2aaab4f57000 rw-p 0000a000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f57000-2aaab5027000 rw-p 2aaab4f57000 00:00 0 
2aaab5027000-2aaab502b000 r-xp 00000000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab502b000-2aaab522b000 ---p 00004000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab522b000-2aaab522c000 rw-p 00004000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab522e000-2aaab5235000 r--s 00000000 08:01 9409795                    /usr/lib64/gconv/gconv-modules.cache
2aaab5235000-2aaab5236000 r-xp 00000000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab5236000-2aaab5436000 ---p 00001000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab5436000-2aaab5438000 rw-p 00001000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab8000000-2aaab8021000 rw-p 2aaab8000000 00:00 0 
2aaab8021000-2aaabc000000 ---p 2aaab8021000 00:00 0 
7fff7ca80000-7fff7cad2000 rwxp 7fff7ca80000 00:00 0                      [stack]
7fff7cad2000-7fff7cad4000 rw-p 7fff7cad2000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

----------------------------------------------------------------------

Comment By: Saurabh Nanda (saurabhnanda)
Date: 2008-02-05 07:17

Message:
I think I'm also facing a similar issue. I'm on a 64 bit Intel machine with libxml-ruby-0.5.2. I'm trying to write a long running RESTful service in Rails. After the first few XML POSTs to the Rails server, it suddenly segfaults.

I can attach the error log. How do I attach a file?

----------------------------------------------------------------------

Comment By: Dan Janowski (danj)
Date: 2007-08-30 07:16

Message:
There is a new memory model released but I do not have this system combo to test. Please take a few minutes and go to the project page and download the MEM2 release 0.5.0 and run the rwtest/doc_file.rb from the 'ext' directory (to use the local build instead of a system installed libxml). Please follow up.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8337&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:38:02 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:38:02 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-9883 ] call-seq for
	ruby_xml_document_validate_schema is incorrect
Message-ID: <20080709173802.BDE7218585BC@rubyforge.org>

Bugs item #9883, was opened at 2007-04-05 12:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9883&group_id=494

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: Charlie Savage (cfis)
Summary: call-seq for ruby_xml_document_validate_schema is incorrect

Initial Comment:
Should be

document.validate_schema

not

document.validate

----------------------------------------------------------------------

Comment By: Charlie Savage (cfis)
Date: 2008-07-09 02:57

Message:
Thanks - fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=9883&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:39:52 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:39:52 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-11766 ] XML::Node#<< behaving
	strangely, causing memory deallocation errors and wreacking havoc
Message-ID: <20080709173952.74EE818585B7@rubyforge.org>

Bugs item #11766, was opened at 2007-06-22 03:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=11766&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: XML::Node#<< behaving strangely, causing memory deallocation errors and wreacking havoc

Initial Comment:
The following code does two strange things:
1) returns
<n_doc><foo/>
    <bar/>
  </n_doc>
when it should return
<n_doc>
<foo/>
</n_doc>

2) Causes strange errors:
ruby(4680) malloc: ***  Deallocation of a pointer not malloced: 0x5090c0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
ruby(4680) malloc: ***  Deallocation of a pointer not malloced: 0x509150; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
ruby(4680) malloc: ***  Deallocation of a pointer not malloced: 0x5091a0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
ruby(4680) malloc: ***  Deallocation of a pointer not malloced: 0x5091f0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug


The code:
require 'rubygems'
require 'xml/libxml'

source = %{<?xml version="1.0"?>
<root>
  <data>
    <foo/>
    <bar/>
  </data>
</root>
}

p = XML::Parser.string(source)
doc = p.parse

data = doc.find('data').first
nodes = data.find('foo')

n_doc = XML::Node.new('n_doc')
n_doc << nodes.first

print n_doc

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:39

Message:
This now works as expected.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=11766&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:41:03 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:41:03 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19589 ] node.find_first() returns a
	node, but find() on the returned node searches parent node
Message-ID: <20080709174103.954D818585C2@rubyforge.org>

Bugs item #19589, was opened at 2008-04-16 12:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19589&group_id=494

Category: General
Group: v0.5
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jamie Orchard-Hays (jamieorc)
>Assigned to: Charlie Savage (cfis)
Summary: node.find_first() returns a node, but find() on the returned node searches parent node

Initial Comment:
Here's an example:

meta = root.find_first('//meta')

correct_hits = root.find('//meta//hit')  => yields just the meta hit
too_many_hits = meta.find('//hit')       => yields all 3 hits

I expect meta.find() to search the context of the meta node, but it does not.

here's the XML for the example

<docHit>
  <meta>
    <hit>a meta hit</hit>
  </meta>
  <hit> a non-meta hit</hit>
  <hit> another non-meta hit</hit>
</docHit>

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:41

Message:
Also, there no longer appears to be a find_first method on node.

----------------------------------------------------------------------

Comment By: Mark Thomas (markthomas)
Date: 2008-04-16 17:06

Message:
Not a bug. The XPath spec treats a *leading* // as an absolute path from the root. Try meta.find('.//hit') to see if it makes a difference.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19589&group_id=494

From noreply at rubyforge.org  Wed Jul  9 13:43:26 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  9 Jul 2008 13:43:26 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-11836 ] NULL pointer in XML::Node#base
	when no xml:base attribute is present
Message-ID: <20080709174326.54C0718585C8@rubyforge.org>

Bugs item #11836, was opened at 2007-06-25 12:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=11836&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: NULL pointer in XML::Node#base when no xml:base attribute is present

Initial Comment:
When a XML::Node#base is called on a node in a document with no xml:base attribute, a NULL pointer error is raised, as this irb session shows:

>> parser = XML::Parser.string('<person />')
=> #<XML::Parser:0x10275c8>
>> doc = parser.parse
=> <?xml version="1.0"?>
<person/>

>> doc.root.base
ArgumentError: NULL pointer given
        from (irb):31:in `base'
        from (irb):31


----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:43

Message:
This now returns nil instead of raising an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=11836&group_id=494

From sean at chittenden.org  Wed Jul  9 16:07:43 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 9 Jul 2008 13:07:43 -0700
Subject: [libxml-devel] Changing node equality
In-Reply-To: <95d2127e-da83-47b8-93ca-f374500ed535@m73g2000hsh.googlegroups.com>
References: <4871C34E.3060908@savagexi.com>
	<CB761BBE-280D-4EDF-A500-B1193C667F16@3skel.com>
	<4872DCE8.8080400@savagexi.com>
	<1b52ec0a-d0d5-4e00-a5ec-331f513efba2@i76g2000hsf.googlegroups.com>
	<48738FF6.8010300@savagexi.com>
	<80311c05-fca2-46ac-a3af-ae8a5aa97cc6@i76g2000hsf.googlegroups.com>
	<4873B3D1.8050306@savagexi.com>
	<95d2127e-da83-47b8-93ca-f374500ed535@m73g2000hsh.googlegroups.com>
Message-ID: <97FEC3D5-8AB1-45FE-BD1B-C5A21053B75D@chittenden.org>

>> Not the same thing. Comparing raw XML string is overly strict. For
>> example I would expect the following two snips to be "equal":
>
>  <root><foo bar="10" baz="20">Hi</foo></root
>
> and
>
>  <root>
>    <foo baz="20" bar="10">
>      Hi
>    </foo>
>  </root>
>
> These would not be equal by string comparison b/c the attribute bar
> and baz are not in the same order (to say nothing of white space).

Actually, they're not equal for a different reasons.  You have to  
enable whitespace stripping on document load, then they would be  
correct.  Internally, XML sees the above fragment like:

  <root>[whitespace, including newline]<foo baz="20" bar="10">
      Hi
    </foo>[whitespace, including newline]</root>

Whitespace is a special XML node that exists between elements.  <:~/   
Not ideal, and not something I agree with, but...

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Wed Jul  9 16:10:35 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 9 Jul 2008 13:10:35 -0700
Subject: [libxml-devel] [Fwd: [ruby-core:17694] Mark functions not
	called on exit]
In-Reply-To: <48747987.5040808@savagexi.com>
References: <48747987.5040808@savagexi.com>
Message-ID: <2E7A4BD8-80E2-4014-8CD8-71599A3A1CCA@chittenden.org>

> After puzzling over it for a bit, I realized the problem is that  
> Mark functions for C objects are not being called when Ruby exits.

> In the meantime, curious if anyone has any ideas on how to solve the  
> issue.


Ready for a gross solution?  Force the garbage collector to run via an  
atexit(3) hook.  *pukes*  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul  9 16:16:13 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 09 Jul 2008 14:16:13 -0600
Subject: [libxml-devel] [Fwd: [ruby-core:17694] Mark functions
 not	called on exit]
In-Reply-To: <2E7A4BD8-80E2-4014-8CD8-71599A3A1CCA@chittenden.org>
References: <48747987.5040808@savagexi.com>
	<2E7A4BD8-80E2-4014-8CD8-71599A3A1CCA@chittenden.org>
Message-ID: <48751C8D.4050608@savagexi.com>



Sean Chittenden wrote:
>> After puzzling over it for a bit, I realized the problem is that Mark 
>> functions for C objects are not being called when Ruby exits.
> 
>> In the meantime, curious if anyone has any ideas on how to solve the 
>> issue.
> 
> 
> Ready for a gross solution?  Force the garbage collector to run via an 
> atexit(3) hook.  *pukes*  -sc

Hah - I thought about it!

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080709/6e524e97/attachment.bin>

From cfis at savagexi.com  Wed Jul  9 16:33:36 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 09 Jul 2008 14:33:36 -0600
Subject: [libxml-devel] And onto libxml-ruby 0.7.0
Message-ID: <487520A0.6070908@savagexi.com>

Ok, I've just pushed up a 0.7.0 libxml release.  I thought about calling 
it 0.6.1, but there were both API changes (attributes) and a fair number 
of internal changes, so I went with 0.7.0.

I also marked this release as stable - at this point I think the library 
is in good shape.  So please download it and give it a spin.

Changes:

* Added new attributes class to provide a more natural way of working 
with attributes

* Fixed XML::Attr to better support namespaces

* Added documentation on how to use namespaces with XPath

* Removed allocation of extraneous structures used to wrap nodes, 
namespaces and attributes

* Cleaned up tests and added new test suite

* Updated rdocs and README file

* Cleaned out most of the bug list

* Fixed up eql? test

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080709/c11c75c1/attachment-0001.bin>

From cfis at savagexi.com  Wed Jul  9 16:43:55 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 09 Jul 2008 14:43:55 -0600
Subject: [libxml-devel] Need permission to update rdocs
Message-ID: <4875230B.7000502@savagexi.com>

I'd like to update the rdocs online at:

http://libxml.rubyforge.org/rdoc/

Except when I try I get a permission errors.

Trans, Dan or Sean, can you either do this or alternatively give me 
permission to?

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080709/979ce9fe/attachment.bin>

From paul at aps.org  Wed Jul  9 22:10:29 2008
From: paul at aps.org (Paul Dlug)
Date: Wed, 9 Jul 2008 22:10:29 -0400
Subject: [libxml-devel] DTD's still loaded when default_load_external_dtd is
	false
Message-ID: <8CBA524D-218A-4802-A875-B07D40E27A8A@aps.org>

Even if XML::Parser.default_load_external_dtd is set to false the  
parser loads the DTD, see test script:

require 'xml/libxml'

xml = <<TEST
<test><title>T1</title></test>
TEST

xmldtd = <<TEST
<!DOCTYPE test PUBLIC "-//TEST" "test.dtd" []>
<test><title>T1</title></test>
TEST

XML::Parser.default_load_external_dtd = false

puts XML::Document.string(xml).root.find_first('title')
puts XML::Document.string(xmldtd).root.find_first('title')


This generates the output:

<title>T1</title>
I/O warning : failed to load external entity "test.dtd"
<!DOCTYPE test PUBLIC "-//TEST" "test.dtd" []>
                                               ^
<title>T1</title>

I can suppress the warnings with default_warnings=false but this is  
not the issue, the parser still attempts to load the DTD. In the case  
above the DTD does not exist so no harm is done. In another test case  
I have the DTD does exist but should not be loaded, in this case the  
bug makes it impossible to work with the XML.


--Paul

From shimbo at is.naist.jp  Wed Jul  9 23:54:43 2008
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Thu, 10 Jul 2008 12:54:43 +0900
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <20080709173738.5B60E15B8002@rubyforge.org>
References: <20080709173738.5B60E15B8002@rubyforge.org>
Message-ID: <989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>

Hello,

> require 'xml/libxml'
>
> (1..10000).each{|time|
>  XML::Document.file('test.xml')
>  p time if time % 100 == 0
> }

>>Comment By: Charlie Savage (cfis)
> Date: 2008-07-09 11:37
>
> Message:
> I assume this is now fixed with the new memory model.

It won't segfault anymore, but now I get the following error:

$ ruby libxml-test.rb
100
200
Too many open filesI/O warning : failed to load external entity "test.xml"
libxml-test.rb:7:in `file': test.xml (IOError)
	from libxml-test.rb:7
	from libxml-test.rb:6:in `each'
	from libxml-test.rb:6

However, the error disappears if "GC.start" is inserted just above
XML::Document.file(...).

This happens with libxml-ruby 0.7.0 (gem), but it has been the same
since the new memory model was first introduced.

The tested platforms are:
Mac OS 10.5.4 (Intel) and Ubuntu Linux 8.04 (i686).

Masashi Shimbo

From cfis at savagexi.com  Thu Jul 10 02:53:01 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 00:53:01 -0600
Subject: [libxml-devel] DTD's still loaded when
 default_load_external_dtd is	false
In-Reply-To: <8CBA524D-218A-4802-A875-B07D40E27A8A@aps.org>
References: <8CBA524D-218A-4802-A875-B07D40E27A8A@aps.org>
Message-ID: <4875B1CD.1040201@savagexi.com>

Hi Paul,

> Even if XML::Parser.default_load_external_dtd is set to false the parser 
> loads the DTD, see test script:

Upgrade to the latest libxml version (0.7.0) - it works fine here.  I've 
added your test case to tests/tc_xml_dtd.rb (in SVN, but not in the 
0.7.0 release).

   def test_external_dtd
     xml = <<-EOS
       <!DOCTYPE test PUBLIC "-//TEST" "test.dtd" []>
       <test>
         <title>T1</title>
       </test>
     EOS

     messages = Array.new
     XML::Parser.register_error_handler(lambda { |msg| messages << msg })

     XML::Parser.default_load_external_dtd = false
     doc = XML::Parser.string(xml).parse
     assert_equal(Array.new, messages)

     XML::Parser.default_load_external_dtd = true
     doc = XML::Parser.string(xml).parse
     assert_equal('I/O warning : failed to load external entity 
"test.dtd" <!DOCTYPE test PUBLIC "-//TEST" "test.dtd" []> ^',
                  messages.map{|msg| msg.strip}.join(' '))
   end

> I can suppress the warnings with default_warnings=false but this is not 
> the issue, the parser still attempts to load the DTD. In the case above 
> the DTD does not exist so no harm is done. In another test case I have 
> the DTD does exist but should not be loaded, in this case the bug makes 
> it impossible to work with the XML.

Upgrade, and see if the problem disappears.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/fe24dfcc/attachment.bin>

From cfis at savagexi.com  Thu Jul 10 03:13:18 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 01:13:18 -0600
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
 segfault on fbsd-amd64
In-Reply-To: <989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>
	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>
Message-ID: <4875B68E.9090002@savagexi.com>

Hi Masashi,

>> require 'xml/libxml'
>>
>> (1..10000).each{|time|
>>  XML::Document.file('test.xml')
>>  p time if time % 100 == 0
>> }
> 
> It won't segfault anymore, but now I get the following error:
> 
> Too many open filesI/O warning : failed to load external entity "test.xml"
> libxml-test.rb:7:in `file': test.xml (IOError)
> 	from libxml-test.rb:7
> 	from libxml-test.rb:6:in `each'
> 	from libxml-test.rb:6
> 
> However, the error disappears if "GC.start" is inserted just above
> XML::Document.file(...).

Right.  This is another Ruby GC issue.  If you don't call GC.start, then 
  all the documents that you have created remain open.  I assume this 
causes the OS to eventually run out of file handles, thus resulting in 
the error (which is being raised by libxml not Ruby).

By calling GC.start, the documents are freed and the file handles are 
released.

So I don't see this as a bug in the libxml bindings.

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/813552d5/attachment.bin>

From shimbo at is.naist.jp  Thu Jul 10 04:26:49 2008
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Thu, 10 Jul 2008 17:26:49 +0900
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <4875B68E.9090002@savagexi.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>
	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>
	<4875B68E.9090002@savagexi.com>
Message-ID: <989032930807100126s66a6e1dcuc892ff97e2008ddb@mail.gmail.com>

Hi,

>> However, the error disappears if "GC.start" is inserted just above
>> XML::Document.file(...).
>
> Right.  This is another Ruby GC issue.  If you don't call GC.start, then
>  all the documents that you have created remain open.  I assume this causes
> the OS to eventually run out of file handles, thus resulting in the error
> (which is being raised by libxml not Ruby).
>
> By calling GC.start, the documents are freed and the file handles are
> released.
>
> So I don't see this as a bug in the libxml bindings.

Maybe you are right, but if I change XML::Document.file("test.xml")
to File.open("test.xml"), I won't run out of file handles.

I wonder what makes the difference...

And if I remember correctly, even the original test code with
libxml-ruby 3.8 did not run out of file handles on 32bit intel machines
either - the reported segfault only affected the amd64 (and maybe
other) architecture.

Masashi

From ast at atownley.org  Thu Jul 10 10:58:00 2008
From: ast at atownley.org (Andrew S. Townley)
Date: Thu, 10 Jul 2008 15:58:00 +0100
Subject: [libxml-devel] Back
In-Reply-To: <A278C778-E30D-49ED-9FF8-14B78B20579E@chittenden.org>
References: <47f5e8dd-0c0d-41a0-973a-f14b818c1881@79g2000hsk.googlegroups.com>
	<486D094E.5010506@savagexi.com>
	<4f0b5e5c-f5b2-43db-8284-55206e51e1dc@27g2000hsf.googlegroups.com>
	<4871B8D4.7050108@savagexi.com>
	<7CAE470C-442D-4460-8CBD-8CC0FD666AD7@chittenden.org>
	<4872667B.1020401@savagexi.com>
	<A278C778-E30D-49ED-9FF8-14B78B20579E@chittenden.org>
Message-ID: <1215701880.8997.8.camel@linna>

On Mon, 2008-07-07 at 11:57 -0700, Sean Chittenden wrote:
> >> Is there any reason to nuke 'em?  -sc
> >
> > I was thinking more along the lines of whether there is any reason  
> > to keep them.
> >
> > My thinking in getting rid of them is the repository will have less  
> > clutter (less code) and check out times will be significantly  
> > reduced. Since they are now dead code, having them hang around just  
> > adds to the mental burden of getting up to speed with the library.
> 
> 
> Oh yeah!  @#!$  Subversion.  :(  Hrm.  Tom says he's going to add  
> mercurial support next to rubyforge so I'd hold onto 'em for the time  
> being since that overhead will vanish upon import.  <:~]  -sc

Been away for a bit, so sorry for the time lag, but....

doesn't this aspect of SVN sorta defeat the purpose of a VCS? (not
wanting to start/continue VCS wars, btw).

I agree with Sean.  They should all be kept until migration to a
different/better tool, otherwise you might as well start nuking them
after every release. ;)

ast
-- 
Andrew S. Townley <ast at atownley.org>
http://atownley.org


From todd.fisher at gmail.com  Thu Jul 10 11:50:46 2008
From: todd.fisher at gmail.com (Todd Fisher)
Date: Thu, 10 Jul 2008 11:50:46 -0400
Subject: [libxml-devel] SaxParser
Message-ID: <e9a952090807100850r19f9abe8j5fdbc6f7e771d874@mail.gmail.com>

I'm wondering if there are any plans to support reading from a socket
to send data through the SaxParser.   If I'm not mistaken it currently
has a .string= and .filename = method.

Thanks,
Todd

From aaron.patterson at gmail.com  Thu Jul 10 13:52:18 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Thu, 10 Jul 2008 10:52:18 -0700
Subject: [libxml-devel] running tests from svn
Message-ID: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>

Hi!

I'm trying to compile and run the tests from trunk.  As far as I can
tell, you just run setup.rb.  Is that correct?  The tests don't seem
to run for me when I do that.  I tried running the tests individually,
but it seems libxml.rb is doing a require on 'libxml_ruby.so' which
doesn't exist on OS X.  Is the require on the so file intentional?

Thanks!

-- 
Aaron Patterson
http://tenderlovemaking.com/

From noreply at rubyforge.org  Thu Jul 10 03:15:09 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 10 Jul 2008 03:15:09 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
Message-ID: <20080710071510.61E5B1858289@rubyforge.org>

Bugs item #8337, was opened at 2007-01-31 10:47
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8337&group_id=494

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: Charlie Savage (cfis)
Summary: Opening many files causes segfault on fbsd-amd64

Initial Comment:
I have a number of xml files I'm parsing, and it seems the libxml-ruby will cause a segfault if I open too many files too quickly.

For example, if your script test.rb is:
--
require 'xml/libxml'

(1..10000).each{|time|
  XML::Document.file('test.xml')
  p time if time % 100 == 0
}
--
and test.xml is
--
<?xml version="1.0"?>
<test/>
--
Then, on fbsd-amd64, you'll see
100
200
300
400
500
test.rb:5: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [amd64-freebsd6]

zsh: abort (core dumped)  ruby test.rb


It seems to error in the same place every time.  Interestingly, for so short an XML file, if you remove the if clause from the p statement, there won't be any errors, however longer XML files will still suffer this problem.  More interestingly, the problem can be avoided entirely by disabling the GC.

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-10 01:15

Message:
For follow up see thread at:

http://rubyforge.org/pipermail/libxml-devel/2008-July/000890.html

----------------------------------------------------------------------

Comment By: Charlie Savage (cfis)
Date: 2008-07-09 11:37

Message:
I assume this is now fixed with the new memory model.

----------------------------------------------------------------------

Comment By: Saurabh Nanda (saurabhnanda)
Date: 2008-02-05 07:19

Message:
Here's the error log. I don't know what'll happen to the formatting, though:


*** glibc detected *** /usr/local/bin/ruby: double free or corruption (out): 0x0000000012933740 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ef4e6e8a0]
/lib64/libc.so.6(cfree+0x8c)[0x3ef4e71fbc]
/usr/lib64/libxml2.so.2(xmlCharEncCloseFunc+0x51)[0x3f0202def1]
/usr/lib64/libxml2.so.2(xmlFreeParserInputBuffer+0x2d)[0x3f02057efd]
/usr/lib64/libxml2.so.2(xmlFreeInputStream+0x67)[0x3f020322a7]
/usr/lib64/libxml2.so.2(xmlFreeParserCtxt+0x19)[0x3f020322e9]
/home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so(ruby_xml_parser_context_free+0x11)[0x2aaab4b17721]
/usr/local/bin/ruby[0x42d1b2]
/usr/local/bin/ruby(ruby_xmalloc+0x67)[0x42d5c7]
/usr/local/bin/ruby[0x40e14d]
/usr/local/bin/ruby[0x4114fe]
/usr/local/bin/ruby[0x417a21]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby(rb_ary_each+0x23)[0x4808f3]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby[0x419e52]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x4177e2]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416d5e]
/usr/local/bin/ruby[0x415cb3]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby(rb_funcall2+0x32)[0x41b272]
/usr/local/bin/ruby[0x41cf58]
/usr/local/bin/ruby[0x41b136]
/usr/local/bin/ruby[0x4234b1]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x420104]
/usr/local/bin/ruby[0x4161fb]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x416c26]
/usr/local/bin/ruby[0x417eba]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby(rb_ary_each+0x23)[0x4808f3]
/usr/local/bin/ruby[0x41a33d]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x4171c7]
/usr/local/bin/ruby[0x41aba1]
/usr/local/bin/ruby[0x41b058]
/usr/local/bin/ruby[0x4166ce]
/usr/local/bin/ruby[0x41918d]
/usr/local/bin/ruby[0x419e52]
======= Memory map: ========
00400000-004c2000 r-xp 00000000 08:05 12025858                           /usr/local/bin/ruby
006c2000-006c4000 rw-p 000c2000 08:05 12025858                           /usr/local/bin/ruby
006c4000-006e1000 rw-p 006c4000 00:00 0 
106ab000-133f4000 rw-p 106ab000 00:00 0 
3ef4600000-3ef461a000 r-xp 00000000 08:01 7972263                        /lib64/ld-2.5.so
3ef4819000-3ef481a000 r--p 00019000 08:01 7972263                        /lib64/ld-2.5.so
3ef481a000-3ef481b000 rw-p 0001a000 08:01 7972263                        /lib64/ld-2.5.so
3ef4a00000-3ef4a14000 r-xp 00000000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4a14000-3ef4c13000 ---p 00014000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4c13000-3ef4c14000 rw-p 00013000 08:01 6175180                        /usr/lib64/libz.so.1.2.3
3ef4e00000-3ef4f44000 r-xp 00000000 08:01 7972264                        /lib64/libc-2.5.so
3ef4f44000-3ef5144000 ---p 00144000 08:01 7972264                        /lib64/libc-2.5.so
3ef5144000-3ef5148000 r--p 00144000 08:01 7972264                        /lib64/libc-2.5.so
3ef5148000-3ef5149000 rw-p 00148000 08:01 7972264                        /lib64/libc-2.5.so
3ef5149000-3ef514e000 rw-p 3ef5149000 00:00 0 
3ef5200000-3ef5282000 r-xp 00000000 08:01 7972270                        /lib64/libm-2.5.so
3ef5282000-3ef5481000 ---p 00082000 08:01 7972270                        /lib64/libm-2.5.so
3ef5481000-3ef5482000 r--p 00081000 08:01 7972270                        /lib64/libm-2.5.so
3ef5482000-3ef5483000 rw-p 00082000 08:01 7972270                        /lib64/libm-2.5.so
3ef5600000-3ef5602000 r-xp 00000000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5602000-3ef5802000 ---p 00002000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5802000-3ef5803000 r--p 00002000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5803000-3ef5804000 rw-p 00003000 08:01 7972269                        /lib64/libdl-2.5.so
3ef5a00000-3ef5a15000 r-xp 00000000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5a15000-3ef5c14000 ---p 00015000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c14000-3ef5c15000 r--p 00014000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c15000-3ef5c16000 rw-p 00015000 08:01 7972265                        /lib64/libpthread-2.5.so
3ef5c16000-3ef5c1a000 rw-p 3ef5c16000 00:00 0 
3ef5e00000-3ef5e35000 r-xp 00000000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef5e35000-3ef6034000 ---p 00035000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef6034000-3ef603c000 rw-p 00034000 08:01 9365090                        /usr/lib64/libreadline.so.5.1
3ef603c000-3ef603d000 rw-p 3ef603c000 00:00 0 
3ef9a00000-3ef9a0d000 r-xp 00000000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3ef9a0d000-3ef9c0c000 ---p 0000d000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3ef9c0c000-3ef9c0d000 rw-p 0000c000 08:01 7972150                        /lib64/libgcc_s-4.1.1-20070105.so.1
3efb600000-3efb614000 r-xp 00000000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb614000-3efb813000 ---p 00014000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb813000-3efb814000 r--p 00013000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb814000-3efb815000 rw-p 00014000 08:01 7972283                        /lib64/libnsl-2.5.so
3efb815000-3efb817000 rw-p 3efb815000 00:00 0 
3efe400000-3efe525000 r-xp 00000000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe525000-3efe724000 ---p 00125000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe724000-3efe743000 rw-p 00124000 08:01 7972274                        /lib64/libcrypto.so.0.9.8b
3efe743000-3efe747000 rw-p 3efe743000 00:00 0 
3efe800000-3efe811000 r-xp 00000000 08:01 7972272                        /lib64/libresolv-2.5.so
3efe811000-3efea11000 ---p 00011000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea11000-3efea12000 r--p 00011000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea12000-3efea13000 rw-p 00012000 08:01 7972272                        /lib64/libresolv-2.5.so
3efea13000-3efea15000 rw-p 3efea13000 00:00 0 
3efec00000-3efec07000 r-xp 00000000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3efec07000-3efee06000 ---p 00007000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3efee06000-3efee07000 rw-p 00006000 08:01 9352632                        /usr/lib64/libkrb5support.so.0.1
3eff400000-3eff402000 r-xp 00000000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff402000-3eff601000 ---p 00002000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff601000-3eff602000 rw-p 00001000 08:01 7972273                        /lib64/libcom_err.so.2.1
3eff800000-3eff884000 r-xp 00000000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3eff884000-3effa84000 ---p 00084000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3effa84000-3effa88000 rw-p 00084000 08:01 6175186                        /usr/lib64/libkrb5.so.3.2
3effc00000-3effc23000 r-xp 00000000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3effc23000-3effe23000 ---p 00023000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3effe23000-3effe25000 rw-p 00023000 08:01 6175185                        /usr/lib64/libk5crypto.so.3.0
3f00400000-3f00429000 r-xp 00000000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00429000-3f00628000 ---p 00029000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00628000-3f0062a000 rw-p 00028000 08:01 6175187                        /usr/lib64/libgssapi_krb5.so.2.2
3f00800000-3f00843000 r-xp 00000000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f00843000-3f00a43000 ---p 00043000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f00a43000-3f00a49000 rw-p 00043000 08:01 7972275                        /lib64/libssl.so.0.9.8b
3f02000000-3f02133000 r-xp 00000000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f02133000-3f02333000 ---p 00133000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f02333000-3f0233c000 rw-p 00133000 08:01 6175181                        /usr/lib64/libxml2.so.2.6.26
3f0233c000-3f0233d000 rw-p 3f0233c000 00:00 0 
3f02800000-3f02805000 r-xp 00000000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02805000-3f02a04000 ---p 00005000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a04000-3f02a05000 r--p 00004000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a05000-3f02a06000 rw-p 00005000 08:01 7972280                        /lib64/libcrypt-2.5.so
3f02a06000-3f02a34000 rw-p 3f02a06000 00:00 0 
3f07800000-3f0784f000 r-xp 00000000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f0784f000-3f07a4e000 ---p 0004f000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f07a4e000-3f07a5c000 rw-p 0004e000 08:01 9352576                        /usr/lib64/libncurses.so.5.5
3f07a5c000-3f07a5d000 rw-p 3f07a5c000 00:00 0 
2aaaaaaab000-2aaaaaaaf000 rw-p 2aaaaaaab000 00:00 0 
2aaaaaad6000-2aaaaab3b000 rw-p 2aaaaaad6000 00:00 0 
2aaaaab3c000-2aaaaabec000 rw-p 2aaaaab3c000 00:00 0 
2aaaaabec000-2aaaaabf6000 r-xp 00000000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaabf6000-2aaaaadf6000 ---p 0000a000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaadf6000-2aaaaadf7000 rw-p 0000a000 08:05 12649070                   /usr/local/lib/ruby/1.8/x86_64-linux/socket.so
2aaaaadf7000-2aaaaadfb000 r-xp 00000000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaadfb000-2aaaaaffb000 ---p 00004000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaaffb000-2aaaaaffc000 rw-p 00004000 08:05 12649051                   /usr/local/lib/ruby/1.8/x86_64-linux/stringio.so
2aaaaaffc000-2aaaab018000 r-xp 00000000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab018000-2aaaab217000 ---p 0001c000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab217000-2aaaab218000 rw-p 0001b000 08:05 12649067                   /usr/local/lib/ruby/1.8/x86_64-linux/syck.so
2aaaab218000-2aaaab219000 rw-p 2aaaab218000 00:00 0 
2aaaab21a000-2aaaab357000 rw-p 2aaaab21a000 00:00 0 
2aaaab357000-2aaaab35f000 r-xp 00000000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab35f000-2aaaab55f000 ---p 00008000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab55f000-2aaaab560000 rw-p 00008000 08:05 12649048                   /usr/local/lib/ruby/1.8/x86_64-linux/zlib.so
2aaaab560000-2aaaab563000 r-xp 00000000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab563000-2aaaab762000 ---p 00003000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab762000-2aaaab763000 rw-p 00002000 08:05 12649046                   /usr/local/lib/ruby/1.8/x86_64-linux/digest.so
2aaaab763000-2aaaab766000 r-xp 00000000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab766000-2aaaab965000 ---p 00003000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab965000-2aaaab966000 rw-p 00002000 08:05 12649054                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/sha2.so
2aaaab966000-2aaaab99f000 r-xp 00000000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaab99f000-2aaaabb9f000 ---p 00039000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaabb9f000-2aaaabba2000 rw-p 00039000 08:05 12649058                   /usr/local/lib/ruby/1.8/x86_64-linux/openssl.so
2aaaabba2000-2aaaabba3000 r-xp 00000000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabba3000-2aaaabda2000 ---p 00001000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabda2000-2aaaabda3000 rw-p 00000000 08:05 12649059                   /usr/local/lib/ruby/1.8/x86_64-linux/fcntl.so
2aaaabda3000-2aaaabfdd000 rw-p 2aaaabda3000 00:00 0 
2aaaabfdd000-2aaaabfdf000 r-xp 00000000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaabfdf000-2aaaac1de000 ---p 00002000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaac1de000-2aaaac1df000 rw-p 00001000 08:05 12649064                   /usr/local/lib/ruby/1.8/x86_64-linux/etc.so
2aaaac1df000-2aaaac1e4000 r-xp 00000000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac1e4000-2aaaac3e4000 ---p 00005000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac3e4000-2aaaac3e5000 rw-p 00005000 08:01 6469194                    /home/cleartrip/rails-libs/ct-gems/gems/mongrel-1.1.3/lib/http11.so
2aaaac3e5000-2aaaac3e9000 r-xp 00000000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac3e9000-2aaaac5e8000 ---p 00004000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac5e8000-2aaaac5e9000 rw-p 00003000 08:01 6469105                    /home/cleartrip/rails-libs/ct-gems/gems/fastthread-1.0.1/lib/fastthread.so
2aaaac5e9000-2aaaac9eb000 rw-p 2aaaac5e9000 00:00 0 
2aaaac9eb000-2aaaac9ef000 r-xp 00000000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaac9ef000-2aaaacbee000 ---p 00004000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaacbee000-2aaaacbef000 rw-p 00003000 08:05 12649045                   /usr/local/lib/ruby/1.8/x86_64-linux/strscan.so
2aaaacbef000-2aaaacbf9000 r-xp 00000000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacbf9000-2aaaacdf9000 ---p 0000a000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacdf9000-2aaaacdfa000 rw-p 0000a000 08:05 12649063                   /usr/local/lib/ruby/1.8/x86_64-linux/bigdecimal.so
2aaaacdfa000-2aaaace36000 r-xp 00000000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaace36000-2aaaad036000 ---p 0003c000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaad036000-2aaaad03a000 rw-p 0003c000 08:05 12649050                   /usr/local/lib/ruby/1.8/x86_64-linux/nkf.so
2aaaad03a000-2aaaad03b000 rw-p 2aaaad03a000 00:00 0 
2aaaad03c000-2aaaad772000 rw-p 2aaaad03c000 00:00 0 
2aaaad772000-2aaaad783000 r-xp 00000000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad783000-2aaaad882000 ---p 00011000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad882000-2aaaad884000 rw-p 00010000 08:05 12651841                   /usr/local/lib/ruby/site_ruby/1.8/x86_64-linux/oci8lib.so
2aaaad884000-2aaaad8a7000 rw-p 2aaaad884000 00:00 0 
2aaaad8ae000-2aaaad986000 r-xp 00000000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaad986000-2aaaadb86000 ---p 000d8000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaadb86000-2aaaadb8b000 rw-p 000d8000 08:01 9374704                    /usr/lib64/libruby.so.1.8.5
2aaaadb8b000-2aaaadba9000 rw-p 2aaaadb8b000 00:00 0 
2aaaadba9000-2aaaaed60000 r-xp 00000000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaed60000-2aaaaee60000 ---p 011b7000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaee60000-2aaaaef01000 rw-p 011b7000 08:05 5701727                    /usr/local/oracle/libclntsh.so.10.1
2aaaaef01000-2aaaaef15000 rw-p 2aaaaef01000 00:00 0 
2aaaaef15000-2aaaaf206000 r-xp 00000000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf206000-2aaaaf305000 ---p 002f1000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf305000-2aaaaf3b5000 rw-p 002f0000 08:05 5701635                    /usr/local/oracle/libnnz10.so
2aaaaf3b5000-2aaaaf3b7000 rw-p 2aaaaf3b5000 00:00 0 
2aaaaf3b7000-2aaab369a000 r-xp 00000000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab369a000-2aaab379a000 ---p 042e3000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab379a000-2aaab379c000 rw-p 042e3000 08:05 5701724                    /usr/local/oracle/libociei.so
2aaab379c000-2aaab37fb000 rw-p 2aaab379c000 00:00 0 
2aaab37fb000-2aaab37fc000 r-xp 00000000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab37fc000-2aaab39fb000 ---p 00001000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab39fb000-2aaab39fc000 rw-p 00000000 08:05 12649053                   /usr/local/lib/ruby/1.8/x86_64-linux/digest/md5.so
2aaab39fc000-2aaab39ff000 r-xp 00000000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab39ff000-2aaab3bff000 ---p 00003000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab3bff000-2aaab3c00000 rw-p 00003000 08:05 12649072                   /usr/local/lib/ruby/1.8/x86_64-linux/racc/cparse.so
2aaab3c00000-2aaab3c04000 r-xp 00000000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3c04000-2aaab3e03000 ---p 00004000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3e03000-2aaab3e04000 rw-p 00003000 08:05 12649068                   /usr/local/lib/ruby/1.8/x86_64-linux/iconv.so
2aaab3e04000-2aaab4aff000 rw-p 2aaab3e04000 00:00 0 
2aaab4aff000-2aaab4b20000 r-xp 00000000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4b20000-2aaab4d20000 ---p 00021000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4d20000-2aaab4d22000 rw-p 00021000 08:01 6470109                    /home/cleartrip/rails-libs/ct-gems/gems/libxml-ruby-0.5.2.0/lib/xml/libxml_so.so
2aaab4d4c000-2aaab4d56000 r-xp 00000000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4d56000-2aaab4f55000 ---p 0000a000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f55000-2aaab4f56000 r--p 00009000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f56000-2aaab4f57000 rw-p 0000a000 08:01 7971996                    /lib64/libnss_files-2.5.so
2aaab4f57000-2aaab5027000 rw-p 2aaab4f57000 00:00 0 
2aaab5027000-2aaab502b000 r-xp 00000000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab502b000-2aaab522b000 ---p 00004000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab522b000-2aaab522c000 rw-p 00004000 08:05 12649060                   /usr/local/lib/ruby/1.8/x86_64-linux/readline.so
2aaab522e000-2aaab5235000 r--s 00000000 08:01 9409795                    /usr/lib64/gconv/gconv-modules.cache
2aaab5235000-2aaab5236000 r-xp 00000000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab5236000-2aaab5436000 ---p 00001000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab5436000-2aaab5438000 rw-p 00001000 08:01 9409978                    /usr/lib64/gconv/ISO8859-1.so
2aaab8000000-2aaab8021000 rw-p 2aaab8000000 00:00 0 
2aaab8021000-2aaabc000000 ---p 2aaab8021000 00:00 0 
7fff7ca80000-7fff7cad2000 rwxp 7fff7ca80000 00:00 0                      [stack]
7fff7cad2000-7fff7cad4000 rw-p 7fff7cad2000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

----------------------------------------------------------------------

Comment By: Saurabh Nanda (saurabhnanda)
Date: 2008-02-05 07:17

Message:
I think I'm also facing a similar issue. I'm on a 64 bit Intel machine with libxml-ruby-0.5.2. I'm trying to write a long running RESTful service in Rails. After the first few XML POSTs to the Rails server, it suddenly segfaults.

I can attach the error log. How do I attach a file?

----------------------------------------------------------------------

Comment By: Dan Janowski (danj)
Date: 2007-08-30 07:16

Message:
There is a new memory model released but I do not have this system combo to test. Please take a few minutes and go to the project page and download the MEM2 release 0.5.0 and run the rwtest/doc_file.rb from the 'ext' directory (to use the local build instead of a system installed libxml). Please follow up.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=8337&group_id=494

From sean at chittenden.org  Thu Jul 10 18:02:36 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 10 Jul 2008 15:02:36 -0700
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <4875B68E.9090002@savagexi.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>
	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>
	<4875B68E.9090002@savagexi.com>
Message-ID: <9FC4467B-1C29-4C67-84EE-9B5C35728DFC@chittenden.org>

>>> require 'xml/libxml'
>>>
>>> (1..10000).each{|time|
>>> XML::Document.file('test.xml')
>>> p time if time % 100 == 0
>>> }
>> It won't segfault anymore, but now I get the following error:
>> Too many open filesI/O warning : failed to load external entity  
>> "test.xml"
>> libxml-test.rb:7:in `file': test.xml (IOError)
>> 	from libxml-test.rb:7
>> 	from libxml-test.rb:6:in `each'
>> 	from libxml-test.rb:6
>> However, the error disappears if "GC.start" is inserted just above
>> XML::Document.file(...).
>
> Right.  This is another Ruby GC issue.  If you don't call GC.start,  
> then  all the documents that you have created remain open.  I assume  
> this causes the OS to eventually run out of file handles, thus  
> resulting in the error (which is being raised by libxml not Ruby).
>
> By calling GC.start, the documents are freed and the file handles  
> are released.
>
> So I don't see this as a bug in the libxml bindings.


Hrm....  while it's not technically a libxml error, one could easily  
argue that libxml should call rb_gc_start() if the open fails and  
retry.  I just committed a fix to trunk that fixes this scenario.  It  
will still spew errors whenever the GC is called due to the lack of  
wrapping around libxml's error handling, but it's appropriate to leave  
that there for the time being.  -sc

% ruby /tmp/test.rb
100
200
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
300
400
500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
600
700
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
800
900
1000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
1100
1200
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
1300
1400
1500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
1600
1700
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
1800
1900
2000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
2100
2200
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
2300
2400
2500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
2600
2700
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
2800
2900
3000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
3100
3200
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
3300
3400
3500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
3600
3700
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
3800
3900
4000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
4100
4200
4300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
4400
4500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
4600
4700
4800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
4900
5000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
5100
5200
5300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
5400
5500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
5600
5700
5800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
5900
6000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
6100
6200
6300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
6400
6500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
6600
6700
6800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
6900
7000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
7100
7200
7300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
7400
7500
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
7600
7700
7800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
7900
8000
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
8100
8200
8300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
8400
8500
8600
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
8700
8800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
8900
9000
9100
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
9200
9300
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
9400
9500
9600
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
9700
9800
Too many open filesToo many open filesI/O warning : failed to load  
external entity "test.xml"
logic 0
9900
10000

--
Sean Chittenden
sean at chittenden.org




From noreply at rubyforge.org  Thu Jul 10 18:17:01 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 10 Jul 2008 18:17:01 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19648 ] rake install DESTDIR fails
Message-ID: <20080710221701.D4BA718581AB@rubyforge.org>

Bugs item #19648, was opened at 2008-04-19 10:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19648&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Benjamin Reed (rangerrick)
>Assigned to: Charlie Savage (cfis)
Summary: rake install DESTDIR fails

Initial Comment:
I'm the maintainer for libxml-ruby in Fink (http://www.finkproject.org/) -- I was trying to update it to the latest version and it is failing on rake install:

Sin:libxml-ruby-0.5.4 root# rake install DESTDIR=/sw/src/fink.build/root-libxml2-rb18-0.5.4-1 --trace 
(in /sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4)
** Invoke install (first_time)
** Execute install
rake aborted!
uninitialized constant Setup::Installer::RBCONFIG
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:2028:in `const_missing'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:864:in `dllext'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:856:in `rubyextentions'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:821:in `install_dir_ext'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1021:in `__send__'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1021:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1038:in `dive_into'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1019:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1023:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1022:in `each'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1022:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1038:in `dive_into'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1019:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1013:in `exec_task_traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1008:in `each'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1008:in `exec_task_traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:808:in `exec_install'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:457:in `rake_define'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/bin/rake:16:in `load'
/usr/bin/rake:16



----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-10 16:17

Message:
Benjamin,

Can you try with the latest gem and see if the problem is still occurring?   


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19648&group_id=494

From noreply at rubyforge.org  Thu Jul 10 18:17:43 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 10 Jul 2008 18:17:43 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-12314 ] node.to_s doesn't print the
	XML on 64bit AMD?
Message-ID: <20080710221744.04A0218585B5@rubyforge.org>

Bugs item #12314, was opened at 2007-07-15 20:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=12314&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: node.to_s doesn't print the XML on 64bit AMD?

Initial Comment:
I' trying to rerun a project from last year, but the code
behaves differently to the old system.

Old system 
Linux oldsrv 2.6.10-1.12_FC2 #1 Wed Feb 2 01:13:49 EST 2005 i686 athlon i386 GNU/Linux
alex at oldsrv:~ ruby -v
ruby 1.8.3 (2005-09-21) [i686-linux]


New system
Linux newsrv 2.6.15-26-amd64-server #1 SMP Thu Aug 3 03:32:26 UTC 2006 x86_64 GNU/Linux
kru031 at newsrv:~ ruby -v
ruby 1.8.4 (2005-12-24) [x86_64-linux]


root at newsrv:~ dpkg -l | grep ruby
ii  libfcgi-ruby1.8                    0.8.6-1                      FastCGI library for Ruby
ii  libmysql-ruby                      2.7-1.1build2                MySQL module for Ruby
ii  libmysql-ruby1.8                   2.7-1.1build2                MySQL module for Ruby 1.8
ii  libreadline-ruby1.8                1.8.4-1ubuntu1.3             Readline interface for Ruby 1.8
ii  libreadline-ruby1.9                1.9.0+20060423-3ubuntu1      Readline interface for Ruby 1.9
ii  libruby1.8                         1.8.4-1ubuntu1.3             Libraries necessary to run Ruby 1.8
ii  libruby1.9                         1.9.0+20060423-3ubuntu1      Libraries necessary to run Ruby 1.9
ii  libxml-ruby1.8                     0.3.4-4                      Ruby interface to libxml
ii  libxslt-ruby1.8                    0.3.4-3                      Ruby interface to libxslt
ii  libzlib-ruby                       0.6.0+ruby1.8.2-1            Extension library to use zlib from Ruby
ii  rdoc                               1.8.2-1                      Generate documentation from ruby source file
ii  ruby                               1.8.2-1                      An interpreter of object-oriented scripting 
ii  ruby1.8                            1.8.4-1ubuntu1.3             Interpreter of object-oriented scripting lan
ii  ruby1.8-dev                        1.8.4-1ubuntu1.3             Header files for compiling extension modules

root at rosella:~ dpkg -l | grep xml
ii  libxml-ruby1.8                     0.3.4-4                      Ruby interface to libxml
ii  libxml2                            2.6.24.dfsg-1ubuntu1         GNOME XML library
ii  libxml2-dev                        2.6.24.dfsg-1ubuntu1         Development files for the GNOME XML library
ii  libxml2-utils                      2.6.24.dfsg-1ubuntu1         XML utilities



example code:


      1   xmldoc.find(an_xpath).each do |matchingnode|
      2     outfile << "<DOC>\n"
      3     outfile << "#{matchingnode.path}\n"
      4     outfile << matchingnode
      5     outfile << "\n</DOC>\n"
      6     count+=3+matchingnode.to_s.count("\n")
      7   end

Line 3 works fine under both systems.
On the old system line 4 printed the node (subtree), on the new system it prints an empty string or only some text nodes from within the tree.
On every other file it crashes:
  undefined method `count' for nil:NilClass (NoMethodError)


Any hint would be appreciated!
 sledgy .at. gmx.net




----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-10 16:17

Message:
Can you try again with the lastest version?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=12314&group_id=494

From marsipan at gmail.com  Thu Jul 10 19:02:08 2008
From: marsipan at gmail.com (Mars)
Date: Thu, 10 Jul 2008 16:02:08 -0700 (PDT)
Subject: [libxml-devel] And onto libxml-ruby 0.7.0
In-Reply-To: <487520A0.6070908@savagexi.com>
References: <487520A0.6070908@savagexi.com>
Message-ID: <eab388e2-8b60-42af-909b-b814c25c2b1a@y21g2000hsf.googlegroups.com>

As of 0.7.0, I'm experiencing a problem with XPath attribute
selectors.

When:
  my_node contains <highlight from="3" to="9" type="queryTerm"/>

The attribute selector no longer works:
  my_node.find_first('@from') => nil

It worked in 0.5.4 & 0.6.0.

Any idea what's up with that?
*Mars


Charlie Savage wrote:
> Ok, I've just pushed up a 0.7.0 libxml release.  I thought about calling
> it 0.6.1, but there were both API changes (attributes) and a fair number
> of internal changes, so I went with 0.7.0.
>
> I also marked this release as stable - at this point I think the library
> is in good shape.  So please download it and give it a spin.
>
> Changes:
>
> * Added new attributes class to provide a more natural way of working
> with attributes
>
> * Fixed XML::Attr to better support namespaces
>
> * Added documentation on how to use namespaces with XPath
>
> * Removed allocation of extraneous structures used to wrap nodes,
> namespaces and attributes
>
> * Cleaned up tests and added new test suite
>
> * Updated rdocs and README file
>
> * Cleaned out most of the bug list
>
> * Fixed up eql? test
>
> Thanks,
>
> Charlie
>
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel

From cfis at savagexi.com  Thu Jul 10 19:10:48 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 17:10:48 -0600
Subject: [libxml-devel] Announcing libxslt-ruby 0.7.0
Message-ID: <487696F8.5060703@savagexi.com>

Hi everyone,

I've pushed out a libxslt 0.7.0 release to match yesterday's libxml 
0.7.0 release.

Changes:

* Ability to reuse the same stylesheet multile times

* Simpler api

* Compatibility layer for pre-0.7.0 versions

* Major rewrite, resulting in significantly less code

* Updated RDocs.


To see the difference, here is the new API:

   stylesheet_doc = XML::Document.file('stylesheet_file')
   stylesheet = XSLT::Stylesheet.new(stylesheet_doc)


   xml_doc = XML::Document.file('xml_file')

   result_doc = stylesheet.apply(xml_doc)



And here is the old way:

   xsl_file = File.expand_path('files/fuzface.xsl')
   xslt = XML::XSLT.file(xsl_file)

   xml_file = File.expand_path('files/fuzface.xml')
   xslt.doc = XML::Document.file(xml_file)

   stylesheet = xslt.parse
   result_string = stylesheet.apply(xml_doc)


The old API had a number of issues:

* The XSLT namespace was nested in XML - that seems like a bad idea now 
that libxslt is its own gem

* Stylesheets could only be opened from files

* A stylesheet could only be used once

* A needless parse call was required

* The result of the apply transformation was returned as a string

By having libxslt read and work with XML::Documents more naturally, I 
was able to remove roughly 50% of the bindings code and at the same time 
provide more functionality.

Note that for backwards compatibility, I added some Ruby code in the 
bindings that mimics the old API (would be nice if it spit out 
deprecation warnings, suppose we could borrow the code Rail's uses for 
that).

So give it a try, and report any bugs.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/a9ad1d88/attachment.bin>

From sean at chittenden.org  Thu Jul 10 19:25:14 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 10 Jul 2008 16:25:14 -0700
Subject: [libxml-devel] [ libxml-Bugs-19648 ] rake install DESTDIR fails
In-Reply-To: <20080710221701.D4BA718581AB@rubyforge.org>
References: <20080710221701.D4BA718581AB@rubyforge.org>
Message-ID: <FFAFC473-DD1C-4F4C-A52E-A58C33DB5A24@chittenden.org>

> I'm the maintainer for libxml-ruby in Fink (http://www.finkproject.org/ 
> ) -- I was trying to update it to the latest version and it is  
> failing on rake install:
>
> Sin:libxml-ruby-0.5.4 root# rake install DESTDIR=/sw/src/fink.build/ 
> root-libxml2-rb18-0.5.4-1 --trace
> (in /sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4)
> ** Invoke install (first_time)
> ** Execute install
> rake aborted!
> uninitialized constant Setup::Installer::RBCONFIG
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ 
> gems/1.8/gems/rake-0.7.3/lib/rake.rb:2028:in `const_missing'
>
>> Comment By: Charlie Savage (cfis)
> Date: 2008-07-10 16:17
>
> Message:
> Benjamin,
>
> Can you try with the latest gem and see if the problem is still  
> occurring?


I think I committed the fix to this earlier today.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Thu Jul 10 23:03:06 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:03:06 -0600
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
 segfault on fbsd-amd64
In-Reply-To: <989032930807100126s66a6e1dcuc892ff97e2008ddb@mail.gmail.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>	<4875B68E.9090002@savagexi.com>
	<989032930807100126s66a6e1dcuc892ff97e2008ddb@mail.gmail.com>
Message-ID: <4876CD6A.6010205@savagexi.com>



>> So I don't see this as a bug in the libxml bindings.
> 
> Maybe you are right, but if I change XML::Document.file("test.xml")
> to File.open("test.xml"), I won't run out of file handles.
> 
> I wonder what makes the difference...


Well, File.open is a ruby method while Document.open is a libxml method. 
  Perhaps Ruby has some smarts built into it with File.open and the 
garbage collector.

> And if I remember correctly, even the original test code with
> libxml-ruby 3.8 did not run out of file handles on 32bit intel machines
> either - the reported segfault only affected the amd64 (and maybe
> other) architecture.

Interesting.  Could be a difference in libxml, or maybe a difference in 
the bindings.  Would have to check svn to know for sure.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/a32774e1/attachment.bin>

From cfis at savagexi.com  Thu Jul 10 23:27:41 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:27:41 -0600
Subject: [libxml-devel] SaxParser
In-Reply-To: <e9a952090807100850r19f9abe8j5fdbc6f7e771d874@mail.gmail.com>
References: <e9a952090807100850r19f9abe8j5fdbc6f7e771d874@mail.gmail.com>
Message-ID: <4876D32D.9030807@savagexi.com>

Hi Todd,

> I'm wondering if there are any plans to support reading from a socket
> to send data through the SaxParser.   If I'm not mistaken it currently
> has a .string= and .filename = method.

If you mean opening up a document that resides at a URI via HTTP, then 
that would be easy since libxml supports it via the 
xmlCreateURLParserCtxt method.

As for more raw sockets, I'd just say use what's built into Ruby, 
download the data at the other end, and feed it into libxml.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/5cae6421/attachment.bin>

From cfis at savagexi.com  Thu Jul 10 23:30:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:30:29 -0600
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
 segfault on fbsd-amd64
In-Reply-To: <9FC4467B-1C29-4C67-84EE-9B5C35728DFC@chittenden.org>
References: <20080709173738.5B60E15B8002@rubyforge.org>	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>	<4875B68E.9090002@savagexi.com>
	<9FC4467B-1C29-4C67-84EE-9B5C35728DFC@chittenden.org>
Message-ID: <4876D3D5.6090902@savagexi.com>

Hey Sean,

>>>> (1..10000).each{|time|
>>>> XML::Document.file('test.xml')
>>>> p time if time % 100 == 0
>>>> }
>>> It won't segfault anymore, but now I get the following error:
>>> Too many open filesI/O warning : failed to load external entity 
>>> "test.xml"
>>> libxml-test.rb:7:in `file': test.xml (IOError)
>>>     from libxml-test.rb:7
>>>     from libxml-test.rb:6:in `each'
>>>     from libxml-test.rb:6
>>> However, the error disappears if "GC.start" is inserted just above
>>> XML::Document.file(...).
>>
>> Right.  This is another Ruby GC issue.  If you don't call GC.start, 
>> then  all the documents that you have created remain open.  I assume 
>> this causes the OS to eventually run out of file handles, thus 
>> resulting in the error (which is being raised by libxml not Ruby).
>>
>> By calling GC.start, the documents are freed and the file handles are 
>> released.
>>
>> So I don't see this as a bug in the libxml bindings.
> 
> 
> Hrm....  while it's not technically a libxml error, one could easily 
> argue that libxml should call rb_gc_start() if the open fails and 
> retry. 

Ah, good idea.  It just retries once after doing a GC?

Have time to turn this into a test case?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/66c92283/attachment.bin>

From cfis at savagexi.com  Thu Jul 10 23:44:52 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:44:52 -0600
Subject: [libxml-devel] And onto libxml-ruby 0.7.0
In-Reply-To: <eab388e2-8b60-42af-909b-b814c25c2b1a@y21g2000hsf.googlegroups.com>
References: <487520A0.6070908@savagexi.com>
	<eab388e2-8b60-42af-909b-b814c25c2b1a@y21g2000hsf.googlegroups.com>
Message-ID: <4876D734.2010807@savagexi.com>

Hi Mars

> As of 0.7.0, I'm experiencing a problem with XPath attribute
> selectors.
> 
> When:
>   my_node contains <highlight from="3" to="9" type="queryTerm"/>
> 
> The attribute selector no longer works:
>   my_node.find_first('@from') => nil
> 
> It worked in 0.5.4 & 0.6.0.
> 
> Any idea what's up with that?

Yes - that's my mistake.  When trying to hunt down a memory error, I 
commented out the returning of attributes.  Unfortunately, there aren't 
any tests for that, so I totally forgot to comment it back in.

Fix and test applied to SVN.  I suppose that warrants a 0.7.1 bug fix 
release fairly soonish...

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/893d6cb8/attachment-0001.bin>

From cfis at savagexi.com  Thu Jul 10 23:51:23 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:51:23 -0600
Subject: [libxml-devel] [ libxml-Bugs-19648 ] rake install DESTDIR fails
In-Reply-To: <FFAFC473-DD1C-4F4C-A52E-A58C33DB5A24@chittenden.org>
References: <20080710221701.D4BA718581AB@rubyforge.org>
	<FFAFC473-DD1C-4F4C-A52E-A58C33DB5A24@chittenden.org>
Message-ID: <4876D8BB.706@savagexi.com>



>>> Comment By: Charlie Savage (cfis)
>> Date: 2008-07-10 16:17
>>
>> Message:
>> Benjamin,
>>
>> Can you try with the latest gem and see if the problem is still 
>> occurring?
> 
> 
> I think I committed the fix to this earlier today.  -sc

Nice.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/7434f923/attachment.bin>

From cfis at savagexi.com  Thu Jul 10 23:52:39 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 10 Jul 2008 21:52:39 -0600
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
Message-ID: <4876D907.4060003@savagexi.com>



Aaron Patterson wrote:
> Hi!
> 
> I'm trying to compile and run the tests from trunk.  As far as I can
> tell, you just run setup.rb.  Is that correct?  The tests don't seem
> to run for me when I do that.

Not sure, I run ruby test/test_suite.rb.


   I tried running the tests individually,
> but it seems libxml.rb is doing a require on 'libxml_ruby.so' which
> doesn't exist on OS X.  Is the require on the so file intentional?

What is it on OS X?  Is it libxml_ruby.bundle?  If you lose the ".so" 
bit, does it work (so require 'libxml_ruby').

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080710/ba02b2df/attachment.bin>

From aaron.patterson at gmail.com  Fri Jul 11 01:17:09 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Thu, 10 Jul 2008 22:17:09 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <4876D907.4060003@savagexi.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
Message-ID: <6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>

2008/7/10 Charlie Savage <cfis at savagexi.com>:
>
>
> Aaron Patterson wrote:
>>
>> Hi!
>>
>> I'm trying to compile and run the tests from trunk.  As far as I can
>> tell, you just run setup.rb.  Is that correct?  The tests don't seem
>> to run for me when I do that.
>
> Not sure, I run ruby test/test_suite.rb.

Looks like the test suite must be run from within the test directory.
Otherwise test assets will not be found.  I've added a patch to the
tracker that figures out where the assets directory is so that you can
run the tests from a different directory (e.g. the root of the
project).

http://rubyforge.org/tracker/index.php?func=detail&aid=21162&group_id=494&atid=1973

-- 
Aaron Patterson
http://tenderlovemaking.com/

From aaron.patterson at gmail.com  Fri Jul 11 01:42:31 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Thu, 10 Jul 2008 22:42:31 -0700
Subject: [libxml-devel] implementing in Ruby vs C
Message-ID: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>

Hi!

As I've started reading through the libxml-ruby code, I have run
across methods implemented in C that could be implemented in Ruby.  I
would like to change them to be implemented in Ruby.  Is anyone
opposed to that?  I think it would make coding easier, less buggy, and
more fun!

-- 
Aaron Patterson
http://tenderlovemaking.com/

From todd.fisher at gmail.com  Fri Jul 11 07:44:21 2008
From: todd.fisher at gmail.com (Todd Fisher)
Date: Fri, 11 Jul 2008 07:44:21 -0400
Subject: [libxml-devel] SaxParser
In-Reply-To: <4876D32D.9030807@savagexi.com>
References: <e9a952090807100850r19f9abe8j5fdbc6f7e771d874@mail.gmail.com>
	<4876D32D.9030807@savagexi.com>
Message-ID: <e9a952090807110444u44f4b604m2f194e167143b325@mail.gmail.com>

Hi Charlie,

  I guess what I'm wondering is how can the data from ruby be fed
into libxml-ruby SaxParser - when I only see 2 methods for passing
data, parser.string= and parser.filename= .  I must be missing
understanding.

Thanks,
Todd

2008/7/10 Charlie Savage <cfis at savagexi.com>:
> Hi Todd,
>
>> I'm wondering if there are any plans to support reading from a socket
>> to send data through the SaxParser.   If I'm not mistaken it currently
>> has a .string= and .filename = method.
>
> If you mean opening up a document that resides at a URI via HTTP, then that
> would be easy since libxml supports it via the xmlCreateURLParserCtxt
> method.
>
> As for more raw sockets, I'd just say use what's built into Ruby, download
> the data at the other end, and feed it into libxml.
>
> Charlie
>
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
>

From noreply at rubyforge.org  Fri Jul 11 00:02:11 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 11 Jul 2008 00:02:11 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-19648 ] rake install DESTDIR fails
Message-ID: <20080711040211.E445A18585B8@rubyforge.org>

Bugs item #19648, was opened at 2008-04-19 10:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19648&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Benjamin Reed (rangerrick)
>Assigned to: Sean Chittenden (seanc)
Summary: rake install DESTDIR fails

Initial Comment:
I'm the maintainer for libxml-ruby in Fink (http://www.finkproject.org/) -- I was trying to update it to the latest version and it is failing on rake install:

Sin:libxml-ruby-0.5.4 root# rake install DESTDIR=/sw/src/fink.build/root-libxml2-rb18-0.5.4-1 --trace 
(in /sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4)
** Invoke install (first_time)
** Execute install
rake aborted!
uninitialized constant Setup::Installer::RBCONFIG
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:2028:in `const_missing'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:864:in `dllext'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:856:in `rubyextentions'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:821:in `install_dir_ext'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1021:in `__send__'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1021:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1038:in `dive_into'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1019:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1023:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1022:in `each'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1022:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1038:in `dive_into'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1019:in `traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1013:in `exec_task_traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1008:in `each'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:1008:in `exec_task_traverse'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:808:in `exec_install'
/sw/src/fink.build/libxml2-rb18-0.5.4-1/libxml-ruby-0.5.4/setup.rb:457:in `rake_define'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/bin/rake:16:in `load'
/usr/bin/rake:16



----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-10 22:02

Message:
Should be fixed with changes from Sean.

----------------------------------------------------------------------

Comment By: Charlie Savage (cfis)
Date: 2008-07-10 16:17

Message:
Benjamin,

Can you try with the latest gem and see if the problem is still occurring?   


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=19648&group_id=494

From noreply at rubyforge.org  Fri Jul 11 10:33:13 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 11 Jul 2008 10:33:13 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21169 ] each_attr is broken in 0.7.0
Message-ID: <20080711143313.E897118585A7@rubyforge.org>

Bugs item #21169, was opened at 2008-07-11 14:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

Category: General
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tiago Macedo (tmacedo)
Assigned to: Nobody (None)
Summary: each_attr is broken in 0.7.0

Initial Comment:
NameError: undefined local variable or method `properties' for #<XML::Node:0xb742ce64>
    /usr/lib/ruby/gems/1.8/gems/libxml-ruby-0.7.0/lib/libxml.rb:83:in `each_attr'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:167:in `hash_of_attributes'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:76:in `collapse'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:64:in `out'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:53:in `xml_in'
    ./test/../lib/aws/s3/parsing.rb:64:in `parse'
    ./test/../lib/aws/s3/parsing.rb:55:in `initialize'
    ./test/parsing_test.rb:59:in `new'
    ./test/parsing_test.rb:59:in `test_policy_grants_are_always_an_array'


I ran into this issue by running the aws-s3 tests. aws-s3 relies in faster-xml-simple for libxml-ruby support

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

From noreply at rubyforge.org  Fri Jul 11 10:34:24 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 11 Jul 2008 10:34:24 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21169 ] each_attr is broken in 0.7.0
Message-ID: <20080711143424.9A3CF18585C3@rubyforge.org>

Bugs item #21169, was opened at 2008-07-11 14:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

Category: General
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tiago Macedo (tmacedo)
Assigned to: Nobody (None)
Summary: each_attr is broken in 0.7.0

Initial Comment:
NameError: undefined local variable or method `properties' for #<XML::Node:0xb742ce64>
    /usr/lib/ruby/gems/1.8/gems/libxml-ruby-0.7.0/lib/libxml.rb:83:in `each_attr'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:167:in `hash_of_attributes'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:76:in `collapse'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:64:in `out'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:53:in `xml_in'
    ./test/../lib/aws/s3/parsing.rb:64:in `parse'
    ./test/../lib/aws/s3/parsing.rb:55:in `initialize'
    ./test/parsing_test.rb:59:in `new'
    ./test/parsing_test.rb:59:in `test_policy_grants_are_always_an_array'


I ran into this issue by running the aws-s3 tests. aws-s3 relies in faster-xml-simple for libxml-ruby support

----------------------------------------------------------------------

>Comment By: Tiago Macedo (tmacedo)
Date: 2008-07-11 14:34

Message:
I'm using gentoo's dev-libs/libxml2-2.6.32

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

From sean at chittenden.org  Fri Jul 11 11:52:21 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 08:52:21 -0700
Subject: [libxml-devel] implementing in Ruby vs C
In-Reply-To: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
References: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
Message-ID: <332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>

> As I've started reading through the libxml-ruby code, I have run
> across methods implemented in C that could be implemented in Ruby.  I
> would like to change them to be implemented in Ruby.  Is anyone
> opposed to that?  I think it would make coding easier, less buggy, and
> more fun!


I'm not entirely opposed to the idea... but am curious for some  
example functions.  :)  -sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Fri Jul 11 12:23:23 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 09:23:23 -0700
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <4876D3D5.6090902@savagexi.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>	<4875B68E.9090002@savagexi.com>
	<9FC4467B-1C29-4C67-84EE-9B5C35728DFC@chittenden.org>
	<4876D3D5.6090902@savagexi.com>
Message-ID: <FEB67B7B-EC4D-475B-AD82-9E05F58DBA19@chittenden.org>

> Ah, good idea.  It just retries once after doing a GC?

Yup.

> Have time to turn this into a test case?

Done.  I also cleaned up the tests so that they almost all pass now.   
If you're opening files in tests, use something akin to:

File.open(File.join(File.dirname(__FILE__), 'model/foo.xml')) {|f| ... }

Ideally there should/would be a helper method/macro that'd type that  
for you, but I didn't add it at this time.  -sc


% ./setup.rb test
Loaded suite test
Started
.................................................................................................................
EXPECTING: TWO ERRORS:
F................
Finished in 0.874862 seconds.

   1) Failure:
test_error_handler(TextParser) [/Users/sean/src/ruby-libxml/trunk/test/ 
tc_xml_parser.rb:198]:
<nil> expected but was
<#<Proc:0x005c9874@/Users/sean/src/ruby-libxml/trunk/test/ 
tc_xml_dtd.rb:59>>.

130 tests, 716 assertions, 1 failures, 0 errors


--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 12:23:34 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 09:23:34 -0700
Subject: [libxml-devel] implementing in Ruby vs C
In-Reply-To: <332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
References: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
	<332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
Message-ID: <6959e1680807110923h2a8ecdbcgb0c2a9fcfed56bb3@mail.gmail.com>

On Fri, Jul 11, 2008 at 8:52 AM, Sean Chittenden <sean at chittenden.org> wrote:
>> As I've started reading through the libxml-ruby code, I have run
>> across methods implemented in C that could be implemented in Ruby.  I
>> would like to change them to be implemented in Ruby.  Is anyone
>> opposed to that?  I think it would make coding easier, less buggy, and
>> more fun!
>
>
> I'm not entirely opposed to the idea... but am curious for some example
> functions.  :)  -sc

XML::Parser.register_error_handler could be implemented in ruby.
ruby_xml_attr_not_type_name() could be implemented in ruby.

All of the rb_define_consts in ruby_xml_node.c

ruby_xml_node_set_xpath_get() in ruby_xml_node_set.c

Thats all I can remember for now!  haha!

I haven't read through all of the code, but I'm just guessing there
are more things....

By the way, I added a patch to the tracker to do some cleanups in the tests.

  http://rubyforge.org/tracker/?func=detail&aid=21162&group_id=494&atid=1973

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 12:30:34 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 09:30:34 -0700
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <4876CD6A.6010205@savagexi.com>
References: <20080709173738.5B60E15B8002@rubyforge.org>	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>	<4875B68E.9090002@savagexi.com>
	<989032930807100126s66a6e1dcuc892ff97e2008ddb@mail.gmail.com>
	<4876CD6A.6010205@savagexi.com>
Message-ID: <1902FE14-ED3C-4DA2-8804-502038ACA6B5@chittenden.org>

>>> So I don't see this as a bug in the libxml bindings.
>> Maybe you are right, but if I change XML::Document.file("test.xml")
>> to File.open("test.xml"), I won't run out of file handles.
>> I wonder what makes the difference...
>
> Well, File.open is a ruby method while Document.open is a libxml  
> method.  Perhaps Ruby has some smarts built into it with File.open  
> and the garbage collector.

Ruby does the same thing libxml now does, it calls the GC whenever  
errno is set to EMFILE or ENFILE.

>> And if I remember correctly, even the original test code with
>> libxml-ruby 3.8 did not run out of file handles on 32bit intel  
>> machines
>> either - the reported segfault only affected the amd64 (and maybe
>> other) architecture.
>
> Interesting.  Could be a difference in libxml, or maybe a difference  
> in the bindings.  Would have to check svn to know for sure.


I don't know why that would be... maybe on the other machine you had  
your limits set higher and the GC always kicked in.  The test code  
uses sh -c `ulimit -n` to make sure that things run out of FDs.  -sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Fri Jul 11 12:33:59 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 09:33:59 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
Message-ID: <E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>

>> Not sure, I run ruby test/test_suite.rb.
>
> Looks like the test suite must be run from within the test directory.
> Otherwise test assets will not be found.  I've added a patch to the
> tracker that figures out where the assets directory is so that you can
> run the tests from a different directory (e.g. the root of the
> project).
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=21162&group_id=494&atid=1973


Ha!  I just committed something nearly identical to this because I  
couldn't run the tests using ./setup.rb test.  I didn't use the  
constant, however and did the File.join(...) for each open call.   
Anyway, let me know if trunk works for the tests for you now.  -sc

--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 12:37:31 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 09:37:31 -0700
Subject: [libxml-devel] implementing in Ruby vs C
In-Reply-To: <332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
References: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
	<332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
Message-ID: <6959e1680807110937m5ec8ddfdodeb778f5fe7b2878@mail.gmail.com>

On Fri, Jul 11, 2008 at 8:52 AM, Sean Chittenden <sean at chittenden.org> wrote:
>> As I've started reading through the libxml-ruby code, I have run
>> across methods implemented in C that could be implemented in Ruby.  I
>> would like to change them to be implemented in Ruby.  Is anyone
>> opposed to that?  I think it would make coding easier, less buggy, and
>> more fun!
>
>
> I'm not entirely opposed to the idea... but am curious for some example
> functions.  :)  -sc

Oh, also if all of the XML_ATTRIBUTE_* constants were made available
in ruby, then you could write a c function to return the integer of
xnode->type, then write all of your *? methods in ruby.

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 12:41:14 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 09:41:14 -0700
Subject: [libxml-devel] implementing in Ruby vs C
In-Reply-To: <6959e1680807110923h2a8ecdbcgb0c2a9fcfed56bb3@mail.gmail.com>
References: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
	<332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
	<6959e1680807110923h2a8ecdbcgb0c2a9fcfed56bb3@mail.gmail.com>
Message-ID: <1600E4DC-AE70-469E-91F2-541A50A55141@chittenden.org>

>> I'm not entirely opposed to the idea... but am curious for some  
>> example
>> functions.  :)  -sc
>
> XML::Parser.register_error_handler could be implemented in ruby.
> ruby_xml_attr_not_type_name() could be implemented in ruby.
>
> All of the rb_define_consts in ruby_xml_node.c
>
> ruby_xml_node_set_xpath_get() in ruby_xml_node_set.c
>
> Thats all I can remember for now!  haha!
>
> I haven't read through all of the code, but I'm just guessing there
> are more things....


Hrm, alright.

If the C version has bugs and someone (i.e. you) submits a bug free  
version that's pure ruby, I think it'd get committed if fixing the C  
version takes more than a few minutes.  From a speed and memory  
perspective, I'd err on the side of keeping things in C (libxml !=  
REXML), but since most all of the heavy lifting is happening in C  
anyway, it doesn't take much to convince that it'd belong in ruby if  
there's a bug.

Said differently, let sleeping dogs lie and don't waste effort unless  
effort needs to be expended to fix something... patches welcome.  *grin*

How's that?  -sc


--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 12:45:51 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 09:45:51 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
Message-ID: <6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>

On Fri, Jul 11, 2008 at 9:33 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> Not sure, I run ruby test/test_suite.rb.
>>
>> Looks like the test suite must be run from within the test directory.
>> Otherwise test assets will not be found.  I've added a patch to the
>> tracker that figures out where the assets directory is so that you can
>> run the tests from a different directory (e.g. the root of the
>> project).
>>
>>
>> http://rubyforge.org/tracker/index.php?func=detail&aid=21162&group_id=494&atid=1973
>
>
> Ha!  I just committed something nearly identical to this because I couldn't
> run the tests using ./setup.rb test.  I didn't use the constant, however and
> did the File.join(...) for each open call.  Anyway, let me know if trunk
> works for the tests for you now.  -sc

The tests still do not work from setup.rb.  When I try to run the test
suite from the root directory, I get an error loading libxml_ruby.

I typically run the tests like this:

[][aaron at amac libxml]$ ruby -I lib:ext:test test/test_suite.rb

This patch seems to fix things (I will submit it to the tracker if you'd like):

[][aaron at amac libxml]$ svn diff
Index: lib/libxml.rb
===================================================================
--- lib/libxml.rb	(revision 382)
+++ lib/libxml.rb	(working copy)
@@ -1,7 +1,7 @@
 # $Id$
 # Please see the LICENSE file for copyright and distribution information

-require 'libxml_ruby'
+require 'libxml/libxml_ruby'

 module XML::XMLParserOptions
   XML_PARSE_RECOVER = 1 # recover on errors
@@ -131,4 +131,4 @@
   def to_s
     "#{name} = #{value}"
   end
-end
\ No newline at end of file
+end
[][aaron at amac libxml]$

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 12:52:10 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 09:52:10 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
Message-ID: <21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>

>> Ha!  I just committed something nearly identical to this because I  
>> couldn't
>> run the tests using ./setup.rb test.  I didn't use the constant,  
>> however and
>> did the File.join(...) for each open call.  Anyway, let me know if  
>> trunk
>> works for the tests for you now.  -sc
>
> The tests still do not work from setup.rb.  When I try to run the test
> suite from the root directory, I get an error loading libxml_ruby.
>
> I typically run the tests like this:
>
> [][aaron at amac libxml]$ ruby -I lib:ext:test test/test_suite.rb

Can you try with just `./setup.rb test` ?  I'm cautious about updating  
lib/libxml.rb simply because it's included by everything and I'm still  
not up to speed post-gem'ification re: path/packaging.

I'll commit it for now, but I'm not entirely sure of its complete  
correctness (unit tests work for me).  If this breaks anything for  
anyone, scream.  -sc

--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 12:53:42 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 09:53:42 -0700
Subject: [libxml-devel] implementing in Ruby vs C
In-Reply-To: <1600E4DC-AE70-469E-91F2-541A50A55141@chittenden.org>
References: <6959e1680807102242l6f5ca976n328307db65b64280@mail.gmail.com>
	<332B5BE1-F458-4C79-91AA-EEB8C963917C@chittenden.org>
	<6959e1680807110923h2a8ecdbcgb0c2a9fcfed56bb3@mail.gmail.com>
	<1600E4DC-AE70-469E-91F2-541A50A55141@chittenden.org>
Message-ID: <6959e1680807110953j7357a8dcoe611f61edb3a88c0@mail.gmail.com>

On Fri, Jul 11, 2008 at 9:41 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> I'm not entirely opposed to the idea... but am curious for some example
>>> functions.  :)  -sc
>>
>> XML::Parser.register_error_handler could be implemented in ruby.
>> ruby_xml_attr_not_type_name() could be implemented in ruby.
>>
>> All of the rb_define_consts in ruby_xml_node.c
>>
>> ruby_xml_node_set_xpath_get() in ruby_xml_node_set.c
>>
>> Thats all I can remember for now!  haha!
>>
>> I haven't read through all of the code, but I'm just guessing there
>> are more things....
>
>
> Hrm, alright.
>
> If the C version has bugs and someone (i.e. you) submits a bug free version
> that's pure ruby, I think it'd get committed if fixing the C version takes
> more than a few minutes.  From a speed and memory perspective, I'd err on
> the side of keeping things in C (libxml != REXML), but since most all of the
> heavy lifting is happening in C anyway, it doesn't take much to convince
> that it'd belong in ruby if there's a bug.
>
> Said differently, let sleeping dogs lie and don't waste effort unless effort
> needs to be expended to fix something... patches welcome.  *grin*
>
> How's that?  -sc

Perfect.  I will submit patches.  It does not seem like wasted effort
to me because I would much rather read Ruby than C.  Also, I've found
that in my large C extension project, having as more Ruby helps my
brain keep things in order!

-- 
Aaron Patterson
http://tenderlovemaking.com/

From aaron.patterson at gmail.com  Fri Jul 11 13:42:33 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 10:42:33 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
Message-ID: <6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>

On Fri, Jul 11, 2008 at 9:52 AM, Sean Chittenden <sean at chittenden.org> wrote:

[snip]

> Can you try with just `./setup.rb test` ?  I'm cautious about updating
> lib/libxml.rb simply because it's included by everything and I'm still not
> up to speed post-gem'ification re: path/packaging.

[][aaron at amac libxml]$ ./setup.rb test
/Users/aaron/svn/libxml/test/tc_well_formed.rb:1:in `require': no such
file to load -- libxml (LoadError)
	from /Users/aaron/svn/libxml/test/tc_well_formed.rb:1
	from ./test/test_suite.rb:1:in `require'
	from ./test/test_suite.rb:1
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/test/unit/collector/dir.rb:90:in
`require'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/test/unit/collector/dir.rb:90:in
`collect_file'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/test/unit/collector/dir.rb:73:in
`recursive_collect'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/test/unit/collector/dir.rb:58:in
`each'


-- 
Aaron Patterson
http://tenderlovemaking.com/

From aaron.patterson at gmail.com  Fri Jul 11 13:45:55 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 10:45:55 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
Message-ID: <6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>

On Fri, Jul 11, 2008 at 9:52 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> Ha!  I just committed something nearly identical to this because I
>>> couldn't
>>> run the tests using ./setup.rb test.  I didn't use the constant, however
>>> and
>>> did the File.join(...) for each open call.  Anyway, let me know if trunk
>>> works for the tests for you now.  -sc
>>
>> The tests still do not work from setup.rb.  When I try to run the test
>> suite from the root directory, I get an error loading libxml_ruby.
>>
>> I typically run the tests like this:
>>
>> [][aaron at amac libxml]$ ruby -I lib:ext:test test/test_suite.rb
>
> Can you try with just `./setup.rb test` ?  I'm cautious about updating
> lib/libxml.rb simply because it's included by everything and I'm still not
> up to speed post-gem'ification re: path/packaging.
>
> I'll commit it for now, but I'm not entirely sure of its complete
> correctness (unit tests work for me).  If this breaks anything for anyone,
> scream.  -sc

I've added a patch to the tracker that adds a test task and a build
task to the rake file.

  http://rubyforge.org/tracker/index.php?func=detail&aid=21172&group_id=494&atid=1973

If you apply that patch, you can just execute 'rake build' to build
the extension, and 'rake test' to run the tests.
Also, 'rake extensions:clean' will clean up the extensions directory.

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 13:46:07 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 10:46:07 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
Message-ID: <F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>

>> Can you try with just `./setup.rb test` ?  I'm cautious about  
>> updating
>> lib/libxml.rb simply because it's included by everything and I'm  
>> still not
>> up to speed post-gem'ification re: path/packaging.
>
> [][aaron at amac libxml]$ ./setup.rb test
> /Users/aaron/svn/libxml/test/tc_well_formed.rb:1:in `require': no such
> file to load -- libxml (LoadError)

Wild.  Alright.  It works for me out of the box.  Is this trunk or  
before the libxml.rb patch?  -sc

--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 13:49:52 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 10:49:52 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
	<F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
Message-ID: <6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>

On Fri, Jul 11, 2008 at 10:46 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> Can you try with just `./setup.rb test` ?  I'm cautious about updating
>>> lib/libxml.rb simply because it's included by everything and I'm still
>>> not
>>> up to speed post-gem'ification re: path/packaging.
>>
>> [][aaron at amac libxml]$ ./setup.rb test
>> /Users/aaron/svn/libxml/test/tc_well_formed.rb:1:in `require': no such
>> file to load -- libxml (LoadError)
>
> Wild.  Alright.  It works for me out of the box.  Is this trunk or before
> the libxml.rb patch?  -sc

setup.rb has never successfully run the tests for me, even before the
libxml.rb patch.  I'm on OS X.

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 13:54:35 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 10:54:35 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
	<F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
	<6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>
Message-ID: <21284899-D46D-4613-B016-95D09291B4E1@chittenden.org>

>> Wild.  Alright.  It works for me out of the box.  Is this trunk or  
>> before
>> the libxml.rb patch?  -sc
>
> setup.rb has never successfully run the tests for me, even before the
> libxml.rb patch.  I'm on OS X.


Strange.  I'm OS-X and here's my output with trunk.  -sc


% rake test
(in /Users/sean/src/ruby-libxml/trunk)
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/ 
rake_test_loader
Started
.................................................................................................................
EXPECTING: TWO ERRORS:
F................
Finished in 0.873033 seconds.

   1) Failure:
test_error_handler(TextParser) [./test/tc_xml_parser.rb:198]:
<nil> expected but was
<#<Proc:0x00549778 at ./test/tc_xml_dtd.rb:59>>.

130 tests, 716 assertions, 1 failures, 0 errors
rake aborted!
Command failed with status (1): [/opt/local/bin/ruby -Ilib:test:ext "/ 
opt/l...]

(See full trace by running task with --trace)
Exit 1


--
Sean Chittenden
sean at chittenden.org




From aaron.patterson at gmail.com  Fri Jul 11 14:02:24 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 11:02:24 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <21284899-D46D-4613-B016-95D09291B4E1@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
	<F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
	<6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>
	<21284899-D46D-4613-B016-95D09291B4E1@chittenden.org>
Message-ID: <6959e1680807111102n7d29a99bgf09156ceaca266fb@mail.gmail.com>

On Fri, Jul 11, 2008 at 10:54 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> Wild.  Alright.  It works for me out of the box.  Is this trunk or before
>>> the libxml.rb patch?  -sc
>>
>> setup.rb has never successfully run the tests for me, even before the
>> libxml.rb patch.  I'm on OS X.
>
>
> Strange.  I'm OS-X and here's my output with trunk.  -sc
>
>
> % rake test
> (in /Users/sean/src/ruby-libxml/trunk)
> Loaded suite
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader
> Started
> .................................................................................................................
> EXPECTING: TWO ERRORS:
> F................
> Finished in 0.873033 seconds.
>
>  1) Failure:
> test_error_handler(TextParser) [./test/tc_xml_parser.rb:198]:
> <nil> expected but was
> <#<Proc:0x00549778 at ./test/tc_xml_dtd.rb:59>>.
>
> 130 tests, 716 assertions, 1 failures, 0 errors
> rake aborted!
> Command failed with status (1): [/opt/local/bin/ruby -Ilib:test:ext
> "/opt/l...]
>
> (See full trace by running task with --trace)
> Exit 1

Yes, I think that is because of the implementation of
register_error_handler.  I had fixed this in one of my previous
patches....  Anyway, this seems to do the trick:

[][aaron at amac libxml]$ svn diff
Index: test/tc_xml_dtd.rb
===================================================================
--- test/tc_xml_dtd.rb	(revision 384)
+++ test/tc_xml_dtd.rb	(working copy)
@@ -3,6 +3,7 @@

 class TestDtd < Test::Unit::TestCase
   def setup
+    XML::Parser.register_error_handler(nil)
     xp = XML::Parser.string(<<-EOS)
       <root>
         <head a="ee" id="1">Colorado</head>
[][aaron at amac libxml]$

register_error_handler holds a reference to the lambda *on the class*
(well, actually as a static VALUE).  So if the error_handler was set
somewhere else, it won't necessarily be nil (which is what that
failing test asserts).

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 14:47:25 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 11:47:25 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111102n7d29a99bgf09156ceaca266fb@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
	<F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
	<6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>
	<21284899-D46D-4613-B016-95D09291B4E1@chittenden.org>
	<6959e1680807111102n7d29a99bgf09156ceaca266fb@mail.gmail.com>
Message-ID: <97597BD3-312C-43FF-8618-8679D2228539@chittenden.org>

>> 130 tests, 716 assertions, 1 failures, 0 errors
>> rake aborted!
>> Command failed with status (1): [/opt/local/bin/ruby -Ilib:test:ext
>> "/opt/l...]
>>
>> (See full trace by running task with --trace)
>> Exit 1
>
> Yes, I think that is because of the implementation of
> register_error_handler.  I had fixed this in one of my previous
> patches....  Anyway, this seems to do the trick:

Yup, that fixes things... the output is all over the place.  Hrm, this  
works better but is a change in behavior.  I just committed the  
following (NOTE, this is a change in behavior and I am willing to  
revert this, but think this is a step forward, albeit an API change):

Clean up the error handling a bit and change the arguments for  
register_error_handler.

If XML::Parser.register_error_handler() is nil or false, error  
messages will be dropped on the floor.

If XML::Parser.register_error_handler() is true, it will print to  
stderr.

If XML::Parser.register_error_handler() is anything else, it will call  
the proc.  For example:

         XML::Parser.register_error_handler(lambda {|msg| p msg })


Ideally, I'd like it if XML::Parser.register_error_handler() would  
accept an IO object that the library would print to, but that's just a  
nicety (e.g. XML::Parser.register_error_handler($stdout)).  -sc

% rake test
(in /Users/sean/src/ruby-libxml/trunk)
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/ 
rake_test_loader
Started
..................................................................................................................................
Finished in 0.999928 seconds.

130 tests, 720 assertions, 0 failures, 0 errors


--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Fri Jul 11 15:00:26 2008
From: transfire at gmail.com (Trans)
Date: Fri, 11 Jul 2008 12:00:26 -0700 (PDT)
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com> 
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com> 
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
Message-ID: <96b3a4cf-9899-462b-b0c6-1461e8abf828@27g2000hsf.googlegroups.com>



On Jul 11, 12:45?pm, "Aaron Patterson" <aaron.patter... at gmail.com>
wrote:
> On Fri, Jul 11, 2008 at 9:33 AM, Sean Chittenden <s... at chittenden.org> wrote:
> >>> Not sure, I run ruby test/test_suite.rb.
>
> >> Looks like the test suite must be run from within the test directory.
> >> Otherwise test assets will not be found. ?I've added a patch to the
> >> tracker that figures out where the assets directory is so that you can
> >> run the tests from a different directory (e.g. the root of the
> >> project).
>
> >>http://rubyforge.org/tracker/index.php?func=detail&aid=21162&group_id...
>
> > Ha! ?I just committed something nearly identical to this because I couldn't
> > run the tests using ./setup.rb test. ?I didn't use the constant, however and
> > did the File.join(...) for each open call. ?Anyway, let me know if trunk
> > works for the tests for you now. ?-sc
>
> The tests still do not work from setup.rb. ?When I try to run the test
> suite from the root directory, I get an error loading libxml_ruby.
>
> I typically run the tests like this:
>
> [][aaron at amac libxml]$ ruby -I lib:ext:test test/test_suite.rb
>
> This patch seems to fix things (I will submit it to the tracker if you'd like):
>
> [][aaron at amac libxml]$ svn diff
> Index: lib/libxml.rb
> ===================================================================
> --- lib/libxml.rb ? ? ? (revision 382)
> +++ lib/libxml.rb ? ? ? (working copy)
> @@ -1,7 +1,7 @@
> ?# $Id$
> ?# Please see the LICENSE file for copyright and distribution information
>
> -require 'libxml_ruby'
> +require 'libxml/libxml_ruby'

That works if ext/ is added to the load path. But if you look at meta/
project.yaml you will see that the loadpath is [lib, ext/libxml]. The
lack of "ext/libxml" in the $LOAD_PATH is probably why you had some
troubles. (If you are wondering, meta/project.yaml is what reap used
to do it's thing.)

We can change the loadpath to just "ext" --that seems like a nice
simplification actually. But we will need to make sure 'libxml_ruby'
=> libxml/libxml_ruby' where ever it occurs. Does anyone see a reason
not to do so?

T.

From transfire at gmail.com  Fri Jul 11 15:15:46 2008
From: transfire at gmail.com (Trans)
Date: Fri, 11 Jul 2008 12:15:46 -0700 (PDT)
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com> 
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com> 
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com> 
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>
Message-ID: <1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>



On Jul 11, 1:45?pm, "Aaron Patterson" <aaron.patter... at gmail.com>
wrote:

> I've added a patch to the tracker that adds a test task and a build
> task to the rake file.
>
> ?http://rubyforge.org/tracker/index.php?func=detail&aid=21172&group_id...
>
> If you apply that patch, you can just execute 'rake build' to build
> the extension, and 'rake test' to run the tests.
> Also, 'rake extensions:clean' will clean up the extensions directory.

It's important that setup.rb works and can do these things (i.e.
build, test, install, etc.) b/c that's is how people NOT using
RubyGems perform an installation. And since setup.rb already has to do
these things, it is not DRY to have separate code in the Rakefile to
do the exact same thing. This is why the original Rakefile loaded
setup.rb, which I had modified to support Rake tasks. So, if there is
a problem with using setup.rb we need to fix it, not just work around
it with a new rake task.

However, I would like to do away with the setup.rb file and replace is
with a set of scripts in the directory "script/", eg. script/make,
script/test, script/install, etc. which (IMHO) is much more intuitive
way to provide these.

T.

From aaron.patterson at gmail.com  Fri Jul 11 15:21:32 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 12:21:32 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>
	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>
Message-ID: <6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>

On Fri, Jul 11, 2008 at 12:15 PM, Trans <transfire at gmail.com> wrote:
>
>
> On Jul 11, 1:45 pm, "Aaron Patterson" <aaron.patter... at gmail.com>
> wrote:
>
>> I've added a patch to the tracker that adds a test task and a build
>> task to the rake file.
>>
>>  http://rubyforge.org/tracker/index.php?func=detail&aid=21172&group_id...
>>
>> If you apply that patch, you can just execute 'rake build' to build
>> the extension, and 'rake test' to run the tests.
>> Also, 'rake extensions:clean' will clean up the extensions directory.
>
> It's important that setup.rb works and can do these things (i.e.
> build, test, install, etc.) b/c that's is how people NOT using
> RubyGems perform an installation. And since setup.rb already has to do
> these things, it is not DRY to have separate code in the Rakefile to
> do the exact same thing. This is why the original Rakefile loaded
> setup.rb, which I had modified to support Rake tasks. So, if there is
> a problem with using setup.rb we need to fix it, not just work around
> it with a new rake task.
>
> However, I would like to do away with the setup.rb file and replace is
> with a set of scripts in the directory "script/", eg. script/make,
> script/test, script/install, etc. which (IMHO) is much more intuitive
> way to provide these.

Separate scripts are more intuitive than rake tasks?

-- 
Aaron Patterson
http://tenderlovemaking.com/

From sean at chittenden.org  Fri Jul 11 15:26:25 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Fri, 11 Jul 2008 12:26:25 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>
	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>
	<6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
Message-ID: <CD514D04-AC19-4FEF-A594-F2B0667818A8@chittenden.org>

> Separate scripts are more intuitive than rake tasks?


I agree with Aaron in terms of usability... though I think setup.rb  
should be implemented in terms of rake tasks since setup.rb < rake  
functionality.  Granted that's not what exists in code....  -sc

--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Fri Jul 11 16:07:01 2008
From: transfire at gmail.com (Trans)
Date: Fri, 11 Jul 2008 13:07:01 -0700 (PDT)
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com> 
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com> 
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com> 
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com> 
	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com> 
	<6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
Message-ID: <122d31f7-22dd-43b1-a0fb-874d1d7b2e1a@t54g2000hsg.googlegroups.com>


On Jul 11, 3:21?pm, "Aaron Patterson" <aaron.patter... at gmail.com>
wrote:

> Separate scripts are more intuitive than rake tasks?

I understand what you thinking, but there are some considerations
involved. The reason we should use scripts rather than the Rakefile
(whether it be via the traditional setup.rb script or through separate
scripts as I have suggested) is because the end-installer ought not
need Rake to preform an installation (Rake is not included in Ruby
1.8+, btw). Moreover, a rakefile is intended for project maintainers --
it can have all sorts of maintainer tasks in it, including things like
packaging, uploading, publishing the website, making an announcement,
etc. There's no reason to provide an end user with these functions,
just as some support files are not included in a package. Finally,
setup.rb is not a simple script, and personally I wouldn't want to re-
implement all that as a Rake task (though I have in fact gone down
that path once, only to realize afterward that it was a pointless
affair for the other reasons stated).

The Rakefile can easily route to the separate end-user scripts as
needed.

T.

From aaron.patterson at gmail.com  Fri Jul 11 16:21:13 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 13:21:13 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <122d31f7-22dd-43b1-a0fb-874d1d7b2e1a@t54g2000hsg.googlegroups.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>
	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>
	<6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
	<122d31f7-22dd-43b1-a0fb-874d1d7b2e1a@t54g2000hsg.googlegroups.com>
Message-ID: <6959e1680807111321s60ab23eey4438c28248ef2e87@mail.gmail.com>

On Fri, Jul 11, 2008 at 1:07 PM, Trans <transfire at gmail.com> wrote:
>
> On Jul 11, 3:21 pm, "Aaron Patterson" <aaron.patter... at gmail.com>
> wrote:
>
>> Separate scripts are more intuitive than rake tasks?
>
> I understand what you thinking, but there are some considerations
> involved. The reason we should use scripts rather than the Rakefile
> (whether it be via the traditional setup.rb script or through separate
> scripts as I have suggested) is because the end-installer ought not
> need Rake to preform an installation (Rake is not included in Ruby
> 1.8+, btw). Moreover, a rakefile is intended for project maintainers --
> it can have all sorts of maintainer tasks in it, including things like
> packaging, uploading, publishing the website, making an announcement,
> etc. There's no reason to provide an end user with these functions,
> just as some support files are not included in a package. Finally,
> setup.rb is not a simple script, and personally I wouldn't want to re-
> implement all that as a Rake task (though I have in fact gone down
> that path once, only to realize afterward that it was a pointless
> affair for the other reasons stated).

IMO, it seems like more work than its worth to support the few people
that don't have rake installed.  If a user has to make sure that gcc,
libxml, libiconv, zlib, ruby, etc are installed, why not rake?

-- 
Aaron Patterson
http://tenderlovemaking.com/

From aaron.patterson at gmail.com  Fri Jul 11 17:09:00 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Fri, 11 Jul 2008 14:09:00 -0700
Subject: [libxml-devel] running tests from svn
In-Reply-To: <97597BD3-312C-43FF-8618-8679D2228539@chittenden.org>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111042r423009deq603cc15d6d296375@mail.gmail.com>
	<F5E43DEC-3F65-43F5-8226-00AAB57537B9@chittenden.org>
	<6959e1680807111049v60de847dk7861f99342c55ac7@mail.gmail.com>
	<21284899-D46D-4613-B016-95D09291B4E1@chittenden.org>
	<6959e1680807111102n7d29a99bgf09156ceaca266fb@mail.gmail.com>
	<97597BD3-312C-43FF-8618-8679D2228539@chittenden.org>
Message-ID: <6959e1680807111409tbad5976t3846a39db3712cf2@mail.gmail.com>

On Fri, Jul 11, 2008 at 11:47 AM, Sean Chittenden <sean at chittenden.org> wrote:
>>> 130 tests, 716 assertions, 1 failures, 0 errors
>>> rake aborted!
>>> Command failed with status (1): [/opt/local/bin/ruby -Ilib:test:ext
>>> "/opt/l...]
>>>
>>> (See full trace by running task with --trace)
>>> Exit 1
>>
>> Yes, I think that is because of the implementation of
>> register_error_handler.  I had fixed this in one of my previous
>> patches....  Anyway, this seems to do the trick:
>
> Yup, that fixes things... the output is all over the place.  Hrm, this works
> better but is a change in behavior.  I just committed the following (NOTE,
> this is a change in behavior and I am willing to revert this, but think this
> is a step forward, albeit an API change):
>
> Clean up the error handling a bit and change the arguments for
> register_error_handler.
>
> If XML::Parser.register_error_handler() is nil or false, error messages will
> be dropped on the floor.
>
> If XML::Parser.register_error_handler() is true, it will print to stderr.
>
> If XML::Parser.register_error_handler() is anything else, it will call the
> proc.  For example:
>
>        XML::Parser.register_error_handler(lambda {|msg| p msg })
>
>
> Ideally, I'd like it if XML::Parser.register_error_handler() would accept an
> IO object that the library would print to, but that's just a nicety (e.g.
> XML::Parser.register_error_handler($stdout)).  -sc

Ask and you shall receive Sean,

I've submitted a patch that moves register_error_handler from C to
Ruby, and lets you pass an IO object where error message may be
written.

http://rubyforge.org/tracker/index.php?func=detail&aid=21174&group_id=494&atid=1973

-- 
Aaron Patterson
http://tenderlovemaking.com/

From shimbo at is.naist.jp  Fri Jul 11 17:25:57 2008
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Sat, 12 Jul 2008 06:25:57 +0900
Subject: [libxml-devel] [ libxml-Bugs-8337 ] Opening many files causes
	segfault on fbsd-amd64
In-Reply-To: <1902FE14-ED3C-4DA2-8804-502038ACA6B5@chittenden.org>
References: <20080709173738.5B60E15B8002@rubyforge.org>
	<989032930807092054n60a16e3dq7faf4ad2988c5953@mail.gmail.com>
	<4875B68E.9090002@savagexi.com>
	<989032930807100126s66a6e1dcuc892ff97e2008ddb@mail.gmail.com>
	<4876CD6A.6010205@savagexi.com>
	<1902FE14-ED3C-4DA2-8804-502038ACA6B5@chittenden.org>
Message-ID: <989032930807111425m1f1d8ddfx23ee30958842851a@mail.gmail.com>

Hello Sean and Charlie,

>> Well, File.open is a ruby method while Document.open is a libxml method.
>>  Perhaps Ruby has some smarts built into it with File.open and the garbage
>> collector.
>
> Ruby does the same thing libxml now does, it calls the GC whenever errno is
> set to EMFILE or ENFILE.

Yes. Thank you very much for fixing this!

Masashi Shimbo

From transfire at gmail.com  Fri Jul 11 21:46:48 2008
From: transfire at gmail.com (Trans)
Date: Fri, 11 Jul 2008 18:46:48 -0700 (PDT)
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111321s60ab23eey4438c28248ef2e87@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com> 
	<4876D907.4060003@savagexi.com>
	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com> 
	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>
	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com> 
	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>
	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com> 
	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com> 
	<6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com> 
	<122d31f7-22dd-43b1-a0fb-874d1d7b2e1a@t54g2000hsg.googlegroups.com> 
	<6959e1680807111321s60ab23eey4438c28248ef2e87@mail.gmail.com>
Message-ID: <e3b94d52-3c4d-4ef4-9003-d54e7a8e155b@k37g2000hsf.googlegroups.com>



On Jul 11, 4:21?pm, "Aaron Patterson" <aaron.patter... at gmail.com>
wrote:

> IMO, it seems like more work than its worth to support the few people
> that don't have rake installed. ?If a user has to make sure that gcc,
> libxml, libiconv, zlib, ruby, etc are installed, why not rake?

That's not the main issue. setup.rb or equivalent is going to be there
anyway. why are we going to support two scripts to do the same thing?
and if you say, just put it all in the rakefile, what difference does
it make? You will just end up coping setup.rb into the rakefile.
setup.rb provides features that you maybe not realize, such as
alternate configuration and prefix, updates shebang lines, etc.

T.

From cfis at savagexi.com  Sat Jul 12 15:23:32 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 13:23:32 -0600
Subject: [libxml-devel] require 'libxml/libxml_ruby' breaks libxml
Message-ID: <487904B4.5000604@savagexi.com>

Ok, patch 383 breaks Windows and Linux.

Here is the patch:

Index: libxml.rb
===================================================================
-require 'libxml_ruby'
+require 'libxml/libxml_ruby'

The original code was correct.

In the case of a gem, libxml gets installed like this:

gems
   libxml
     ext
       libxml directory

     lib
       libxml.rb
       libxml_ruby.so
       <other ruby files>

In this case, require 'libxml_ruby' pulls from lib/xml_ruby.so

For setup.rb, libxml gets installed like this:

site_ruby
   libxml.rb
   i386-linux
     libxml_ruby.so

In this case, require 'libxml_ruby' pulls i386-linux/xml_ruby.so

So, I'm reverting the patch.

Also, there is an issue with setup.rb.  But I'll put that in a separate 
email.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/de7a4147/attachment.bin>

From cfis at savagexi.com  Sat Jul 12 15:29:09 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 13:29:09 -0600
Subject: [libxml-devel] Reverting setup.rb to 3.4.1
Message-ID: <48790605.4040900@savagexi.com>

Looking into the setup.rb issues, I realized two things:

* setup.rb wasn't included in the gems or .tgz packages, that is now fixed

* setup.rb was using an unreleased 3.5.0 version


The problem with the second issue is when I tried to run setup.rb on 
Linux (Fedora 8), it didn't work.  The offending line was line 10 at the 
very start:

PACKAGE = File.read(Dir.glob('{.,meta/}unixname{,.txt}',

So, I reverted to the last official setup.rb release, 3.4.1. That one 
ran correctly when I tried using it.

As a result, I've checked in the older version.  Feel free to shout out 
if this is the wrong thing to do.

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/641823b8/attachment.bin>

From cfis at savagexi.com  Sat Jul 12 15:43:55 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 13:43:55 -0600
Subject: [libxml-devel] running tests from svn
In-Reply-To: <6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
References: <6959e1680807101052rf4086a6h8c4d537d23279a78@mail.gmail.com>	<4876D907.4060003@savagexi.com>	<6959e1680807102217o2e502b2bi82466c177d7d2921@mail.gmail.com>	<E4C632B1-1F2A-4A59-A0E0-B06621C6F7C3@chittenden.org>	<6959e1680807110945y2822b7c0n1508972083064add@mail.gmail.com>	<21AC2872-B617-4A91-8B14-AB9912281117@chittenden.org>	<6959e1680807111045h55e8751h31cdf6f17393ac08@mail.gmail.com>	<1289793b-aaa0-48c5-8f8d-ac5537a1b3a0@w7g2000hsa.googlegroups.com>
	<6959e1680807111221l4e9cefd8naeaa8e96100af145@mail.gmail.com>
Message-ID: <4879097B.1010502@savagexi.com>

To follow up on this thread, with the updated setup.rb file in SVN, on 
Linux 8, this is what I get:

[cfis at orthoceras libxml-ruby-0.7.1]$ ruby setup.rb test
Running tests...
Loaded suite test
Started
.....................................................................................................................
/tmp/libxml-ruby-0.7.1/test/tc_xml_parser.rb:218: command not found: 
ulimit -n
................
Finished in 0.759047 seconds.


So seems ok.

Charlie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/910bb012/attachment.bin>

From cfis at savagexi.com  Sat Jul 12 16:04:54 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 14:04:54 -0600
Subject: [libxml-devel] implementing in Ruby vs C
Message-ID: <48790E66.4020409@savagexi.com>

> Hi!
> 
> As I've started reading through the libxml-ruby code, I have run
> across methods implemented in C that could be implemented in Ruby.  I
> would like to change them to be implemented in Ruby.  Is anyone
> opposed to that?  I think it would make coding easier, less buggy, and
> more fun!

So like Sean, I'm fine with this.

To make this easier, I've broken up lib/libxml.rb into a number of 
files, one per class.  That is more in line with Ruby standards, and 
reduces the changes of any conflicts.  So now libxml.rb is now just a 
list of requires.

So have at it...

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/47da1ca3/attachment-0001.bin>

From cfis at savagexi.com  Sat Jul 12 17:05:13 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 15:05:13 -0600
Subject: [libxml-devel] Proposed libxml 0.7.1 release
Message-ID: <48791C89.50906@savagexi.com>

Hi everyone,

I propose that we push out a 0.7.1 release that fixes the following bugs:

* Fix bug in accessing attribute results for an xpath expression

* Add backwards compatibility code for accessing node.properties (you 
should now use node.attributes)

* Fixes to setup.rb so it correctly works

* Fix file handling issues caused by opening multiple XML::Document 
instances

* Fix tests to use absolute paths

* Moved error handling to Ruby for more flexibility

The first three bugs are particularly nasty, and thus my eagerness to 
push out another update.

Thoughts?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/229f6d54/attachment.bin>

From transfire at gmail.com  Sat Jul 12 18:17:37 2008
From: transfire at gmail.com (Trans)
Date: Sat, 12 Jul 2008 15:17:37 -0700 (PDT)
Subject: [libxml-devel] Reverting setup.rb to 3.4.1
In-Reply-To: <48790605.4040900@savagexi.com>
References: <48790605.4040900@savagexi.com>
Message-ID: <84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>



On Jul 12, 3:29?pm, Charlie Savage <c... at savagexi.com> wrote:
> Looking into the setup.rb issues, I realized two things:
>
> * setup.rb wasn't included in the gems or .tgz packages, that is now fixed
>
> * setup.rb was using an unreleased 3.5.0 version
>
> The problem with the second issue is when I tried to run setup.rb on
> Linux (Fedora 8), it didn't work. ?The offending line was line 10 at the
> very start:
>
> PACKAGE = File.read(Dir.glob('{.,meta/}unixname{,.txt}',
>
> So, I reverted to the last official setup.rb release, 3.4.1. That one
> ran correctly when I tried using it.
>
> As a result, I've checked in the older version. ?Feel free to shout out
> if this is the wrong thing to do.

Well, I'd like to know why the line wasn't working? The line was there
in order to support installation of documentation to standard OS
location --a 3.5.0 feature. If the line had a problem  finding the
file my guess is the package was also missing the meta/ directory.
Ultimately this line isn't the best solution, but it sufficed until a
better approach became apparent. That aside, a quick fix would have
been:

  PACKAGE = 'libxml-ruby'

which is all this effectively does.

I realize that there is a great energy moving things along right now.
Believe me, I more than anyone am happy to see it! But I have to ask
you to consider a bit more why things may be the way they are. If
you're not sure then ask. For instance, I just rechecked out the
current trunk, and I see that lib/libxml has been moved to to just
lib/. That will break things very badly for anyone who installs using
setup.rb --in fact it will make a mess of their site_ruby directory!
Please move it back.

You can leave the 3.4.1 version of setup.rb for now. That's fine.
3.5.0 still needed a few tweaks --and as I said before I'd like to
replace it altogether anyway.

T.

From cfis at savagexi.com  Sat Jul 12 18:41:49 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 16:41:49 -0600
Subject: [libxml-devel] Reverting setup.rb to 3.4.1
In-Reply-To: <84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
Message-ID: <4879332D.2050501@savagexi.com>

Hi Trans,

>> As a result, I've checked in the older version.  Feel free to shout out
>> if this is the wrong thing to do.
> 
> Well, I'd like to know why the line wasn't working? The line was there
> in order to support installation of documentation to standard OS
> location --a 3.5.0 feature. If the line had a problem  finding the
> file my guess is the package was also missing the meta/ directory.
> Ultimately this line isn't the best solution, but it sufficed until a
> better approach became apparent. That aside, a quick fix would have
> been:
> 
>   PACKAGE = 'libxml-ruby'
> 
> which is all this effectively does.
> 
> I realize that there is a great energy moving things along right now.
> Believe me, I more than anyone am happy to see it! 

Sure, here is what I get:

$tar -xvzf libxml-ruby-0.7.1.tgz
$cd libxml-ruby-0.7.1
$ruby setup.rb

setup.rb:10:in `read': can't convert nil into String (TypeError)
         from setup.rb:10

Where:

Dir.glob('{.,meta/}unixname{,.txt}') returns []

So this breaks:

PACKAGE = File.read(Dir.glob('{.,meta/}unixname{,.txt}', 
File::FNM_CASEFOLD).first).strip


But I have to ask
> you to consider a bit more why things may be the way they are. If
> you're not sure then ask. 

Of course - which is why I posted a message to the mailing list saying 
what I did - my fix was temporary until I got further feedback.

For instance, I just rechecked out the
> current trunk, and I see that lib/libxml has been moved to to just
> lib/. 

Not sure what you mean here. Are you referring the files in that 
directory or are you referring to the requires in lib/libxml.rb?

That will break things very badly for anyone who installs using
> setup.rb --in fact it will make a mess of their site_ruby directory!
> Please move it back.

I agree the ruby/site_ruby directory does become a mess, and that 
putting files into a sub xml directory would be good.  However, I didn't 
actually change that - its the same as it was before.  The only change I 
made was splitting libxml.rb into separate files for easier maintenance. 
  I didn't change the directory layout or file locations.  So I'm not 
sure what needs to be reverted?  I don't think mashing all the files 
back into a single file is a good idea.  I do think movnig them into the 
xml subdirectory has some merit.

> You can leave the 3.4.1 version of setup.rb for now. That's fine.
> 3.5.0 still needed a few tweaks --and as I said before I'd like to
> replace it altogether anyway.

I'm fine either way, setup.rb isn't my cup of tea. Just as long as 
what's checked-in works.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/ad541951/attachment.bin>

From noreply at rubyforge.org  Sat Jul 12 15:47:38 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 12 Jul 2008 15:47:38 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21169 ] each_attr is broken in 0.7.0
Message-ID: <20080712194738.A7E4318585B8@rubyforge.org>

Bugs item #21169, was opened at 2008-07-11 08:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

Category: General
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Tiago Macedo (tmacedo)
>Assigned to: Charlie Savage (cfis)
Summary: each_attr is broken in 0.7.0

Initial Comment:
NameError: undefined local variable or method `properties' for #<XML::Node:0xb742ce64>
    /usr/lib/ruby/gems/1.8/gems/libxml-ruby-0.7.0/lib/libxml.rb:83:in `each_attr'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:167:in `hash_of_attributes'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:76:in `collapse'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:64:in `out'
    ./test/../lib/aws/../../support/faster-xml-simple/lib/faster_xml_simple.rb:53:in `xml_in'
    ./test/../lib/aws/s3/parsing.rb:64:in `parse'
    ./test/../lib/aws/s3/parsing.rb:55:in `initialize'
    ./test/parsing_test.rb:59:in `new'
    ./test/parsing_test.rb:59:in `test_policy_grants_are_always_an_array'


I ran into this issue by running the aws-s3 tests. aws-s3 relies in faster-xml-simple for libxml-ruby support

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-12 13:47

Message:
Hi Tiago,

There is now a new attributes class that is a collection of attributes - so its a cleaner api than previously.  Thus new code should look like this:

node.attributes.each do |attr|
..
end

I have added a patch for backwards compatibility though to SVN.  It will be in 0.7.1 (upcoming soon).

----------------------------------------------------------------------

Comment By: Tiago Macedo (tmacedo)
Date: 2008-07-11 08:34

Message:
I'm using gentoo's dev-libs/libxml2-2.6.32

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21169&group_id=494

From transfire at gmail.com  Sat Jul 12 22:56:27 2008
From: transfire at gmail.com (Trans)
Date: Sat, 12 Jul 2008 19:56:27 -0700 (PDT)
Subject: [libxml-devel] Reverting setup.rb to 3.4.1
In-Reply-To: <4879332D.2050501@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
Message-ID: <058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>



On Jul 12, 6:41?pm, Charlie Savage <c... at savagexi.com> wrote:

> >> As a result, I've checked in the older version. ?Feel free to shout out
> >> if this is the wrong thing to do.
>
> > Well, I'd like to know why the line wasn't working? The line was there
> > in order to support installation of documentation to standard OS
> > location --a 3.5.0 feature. If the line had a problem ?finding the
> > file my guess is the package was also missing the meta/ directory.
> > Ultimately this line isn't the best solution, but it sufficed until a
> > better approach became apparent. That aside, a quick fix would have
> > been:
>
> > ? PACKAGE = 'libxml-ruby'
>
> > which is all this effectively does.
>
> > I realize that there is a great energy moving things along right now.
> > Believe me, I more than anyone am happy to see it!
>
> Sure, here is what I get:
>
> $tar -xvzf libxml-ruby-0.7.1.tgz
> $cd libxml-ruby-0.7.1
> $ruby setup.rb
>
> setup.rb:10:in `read': can't convert nil into String (TypeError)
> ? ? ? ? ?from setup.rb:10
>
> Where:
>
> Dir.glob('{.,meta/}unixname{,.txt}') returns []
>
> So this breaks:
>
> PACKAGE = File.read(Dir.glob('{.,meta/}unixname{,.txt}',
> File::FNM_CASEFOLD).first).strip

> But I have to ask
>
> > you to consider a bit more why things may be the way they are. If
> > you're not sure then ask.
>
> Of course - which is why I posted a message to the mailing list saying
> what I did - my fix was temporary until I got further feedback.

You're right. You did. I was meaning to focus on this in particular.
It was a meant more as general cautionary note for all of us.

> For instance, I just rechecked out the
>
> > current trunk, and I see that lib/libxml has been moved to to just
> > lib/.
>
> Not sure what you mean here. Are you referring the files in that
> directory or are you referring to the requires in lib/libxml.rb?
>
> That will break things very badly for anyone who installs using
>
> > setup.rb --in fact it will make a mess of their site_ruby directory!
> > Please move it back.
>
> I agree the ruby/site_ruby directory does become a mess, and that
> putting files into a sub xml directory would be good. ?However, I didn't
> actually change that - its the same as it was before. ?The only change I
> made was splitting libxml.rb into separate files for easier maintenance.
> ? I didn't change the directory layout or file locations. ?So I'm not
> sure what needs to be reverted? ?I don't think mashing all the files
> back into a single file is a good idea. ?I do think movnig them into the
> xml subdirectory has some merit.

No not lib/xml/, that's were we had been. we need the code under lib/
libxml/. the xml/ directory is there only for backward compatibility.

T.

From cfis at savagexi.com  Sun Jul 13 00:36:52 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 12 Jul 2008 22:36:52 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
Message-ID: <48798664.8030904@savagexi.com>

Moving to new thread...

> No not lib/xml/, that's were we had been. we need the code under lib/
> libxml/. the xml/ directory is there only for backward compatibility.

So is this what you are proposing?

lib
   libxml.rb
   libxml
      attributes.rb
      attr.rb
      <plus other ruby files>


Meaning libxml.rb would look like this:

require 'libxml_ruby'
require 'libxml/attributes'
<etc>

Wouldn't using the existing subdirectory xml be more natural, simple 
since all the subiles are in the XML namespace?

Or are you proposing:

lib
   libxml
      libxml.rb
      xml
        attributes.rb
        attr.rb
        <plus other ruby files>

In this case, then code that uses libxml would have to do this:

require 'libxml/libxml'

Versus what happens now:

require 'libxml'

Thanks,

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080712/88fea56f/attachment-0001.bin>

From transfire at gmail.com  Sun Jul 13 07:00:50 2008
From: transfire at gmail.com (Trans)
Date: Sun, 13 Jul 2008 04:00:50 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <48798664.8030904@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
Message-ID: <3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>



On Jul 13, 12:36?am, Charlie Savage <c... at savagexi.com> wrote:
> Moving to new thread...
>
> > No not lib/xml/, that's were we had been. we need the code under lib/
> > libxml/. the xml/ directory is there only for backward compatibility.
>
> So is this what you are proposing?
>
> lib
> ? ?libxml.rb
> ? ?libxml
> ? ? ? attributes.rb
> ? ? ? attr.rb
> ? ? ? <plus other ruby files>
>
> Meaning libxml.rb would look like this:
>
> require 'libxml_ruby'
> require 'libxml/attributes'
> <etc>

Yep. See...

 
http://groups.google.com/group/libxml-devel/browse_thread/thread/2b87c9656c14eb2c/ae99e0bf4ffa9603?hl=en&lnk=gst&q=libxml+name#ae99e0bf4ffa9603

As Dan said in another thread too, we can set

  XML = LibXML

for compatibility.

T.

From aaron.patterson at gmail.com  Sun Jul 13 15:39:30 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Sun, 13 Jul 2008 12:39:30 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
Message-ID: <6959e1680807131239k7dcb9047m67bf2ee6f830e887@mail.gmail.com>

On Sun, Jul 13, 2008 at 4:00 AM, Trans <transfire at gmail.com> wrote:
>
>
> On Jul 13, 12:36 am, Charlie Savage <c... at savagexi.com> wrote:
>> Moving to new thread...
>>
>> > No not lib/xml/, that's were we had been. we need the code under lib/
>> > libxml/. the xml/ directory is there only for backward compatibility.
>>
>> So is this what you are proposing?
>>
>> lib
>>    libxml.rb
>>    libxml
>>       attributes.rb
>>       attr.rb
>>       <plus other ruby files>
>>
>> Meaning libxml.rb would look like this:
>>
>> require 'libxml_ruby'
>> require 'libxml/attributes'
>> <etc>
>
> Yep. See...
>
>
> http://groups.google.com/group/libxml-devel/browse_thread/thread/2b87c9656c14eb2c/ae99e0bf4ffa9603?hl=en&lnk=gst&q=libxml+name#ae99e0bf4ffa9603
>
> As Dan said in another thread too, we can set
>
>  XML = LibXML
>
> for compatibility.

The top level constant doesn't really matter to me.  As long as we do
like you said, and make sure to set the XML constant for
compatibility.

A couple things I would like are:  1) each ruby class in its own file,
and 2) each class under a directory corresponding to its module/class.

For example, the class LibXML::Node::Set would live as
"lib/libxml/node/set.rb".  The LibXML::Node class would live as
"lib/libxml/node.rb", and 'require' any classes that are defined in
its namespace.

In my experience, that has made finding classes easy and fairly intuitive.

-- 
Aaron Patterson
http://tenderlovemaking.com/

From transfire at gmail.com  Sun Jul 13 20:53:51 2008
From: transfire at gmail.com (Trans)
Date: Sun, 13 Jul 2008 17:53:51 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <6959e1680807131239k7dcb9047m67bf2ee6f830e887@mail.gmail.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<6959e1680807131239k7dcb9047m67bf2ee6f830e887@mail.gmail.com>
Message-ID: <bf30b813-cc63-4e2c-b2cd-41247b87710f@f36g2000hsa.googlegroups.com>



On Jul 13, 3:39?pm, "Aaron Patterson" <aaron.patter... at gmail.com>
wrote:
> On Sun, Jul 13, 2008 at 4:00 AM, Trans <transf... at gmail.com> wrote:
>
> > On Jul 13, 12:36 am, Charlie Savage <c... at savagexi.com> wrote:
> >> Moving to new thread...
>
> >> > No not lib/xml/, that's were we had been. we need the code under lib/
> >> > libxml/. the xml/ directory is there only for backward compatibility.
>
> >> So is this what you are proposing?
>
> >> lib
> >> ? ?libxml.rb
> >> ? ?libxml
> >> ? ? ? attributes.rb
> >> ? ? ? attr.rb
> >> ? ? ? <plus other ruby files>
>
> >> Meaning libxml.rb would look like this:
>
> >> require 'libxml_ruby'
> >> require 'libxml/attributes'
> >> <etc>
>
> > Yep. See...
>
> >http://groups.google.com/group/libxml-devel/browse_thread/thread/2b87...
>
> > As Dan said in another thread too, we can set
>
> > ?XML = LibXML
>
> > for compatibility.
>
> The top level constant doesn't really matter to me. ?As long as we do
> like you said, and make sure to set the XML constant for
> compatibility.

If there are no objections I can go ahead and make these adjustments.

> A couple things I would like are: ?1) each ruby class in its own file,
> and 2) each class under a directory corresponding to its module/class.
>
> For example, the class LibXML::Node::Set would live as
> "lib/libxml/node/set.rb". ?The LibXML::Node class would live as
> "lib/libxml/node.rb", and 'require' any classes that are defined in
> its namespace.
>
> In my experience, that has made finding classes easy and fairly intuitive.

Works for me, but I'll leave this to others (unless no one else wants
to do it).

T.

From cfis at savagexi.com  Sun Jul 13 21:56:38 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sun, 13 Jul 2008 19:56:38 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
Message-ID: <487AB256.3040206@savagexi.com>


> On Jul 13, 12:36 am, Charlie Savage <c... at savagexi.com> wrote:
>> Moving to new thread...
>>
>>> No not lib/xml/, that's were we had been. we need the code under lib/
>>> libxml/. the xml/ directory is there only for backward compatibility.
>> So is this what you are proposing?
>>
>> lib
>>    libxml.rb
>>    libxml
>>       attributes.rb
>>       attr.rb
>>       <plus other ruby files>
>>
>> Meaning libxml.rb would look like this:
>>
>> require 'libxml_ruby'
>> require 'libxml/attributes'
>> <etc>
> 
> Yep. See...
> 
>  
> http://groups.google.com/group/libxml-devel/browse_thread/thread/2b87c9656c14eb2c/ae99e0bf4ffa9603?hl=en&lnk=gst&q=libxml+name#ae99e0bf4ffa9603

I agree on the subdirectory, but I would vote its called xml and not 
libxml - mostly because that is what it already is.  Or is there some 
compatibility issue with other ruby xml libraries?

In truth though, its a fairly academic discussion.  From a a user 
perspective they'll just say require 'libxml' and how the code is 
actually pulled in irrelevant.


> 
> As Dan said in another thread too, we can set
> 
>   XML = LibXML

I interpret that to mean the C code should change the name of the module 
it defines from XML to LibXML.  Right now libxslt defines a module 
called XSLT, and the xpath code defines a class called XPath (should be 
a module). In other words, the libraries are naming the modules after 
the functionality they provide, versus the library name.

Either way is of course fine, and I can't see how one way is better than 
the other. Since this decision was made long ago, changing it strikes me 
as arbitrary, mostly change for changes sake.  What benefit does it 
offer that would make it worth it?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080713/524f2b97/attachment.bin>

From cfis at savagexi.com  Sun Jul 13 22:09:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sun, 13 Jul 2008 20:09:29 -0600
Subject: [libxml-devel] Why XML::Node::Set?
Message-ID: <487AB559.7010901@savagexi.com>

Looking through the xpath code, there is a class XML::Node::Set that 
seems fairly pointless. It duplicates the functionality already provided 
in the XPath::Object class.

nodes = document.find('/header')
nodes.class == XPath::Object
nodes.first
nodes.length
nodes.each do |node|
  ..
end

And then...

node_set = nodes.set
node_set.class == XML::Node::Set
node.first
node.length
node.each do |node|
  ..
end


Seems better to re-purpose the XML::Node::Set to be used to return a 
node set when a user calls node.children (which now returns a node, 
which is fairly weird, although that is how libxml works).

If that doesn't make sense, then it should just be removed. 
XPath::Object#set could just return itself, calling code would be none 
the wiser since the API's are identical.

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080713/2758873d/attachment.bin>

From transfire at gmail.com  Sun Jul 13 22:42:36 2008
From: transfire at gmail.com (Trans)
Date: Sun, 13 Jul 2008 22:42:36 -0400
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487AB256.3040206@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
Message-ID: <4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>

2008/7/13 Charlie Savage <cfis at savagexi.com>:

> I agree on the subdirectory, but I would vote its called xml and not libxml
> - mostly because that is what it already is.  Or is there some compatibility
> issue with other ruby xml libraries?
>
> In truth though, its a fairly academic discussion.  From a a user
> perspective they'll just say require 'libxml' and how the code is actually
> pulled in irrelevant.
>
>
>>
>> As Dan said in another thread too, we can set
>>
>>  XML = LibXML
>
> I interpret that to mean the C code should change the name of the module it
> defines from XML to LibXML.  Right now libxslt defines a module called XSLT,
> and the xpath code defines a class called XPath (should be a module). In
> other words, the libraries are naming the modules after the functionality
> they provide, versus the library name.
>
> Either way is of course fine, and I can't see how one way is better than the
> other. Since this decision was made long ago, changing it strikes me as
> arbitrary, mostly change for changes sake.  What benefit does it offer that
> would make it worth it?

It follows general practice -- of naming the project, gem, lib
directory and main module all the same. This is done to prevent people
from stepping on each other toes, plus of course it provides
convenience and consistency.

Also, to use XML as our top-level namespace is to claim a sort of
ownership to that name --in which case we might as well name the
project "xml" too. Of course, we could argue that LibXML is *THE* xml
library, so the namespace is appropriate. I'm just not sure that's
really fair. What if the REXML considered itself in a similar light
for Ruby and had decided to use XML as it's namespace? Then again, who
does have legitimate claim to the XML namespace? Matz? So one could
argue this either way. As you say, it is somewhat academic. But I
think it's just generally better to stick with the general practice,
if we can.

Note, a possible alternative is to use LibXML::XML::

T.

From sean at chittenden.org  Mon Jul 14 01:12:45 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Sun, 13 Jul 2008 22:12:45 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
Message-ID: <680B882A-F681-4D7B-A83C-CE9B551A6317@chittenden.org>

> Note, a possible alternative is to use LibXML::XML::


I think libxml.rb could/should include LibXML if the XML namespace is  
not included.  Let users unfoobar their own env however they see fit  
to have two conflicting XML modules.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Mon Jul 14 04:10:54 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 02:10:54 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
Message-ID: <487B0A0E.8010500@savagexi.com>


> It follows general practice -- of naming the project, gem, lib
> directory and main module all the same. This is done to prevent people
> from stepping on each other toes, plus of course it provides
> convenience and consistency.
> 
> Also, to use XML as our top-level namespace is to claim a sort of
> ownership to that name --in which case we might as well name the
> project "xml" too. Of course, we could argue that LibXML is *THE* xml
> library, so the namespace is appropriate. I'm just not sure that's
> really fair. 

I agree.  If things were starting from scratch, this would be a 
non-issue, LibXml would clearly be the right choice.  The problem of 
course is things aren't starting from scratch.

So - say we switch to a LibXML namespace.  Then of course the first 
thing we would have to do is map the XML namespace to the LibXML 
namespace.  Because if we don't, everyone's code will break, and that 
will result in unhappy users.

Thus I don't see much point in changing.  It was a mistake for sure, but 
one that was made and is now undoable.  And I suppose on the bright 
side, no other module has claimed the XML namespace, has it (I guess we 
get squatters rights).

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/49621966/attachment.bin>

From danj at 3skel.com  Mon Jul 14 08:32:23 2008
From: danj at 3skel.com (Dan Janowski)
Date: Mon, 14 Jul 2008 08:32:23 -0400
Subject: [libxml-devel] Why XML::Node::Set?
In-Reply-To: <487AB559.7010901@savagexi.com>
References: <487AB559.7010901@savagexi.com>
Message-ID: <1269D461-2FB5-4FC8-A889-F9D7F04057AF@3skel.com>

I did this for compatibility. Set is clearly just a pass through to  
Object. I cannot recall if there is something that expects identity in  
is_a?.

Dan


On Jul 13, 2008, at 22:09, Charlie Savage wrote:
> Looking through the xpath code, there is a class XML::Node::Set that  
> seems fairly pointless. It duplicates the functionality already  
> provided in the XPath::Object class.
>
> nodes = document.find('/header')
> nodes.class == XPath::Object
> nodes.first
> nodes.length
> nodes.each do |node|
> ..
> end
>
> And then...
>
> node_set = nodes.set
> node_set.class == XML::Node::Set
> node.first
> node.length
> node.each do |node|
> ..
> end
>
>
> Seems better to re-purpose the XML::Node::Set to be used to return a  
> node set when a user calls node.children (which now returns a node,  
> which is fairly weird, although that is how libxml works).
>
> If that doesn't make sense, then it should just be removed.  
> XPath::Object#set could just return itself, calling code would be  
> none the wiser since the API's are identical.
>
> Charlie
>
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel


From transfire at gmail.com  Mon Jul 14 09:08:01 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 06:08:01 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B0A0E.8010500@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
Message-ID: <7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>



On Jul 14, 4:10?am, Charlie Savage <c... at savagexi.com> wrote:
> > It follows general practice -- of naming the project, gem, lib
> > directory and main module all the same. This is done to prevent people
> > from stepping on each other toes, plus of course it provides
> > convenience and consistency.
>
> > Also, to use XML as our top-level namespace is to claim a sort of
> > ownership to that name --in which case we might as well name the
> > project "xml" too. Of course, we could argue that LibXML is *THE* xml
> > library, so the namespace is appropriate. I'm just not sure that's
> > really fair.
>
> I agree. ?If things were starting from scratch, this would be a
> non-issue, LibXml would clearly be the right choice. ?The problem of
> course is things aren't starting from scratch.
>
> So - say we switch to a LibXML namespace. ?Then of course the first
> thing we would have to do is map the XML namespace to the LibXML
> namespace. ?Because if we don't, everyone's code will break, and that
> will result in unhappy users.

True. But the idea, as with any change like this, would be to encourge
users to migrate to LibXML:: and deprecate XML:: at sometime in the
far future.

> Thus I don't see much point in changing. ?It was a mistake for sure, but
> one that was made and is now undoable. ?And I suppose on the bright
> side, no other module has claimed the XML namespace, has it (I guess we
> get squatters rights).

True as well. But I wouldn't say undoable. We can *responsibly*
migrate. Or we can take a simpler solution and just wrap everything in
LibXML module. Then in libxml.rb:

  include LibXML

I leave it up to you all to decide what is best. All I ask is that the
lib directory at least be called 'libxml'.  There is a more direct
connection between the project name and the file system space than
there is between the file space and the module structure. The later is
convenient, but quite optional.

T.

From cfis at savagexi.com  Mon Jul 14 12:22:00 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 10:22:00 -0600
Subject: [libxml-devel] Why XML::Node::Set?
In-Reply-To: <1269D461-2FB5-4FC8-A889-F9D7F04057AF@3skel.com>
References: <487AB559.7010901@savagexi.com>
	<1269D461-2FB5-4FC8-A889-F9D7F04057AF@3skel.com>
Message-ID: <487B7D28.1040403@savagexi.com>



Dan Janowski wrote:
> I did this for compatibility. Set is clearly just a pass through to 
> Object.

Other way around.  You get an Object back and call Object#set to get a 
set if you want.

> I cannot recall if there is something that expects identity in 
> is_a?.

Hmm, not identity, but maybe equality.  But I think that is to_arr 
instead of to_a.

So objections to getting rid of it in the long-term (not going to do 
that right now)?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/06483f53/attachment.bin>

From cfis at savagexi.com  Mon Jul 14 12:34:51 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 10:34:51 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
Message-ID: <487B802B.5080709@savagexi.com>

> 
> True as well. But I wouldn't say undoable. We can *responsibly*
> migrate. Or we can take a simpler solution and just wrap everything in
> LibXML module. Then in libxml.rb:
> 
>   include LibXML

Ok - I can agree with that.  Done.

> I leave it up to you all to decide what is best. All I ask is that the
> lib directory at least be called 'libxml'. 

Done.

With those changes, I'm going to cut a new 0.7.1 release unless there 
are objections.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/cd35e00e/attachment-0001.bin>

From transfire at gmail.com  Mon Jul 14 12:47:18 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 09:47:18 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B802B.5080709@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
Message-ID: <b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>



On Jul 14, 12:34?pm, Charlie Savage <c... at savagexi.com> wrote:
> > True as well. But I wouldn't say undoable. We can *responsibly*
> > migrate. Or we can take a simpler solution and just wrap everything in
> > LibXML module. Then in libxml.rb:
>
> > ? include LibXML
>
> Ok - I can agree with that. ?Done.
>
> > I leave it up to you all to decide what is best. All I ask is that the
> > lib directory at least be called 'libxml'.
>
> Done.
>
> With those changes, I'm going to cut a new 0.7.1 release unless there
> are objections.

Cool. But give me a few hours to check it out, okay?

T.

From transfire at gmail.com  Mon Jul 14 12:47:18 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 09:47:18 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B802B.5080709@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
Message-ID: <b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>



On Jul 14, 12:34?pm, Charlie Savage <c... at savagexi.com> wrote:
> > True as well. But I wouldn't say undoable. We can *responsibly*
> > migrate. Or we can take a simpler solution and just wrap everything in
> > LibXML module. Then in libxml.rb:
>
> > ? include LibXML
>
> Ok - I can agree with that. ?Done.
>
> > I leave it up to you all to decide what is best. All I ask is that the
> > lib directory at least be called 'libxml'.
>
> Done.
>
> With those changes, I'm going to cut a new 0.7.1 release unless there
> are objections.

Cool. But give me a few hours to check it out, okay?

T.

From cfis at savagexi.com  Mon Jul 14 12:48:24 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 10:48:24 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>
	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
Message-ID: <487B8358.1050607@savagexi.com>



Trans wrote:
> 
> On Jul 14, 12:34 pm, Charlie Savage <c... at savagexi.com> wrote:
>>> True as well. But I wouldn't say undoable. We can *responsibly*
>>> migrate. Or we can take a simpler solution and just wrap everything in
>>> LibXML module. Then in libxml.rb:
>>>   include LibXML
>> Ok - I can agree with that.  Done.
>>
>>> I leave it up to you all to decide what is best. All I ask is that the
>>> lib directory at least be called 'libxml'.
>> Done.
>>
>> With those changes, I'm going to cut a new 0.7.1 release unless there
>> are objections.
> 
> Cool. But give me a few hours to check it out, okay?

No problem.  Just updating the RDocs at the moment.  The namespace 
change is checked in.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/92bff1e8/attachment.bin>

From transfire at gmail.com  Mon Jul 14 13:32:56 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 10:32:56 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B8358.1050607@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
	<487B8358.1050607@savagexi.com>
Message-ID: <eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>



On Jul 14, 12:48?pm, Charlie Savage <c... at savagexi.com> wrote:
> Trans wrote:
>
> > On Jul 14, 12:34 pm, Charlie Savage <c... at savagexi.com> wrote:
> >>> True as well. But I wouldn't say undoable. We can *responsibly*
> >>> migrate. Or we can take a simpler solution and just wrap everything in
> >>> LibXML module. Then in libxml.rb:
> >>> ? include LibXML
> >> Ok - I can agree with that. ?Done.
>
> >>> I leave it up to you all to decide what is best. All I ask is that the
> >>> lib directory at least be called 'libxml'.
> >> Done.
>
> >> With those changes, I'm going to cut a new 0.7.1 release unless there
> >> are objections.
>
> > Cool. But give me a few hours to check it out, okay?
>
> No problem. ?Just updating the RDocs at the moment. ?The namespace
> change is checked in.

Okay. I just did a little clean up. You'll notice I added an admin/
directory; this works well for separating administrative material. And
I updated the Rakefile -- The gem's require_path needed ext/libxml
added to it; and I made packages get stored in admin/pkg/ instead of
pkg/.

T.

From transfire at gmail.com  Mon Jul 14 13:51:06 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 10:51:06 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B802B.5080709@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
Message-ID: <55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>



On Jul 14, 12:34?pm, Charlie Savage <c... at savagexi.com> wrote:
> > True as well. But I wouldn't say undoable. We can *responsibly*
> > migrate. Or we can take a simpler solution and just wrap everything in
> > LibXML module. Then in libxml.rb:
>
> > ? include LibXML
>
> Ok - I can agree with that. ?Done.
>
> > I leave it up to you all to decide what is best. All I ask is that the
> > lib directory at least be called 'libxml'.
>
> Done.
>
> With those changes, I'm going to cut a new 0.7.1 release unless there
> are objections.

He he. Hold on. I think you misunderstood what I mean by "include
LibXML". This is what I was thinking (using document.rb as an
example):

  module LibXML
    module XML
      class Document
        ...

then in libxml.rb:

  include LibXML

so everything will work just as it did before, but there would be an
extra level of namespace. I'm not sure this is the best solution, but
it was the thought.

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

T.

From cfis at savagexi.com  Mon Jul 14 13:42:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 11:42:29 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>	<487B8358.1050607@savagexi.com>
	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
Message-ID: <487B9005.7030901@savagexi.com>



Trans wrote:
> 
> On Jul 14, 12:48 pm, Charlie Savage <c... at savagexi.com> wrote:
>> Trans wrote:
>>
>>> On Jul 14, 12:34 pm, Charlie Savage <c... at savagexi.com> wrote:
>>>>> True as well. But I wouldn't say undoable. We can *responsibly*
>>>>> migrate. Or we can take a simpler solution and just wrap everything in
>>>>> LibXML module. Then in libxml.rb:
>>>>>   include LibXML
>>>> Ok - I can agree with that.  Done.
>>>>> I leave it up to you all to decide what is best. All I ask is that the
>>>>> lib directory at least be called 'libxml'.
>>>> Done.
>>>> With those changes, I'm going to cut a new 0.7.1 release unless there
>>>> are objections.
>>> Cool. But give me a few hours to check it out, okay?
>> No problem.  Just updating the RDocs at the moment.  The namespace
>> change is checked in.
> 
> Okay. I just did a little clean up. You'll notice I added an admin/
> directory; this works well for separating administrative material. And
> I updated the Rakefile -- The gem's require_path needed ext/libxml
> added to it; and I made packages get stored in admin/pkg/ instead of
> pkg/.

Sounds great.

One question though - do we really want the pkg directory to be checked 
into SVN?

The issue is that rake clobber removes it, so then SVN gets confused 
when the packages are rebuilt and the directory is recreated.  If we do 
want it in SVN, then rake clobber is going to have to be changed (which 
would mean changing the rake packaging tasks assumedly).

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/bf4a7d62/attachment.bin>

From transfire at gmail.com  Mon Jul 14 14:13:29 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 14:13:29 -0400
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487B9005.7030901@savagexi.com>
References: <48790605.4040900@savagexi.com> <487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
	<487B8358.1050607@savagexi.com>
	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
	<487B9005.7030901@savagexi.com>
Message-ID: <4b6f054f0807141113i1427d161k8f36854975473e37@mail.gmail.com>

2008/7/14 Charlie Savage <cfis at savagexi.com>:
>
>
> Trans wrote:
>>
>> On Jul 14, 12:48 pm, Charlie Savage <c... at savagexi.com> wrote:
>>>
>>> Trans wrote:
>>>
>>>> On Jul 14, 12:34 pm, Charlie Savage <c... at savagexi.com> wrote:
>>>>>>
>>>>>> True as well. But I wouldn't say undoable. We can *responsibly*
>>>>>> migrate. Or we can take a simpler solution and just wrap everything in
>>>>>> LibXML module. Then in libxml.rb:
>>>>>>  include LibXML
>>>>>
>>>>> Ok - I can agree with that.  Done.
>>>>>>
>>>>>> I leave it up to you all to decide what is best. All I ask is that the
>>>>>> lib directory at least be called 'libxml'.
>>>>>
>>>>> Done.
>>>>> With those changes, I'm going to cut a new 0.7.1 release unless there
>>>>> are objections.
>>>>
>>>> Cool. But give me a few hours to check it out, okay?
>>>
>>> No problem.  Just updating the RDocs at the moment.  The namespace
>>> change is checked in.
>>
>> Okay. I just did a little clean up. You'll notice I added an admin/
>> directory; this works well for separating administrative material. And
>> I updated the Rakefile -- The gem's require_path needed ext/libxml
>> added to it; and I made packages get stored in admin/pkg/ instead of
>> pkg/.
>
> Sounds great.
>
> One question though - do we really want the pkg directory to be checked into
> SVN?
>
> The issue is that rake clobber removes it, so then SVN gets confused when
> the packages are rebuilt and the directory is recreated.  If we do want it
> in SVN, then rake clobber is going to have to be changed (which would mean
> changing the rake packaging tasks assumedly).

Nope. we should add it to svn ignore property.

T.

From cfis at savagexi.com  Mon Jul 14 15:01:10 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 13:01:10 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>	<487B8358.1050607@savagexi.com>
	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
Message-ID: <487BA276.3070504@savagexi.com>

FYI,


> I updated the Rakefile -- The gem's require_path needed ext/libxml
> added to it; and I made packages get stored in admin/pkg/ instead of
> pkg/.

That broke the gem.  spec.require_path assumes that you pass it a 
string.  What you really wanted to do was:

   spec.require_paths = ["lib", "ext/libxml"]

Fix checked in.

Also, I incremented the version to 0.8.0, based on the thought that the 
LibXML module change warranted more than a 0.7.1 release.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/77a5d041/attachment.bin>

From transfire at gmail.com  Mon Jul 14 15:21:50 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 12:21:50 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487BA276.3070504@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
	<487B8358.1050607@savagexi.com>
	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
	<487BA276.3070504@savagexi.com>
Message-ID: <ad17be64-901f-47d3-9147-dd6bc2bc9f38@a70g2000hsh.googlegroups.com>



On Jul 14, 3:01?pm, Charlie Savage <c... at savagexi.com> wrote:
> FYI,
>
> > I updated the Rakefile -- The gem's require_path needed ext/libxml
> > added to it; and I made packages get stored in admin/pkg/ instead of
> > pkg/.
>
> That broke the gem. ?spec.require_path assumes that you pass it a
> string. ?What you really wanted to do was:
>
> ? ?spec.require_paths = ["lib", "ext/libxml"]

oops. that's what I meant to put.

> Fix checked in.
>
> Also, I incremented the version to 0.8.0, based on the thought that the
> LibXML module change warranted more than a 0.7.1 release.

okay. but lets try to pace ourselves a bit or will be out out of
numbers soon ;)

T.

From cfis at savagexi.com  Mon Jul 14 15:28:58 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 13:28:58 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <ad17be64-901f-47d3-9147-dd6bc2bc9f38@a70g2000hsh.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>	<487B8358.1050607@savagexi.com>	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>	<487BA276.3070504@savagexi.com>
	<ad17be64-901f-47d3-9147-dd6bc2bc9f38@a70g2000hsh.googlegroups.com>
Message-ID: <487BA8FA.6090402@savagexi.com>

>> Also, I incremented the version to 0.8.0, based on the thought that the
>> LibXML module change warranted more than a 0.7.1 release.
> 
> okay. but lets try to pace ourselves a bit or will be out out of
> numbers soon ;)

No doubt!  And we might event get to a 1.0.0 :)

FWIW, I actually think we're close to a 1.0.0 quality release.  The only 
issue I know about is the segmentation fault that occurs if a document 
is freed by the GC before any dependent XML::XPath::Object instances. 
I've worked out in my head how to fix that, and the internal XPath 
refactoring I checked in got the code to a point where its now solvable 
(although in an ugly manner).

Luckily, we have all of 0.8.x and 0.9.x to make sure we get it right.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/bd91a148/attachment.bin>

From transfire at gmail.com  Mon Jul 14 18:52:10 2008
From: transfire at gmail.com (Trans)
Date: Mon, 14 Jul 2008 15:52:10 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487BA8FA.6090402@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>
	<4879332D.2050501@savagexi.com>
	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>
	<48798664.8030904@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>
	<487B8358.1050607@savagexi.com>
	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>
	<487BA276.3070504@savagexi.com>
	<ad17be64-901f-47d3-9147-dd6bc2bc9f38@a70g2000hsh.googlegroups.com>
	<487BA8FA.6090402@savagexi.com>
Message-ID: <94bc0a73-26ff-4e15-bb11-1f91dce10832@2g2000hsn.googlegroups.com>



On Jul 14, 3:28?pm, Charlie Savage <c... at savagexi.com> wrote:
> >> Also, I incremented the version to 0.8.0, based on the thought that the
> >> LibXML module change warranted more than a 0.7.1 release.
>
> > okay. but lets try to pace ourselves a bit or will be out out of
> > numbers soon ;)
>
> No doubt! ?And we might event get to a 1.0.0 :)
>
> FWIW, I actually think we're close to a 1.0.0 quality release. ?The only
> issue I know about is the segmentation fault that occurs if a document
> is freed by the GC before any dependent XML::XPath::Object instances.
> I've worked out in my head how to fix that, and the internal XPath
> refactoring I checked in got the code to a point where its now solvable
> (although in an ugly manner).
>
> Luckily, we have all of 0.8.x and 0.9.x to make sure we get it right.

:)

Concerning the next release, let's here from Sean on on the namespace
first; if it works for him then go for it.

BTW, I asked about it on ruby-talk to see what general sense of it
there might be.

  http://groups.google.com/group/ruby-talk-google/browse_thread/thread/184734f1a537d9f4?hl=en#

T.


From cfis at savagexi.com  Mon Jul 14 19:26:18 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 17:26:18 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <94bc0a73-26ff-4e15-bb11-1f91dce10832@2g2000hsn.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>	<487B8358.1050607@savagexi.com>	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>	<487BA276.3070504@savagexi.com>	<ad17be64-901f-47d3-9147-dd6bc2bc9f38@a70g2000hsh.googlegroups.com>	<487BA8FA.6090402@savagexi.com>
	<94bc0a73-26ff-4e15-bb11-1f91dce10832@2g2000hsn.googlegroups.com>
Message-ID: <487BE09A.2080306@savagexi.com>

> 
> Concerning the next release, let's here from Sean on on the namespace
> first; if it works for him then go for it.

Ok - Sean?  I'd like to get this out sooner than later due to the 
attribute issues with 0.7.0.

FYI - I made sure all tests worked using the XML namespace.

> 
> BTW, I asked about it on ruby-talk to see what general sense of it
> there might be.
> 
>   http://groups.google.com/group/ruby-talk-google/browse_thread/thread/184734f1a537d9f4?hl=en#

I'll respond there then.

Note I did this is libxml.rb


# Deprecated <etc>
module XML
   include LibXML
end

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/30e00f31/attachment-0001.bin>

From cfis at savagexi.com  Tue Jul 15 01:30:26 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 23:30:26 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
Message-ID: <487C35F2.7050103@savagexi.com>

> 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

Hmm, good question.  I bet either way probably works.  I suppose the 
global variable would be easier to override though versus the include 
(can you uninclude something?).

I got started down the include route to make XML::XSLT work.

module XML
   include LibXSLT
end

But I suppose that could also be a global variable.  So...I don't have 
an opinion either way.

FYI, I moved to XSLT to LibXSLT to be consistent.  Although when I 
started using it, I found it to be a bit ugly.  Take a look:

   # Create a new XSL Transform
   stylesheet_doc = LibXML::Document.file('files/fuzface.xsl')
   stylesheet     = LibXSLT::Stylesheet.new(stylesheet_doc)

   # Transform a xml document
   xml_doc = LibXML::Document.file('files/fuzface.xml')
   result = stylesheet.apply(xml_doc)


Notice how hard it becomes to distinguish the namespaces (LibXML and 
LibXSLT).  Compare:

   # Create a new XSL Transform
   stylesheet_doc = XML::Document.file('files/fuzface.xsl')
   stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)

Thoughts?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/ae83b1a7/attachment.bin>

From cfis at savagexi.com  Tue Jul 15 01:33:53 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 14 Jul 2008 23:33:53 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <4b6f054f0807141113i1427d161k8f36854975473e37@mail.gmail.com>
References: <48790605.4040900@savagexi.com>
	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<b84183df-53d4-4cce-9b59-132c6e2fa567@b1g2000hsg.googlegroups.com>	<487B8358.1050607@savagexi.com>	<eac62f1c-03d1-488b-a1e0-cf79db75e459@s50g2000hsb.googlegroups.com>	<487B9005.7030901@savagexi.com>
	<4b6f054f0807141113i1427d161k8f36854975473e37@mail.gmail.com>
Message-ID: <487C36C1.20204@savagexi.com>



>> The issue is that rake clobber removes it, so then SVN gets confused when
>> the packages are rebuilt and the directory is recreated.  If we do want it
>> in SVN, then rake clobber is going to have to be changed (which would mean
>> changing the rake packaging tasks assumedly).
> 
> Nope. we should add it to svn ignore property.

Hoping you'd say that.  Done.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080714/6abad436/attachment.bin>

From sean at chittenden.org  Tue Jul 15 12:30:08 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Tue, 15 Jul 2008 09:30:08 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487C35F2.7050103@savagexi.com>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
Message-ID: <7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>

>> 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.

# XX untested
if ['0','false','no','off',false,nil,'hell god damn "no!" me  
harder'].include? (ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :  
ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
   # Only LibXML class
else
   XML = LibXML
end

Then users can set the env variable and goto town however they want.

> FYI, I moved to XSLT to LibXSLT to be consistent.  Although when I  
> started using it, I found it to be a bit ugly.  Take a look:
>
>  # Create a new XSL Transform
>  stylesheet_doc = LibXML::Document.file('files/fuzface.xsl')
>  stylesheet     = LibXSLT::Stylesheet.new(stylesheet_doc)
>
>  # Transform a xml document
>  xml_doc = LibXML::Document.file('files/fuzface.xml')
>  result = stylesheet.apply(xml_doc)
>
>
> Notice how hard it becomes to distinguish the namespaces (LibXML and  
> LibXSLT).  Compare:
>
>  # Create a new XSL Transform
>  stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>  stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>
> Thoughts?


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.  Bah!  A "User" identifier is  
holy, but XML is not (one is application, the other is library).  I  
think the above 'LibXML'-ification of the namespace is appropriate,  
however, but focus on making the library easy to use, hence XML vs  
LibXML.

Don't step on other people's dicks intentionally, but it's okay for  
the library to be assertive and to match its ambitions.  Tip-toeing  
around 'what if' is an endless rabbit hole.  We'll adapt and find a  
solution if there is a problem at some point in the future.  Cool?

-sc

--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Tue Jul 15 13:02:37 2008
From: transfire at gmail.com (Trans)
Date: Tue, 15 Jul 2008 13:02:37 -0400
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
References: <48790605.4040900@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
Message-ID: <4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>

On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <sean at chittenden.org> 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 LibXML
>>>  end
>
> Use an environment variable at require time and the module assigns.
>
> # XX untested
> if ['0','false','no','off',false,nil,'hell god damn "no!" me
> harder'].include? (ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :
> ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
>  # Only LibXML class
> else
>  XML = LibXML
> end
>
> Then users can set the env variable and goto town however they want.
>
>> FYI, I moved to XSLT to LibXSLT to be consistent.  Although when I started
>> using it, I found it to be a bit ugly.  Take a look:
>>
>>  # Create a new XSL Transform
>>  stylesheet_doc = LibXML::Document.file('files/fuzface.xsl')
>>  stylesheet     = LibXSLT::Stylesheet.new(stylesheet_doc)
>>
>>  # Transform a xml document
>>  xml_doc = LibXML::Document.file('files/fuzface.xml')
>>  result = stylesheet.apply(xml_doc)
>>
>>
>> Notice how hard it becomes to distinguish the namespaces (LibXML and
>> LibXSLT).  Compare:
>>
>>  # Create a new XSL Transform
>>  stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>>  stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>>
>> Thoughts?
>
>
> 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.  Bah!  A "User" identifier is holy, but XML is not (one is
> application, the other is library).  I think the above 'LibXML'-ification of
> the namespace is appropriate, however, but focus on making the library easy
> to use, hence XML vs LibXML.
>
> Don't step on other people's dicks intentionally, but it's okay for the
> library to be assertive and to match its ambitions.  Tip-toeing around 'what
> if' is an endless rabbit hole.  We'll adapt and find a solution if there is
> a problem at some point in the future.  Cool?

Actually I agree. XML:: and XSLT:: are a lot better. Trying to find
the right balance between ease-of-use and interoperability can be
difficult.

I think we should reconsider wrapping what we have in a LibXML
namespace. This provides for both possibilities. Usage would entail:

  require 'libxml'

  module MyApp
    include LibXML

    # Create a new XSL Transform
    stylesheet_doc = XML::Document.file('files/fuzface.xsl')
    stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
    ...
  end

See that's nice to use and proper! :-)

I think we tend to think in terms of the toplevel, but in most
applications this isn't the case.

T.

From cfis at savagexi.com  Tue Jul 15 14:59:01 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 12:59:01 -0600
Subject: [libxml-devel] Home page benchmark code?
Message-ID: <487CF375.5040104@savagexi.com>

Curious where the code for the benchmark results on the libxml home page 
lives?

Thanks

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/3ebbf7b9/attachment-0001.bin>

From cfis at savagexi.com  Tue Jul 15 15:20:04 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 13:20:04 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
References: <48790605.4040900@savagexi.com>	<84f87cdd-f7bc-4813-982f-9497f62174c8@79g2000hsk.googlegroups.com>	<4879332D.2050501@savagexi.com>	<058091b6-8950-4cca-81dc-af2cf496e9c5@s50g2000hsb.googlegroups.com>	<48798664.8030904@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
Message-ID: <487CF864.1070405@savagexi.com>

> 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.  Bah!  A "User" identifier is holy, but XML is not (one is 
> application, the other is library).  I think the above 
> 'LibXML'-ification of the namespace is appropriate, however, but focus 
> on making the library easy to use, hence XML vs LibXML.

Right, works for me.

> Don't step on other people's dicks intentionally, but it's okay for the 
> library to be assertive and to match its ambitions.  Tip-toeing around 
> 'what if' is an endless rabbit hole.  We'll adapt and find a solution if 
> there is a problem at some point in the future.  Cool?

Well, considering libxml has been around 2002, seems like we have first 
dibs!

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/d71a7686/attachment.bin>

From cfis at savagexi.com  Tue Jul 15 15:26:42 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 13:26:42 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
References: <48790605.4040900@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>	<487C35F2.7050103@savagexi.com>	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
Message-ID: <487CF9F2.5000200@savagexi.com>



> On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <sean at chittenden.org> 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 LibXML
>>>>  end
>> Use an environment variable at require time and the module assigns.
>>
>> # XX untested
>> if ['0','false','no','off',false,nil,'hell god damn "no!" me
>> harder'].include? (ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :
>> ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
>>  # Only LibXML class
>> else
>>  XML = LibXML
>> end
>>
>> Then users can set the env variable and goto town however they want.
>>
>>> FYI, I moved to XSLT to LibXSLT to be consistent.  Although when I started
>>> using it, I found it to be a bit ugly.  Take a look:
>>>
>>>  # Create a new XSL Transform
>>>  stylesheet_doc = LibXML::Document.file('files/fuzface.xsl')
>>>  stylesheet     = LibXSLT::Stylesheet.new(stylesheet_doc)
>>>
>>>  # Transform a xml document
>>>  xml_doc = LibXML::Document.file('files/fuzface.xml')
>>>  result = stylesheet.apply(xml_doc)
>>>
>>>
>>> Notice how hard it becomes to distinguish the namespaces (LibXML and
>>> LibXSLT).  Compare:
>>>
>>>  # Create a new XSL Transform
>>>  stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>>>  stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>>>
>>> Thoughts?
>>
>> 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.  Bah!  A "User" identifier is holy, but XML is not (one is
>> application, the other is library).  I think the above 'LibXML'-ification of
>> the namespace is appropriate, however, but focus on making the library easy
>> to use, hence XML vs LibXML.
>>
>> Don't step on other people's dicks intentionally, but it's okay for the
>> library to be assertive and to match its ambitions.  Tip-toeing around 'what
>> if' is an endless rabbit hole.  We'll adapt and find a solution if there is
>> a problem at some point in the future.  Cool?
> 
> Actually I agree. XML:: and XSLT:: are a lot better. Trying to find
> the right balance between ease-of-use and interoperability can be
> difficult.

Ok, everyone agrees here.

> I think we should reconsider wrapping what we have in a LibXML
> namespace. This provides for both possibilities. Usage would entail:
> 
>   require 'libxml'
> 
>   module MyApp
>     include LibXML
> 
>     # Create a new XSL Transform
>     stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>     stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>     ...
>   end
> 
> See that's nice to use and proper! :-)
> 
> I think we tend to think in terms of the toplevel, but in most
> applications this isn't the case.

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 modules - just to make coding a bit easier doesn't seem 
enough justification?

I'd just as soon do this:

XML = LibXML

And be done with it.  I agree you could do this though:

XML = LibXML::XML

Um, are you really tied to this idea? Going through and changing 
everything again sounds really uninteresting.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/59abe1ec/attachment.bin>

From cfis at savagexi.com  Tue Jul 15 15:46:17 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 13:46:17 -0600
Subject: [libxml-devel] DOM Traversal Changes and Node#children api change
Message-ID: <487CFE89.3050906@savagexi.com>

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 results

* node.children.each actually iterated over a node's child's child, 
which was completely unintuitive.

So I cleaned up the DOM traversal code, added a #each method to the C 
Node class, and them moved a bunch of the C code to Ruby (like next?, 
prev?, etc).   I also exposed a node#first method to match node#last, 
and deprecated node#child (which is the same as node#first).  In the end 
there is a whole lot less code that works a lot better.

But I made one api change.  node#children now returns an array of child 
nodes, as you would expect.  I can't imagine anyone is actually using 
node.children.each because its completely unintuitive.  If anyone thinks 
that is a bad idea, say so now.

I also added a new test suite (tc_xml_traversal.rb) for all these 
methods - previously they were untested.

Changes checked in.

Charlie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/e812ae25/attachment.bin>

From transfire at gmail.com  Tue Jul 15 15:46:39 2008
From: transfire at gmail.com (Trans)
Date: Tue, 15 Jul 2008 15:46:39 -0400
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487CF9F2.5000200@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
Message-ID: <4b6f054f0807151246t6a6cbdel5b20be4dcc676f1c@mail.gmail.com>

2008/7/15 Charlie Savage <cfis at savagexi.com>:
>
>
>> On Tue, Jul 15, 2008 at 12:30 PM, Sean Chittenden <sean at chittenden.org>
>> 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 LibXML
>>>>>  end
>>>
>>> Use an environment variable at require time and the module assigns.
>>>
>>> # XX untested
>>> if ['0','false','no','off',false,nil,'hell god damn "no!" me
>>> harder'].include? (ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :
>>> ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
>>>  # Only LibXML class
>>> else
>>>  XML = LibXML
>>> end
>>>
>>> Then users can set the env variable and goto town however they want.
>>>
>>>> FYI, I moved to XSLT to LibXSLT to be consistent.  Although when I
>>>> started
>>>> using it, I found it to be a bit ugly.  Take a look:
>>>>
>>>>  # Create a new XSL Transform
>>>>  stylesheet_doc = LibXML::Document.file('files/fuzface.xsl')
>>>>  stylesheet     = LibXSLT::Stylesheet.new(stylesheet_doc)
>>>>
>>>>  # Transform a xml document
>>>>  xml_doc = LibXML::Document.file('files/fuzface.xml')
>>>>  result = stylesheet.apply(xml_doc)
>>>>
>>>>
>>>> Notice how hard it becomes to distinguish the namespaces (LibXML and
>>>> LibXSLT).  Compare:
>>>>
>>>>  # Create a new XSL Transform
>>>>  stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>>>>  stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>>>>
>>>> Thoughts?
>>>
>>> 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.  Bah!  A "User" identifier is holy, but XML is not (one is
>>> application, the other is library).  I think the above 'LibXML'-ification
>>> of
>>> the namespace is appropriate, however, but focus on making the library
>>> easy
>>> to use, hence XML vs LibXML.
>>>
>>> Don't step on other people's dicks intentionally, but it's okay for the
>>> library to be assertive and to match its ambitions.  Tip-toeing around
>>> 'what
>>> if' is an endless rabbit hole.  We'll adapt and find a solution if there
>>> is
>>> a problem at some point in the future.  Cool?
>>
>> Actually I agree. XML:: and XSLT:: are a lot better. Trying to find
>> the right balance between ease-of-use and interoperability can be
>> difficult.
>
> Ok, everyone agrees here.
>
>> I think we should reconsider wrapping what we have in a LibXML
>> namespace. This provides for both possibilities. Usage would entail:
>>
>>  require 'libxml'
>>
>>  module MyApp
>>    include LibXML
>>
>>    # Create a new XSL Transform
>>    stylesheet_doc = XML::Document.file('files/fuzface.xsl')
>>    stylesheet     = XSLT::Stylesheet.new(stylesheet_doc)
>>    ...
>>  end
>>
>> See that's nice to use and proper! :-)
>>
>> I think we tend to think in terms of the toplevel, but in most
>> applications this isn't the case.
>
> 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 modules - just to make coding a bit easier doesn't seem enough
> justification?

It strikes me as a bit funny that "good practice" seems cleaver :-) I
know it may seems inconvenient, but it is worth it. Moreover, there is
a simple solution to achieving the effect you want (though I would
discourage it in any code you intend to be reusable by others). Just
use:

  require 'libxml/xml'

Were libxml/xml.rb is simply

  require 'libxml'
  include LibXML

> I'd just as soon do this:
>
> XML = LibXML
>
> And be done with it.  I agree you could do this though:
>
> XML = LibXML::XML
>
> Um, are you really tied to this idea? Going through and changing everything
> again sounds really uninteresting.

Please?

T.

From cfis at savagexi.com  Tue Jul 15 15:51:36 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 13:51:36 -0600
Subject: [libxml-devel] Benchmark Fun
Message-ID: <487CFFC8.7030706@savagexi.com>

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      total        real
libxml    0.032000   0.000000   0.032000 (  0.031000)
Hpricot   0.640000   0.031000   0.671000 (  0.890000)
REXML     1.813000   0.047000   1.860000 (  2.031000)


2. https://svn.concord.org/svn/projects/trunk/common/ruby/xml_benchmarks/

               user     system      total        real
libxml    0.641000   0.031000   0.672000 (  0.672000)
hpricot   5.359000   0.062000   5.421000 (  5.516000)
rexml    22.859000   0.047000  22.906000 ( 23.203000)

Looks pretty good to me.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/629ed06c/attachment.bin>

From transfire at gmail.com  Tue Jul 15 16:49:07 2008
From: transfire at gmail.com (Trans)
Date: Tue, 15 Jul 2008 13:49:07 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487CF9F2.5000200@savagexi.com>
References: <48790605.4040900@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org> 
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com> 
	<487CF9F2.5000200@savagexi.com>
Message-ID: <afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>

(Sorry if this double posts, my email version didn't seem to get
thru.)

On Jul 15, 3:26?pm, Charlie Savage <c... at savagexi.com> 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 modules - just to make coding a bit easier doesn't seem enough
> justification?

It strikes me as a bit funny that "good practice" seems cleaver :-) I
know it may seems inconvenient, but it is worth it. Moreover, there is
a simple solution to achieving the effect you want (though I would
discourage it in any code you intend to be reusable by others). Just
use:

 require 'libxml/xml'

Were libxml/xml.rb is simply

 require 'libxml'
 include LibXML

> I'd just as soon do this:
>
> XML = LibXML
>
> And be done with it.  I agree you could do this though:
>
> XML = LibXML::XML
>
> Um, are you really tied to this idea? Going through and changing everything
> again sounds really uninteresting.

Please?

T.

From cfis at savagexi.com  Tue Jul 15 17:53:45 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 15:53:45 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
References: <48790605.4040900@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>	<487C35F2.7050103@savagexi.com>	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
Message-ID: <487D1C69.1090401@savagexi.com>

> 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 release and publicize it to the world...

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/d5e0dc33/attachment.bin>

From cfis at savagexi.com  Tue Jul 15 18:07:34 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 16:07:34 -0600
Subject: [libxml-devel] Announcing libxml-ruby 0.8.0
Message-ID: <487D1FA6.5080002@savagexi.com>

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, providing more user hooks in the 
XPath::Context class

* Added Node#properties for backwards compatibility

* Updated setup.rb

* Added more tests

* Updated rdocs and README file

* Moved libxml into LibXML namespace

So give it a whirl.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/b9d2bced/attachment.bin>

From cfis at savagexi.com  Tue Jul 15 18:11:57 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 16:11:57 -0600
Subject: [libxml-devel] Annoucing libxslt-ruby 0.8.0
Message-ID: <487D20AD.3020004@savagexi.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/8ca6bd1f/attachment-0001.bin>

From cfis at savagexi.com  Tue Jul 15 18:59:56 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 15 Jul 2008 16:59:56 -0600
Subject: [libxml-devel] Don't Forget to Update the RDocs
Message-ID: <487D2BEC.4020803@savagexi.com>

Hi Trans,

Don't forget to update the RDocs for libxml-ruby (or I can do it if you 
give me permissions).

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080715/ea9e0d68/attachment.bin>

From cfis at savagexi.com  Wed Jul 16 15:22:16 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 13:22:16 -0600
Subject: [libxml-devel] Spreading the word on 0.8.0
Message-ID: <487E4A68.5020905@savagexi.com>

Hi everyone,

With all the work and improvements that have gone into libxml-ruby over 
the last year, it seemed time to get the word out and see if we can 
raise its profile in the Ruby world.

To start this, I posted a blog about the new release:

http://cfis.savagexi.com/articles/2008/07/16/resurrecting-libxml-ruby

And I talked to Peter Cooper, who runs RubyInside.  He was excited (with 
all the recent talk about the sad-state of Ruby's XML support), and 
should be posting an article in the next couple of days about the new 
release.

The next step would be writing a tutorial or two on using the library. 
Any takers?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/4f467f22/attachment.bin>

From noreply at rubyforge.org  Wed Jul 16 16:25:18 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 16 Jul 2008 16:25:18 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21249 ] Build fails on FreeBSD due to
	incomplete include paths
Message-ID: <20080716202518.24B93185859A@rubyforge.org>

Bugs item #21249, was opened at 2008-07-16 20:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21249&group_id=494

Category: General
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Thomas Hurst (freaky)
Assigned to: Nobody (None)
Summary: Build fails on FreeBSD due to incomplete include paths

Initial Comment:
The 0.8.0 gem doesn't include /usr/local/include in the search path in the extension Makefile, resulting in:

make
cc -I. -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd7 -I. -I/usr/local/include/libxml2 -DRUBY_EXTCONF_H=\extconf.h\ -fPIC -pipe  -g -g  -fPIC -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd7 -I. -I/usr/local/include/libxml2 -c cbg.c
In file included from /usr/local/include/libxml2/libxml/parser.h:796,
                 from /usr/local/include/libxml2/libxml/globals.h:18,
                 from /usr/local/include/libxml2/libxml/xmlIO.h:117,
                 from cbg.c:2:
/usr/local/include/libxml2/libxml/encoding.h:28:19: error: iconv.h: No such file or directory
In file included from /usr/local/include/libxml2/libxml/parser.h:796,
                 from /usr/local/include/libxml2/libxml/globals.h:18,
                 from /usr/local/include/libxml2/libxml/xmlIO.h:117,
                 from cbg.c:2:
/usr/local/include/libxml2/libxml/encoding.h:136: error: expected specifier-qualifier-list before 'iconv_t'
*** Error code 1

Stop in /usr/local/lib/ruby/gems/1.8/gems/libxml-ruby-0.8.0/ext/libxml.

I'm not familiar enough with mkmf to see what the best fix is, but hacking it into $INCFLAGS does the trick.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21249&group_id=494

From cfis at savagexi.com  Wed Jul 16 16:41:55 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 14:41:55 -0600
Subject: [libxml-devel] Bug in extconf.rb
Message-ID: <487E5D13.2020100@savagexi.com>

Is this code in extconf.wrong?

   if CFLAGS.index(CONFIG['CCDLFLAGS'])
     $CFLAGS = CFLAGS
   else
     $CFLAGS = CFLAGS + ' ' + CONFIG['CCDLFLAGS']
   end


Isn't the if statement reversed?

Charlie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/945ba1e8/attachment.bin>

From sean at chittenden.org  Wed Jul 16 16:45:25 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 16 Jul 2008 13:45:25 -0700
Subject: [libxml-devel] Bug in extconf.rb
In-Reply-To: <487E5D13.2020100@savagexi.com>
References: <487E5D13.2020100@savagexi.com>
Message-ID: <D800054A-EC53-409B-B0DC-B2CF4A246D10@chittenden.org>

> Is this code in extconf.wrong?
>
>  if CFLAGS.index(CONFIG['CCDLFLAGS'])
>    $CFLAGS = CFLAGS
>  else
>    $CFLAGS = CFLAGS + ' ' + CONFIG['CCDLFLAGS']
>  end
>
>
> Isn't the if statement reversed?


Yup, it is.  Is this related to that FreeBSD bug?  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul 16 16:51:18 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 14:51:18 -0600
Subject: [libxml-devel] Bug in extconf.rb
In-Reply-To: <D800054A-EC53-409B-B0DC-B2CF4A246D10@chittenden.org>
References: <487E5D13.2020100@savagexi.com>
	<D800054A-EC53-409B-B0DC-B2CF4A246D10@chittenden.org>
Message-ID: <487E5F46.70203@savagexi.com>

>> Is this code in extconf.wrong?
>>
>>  if CFLAGS.index(CONFIG['CCDLFLAGS'])
>>    $CFLAGS = CFLAGS
>>  else
>>    $CFLAGS = CFLAGS + ' ' + CONFIG['CCDLFLAGS']
>>  end
>>
>>
>> Isn't the if statement reversed?
> 
> 
> Yup, it is.  Is this related to that FreeBSD bug?  -sc

Not sure.  In that one -I/usr/local/include wasn't added to the gcc 
command line so linking to the iconv headers failed.

My fix was for that was adding this line towards the end of extconf.rb:

$INCFLAGS << " -I/usr/local/include"

Brute force I know...

The way the file is setup, you could already do:

ruby extconf.rb --with-incov-dir=/usr/local/include

But it seems like including /usr/local/include is probably a good idea 
(I hope, let me know if its not).

Charlie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/71bba6e6/attachment-0001.bin>

From sean at chittenden.org  Wed Jul 16 16:55:50 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 16 Jul 2008 13:55:50 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
References: <48790605.4040900@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
Message-ID: <97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>

> require 'libxml/xml'
>
> Were libxml/xml.rb is simply
>
> require 'libxml'
> include LibXML


I know I'm late to the discussion, but how about this tweak:

require 'libxml'
unless ['0','false','no','off',false,nil].include?  
(ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :  
ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
   include LibXML
end

I think a get out of jail free card would be nice and having it  
conditionalized behind an environment variable is convenient for folks  
if they're in a jam.  -sc

--
Sean Chittenden
sean at chittenden.org




From noreply at rubyforge.org  Wed Jul 16 16:46:29 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 16 Jul 2008 16:46:29 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21249 ] Build fails on FreeBSD due to
	incomplete include paths
Message-ID: <20080716204629.DE08F18585B3@rubyforge.org>

Bugs item #21249, was opened at 2008-07-16 14:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21249&group_id=494

Category: General
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Thomas Hurst (freaky)
>Assigned to: Charlie Savage (cfis)
Summary: Build fails on FreeBSD due to incomplete include paths

Initial Comment:
The 0.8.0 gem doesn't include /usr/local/include in the search path in the extension Makefile, resulting in:

make
cc -I. -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd7 -I. -I/usr/local/include/libxml2 -DRUBY_EXTCONF_H=\extconf.h\ -fPIC -pipe  -g -g  -fPIC -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd7 -I. -I/usr/local/include/libxml2 -c cbg.c
In file included from /usr/local/include/libxml2/libxml/parser.h:796,
                 from /usr/local/include/libxml2/libxml/globals.h:18,
                 from /usr/local/include/libxml2/libxml/xmlIO.h:117,
                 from cbg.c:2:
/usr/local/include/libxml2/libxml/encoding.h:28:19: error: iconv.h: No such file or directory
In file included from /usr/local/include/libxml2/libxml/parser.h:796,
                 from /usr/local/include/libxml2/libxml/globals.h:18,
                 from /usr/local/include/libxml2/libxml/xmlIO.h:117,
                 from cbg.c:2:
/usr/local/include/libxml2/libxml/encoding.h:136: error: expected specifier-qualifier-list before 'iconv_t'
*** Error code 1

Stop in /usr/local/lib/ruby/gems/1.8/gems/libxml-ruby-0.8.0/ext/libxml.

I'm not familiar enough with mkmf to see what the best fix is, but hacking it into $INCFLAGS does the trick.

----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-16 14:46

Message:
Can't say mkmf is my thing either, but what you can do is:

ruby extconf.rb --with-incov-dir=/usr/local/include

And then run the makefile.  

However, it seems reasonable to add this path by default, so I checked in this fix to extconf.rb:

$INCFLAGS << " -I/usr/local/include"

Thanks for the report.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21249&group_id=494

From sean at chittenden.org  Wed Jul 16 17:05:41 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 16 Jul 2008 14:05:41 -0700
Subject: [libxml-devel] Bug in extconf.rb
In-Reply-To: <487E5F46.70203@savagexi.com>
References: <487E5D13.2020100@savagexi.com>
	<D800054A-EC53-409B-B0DC-B2CF4A246D10@chittenden.org>
	<487E5F46.70203@savagexi.com>
Message-ID: <841A1BBD-CAB7-477C-8625-B8522301E98C@chittenden.org>

> Not sure.  In that one -I/usr/local/include wasn't added to the gcc  
> command line so linking to the iconv headers failed.
>
> My fix was for that was adding this line towards the end of  
> extconf.rb:
>
> $INCFLAGS << " -I/usr/local/include"
>
> Brute force I know...
>
> The way the file is setup, you could already do:
>
> ruby extconf.rb --with-incov-dir=/usr/local/include
>
> But it seems like including /usr/local/include is probably a good  
> idea (I hope, let me know if its not).


${PREFIX}/include is more correct for FreeBSD.  PREFIX is a make(1)  
variable, however, and I don't know how that info gets easily passed  
to mkmf.  I think you could probably do something like:

incpath = (path + ENV['PATH']).flatten.collect{|dir|  
File.expand_path(File.join(File.expand_path(dir), '../include')))}

I'm not wild about including the ENV['PATH'] bit (security), but the  
rest should nab most corner cases for users.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul 16 17:10:53 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 15:10:53 -0600
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
References: <48790605.4040900@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>	<487C35F2.7050103@savagexi.com>	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>	<487CF9F2.5000200@savagexi.com>	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
Message-ID: <487E63DD.7050805@savagexi.com>

>> Were libxml/xml.rb is simply
>>
>> require 'libxml'
>> include LibXML
> 

So this is what is implemented now in libxml.rb:

module XML
   include LibXML::XML
end

Not saying that's the best solution or anything...

Trans's idea would also be fine.

> I know I'm late to the discussion, but how about this tweak:
> 
> require 'libxml'
> unless ['0','false','no','off',false,nil].include? 
> (ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true : 
> ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
>   include LibXML
> end

So what's the RUBY_LIBXML_SHORT_PATH bit?  Couldn't we just check and 
see if a XML module has already been loaded, and if so, not load ours?

> I think a get out of jail free card would be nice and having it 
> conditionalized behind an environment variable is convenient for folks 
> if they're in a jam.

Oh, I see.  We could check both - an environmental variable as well as 
an XML module exists or not.

But in truth, I'm not sure I care enough.  In that we've had the XML 
namespace a long time, so if some library wants to take it from us let 
them worry about checking for the existence and the XML module defined 
by LibXML.  If it exists, they can nuke it and put in their own.  The 
issue would be load order, if libxml-ruby was loaded afterwards.  Thus 
my idea to check the existence of the XML module.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/b740d9cc/attachment.bin>

From cfis at savagexi.com  Wed Jul 16 17:14:01 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 15:14:01 -0600
Subject: [libxml-devel] Bug in extconf.rb
In-Reply-To: <841A1BBD-CAB7-477C-8625-B8522301E98C@chittenden.org>
References: <487E5D13.2020100@savagexi.com>	<D800054A-EC53-409B-B0DC-B2CF4A246D10@chittenden.org>	<487E5F46.70203@savagexi.com>
	<841A1BBD-CAB7-477C-8625-B8522301E98C@chittenden.org>
Message-ID: <487E6499.4060408@savagexi.com>

> ${PREFIX}/include is more correct for FreeBSD.  PREFIX is a make(1) 
> variable, however, and I don't know how that info gets easily passed to 
> mkmf.  

It doesn't.  mkmf generates the makefile that is run by Make.

I think you could probably do something like:
> 
> incpath = (path + ENV['PATH']).flatten.collect{|dir| 
> File.expand_path(File.join(File.expand_path(dir), '../include')))}
> 
> I'm not wild about including the ENV['PATH'] bit (security), but the 
> rest should nab most corner cases for users.  -sc

Not a bad idea.  I wonder if mkmf does any of that already.  I'm trying 
hard to avoid the whole subject....

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/5462850b/attachment.bin>

From sean at chittenden.org  Wed Jul 16 17:41:00 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 16 Jul 2008 14:41:00 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <487E63DD.7050805@savagexi.com>
References: <48790605.4040900@savagexi.com>	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>	<487AB256.3040206@savagexi.com>	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>	<487B0A0E.8010500@savagexi.com>	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>	<487B802B.5080709@savagexi.com>	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>	<487C35F2.7050103@savagexi.com>	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>	<487CF9F2.5000200@savagexi.com>	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
Message-ID: <B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>

> So what's the RUBY_LIBXML_SHORT_PATH bit?  Couldn't we just check  
> and see if a XML module has already been loaded, and if so, not load  
> ours?

It's an environment variable that determines whether or not the  
library shouldn't include LibXML automatically.  I'd argue that in 99%  
of the cases, it should.  The remaining 1% of the time, they can set  
this global variable and go.  -sc

--
Sean Chittenden
sean at chittenden.org




From dusty.doris at gmail.com  Wed Jul 16 17:35:47 2008
From: dusty.doris at gmail.com (dusty)
Date: Wed, 16 Jul 2008 14:35:47 -0700 (PDT)
Subject: [libxml-devel] trouble with xpath on leopard, ruby 1.8.7-p22,
	0.8 (libxml)
Message-ID: <03f6ae4b-a094-4df2-9591-0dacce1a010e@l64g2000hse.googlegroups.com>

I'm having trouble with xpath on leopard, with ruby 1.8.7-p22 and
libxml-ruby (0.8.0).  I was wondering if someone could take a look at
my syntax and see how it looks here.

doc = '<?xml version="1.0" encoding="UTF-8"?><kml xmlns="http://
earth.google.com/kml/2.0"><Response><name>1600 Pennsylvania Ave NW,
Washington, DC 20500</name><Status><code>200</code><request>geocode</
request></Status><Placemark id="p1"><address>1600 Pennsylvania Ave NW,
Washington, DC 20006, USA</address><AddressDetails Accuracy="8"
xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:
2.0"><Country><CountryNameCode>US</
CountryNameCode><AdministrativeArea><AdministrativeAreaName>DC</
AdministrativeAreaName><Locality><LocalityName>Washington</
LocalityName><Thoroughfare><ThoroughfareName>1600 Pennsylvania Ave NW</
ThoroughfareName></Thoroughfare><PostalCode><PostalCodeNumber>20006</
PostalCodeNumber></PostalCode></Locality></AdministrativeArea></
Country></AddressDetails><Point><coordinates>-77.036698,38.897102,0</
coordinates></Point></Placemark></Response></kml>'

xp = LibXML::XML::Parser.string(doc)

xml = xp.parse

> xml.class
=> LibXML::XML::Document

> xml.root.name
=> "kml"

> xml.root.child.name
=> "Response"

> xml.root.find_first('//Response')
=> nil

> xml.root.find_first('Response')
=> nil


I can't seem to find anything using find, except for just current node
with ('.').  Any suggestions?




From transfire at gmail.com  Wed Jul 16 18:07:46 2008
From: transfire at gmail.com (Trans)
Date: Wed, 16 Jul 2008 15:07:46 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
References: <48790605.4040900@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org> 
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com> 
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com> 
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
Message-ID: <2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>


On Jul 16, 5:41?pm, Sean Chittenden <s... at chittenden.org> wrote:
> > So what's the RUBY_LIBXML_SHORT_PATH bit? ?Couldn't we just check ?
> > and see if a XML module has already been loaded, and if so, not load ?
> > ours?
>
> It's an environment variable that determines whether or not the ?
> library shouldn't include LibXML automatically. ?I'd argue that in 99% ?
> of the cases, it should. ?The remaining 1% of the time, they can set ?
> this global variable and go. ?-sc

Well it depends on whether you are writing an application or just some
personally useful scripts. For an app it needs to be the opposite b/c
then you will have your own namespace, and in that you would 'include
LibXML'. If you are just writing some admin scripts or what not, then
of course you don't care about resuse and you can include it at the
toplevel. It's important that the basic case be NOT to include, b/c
that is the most reusable case and it is what one is asking for, ie.
require 'libxml' provides LibXML. One can always do the include. But I
understand that it can be a pain to have to type 'include LibXML' when
you want it at the toplevel. That's why I suggested a second require
'libxml/xml' which seems fitting since that is what you are asking for
too, LibXML::XML.

I have nothing against the environment variable per say, but keep in
mind if one script expects it to be set to "yes" and another does not,
then they may not work together.

T.

From sean at chittenden.org  Wed Jul 16 19:21:30 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Wed, 16 Jul 2008 16:21:30 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
References: <48790605.4040900@savagexi.com>
	<3dda69c1-7500-4f44-a242-ae05a820c014@m36g2000hse.googlegroups.com>
	<487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
Message-ID: <AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>

> One can always do the include.

Brevity should, generally speaking, always win.

> But I
> understand that it can be a pain to have to type 'include LibXML' when
> you want it at the toplevel. That's why I suggested a second require
> 'libxml/xml' which seems fitting since that is what you are asking for
> too, LibXML::XML.

I missed the semantic difference here, but get it now.

require 'libxml'     # LibXML::XML::*
require 'libxml/xml' # XML::*

That concept works for me... though I'd invert it.

require 'libxml'      # XML::*
require 'ilbxml/app'  # LibXML::XML::*

Where 'libxml.rb' does the include, and libxml/app ('gem', or  
whatever), does not.  ??


--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Wed Jul 16 23:50:32 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 21:50:32 -0600
Subject: [libxml-devel] trouble with xpath on leopard, ruby 1.8.7-p22,
 0.8 (libxml)
In-Reply-To: <03f6ae4b-a094-4df2-9591-0dacce1a010e@l64g2000hse.googlegroups.com>
References: <03f6ae4b-a094-4df2-9591-0dacce1a010e@l64g2000hse.googlegroups.com>
Message-ID: <487EC188.5030803@savagexi.com>

Hi Dusty

> I'm having trouble with xpath on leopard, with ruby 1.8.7-p22 and
> libxml-ruby (0.8.0).  I was wondering if someone could take a look at
> my syntax and see how it looks here.

So it looks like you were able to successfully install and run libxml? 
That's good news, there was an issue with it last week.

Probably better to ask support question on RubyForge, but let's see 
what's the issue.
> 
> xp = LibXML::XML::Parser.string(doc)
> 
> xml = xp.parse
> 
>> xml.class
> => LibXML::XML::Document
> 
>> xml.root.name
> => "kml"
> 
>> xml.root.child.name
> => "Response"
> 
>> xml.root.find_first('//Response')
> => nil
> 
>> xml.root.find_first('Response')
> => nil
> 
> 
> I can't seem to find anything using find, except for just current node
> with ('.').  Any suggestions?

Yes.  This is because the document has a default namespace.

root.find_first('//kml::Response', 'kml:http://earth.google.com/kml/2.0')

And you'll be good.  For more examples, check out the RDocs for the 
XML::XPath class:

http://libxml.rubyforge.org/rdoc/classes/LibXML/XML/XPath.html

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/c3f39629/attachment.bin>

From cfis at savagexi.com  Thu Jul 17 01:41:41 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 16 Jul 2008 23:41:41 -0600
Subject: [libxml-devel] Announcing libxml 0.8.1
Message-ID: <487EDB95.6000200@savagexi.com>

I've just uploaded libxml-ruby 0.8.1 to RubyForge.  This is a bug fix 
release.

The main change is reimplementing Node#each_attr for backwards 
compatibility with gems such as aws-s3.  I tried fixing this for the 
0.8.0 release, but it turns out my earlier fix was incorrect.  Luckily I 
just discovered the AWS team included a nice test suite with the aws-s3 
gem.  All tests now pass.

Thanks,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080716/65f7fc7e/attachment.bin>

From transfire at gmail.com  Thu Jul 17 05:52:01 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 02:52:01 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
References: <48790605.4040900@savagexi.com> <487AB256.3040206@savagexi.com> 
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com> 
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org> 
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com> 
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com> 
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
Message-ID: <45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>



On Jul 16, 7:21?pm, Sean Chittenden <s... at chittenden.org> wrote:
> > One can always do the include.
>
> Brevity should, generally speaking, always win.
>
> > But I
> > understand that it can be a pain to have to type 'include LibXML' when
> > you want it at the toplevel. That's why I suggested a second require
> > 'libxml/xml' which seems fitting since that is what you are asking for
> > too, LibXML::XML.
>
> I missed the semantic difference here, but get it now.
>
> require 'libxml' ? ? # LibXML::XML::*
> require 'libxml/xml' # XML::*
>
> That concept works for me... though I'd invert it.
>
> require 'libxml' ? ? ?# XML::*
> require 'ilbxml/app' ?# LibXML::XML::*
>
> Where 'libxml.rb' does the include, and libxml/app ('gem', or ?
> whatever), does not. ???

It's very unintuitive :(

Is the issue backward compatibility? If so, I point out that we still
support the original naming, which includes LibXML, for backward
compatibility:

   require 'xml/libxml'

While I don't think we ought to support this backward compatibility
indefinitely, might it not suffice until we make the libxml-ruby =>
libxml package name transition?

If on the other hand, it is not backward compatibility, but rather the
lack of brevity, then consider this alternative.Instead of

  require 'libxml/xml'

as I have suggested, what about

  require 'xml'

which makes sense, since that is in effect the end result, ie. XML
loaded at the toplevel namespace.

T.

From sean at chittenden.org  Thu Jul 17 11:08:08 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 08:08:08 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
References: <48790605.4040900@savagexi.com> <487AB256.3040206@savagexi.com>
	<4b6f054f0807131942m11b82585gfcefd0f921406fd8@mail.gmail.com>
	<487B0A0E.8010500@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
	<45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
Message-ID: <EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>

>> require 'libxml'     # LibXML::XML::*
>> require 'libxml/xml' # XML::*
>>
>> That concept works for me... though I'd invert it.
>>
>> require 'libxml'      # XML::*
>> require 'ilbxml/app'  # LibXML::XML::*
>>
>> Where 'libxml.rb' does the include, and libxml/app ('gem', or
>> whatever), does not.  ??
>
> It's very unintuitive :(
>
> Is the issue backward compatibility? If so, I point out that we still
> support the original naming, which includes LibXML, for backward
> compatibility:
>
>   require 'xml/libxml'
>
> While I don't think we ought to support this backward compatibility
> indefinitely, might it not suffice until we make the libxml-ruby =>
> libxml package name transition?
>
> If on the other hand, it is not backward compatibility, but rather the
> lack of brevity, then consider this alternative.Instead of
>
>  require 'libxml/xml'
>
> as I have suggested, what about
>
>  require 'xml'
>
> which makes sense, since that is in effect the end result, ie. XML
> loaded at the toplevel namespace.


That's a gem related question, IMHO, but I like that concept best, to  
be honest.

require 'libxml'
require 'xml'

I think LibXML::XML::* is rather redundant and a waste of keystrokes,  
however, and that it should be LibXML::* and XML::*.  $0.02.  -sc


--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Thu Jul 17 12:15:08 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 10:15:08 -0600
Subject: [libxml-devel] Breaking old classes
Message-ID: <487F700C.2070207@savagexi.com>

Something we didn't consider with the new LibXML namespace.

We broke everyone's extensions.  For instance, I was emailed this example:


Comment out the following 4 lines and the test will pass (in 0.8.1).
class XML::Document
     def a_methodname_very_unlikely_to_be_used_in_this_class arg
     end
end

Which of course doesn't work anymore, since it should be 
LibXML::XML::Document.

Easy to fix of course, but it means everyone has to change their custom 
code.  Sigh.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/2d496fff/attachment.bin>

From sean at chittenden.org  Thu Jul 17 12:39:58 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 09:39:58 -0700
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487F700C.2070207@savagexi.com>
References: <487F700C.2070207@savagexi.com>
Message-ID: <7DFD572F-ECA9-405F-A7D8-96293DEEA764@chittenden.org>

> We broke everyone's extensions.  For instance, I was emailed this  
> example:
>
>
> Comment out the following 4 lines and the test will pass (in 0.8.1).
> class XML::Document
>    def a_methodname_very_unlikely_to_be_used_in_this_class arg
>    end
> end
>
> Which of course doesn't work anymore, since it should be  
> LibXML::XML::Document.
>
> Easy to fix of course, but it means everyone has to change their  
> custom code.  Sigh.


That's why I was suggesting the XML::* by default and ability to wrap  
things if required/desired.  :)  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Thu Jul 17 12:47:49 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 10:47:49 -0600
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <7DFD572F-ECA9-405F-A7D8-96293DEEA764@chittenden.org>
References: <487F700C.2070207@savagexi.com>
	<7DFD572F-ECA9-405F-A7D8-96293DEEA764@chittenden.org>
Message-ID: <487F77B5.8020801@savagexi.com>



> 
> That's why I was suggesting the XML::* by default and ability to wrap 
> things if required/desired.  :)  -sc

Yeah, I think changing it was a mistake.

But its done now, I don't think changing things back will make things 
any better.

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/403f821a/attachment.bin>

From transfire at gmail.com  Thu Jul 17 14:16:42 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 11:16:42 -0700 (PDT)
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487F700C.2070207@savagexi.com>
References: <487F700C.2070207@savagexi.com>
Message-ID: <96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>



On Jul 17, 12:15?pm, Charlie Savage <c... at savagexi.com> wrote:
> Something we didn't consider with the new LibXML namespace.
>
> We broke everyone's extensions. ?For instance, I was emailed this example:
>
> Comment out the following 4 lines and the test will pass (in 0.8.1).
> class XML::Document
> ? ? ?def a_methodname_very_unlikely_to_be_used_in_this_class arg
> ? ? ?end
> end
>
> Which of course doesn't work anymore, since it should be
> LibXML::XML::Document.

No. That's not correct:

>> module LibXML
>>   class XML
>>   end
>> end
=> nil
>>
?> include LibXML
=> Object
>> class XML
>>   def q; "q"; end
>> end
=> nil
>> XML.new.q
=> "q"
>>

What's the problem?

T.

From transfire at gmail.com  Thu Jul 17 14:31:01 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 11:31:01 -0700 (PDT)
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>
References: <48790605.4040900@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org> 
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com> 
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com> 
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
	<45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
	<EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>
Message-ID: <ae687984-3d3a-4683-9494-28f23b46a8fb@2g2000hsn.googlegroups.com>


On Jul 17, 11:08?am, Sean Chittenden <s... at chittenden.org> wrote:

> That's a gem related question, IMHO, but I like that concept best, to ?
> be honest.
>
> require 'libxml'
> require 'xml'

Great. That'll work for me too.

> I think LibXML::XML::* is rather redundant and a waste of keystrokes, ?
> however, and that it should be LibXML::* and XML::*. ?$0.02. ?-sc

Shouldn't need to type all those keystrokes. 99%+ of time you're going
to include LibXML into either the toplevel or one's own module.

T.

From cfis at savagexi.com  Thu Jul 17 14:49:25 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 12:49:25 -0600
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
References: <487F700C.2070207@savagexi.com>
	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
Message-ID: <487F9435.2080207@savagexi.com>



Trans wrote:
> 
> On Jul 17, 12:15 pm, Charlie Savage <c... at savagexi.com> wrote:
>> Something we didn't consider with the new LibXML namespace.
>>
>> We broke everyone's extensions.  For instance, I was emailed this example:
>>
>> Comment out the following 4 lines and the test will pass (in 0.8.1).
>> class XML::Document
>>      def a_methodname_very_unlikely_to_be_used_in_this_class arg
>>      end
>> end
>>
>> Which of course doesn't work anymore, since it should be
>> LibXML::XML::Document.
> 
> No. That's not correct:
> 
>>> module LibXML
>>>   class XML
>>>   end
>>> end
> => nil
> ?> include LibXML
> => Object
>>> class XML
>>>   def q; "q"; end
>>> end
> => nil
>>> XML.new.q
> => "q"
> 
> What's the problem?

Without the include LibXML its broken...  And we're not mixing LibXML 
into the global namespace at the moment.  What we are doing is this:

module XML
   include LibXML::XML
end



Charlie

> 
> T.
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/45db2682/attachment.bin>

From transfire at gmail.com  Thu Jul 17 14:59:31 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 11:59:31 -0700 (PDT)
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487F9435.2080207@savagexi.com>
References: <487F700C.2070207@savagexi.com>
	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
	<487F9435.2080207@savagexi.com>
Message-ID: <4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>



On Jul 17, 2:49?pm, Charlie Savage <c... at savagexi.com> wrote:

> > What's the problem?
>
> Without the include LibXML its broken... ?And we're not mixing LibXML
> into the global namespace at the moment. ?What we are doing is this:
>
> module XML
> ? ?include LibXML::XML
> end

Oh! I thought that changed to just include LibXML. I would prefer that
we just remove this altogether and let people know that they can use:

  require 'xml'

to get the same functionality as before.

T.

From cfis at savagexi.com  Thu Jul 17 15:08:11 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 13:08:11 -0600
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>
References: <487F700C.2070207@savagexi.com>	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>	<487F9435.2080207@savagexi.com>
	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>
Message-ID: <487F989B.50502@savagexi.com>



Trans wrote:
> 
> On Jul 17, 2:49 pm, Charlie Savage <c... at savagexi.com> wrote:
> 
>>> What's the problem?
>> Without the include LibXML its broken...  And we're not mixing LibXML
>> into the global namespace at the moment.  What we are doing is this:
>>
>> module XML
>>    include LibXML::XML
>> end
> 
> Oh! I thought that changed to just include LibXML. I would prefer that
> we just remove this altogether and let people know that they can use:
> 
>   require 'xml'

Well, that is also a breaking change though.

I guess I should change the code to just do include LibXM::XML in 
libxml.rb.  I don't see any other way of getting backwards 
compatibility.  Kind of defeats the whole namespace thing, but well, at 
least another library can undo our include if necessary.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/52f0fa83/attachment.bin>

From transfire at gmail.com  Thu Jul 17 15:59:42 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 12:59:42 -0700 (PDT)
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487F989B.50502@savagexi.com>
References: <487F700C.2070207@savagexi.com>
	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
	<487F9435.2080207@savagexi.com>
	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>
	<487F989B.50502@savagexi.com>
Message-ID: <606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>



On Jul 17, 3:08?pm, Charlie Savage <c... at savagexi.com> wrote:

> Well, that is also a breaking change though.
>
> I guess I should change the code to just do include LibXM::XML in
> libxml.rb.

You mean 'include LibXML'

> ?I don't see any other way of getting backwards
> compatibility. ?Kind of defeats the whole namespace thing, but well, at
> least another library can undo our include if necessary.

It does defeat the whole purpose, and the purpose is a very important
one. Not only does it follow the expectation that 'libxml' provides
LibXML, but it allows people to reuse the library without worrying
about others using the same namespace. This is how Ruby libraries
should be written. I recall years ago that it was not uncommon to see
an include right after a require. Back then I didn't understand it. It
seemed like a waste. But over time it has become clear to me why it
so. It makes a library much more robust. Let me give you an example. I
once created a library like Builder. And it worked simply enough:

  XML.root { foo "bar" }

produced

  <root><foo>bar</foo></root>

So here we have and XML namespace being used. If I wanted to use this
lib and the old LibXML at the same time, I'd have issues and would
have to do some kooky work around. Hey, but I'm a smart kid, and my
lib, at the time, had a general name (with a bunch of other stuff in
it too) called Blow. So I had, Blow::XML. Now I'm safe. Other's
however are not. It took me about three minutes to find:

  http://xml-mapping.rubyforge.org/

I'm sure there are others. XML:: is a common namespace. It stands to
reason, of course. And we want to be able to use it too. To do so, as
a good custodian of Ruby namespaces, means wrapping it in a module
reflecting our libraries project name.

Keep in mind that up until a few months ago the require was 'xml/
libmxl'. And that is still supported. So there really hasn't a whole
lot of time for people to get too attached to 'libxml'. We should just
do it and get it over with so it's solid and there's no more trouble
in the future.

T.

From cfis at savagexi.com  Thu Jul 17 16:05:17 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 14:05:17 -0600
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>
References: <487F700C.2070207@savagexi.com>	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>	<487F9435.2080207@savagexi.com>	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>	<487F989B.50502@savagexi.com>
	<606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>
Message-ID: <487FA5FD.9090203@savagexi.com>



Trans wrote:
> 
> On Jul 17, 3:08 pm, Charlie Savage <c... at savagexi.com> wrote:
> 
>> Well, that is also a breaking change though.
>>
>> I guess I should change the code to just do include LibXM::XML in
>> libxml.rb.
> 
> You mean 'include LibXML'

Right, sorry.

> It does defeat the whole purpose, and the purpose is a very important
> one. Not only does it follow the expectation that 'libxml' provides
> LibXML, but it allows people to reuse the library without worrying
> about others using the same namespace. This is how Ruby libraries
> should be written. I recall years ago that it was not uncommon to see
> an include right after a require. Back then I didn't understand it. It
> seemed like a waste. But over time it has become clear to me why it
> so. It makes a library much more robust. Let me give you an example. I
> once created a library like Builder. And it worked simply enough:
> 
>   XML.root { foo "bar" }
> 
> produced
> 
>   <root><foo>bar</foo></root>
> 
> So here we have and XML namespace being used. If I wanted to use this
> lib and the old LibXML at the same time, I'd have issues and would
> have to do some kooky work around. Hey, but I'm a smart kid, and my
> lib, at the time, had a general name (with a bunch of other stuff in
> it too) called Blow. So I had, Blow::XML. Now I'm safe. Other's
> however are not. It took me about three minutes to find:
> 
>   http://xml-mapping.rubyforge.org/
> 
> I'm sure there are others. XML:: is a common namespace. It stands to
> reason, of course. And we want to be able to use it too. To do so, as
> a good custodian of Ruby namespaces, means wrapping it in a module
> reflecting our libraries project name.

I agree with all the above, but its kind of a moot point, no?
> 
> Keep in mind that up until a few months ago the require was 'xml/
> libmxl'. And that is still supported. So there really hasn't a whole
> lot of time for people to get too attached to 'libxml'. We should just
> do it and get it over with so it's solid and there's no more trouble
> in the future.

Hmm, that is a good point.  Except I thought it was deprecated.

Anyway, what I think you're saying is for the following files:

----
xml/libxml.rb

include LibXML

------
libxml.rb

.. do nothing ...

--------
xml.rb

include LibXML

----

Right?  With of course an obvious problem that require 'xml' is surely 
going to conflict with someone else - putting us back with the same problem.

Charlie




> 
> T.
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/19fa5970/attachment.bin>

From sean at chittenden.org  Thu Jul 17 16:50:29 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 13:50:29 -0700
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487FA5FD.9090203@savagexi.com>
References: <487F700C.2070207@savagexi.com>	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>	<487F9435.2080207@savagexi.com>	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>	<487F989B.50502@savagexi.com>
	<606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>
	<487FA5FD.9090203@savagexi.com>
Message-ID: <2CEFBF1C-E98A-4787-A99A-F1482BCB6657@chittenden.org>

> Right?  With of course an obvious problem that require 'xml' is  
> surely going to conflict with someone else - putting us back with  
> the same problem.


You may be presuming too much.  Do a quick check, if nothing comes  
back, let's use it (why not?).

*puts evil hat on*  Here's another trick that we could use:

 >> module LibXML; end
=> nil
 >> b = false
=> false
 >> ObjectSpace.each_object(Module) {|m| if m.name == 'LibXML'; b =  
true; break; end }
=> nil
 >> b
=> true

Since it's done behind a require, it should only get evaluated once.  - 
sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Thu Jul 17 16:52:14 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 13:52:14 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <ae687984-3d3a-4683-9494-28f23b46a8fb@2g2000hsn.googlegroups.com>
References: <48790605.4040900@savagexi.com>
	<7b3b7c83-d752-4902-bb88-870aefd3e0b7@j22g2000hsf.googlegroups.com>
	<487B802B.5080709@savagexi.com>
	<55af1892-cea7-47cf-9af7-b8cdad669ca7@56g2000hsm.googlegroups.com>
	<487C35F2.7050103@savagexi.com>
	<7A869273-25EA-4198-8DF4-F2B94A33A688@chittenden.org>
	<4b6f054f0807151002u1b53a26ck3594cf9e46b4b38c@mail.gmail.com>
	<487CF9F2.5000200@savagexi.com>
	<afb192cd-a204-4770-85e3-60de59c3ecf2@c58g2000hsc.googlegroups.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
	<45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
	<EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>
	<ae687984-3d3a-4683-9494-28f23b46a8fb@2g2000hsn.googlegroups.com>
Message-ID: <27192902-A992-4820-B6E1-DC2CBCEEA49B@chittenden.org>

>> That's a gem related question, IMHO, but I like that concept best, to
>> be honest.
>>
>> require 'libxml'
>> require 'xml'
>
> Great. That'll work for me too.
>
>> I think LibXML::XML::* is rather redundant and a waste of keystrokes,
>> however, and that it should be LibXML::* and XML::*.  $0.02.  -sc
>
> Shouldn't need to type all those keystrokes. 99%+ of time you're going
> to include LibXML into either the toplevel or one's own module.


Heh.  I disagree, actually, or more correctly, my use case has almost  
always been different.  Most XML processing is done in batch from a  
simple script, not inside of an embedded app that does:

class Foo
   include LibXML
   ...
end

Not saying I haven't done that a few times in a few web apps w/ other  
modules, but it's less frequent for XML, IMHO.  -sc

--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Thu Jul 17 18:59:09 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 18:59:09 -0400
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <27192902-A992-4820-B6E1-DC2CBCEEA49B@chittenden.org>
References: <48790605.4040900@savagexi.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
	<45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
	<EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>
	<ae687984-3d3a-4683-9494-28f23b46a8fb@2g2000hsn.googlegroups.com>
	<27192902-A992-4820-B6E1-DC2CBCEEA49B@chittenden.org>
Message-ID: <4b6f054f0807171559m62bcbdderfc42393f8a3d1d32@mail.gmail.com>

On Thu, Jul 17, 2008 at 4:52 PM, Sean Chittenden <sean at chittenden.org> wrote:
>>> I think LibXML::XML::* is rather redundant and a waste of keystrokes,
>>> however, and that it should be LibXML::* and XML::*.  $0.02.  -sc
>>
>> Shouldn't need to type all those keystrokes. 99%+ of time you're going
>> to include LibXML into either the toplevel or one's own module.
>
>
> Heh.  I disagree, actually, or more correctly, my use case has almost always
> been different.  Most XML processing is done in batch from a simple script,
> not inside of an embedded app that does:
>
> class Foo
>  include LibXML
>  ...
> end
>
> Not saying I haven't done that a few times in a few web apps w/ other
> modules, but it's less frequent for XML, IMHO.  -sc

Quite so, that's what I meant by including LibXML at the toplevel
actually. I fully understand your need and wanting a convenient
require that does so. I trust, require 'xml', which will now do just
that, will work for you?

T.

From transfire at gmail.com  Thu Jul 17 19:05:54 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 16:05:54 -0700 (PDT)
Subject: [libxml-devel] Benchmark Dist?
Message-ID: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>

Do we want to distribute the benchmark scripts, or are they intended
only for admin uses?

T.

From sean at chittenden.org  Thu Jul 17 19:30:49 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 16:30:49 -0700
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>
Message-ID: <29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>

> Do we want to distribute the benchmark scripts, or are they intended
> only for admin uses?

Not sure what the intention was, but let'em go out.  What's the worst  
that could happen?  People figure out that REXML is slow?  -sc

--
Sean Chittenden
sean at chittenden.org




From sean at chittenden.org  Thu Jul 17 19:34:12 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 16:34:12 -0700
Subject: [libxml-devel] Libxml directory structure
In-Reply-To: <4b6f054f0807171559m62bcbdderfc42393f8a3d1d32@mail.gmail.com>
References: <48790605.4040900@savagexi.com>
	<97852595-9E80-429E-B9B6-48706C2347CD@chittenden.org>
	<487E63DD.7050805@savagexi.com>
	<B25ADCD6-CFCE-4984-83E4-9EB3819EF6D7@chittenden.org>
	<2e26b0ea-7d63-4ac9-833e-f61b4b63c0a7@m45g2000hsb.googlegroups.com>
	<AAE81806-1E7D-4DEC-A135-1BCDD7135B2F@chittenden.org>
	<45500b1b-8c10-4032-bb42-8cd4cc552817@m36g2000hse.googlegroups.com>
	<EC74FFF3-1137-44AC-AB10-37D5E8D7021E@chittenden.org>
	<ae687984-3d3a-4683-9494-28f23b46a8fb@2g2000hsn.googlegroups.com>
	<27192902-A992-4820-B6E1-DC2CBCEEA49B@chittenden.org>
	<4b6f054f0807171559m62bcbdderfc42393f8a3d1d32@mail.gmail.com>
Message-ID: <90BB9ED0-561C-49A8-A741-D5EE5D95B231@chittenden.org>

> Quite so, that's what I meant by including LibXML at the toplevel
> actually. I fully understand your need and wanting a convenient
> require that does so. I trust, require 'xml', which will now do just
> that, will work for you?


It will, I'm just concerned about breaking code and think:

require 'libxml'

Should "do the right thing" and guess as best it can (ObjectSpace,  
etc), while

require 'xml'

will be explicit.  -sc

--
Sean Chittenden
sean at chittenden.org




From transfire at gmail.com  Thu Jul 17 18:50:13 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 15:50:13 -0700 (PDT)
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <487FA5FD.9090203@savagexi.com>
References: <487F700C.2070207@savagexi.com>
	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
	<487F9435.2080207@savagexi.com>
	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>
	<487F989B.50502@savagexi.com>
	<606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>
	<487FA5FD.9090203@savagexi.com>
Message-ID: <573c23e9-77ca-4d8f-8946-4aee4822c8f5@p25g2000hsf.googlegroups.com>


On Jul 17, 4:05?pm, Charlie Savage <c... at savagexi.com> wrote:
>
> Anyway, what I think you're saying is for the following files:
>
> ----
> xml/libxml.rb
>
> include LibXML
>
> ------
> libxml.rb
>
> .. do nothing ...
>
> --------
> xml.rb
>
> include LibXML
>
> ----
>
> Right?

Yes.

> With of course an obvious problem that require 'xml' is surely
> going to conflict with someone else - putting us back with the same problem.

Despite the use of XML as a module, I don't think anyone has ever been
so bold as to put forth 'xml.rb', nor do I think they ever will. Thus
by default, I think we can get away with it. :)

T.


From sean at chittenden.org  Thu Jul 17 20:54:56 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 17:54:56 -0700
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <573c23e9-77ca-4d8f-8946-4aee4822c8f5@p25g2000hsf.googlegroups.com>
References: <487F700C.2070207@savagexi.com>
	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>
	<487F9435.2080207@savagexi.com>
	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>
	<487F989B.50502@savagexi.com>
	<606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>
	<487FA5FD.9090203@savagexi.com>
	<573c23e9-77ca-4d8f-8946-4aee4822c8f5@p25g2000hsf.googlegroups.com>
Message-ID: <66F83885-11DF-42FD-9082-794185BF4858@chittenden.org>

>> With of course an obvious problem that require 'xml' is surely
>> going to conflict with someone else - putting us back with the same  
>> problem.
>
> Despite the use of XML as a module, I don't think anyone has ever been
> so bold as to put forth 'xml.rb', nor do I think they ever will. Thus
> by default, I think we can get away with it. :)


No guts, no glory.  Just do it.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Thu Jul 17 21:56:14 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 19:56:14 -0600
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>
	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>
Message-ID: <487FF83E.1090606@savagexi.com>



Sean Chittenden wrote:
>> Do we want to distribute the benchmark scripts, or are they intended
>> only for admin uses?
> 

Yeah, I debated about.  Since I blogged about them, I figured I'd 
include them.  Otherwise no one would ever see them.


> Not sure what the intention was, but let'em go out.  What's the worst 
> that could happen?  People figure out that REXML is slow?  -sc

The downside is the extra bytes (for the test xml files) and making sure 
they actually work.  And also whether including them is appropriate (I 
sent emails to the authors, should also add attribution at the top of 
each one).

I'm fine either way.  I figure they'll get removed sooner or later though.

And while on the subject, where are the benchmarks on the home page 
from? In fact, maybe we just have links to a benchmark page from there 
and take them out of the distribution?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/fd971a36/attachment.bin>

From cfis at savagexi.com  Thu Jul 17 21:59:16 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 19:59:16 -0600
Subject: [libxml-devel] Breaking old classes
In-Reply-To: <573c23e9-77ca-4d8f-8946-4aee4822c8f5@p25g2000hsf.googlegroups.com>
References: <487F700C.2070207@savagexi.com>	<96667ab1-de30-43b5-888b-810ce34c0687@25g2000hsx.googlegroups.com>	<487F9435.2080207@savagexi.com>	<4eafa7ca-a362-474e-afd9-e3e82dd3b12f@56g2000hsm.googlegroups.com>	<487F989B.50502@savagexi.com>	<606d07a4-77aa-4579-ab18-de0a17192622@z66g2000hsc.googlegroups.com>	<487FA5FD.9090203@savagexi.com>
	<573c23e9-77ca-4d8f-8946-4aee4822c8f5@p25g2000hsf.googlegroups.com>
Message-ID: <487FF8F4.1060004@savagexi.com>



Trans wrote:
> On Jul 17, 4:05 pm, Charlie Savage <c... at savagexi.com> wrote:
>> Anyway, what I think you're saying is for the following files:
>>
>> ----
>> xml/libxml.rb
>>
>> include LibXML
>>
>> ------
>> libxml.rb
>>
>> .. do nothing ...
>>
>> --------
>> xml.rb
>>
>> include LibXML
>>
>> ----
>>
>> Right?


Ok - agreed, let's do this. Once its done, I'll push out 0.8.2.  By the 
time we get to 0.8.7ish we should be sitting pretty :)

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/a6964eb5/attachment.bin>

From sean at chittenden.org  Thu Jul 17 22:23:27 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 19:23:27 -0700
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <487FF83E.1090606@savagexi.com>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>
	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>
	<487FF83E.1090606@savagexi.com>
Message-ID: <2DC20203-BC62-4458-9EE1-C8FB0DAE768E@chittenden.org>

If you want to be considerate of the binary size, here's a q: what  
compresses to near 100% efficiency:

aaaaaaaaaaaaaaaaa

Or:

Abcfefghijklnghajabhffgcggcffbhh

?  -sc

-- 
Sean Chittenden


On Jul 17, 2008, at 6:56 PM, Charlie Savage <cfis at savagexi.com> wrote:

>
>
> Sean Chittenden wrote:
>>> Do we want to distribute the benchmark scripts, or are they intended
>>> only for admin uses?
>
> Yeah, I debated about.  Since I blogged about them, I figured I'd  
> include them.  Otherwise no one would ever see them.
>
>
>> Not sure what the intention was, but let'em go out.  What's the  
>> worst that could happen?  People figure out that REXML is slow?  -sc
>
> The downside is the extra bytes (for the test xml files) and making  
> sure they actually work.  And also whether including them is  
> appropriate (I sent emails to the authors, should also add  
> attribution at the top of each one).
>
> I'm fine either way.  I figure they'll get removed sooner or later  
> though.
>
> And while on the subject, where are the benchmarks on the home page  
> from? In fact, maybe we just have links to a benchmark page from  
> there and take them out of the distribution?
>
> Charlie
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel

From cfis at savagexi.com  Thu Jul 17 22:28:28 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Thu, 17 Jul 2008 20:28:28 -0600
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <2DC20203-BC62-4458-9EE1-C8FB0DAE768E@chittenden.org>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>	<487FF83E.1090606@savagexi.com>
	<2DC20203-BC62-4458-9EE1-C8FB0DAE768E@chittenden.org>
Message-ID: <487FFFCC.7060207@savagexi.com>



Sean Chittenden wrote:
> If you want to be considerate of the binary size, here's a q: what 
> compresses to near 100% efficiency:
> 
> aaaaaaaaaaaaaaaaa
> 
> Or:
> 
> Abcfefghijklnghajabhffgcggcffbhh
> 

Yup, no doubt.

Actually, what really does take space is that we ship libxml2.dll for 
all platforms and libxml_ruby.so (windows binary).  Should only include 
them for the windows gem.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080717/7a30c445/attachment.bin>

From sean at chittenden.org  Fri Jul 18 01:36:45 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Thu, 17 Jul 2008 22:36:45 -0700
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <487FFFCC.7060207@savagexi.com>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>	<487FF83E.1090606@savagexi.com>
	<2DC20203-BC62-4458-9EE1-C8FB0DAE768E@chittenden.org>
	<487FFFCC.7060207@savagexi.com>
Message-ID: <3D7991CC-BCA8-4134-8059-388A00A538A0@chittenden.org>

>> If you want to be considerate of the binary size, here's a q: what  
>> compresses to near 100% efficiency:
>> aaaaaaaaaaaaaaaaa
>> Or:
>> Abcfefghijklnghajabhffgcggcffbhh
>
> Yup, no doubt.
>
> Actually, what really does take space is that we ship libxml2.dll  
> for all platforms and libxml_ruby.so (windows binary).  Should only  
> include them for the windows gem.


Gah!  Don't lead me astray like that!  Death to inferior development  
environments... or something like that.

mkdir /tmp/badness
cp -prv . /tmp/badness
find /tmp/badness -type f -print0 | xargs -0 gzip -9
find /tmp/badness -type f -print0 | xargs -0 du -k | sort -n

And Huston, we've got a culprit or two...

[snip]
8	./ext/libxml/ruby_xml_reader.c.gz
12	./benchmark/sock_entries.xml.gz
12	./doc/rdoc/classes/LibXML/XML/Node.html.gz
12	./doc/rdoc/classes/LibXML/XML/Reader.html.gz
12	./setup.rb.gz
48	./mingw/libxml_ruby.so.gz
80	./benchmark/hamlet.xml.gz
496	./mingw/libxml2-2.dll.gz
656	./mingw/libiconv-2.dll.gz

Hamelet's cool in my book and stays.  Windows can goto hell, however  
(who uses that OS anyway?  Mac?  Hello!).  Does the gem format  
preclude our ability to exercise the demons or are we forced to suck  
up and swallow a 400% increase in package size because of the Win32?  - 
sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Fri Jul 18 02:15:49 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Fri, 18 Jul 2008 00:15:49 -0600
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <3D7991CC-BCA8-4134-8059-388A00A538A0@chittenden.org>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>	<487FF83E.1090606@savagexi.com>	<2DC20203-BC62-4458-9EE1-C8FB0DAE768E@chittenden.org>	<487FFFCC.7060207@savagexi.com>
	<3D7991CC-BCA8-4134-8059-388A00A538A0@chittenden.org>
Message-ID: <48803515.8020904@savagexi.com>

> Hamelet's cool in my book and stays.  Windows can goto hell, however 
> (who uses that OS anyway?  Mac?  Hello!).  Does the gem format preclude 
> our ability to exercise the demons or are we forced to suck up and 
> swallow a 400% increase in package size because of the Win32?  -sc

Nah, there are two gems.  One Windows one, one for everybody else.  The 
files are included in both mostly because I'm lazy.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080718/bc76a35b/attachment.bin>

From transfire at gmail.com  Thu Jul 17 19:50:59 2008
From: transfire at gmail.com (Trans)
Date: Thu, 17 Jul 2008 16:50:59 -0700 (PDT)
Subject: [libxml-devel] Benchmark Dist?
In-Reply-To: <29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>
References: <5a22b59d-9032-41d5-ba3d-d7a706abe751@w7g2000hsa.googlegroups.com>
	<29CBB641-1702-42AF-BD9F-851CF17B5C3F@chittenden.org>
Message-ID: <d6a1d79c-9263-41d7-a1fa-5da9ce98c1e0@y21g2000hsf.googlegroups.com>



On Jul 17, 7:30?pm, Sean Chittenden <s... at chittenden.org> wrote:
> > Do we want to distribute the benchmark scripts, or are they intended
> > only for admin uses?
>
> Not sure what the intention was, but let'em go out. ?What's the worst ?
> that could happen? ?People figure out that REXML is slow? ?-sc

LOL :)

Okay, then I will add it as a runnable script, ie. script/bench.

T.

From noreply at rubyforge.org  Fri Jul 18 10:25:19 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 18 Jul 2008 10:25:19 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21265 ] Segmentation Fault when
	setting attribute on CData node
Message-ID: <20080718142519.8872F185859A@rubyforge.org>

Bugs item #21265, was opened at 2008-07-18 10:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21265&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: Segmentation Fault when setting attribute on CData node

Initial Comment:
With libxml-ruby 0.8.1 and ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-linux]:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'libxml'
=> true
irb(main):003:0> cnode = XML::Node.new_cdata('test cdata')
=> <![CDATA[test cdata]]>
irb(main):004:0> cnode['attr'] = '123'
(irb):4: [BUG] Segmentation fault
ruby 1.8.6 (2008-03-03) [i386-linux]

Aborted



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21265&group_id=494

From transfire at gmail.com  Sat Jul 19 13:19:04 2008
From: transfire at gmail.com (Trans)
Date: Sat, 19 Jul 2008 10:19:04 -0700 (PDT)
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
Message-ID: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>

$ script/test
Loaded suite script/test
Started
.................................................................................................Entity:
line 1:
parser
error :
Opening and ending tag mismatch: foo line 1 and foz
<foo><bar/></foz>
                 ^
Entity: line 1:
parser
error :
Opening and ending tag mismatch: foo line 1 and foz
<foo><bar/></foz>
                 ^
.Entity: line 1:
parser
error :
Opening and ending tag mismatch: foo line 1 and foz
<foo><bar/></foz>
                 ^
Entity: line 1:
parser
error :
Opening and ending tag mismatch: foo line 1 and foz
<foo><bar/></foz>
                 ^
../test/tc_parser.rb:262: command not found: ulimit -n
.................Entity: line 1:
parser
error :
Opening and ending tag mismatch: foo line 1 and foz
<foo><bar/></foz>
                 ^
F........................................
Finished in 1.700575 seconds.

  1) Failure:
test_parse_error(TestParserContext) [./test/tc_parser_context.rb:111]:
<true> expected but was
<false>.

157 tests, 740 assertions, 1 failures, 0 errors
/usr/lib/ruby/1.8/test/unit.rb:278: [BUG] Segmentation fault
ruby 1.8.6 (2007-09-24) [x86_64-linux]

From cfis at savagexi.com  Sat Jul 19 14:55:55 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 19 Jul 2008 12:55:55 -0600
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
In-Reply-To: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>
References: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>
Message-ID: <488238BB.5070507@savagexi.com>

>   1) Failure:
> test_parse_error(TestParserContext) [./test/tc_parser_context.rb:111]:
> <true> expected but was
> <false>.
> 
> 157 tests, 740 assertions, 1 failures, 0 errors
> /usr/lib/ruby/1.8/test/unit.rb:278: [BUG] Segmentation fault
> ruby 1.8.6 (2007-09-24) [x86_64-linux]


It looks like the segmentation fault is happening at the program's end. 
  Which leads me to suspects it the XPathObject pointer (Xpath object 
are returned from Document#find and Node#find).  That the one where a 
document is freed before any XpathObjects are freed.

The simple solution is:

nodes = document.find('/foo')
nodes = nil
GC.start

Which is documented under Document#find.

A "real" solution would involve XPath objects registering themselves 
with documents, and documents checking them when freed.  The reason is 
that Ruby calls free functions in random order.  See discussion here:

http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/17725?17500-17840+split-mode-vertical

Anyway, would be worth updating the xpath test to conform to the code 
style above and see if those really are the issues.

The other thing to do, is create a debug build, enable crash dump files, 
and when the seg fault happens send in the stack trace.  That would 
verify my theory or not.

Charlie


> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080719/6f89e4a3/attachment-0001.bin>

From sean at chittenden.org  Sat Jul 19 15:12:10 2008
From: sean at chittenden.org (Sean Chittenden)
Date: Sat, 19 Jul 2008 12:12:10 -0700
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
In-Reply-To: <488238BB.5070507@savagexi.com>
References: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>
	<488238BB.5070507@savagexi.com>
Message-ID: <BEA12085-AE2D-4644-845E-2B0ACBC79DAA@chittenden.org>

> A "real" solution would involve XPath objects registering themselves  
> with documents, and documents checking them when freed.  The reason  
> is that Ruby calls free functions in random order.  See discussion  
> here:
>
> http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/17725?17500-17840+split-mode-vertical

XPathObjects should have a custom mark function that marks their  
dependent XML Document object.  XPathObjects need to have that  
reference in their structure.  -sc

--
Sean Chittenden
sean at chittenden.org




From cfis at savagexi.com  Sat Jul 19 16:45:33 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 19 Jul 2008 14:45:33 -0600
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
In-Reply-To: <BEA12085-AE2D-4644-845E-2B0ACBC79DAA@chittenden.org>
References: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>	<488238BB.5070507@savagexi.com>
	<BEA12085-AE2D-4644-845E-2B0ACBC79DAA@chittenden.org>
Message-ID: <4882526D.8010306@savagexi.com>



Sean Chittenden wrote:
>> A "real" solution would involve XPath objects registering themselves 
>> with documents, and documents checking them when freed.  The reason is 
>> that Ruby calls free functions in random order.  See discussion here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/17725?17500-17840+split-mode-vertical 
>>
> 
> XPathObjects should have a custom mark function that marks their 
> dependent XML Document object.  XPathObjects need to have that reference 
> in their structure.  -sc

They do - that's not the problem.  The problem is that Ruby ignores mark 
functions on process shutdown.  In other words, free functions are 
called in a random order.  For more details see the above thread.

I view this as a shortcoming in Ruby's GC.  To work around requires 
implementing our own custom mark implementation.  Basically an xpath 
object would register a pointer to itself with its parent document. 
When the document is freed, the document checks its list of xpath object 
pointers.  In a normal running program, this will always be none because 
of mark/sweep.  In a terminating process, there may be some.  In that 
case, the document calls back to the xpath object to tell it to free its 
underlying c data.  Then when the xpath object's free function is called 
a few milliseconds later, its already freed its c data so no 
segmentation fault takes place.

I can't decide if its worth the bother or not...Its clearly easier in 
Ruby to set the xpath object to nil and force a GC, but then you are 
forcing a c idiom onto a Ruby programmer.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080719/3d5872c3/attachment.bin>

From transfire at gmail.com  Sat Jul 19 17:50:37 2008
From: transfire at gmail.com (Trans)
Date: Sat, 19 Jul 2008 14:50:37 -0700 (PDT)
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
In-Reply-To: <4882526D.8010306@savagexi.com>
References: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>
	<488238BB.5070507@savagexi.com>
	<BEA12085-AE2D-4644-845E-2B0ACBC79DAA@chittenden.org> 
	<4882526D.8010306@savagexi.com>
Message-ID: <90eaf5a0-315f-4843-ac1e-ec3ba0a451b2@c58g2000hsc.googlegroups.com>



On Jul 19, 4:45?pm, Charlie Savage <c... at savagexi.com> wrote:
> They do - that's not the problem. ?The problem is that Ruby ignores mark
> functions on process shutdown. ?In other words, free functions are
> called in a random order. ?For more details see the above thread.
>
> I view this as a shortcoming in Ruby's GC. ?To work around requires
> implementing our own custom mark implementation. ?Basically an xpath
> object would register a pointer to itself with its parent document.
> When the document is freed, the document checks its list of xpath object
> pointers. ?In a normal running program, this will always be none because
> of mark/sweep. ?In a terminating process, there may be some. ?In that
> case, the document calls back to the xpath object to tell it to free its
> underlying c data. ?Then when the xpath object's free function is called
> a few milliseconds later, its already freed its c data so no
> segmentation fault takes place.

I'm not skilled enough in this area to know for sure, but my gut
feeling is that there must be simpler solution.

> I can't decide if its worth the bother or not...Its clearly easier in
> Ruby to set the xpath object to nil and force a GC, but then you are
> forcing a c idiom onto a Ruby programmer.

A Ruby programmer should never have to force the GC.

T.

From cfis at savagexi.com  Sat Jul 19 18:27:17 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 19 Jul 2008 16:27:17 -0600
Subject: [libxml-devel] Test Errors and Seg fault (08-07-19)
In-Reply-To: <90eaf5a0-315f-4843-ac1e-ec3ba0a451b2@c58g2000hsc.googlegroups.com>
References: <300897c9-dbe0-4f44-ad16-7119162b7831@w7g2000hsa.googlegroups.com>	<488238BB.5070507@savagexi.com>	<BEA12085-AE2D-4644-845E-2B0ACBC79DAA@chittenden.org>
	<4882526D.8010306@savagexi.com>
	<90eaf5a0-315f-4843-ac1e-ec3ba0a451b2@c58g2000hsc.googlegroups.com>
Message-ID: <48826A45.10701@savagexi.com>


> 
> I'm not skilled enough in this area to know for sure, but my gut
> feeling is that there must be simpler solution.

Unfortunately I don't think so.  Nobu suggested a reference counting 
solution, which I don't think would work, and isn't any simpler.

The implementation isn't so horrible, its mostly:

st_hash dependents

Document#register_dependent(VALUE object, callback)
{
   register in hash
}

Document#unregister_dependent(VALUE object)
{
   unregister in hash
}

Document#free
{
   loop over dependents
}

> A Ruby programmer should never have to force the GC.

Yeah, I agree.

Anyway, I put in a test case for just this issue in one of the test 
suites (XPath I think).  It should be commented out at the moment.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080719/0489dc8d/attachment.bin>

From cfis at savagexi.com  Tue Jul 22 14:03:19 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 22 Jul 2008 12:03:19 -0600
Subject: [libxml-devel] Libxml 0.8.3 Release
Message-ID: <488620E7.2080708@savagexi.com>

I pushed out a 0.8.3 libxml release last night (0.8.3 because I botched 
the 0.8.2 release).

Changes:

* To use LibXML you can either require 'xml' or require 'libxml'.
   The differences is that require 'xml' mixes the LibXML module into
   the global namespace, thereby allowing you to write code such
   as document = XML::Document.new.  Note that this is different
   from 0.8.0 and 0.8.1 and may require updating your code.

* Support RelaxNG validation (thanks to Morus Walter)

* Support passing IO objects to XmlReaders (thanks to Tom Hughes)

* Fix segmentation fault caused by adding an attribute to a CDATA node

* Moved node checking functions from C to Ruby

* Improved Windows support - libxml-ruby should now work out of the box.

* Improved Windows support - turned on libxml's zlib and iconv support.

Enjoy,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080722/31d90c7a/attachment.bin>

From cfis at savagexi.com  Tue Jul 22 14:04:49 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Tue, 22 Jul 2008 12:04:49 -0600
Subject: [libxml-devel] LibXSLT 0.8.2 Release
Message-ID: <48862141.7020001@savagexi.com>

I pushed out a 0.8.2 libxslt release last night.  Changes include:

* To use LibXSLT you can either require 'xslt' or require 'libxslt'.
   The differences is that require 'xslt' mixes the LibXML and
   LIBXSLT modules into the global namespace, thereby allowing
   you to write code such as:

   stylesheet = XSLT::Stylesheet.new(XML::Document.new).

Note that this is different from 0.8.0 release and may require updating 
our code.

* Support for libxml-ruby 0.8.2

* Improved Windows support - libxslt-ruby should now work out of the box.

Enjoy,

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080722/3e3a8400/attachment-0001.bin>

From yzheng3000 at gmail.com  Fri Jul 25 02:30:32 2008
From: yzheng3000 at gmail.com (Yan Zheng)
Date: Thu, 24 Jul 2008 23:30:32 -0700
Subject: [libxml-devel] parsing document containing doctype with
	saxparser causes null pointer given
Message-ID: <e1608a50807242330s79e9f8c5i62d356025fed6025@mail.gmail.com>

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 01 Jul 2008 01:19:13 -0600
> From: Charlie Savage <cfis at savagexi.com>
> Subject: Re: [libxml-devel] parsing document containing doctype with
>        saxparser causes null pointer given
> To: libxml-devel at rubyforge.org
> Message-ID: <4869DA71.4050102 at savagexi.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> > Wenn i try to parse a Document that has a doctype declaration with the
> > saxparser i get the following message:
> >
> > /Library/Ruby/Gems/1.8/gems/rails-2.0.2/lib/commands/runner.rb:45:
> > (eval):95:in `parse': NULL pointer given (ArgumentError)
> >       from (eval):95
> >       from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `eval'
> >       from
> /Library/Ruby/Gems/1.8/gems/rails-2.0.2/lib/commands/runner.rb:
> > 45
> >       from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in
> > `gem_original_require'
> >       from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in
> > `require'
> >       from ../../../script/runner:3
> >
> > This is the document (inner contents removed)
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE ONIXmessage SYSTEM "http://www.editeur.org/onix/2.1/short/
> > onix-international.dtd">
> > <ONIXmessage release="2.1">
> > </ONIXmessage>
>
> This seems to work for me.  My test:
>
>
>   xp = XML::SaxParser.new
>   xp.string = <<-EOS
>       <?xml version="1.0" encoding="UTF-8"?>
>          <!DOCTYPE ONIXmessage SYSTEM
> "http://www.editeur.org/onix/2.1/short/onix-international.dtd">
>       <ONIXmessage release="2.1">
>            </ONIXmessage>
>     EOS
>   xp.parse
>
> Charlie
>

I'm having the same issue.  It seems the issue manifest itself when
callbacks is set.  Below is an example; if I remove DOCTYPE tag, the problem
is gone.  Any ideas on solutions or workarounds?

class Handler
  include XML::SaxParser::Callbacks
  def on_start_element(element, attributes)
    puts element
  end
end

xp = XML::SaxParser.new
xp.callbacks = Handler.new
xp.string = <<-EOS
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Results SYSTEM "results.dtd">
<Results>
<a>a1</a>
</Results>
  EOS
xp.parse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080724/c6e6ee3c/attachment.html>

From cfis at savagexi.com  Fri Jul 25 23:05:57 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Fri, 25 Jul 2008 21:05:57 -0600
Subject: [libxml-devel] parsing document containing doctype
 with	saxparser causes null pointer given
In-Reply-To: <e1608a50807242330s79e9f8c5i62d356025fed6025@mail.gmail.com>
References: <e1608a50807242330s79e9f8c5i62d356025fed6025@mail.gmail.com>
Message-ID: <488A9495.5000106@savagexi.com>

> I'm having the same issue.  It seems the issue manifest itself when 
> callbacks is set.  Below is an example; if I remove DOCTYPE tag, the 
> problem is gone.  Any ideas on solutions or workarounds?
> 
> class Handler
>   include XML::SaxParser::Callbacks
>   def on_start_element(element, attributes)
>     puts element
>   end
> end
> 
> xp = XML::SaxParser.new
> xp.callbacks = Handler.new
> xp.string = <<-EOS
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE Results SYSTEM "results.dtd">
> <Results>
> <a>a1</a>
> </Results>
>   EOS
> xp.parse

Works here.  See the last test case in tc_sax_parser.rb (from the 
original bug report).

To be sure, I did this:

   class DocTypeCallback
     include XML::SaxParser::Callbacks
     def on_start_element(element, attributes)
       puts element
     end
   end

   def test_doctype
     @xp.callbacks = DocTypeCallback.new
     @xp.string = <<-EOS
       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE Results SYSTEM "results.dtd">
       <Results>
         <a>a1</a>
       </Results>
     EOS
     doc = @xp.parse
     assert_not_nil(doc)
   end


And it works fine.  So...let's make sure we are all using the same 
versions.  Libxml_ruby version?  libxml version?  Operating system?  Etc.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080725/7453aed1/attachment.bin>

From noreply at rubyforge.org  Sat Jul 19 14:49:08 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 19 Jul 2008 14:49:08 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21265 ] Segmentation Fault when
	setting attribute on CData node
Message-ID: <20080719184908.5E71718585B7@rubyforge.org>

Bugs item #21265, was opened at 2008-07-18 08:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21265&group_id=494

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Charlie Savage (cfis)
Summary: Segmentation Fault when setting attribute on CData node

Initial Comment:
With libxml-ruby 0.8.1 and ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-linux]:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'libxml'
=> true
irb(main):003:0> cnode = XML::Node.new_cdata('test cdata')
=> <![CDATA[test cdata]]>
irb(main):004:0> cnode['attr'] = '123'
(irb):4: [BUG] Segmentation fault
ruby 1.8.6 (2008-03-03) [i386-linux]

Aborted



----------------------------------------------------------------------

>Comment By: Charlie Savage (cfis)
Date: 2008-07-19 12:49

Message:
Fixed - the code now returns an error saying you can't create an attribute on a CData node.  Will be in the next release.

Thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21265&group_id=494

From szymon.kurcab at gmail.com  Wed Jul 30 08:14:53 2008
From: szymon.kurcab at gmail.com (simon)
Date: Wed, 30 Jul 2008 05:14:53 -0700 (PDT)
Subject: [libxml-devel] Namespace atribute inside the node
Message-ID: <85a40dbd-a045-491b-ad50-75a5cffec5d5@d1g2000hsg.googlegroups.com>

Hello,

I have a question, if it is possible to remove namespace definition
attribute inside LibXML::XML::Node object.

Have this object (class LibXML::XML::Node):

<div xmlns:mob="http://www.volantis.com/xmlns/mobilizer"
class="navigation" id="_6" mob:name="Menu"
mob:menustyle="menu_unfolded" propagation="true"
mob:numericshortcuts="false" style="STATIC">
  <a href="/about">Stronka testowa</a>
</div>

There is the same namespace definition inside the root node:

<html xmlns:mob="http://www.volantis.com/xmlns/mobilizer"
xmlns:urid="http://www.volantis.com>
[....]
</html>

Do I have any access to xmlns attriibute (in div node)?
I tried:
node["mob"] or node["xmlns:mob"] and both return nil

Regards,
Szymon

From noreply at rubyforge.org  Wed Jul 30 15:53:35 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 30 Jul 2008 15:53:35 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21395 ] XML::Parser.io unfair to
	StringIO ?
Message-ID: <20080730195335.BC8DA18585B7@rubyforge.org>

Bugs item #21395, was opened at 2008-07-30 15:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21395&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: XML::Parser.io unfair to StringIO ?

Initial Comment:
> LibXML::XML::Parser::VERSION
=> "0.8.3"

> xp = LibXML::XML::Parser.new
=> #<LibXML::XML::Parser:0x5464d8>

> xp.io = StringIO.new('<?xml version="1.0" encoding="utf-8"?><foo></foo>')
TypeError: need an IO object


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21395&group_id=494

From noreply at rubyforge.org  Wed Jul 30 17:45:25 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 30 Jul 2008 17:45:25 -0400 (EDT)
Subject: [libxml-devel] [ libxml-Bugs-21395 ] XML::Parser.io unfair to
	StringIO ?
Message-ID: <20080730214525.3528218585B2@rubyforge.org>

Bugs item #21395, was opened at 2008-07-30 12:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21395&group_id=494

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: XML::Parser.io unfair to StringIO ?

Initial Comment:
> LibXML::XML::Parser::VERSION
=> "0.8.3"

> xp = LibXML::XML::Parser.new
=> #<LibXML::XML::Parser:0x5464d8>

> xp.io = StringIO.new('<?xml version="1.0" encoding="utf-8"?><foo></foo>')
TypeError: need an IO object


----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2008-07-30 14:45

Message:
StringIO doesn't inherit from IO, it just mirrors the interface.

f.e.:

StringIO.new("").kind_of? IO == false

The code will have to be adapted to handle StringIO directly.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1971&aid=21395&group_id=494

From cfis at savagexi.com  Wed Jul 30 21:13:46 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Wed, 30 Jul 2008 19:13:46 -0600
Subject: [libxml-devel] Namespace atribute inside the node
In-Reply-To: <85a40dbd-a045-491b-ad50-75a5cffec5d5@d1g2000hsg.googlegroups.com>
References: <85a40dbd-a045-491b-ad50-75a5cffec5d5@d1g2000hsg.googlegroups.com>
Message-ID: <489111CA.80301@savagexi.com>



simon wrote:
> Hello,
> 
> I have a question, if it is possible to remove namespace definition
> attribute inside LibXML::XML::Node object.
> 
> Have this object (class LibXML::XML::Node):
> 
> <div xmlns:mob="http://www.volantis.com/xmlns/mobilizer"
> class="navigation" id="_6" mob:name="Menu"
> mob:menustyle="menu_unfolded" propagation="true"
> mob:numericshortcuts="false" style="STATIC">
>   <a href="/about">Stronka testowa</a>
> </div>
> 
> There is the same namespace definition inside the root node:
> 
> <html xmlns:mob="http://www.volantis.com/xmlns/mobilizer"
> xmlns:urid="http://www.volantis.com>
> [....]
> </html>
> 
> Do I have any access to xmlns attriibute (in div node)?
> I tried:
> node["mob"] or node["xmlns:mob"] and both return nil

Yes, this part of libxml is confusing and needs to be refactored.  Anwyay:

node.namespace_node  -> the node's namespace

node.namespace or node.ns -> a list of all current namespaces for the node

node.ns_def -> A list of namespaces defined on the element

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20080730/4ecb39e4/attachment-0001.bin>

From aaron.patterson at gmail.com  Thu Jul 31 11:37:32 2008
From: aaron.patterson at gmail.com (Aaron Patterson)
Date: Thu, 31 Jul 2008 08:37:32 -0700
Subject: [libxml-devel] XML namespace
Message-ID: <6959e1680807310837p73d094b0h9a55384e61b723b8@mail.gmail.com>

I guess its a little late to find this, but the expat ruby wrapper is
using the XML namespace.  Just FYI!  :-)

http://rubyforge.org/projects/xmlparser/

-- 
Aaron Patterson
http://tenderlovemaking.com/