From stuart.hungerford at anu.edu.au  Wed Oct 18 21:14:21 2006
From: stuart.hungerford at anu.edu.au (Stuart Hungerford)
Date: Thu, 19 Oct 2006 11:14:21 +1000
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
Message-ID: <4536D16D.2000503@anu.edu.au>

Hi,

I've been trying to install the 0.8.3 libxml-ruby Gem on a
CentOS Linux system.

This install doesn't seem to move the shared library into
the right place?

Looking through the list archives I found a patch for an
Ubuntu installation which I applied and which now creates
a "libxml_so.so" library.  This can be used with a
'require "xml/libxml_so"' but any access to the module
crashes.

So does anyone have a patch or some hints for installing
0.8.3 on Centos or other Linuxes either as a Gem or via
a tarball?

Any advice much appreciated,

Stu

-- 

Stuart Hungerford
ANUSF Data Intensive Projects


From shimbo at is.naist.jp  Thu Oct 19 06:20:42 2006
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Thu, 19 Oct 2006 19:20:42 +0900
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <4536D16D.2000503@anu.edu.au>
References: <4536D16D.2000503@anu.edu.au>
Message-ID: <87r6x4d2th.wl%shimbo@is.naist.jp>

Hi Stu,

    >> Looking through the list archives I found a patch for an
    >> Ubuntu installation which I applied and which now creates
    >> a "libxml_so.so" library.  This can be used with a
    >> 'require "xml/libxml_so"' but any access to the module
    >> crashes.

FYI, the patch I submitted to the list worked fine on Gentoo Linux as
well as Ubuntu here.

Because all it does is to move the shared lib into the right directory,
I suspect the library crash in your case is due to some other reasons.

Can you check whether libxml_so.so crashes or not without the patch?

With the original 0.8.3 gem, libxml_so.so is not installed anywhere, 
but you should be able to regenerated it by running 'make' in
gems/1.8/gems/libxml-ruby-0.3.8/ext/xml.

Then run 'gem check -t libxml-ruby' to see if it's working properly.

    >> So does anyone have a patch or some hints for installing
    >> 0.8.3 on Centos or other Linuxes either as a Gem or via
    >> a tarball?

Or, are you implying that the tarball installation did not work either?
If so, I have no idea what caused the crash...

Cheers,

Masashi Shimbo

From rosco at roscopeco.co.uk  Thu Oct 19 07:42:39 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Thu, 19 Oct 2006 12:42:39 +0100
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <87r6x4d2th.wl%shimbo@is.naist.jp>
References: <4536D16D.2000503@anu.edu.au> <87r6x4d2th.wl%shimbo@is.naist.jp>
Message-ID: <op.thn2tdqzkc9f7k@localhost.localdomain>

On Thu, 19 Oct 2006 11:20:42 +0100, Masashi Shimbo <shimbo at is.naist.jp>  
wrote:

> Hi Stu,
>
>     >> Looking through the list archives I found a patch for an
>     >> Ubuntu installation which I applied and which now creates
>     >> a "libxml_so.so" library.  This can be used with a
>     >> 'require "xml/libxml_so"' but any access to the module
>     >> crashes.
>
> FYI, the patch I submitted to the list worked fine on Gentoo Linux as
> well as Ubuntu here.
>

Apologies to both of you, that patch has been hiding among the backlog in  
my inbox, and I'd completely missed it. I'll get this patch applied and  
committed asap.

However, Stuart:

> Because all it does is to move the shared lib into the right directory,
> I suspect the library crash in your case is due to some other reasons.
>
> Can you check whether libxml_so.so crashes or not without the patch?
>

And if so, could you post up your ruby version, platform and compiler  
details, make output and any output you get after the crash.

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Thu Oct 19 07:48:29 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Thu, 19 Oct 2006 12:48:29 +0100
Subject: [libxml-devel] cdata comment patch
In-Reply-To: <20060830012702.92362.qmail@web32410.mail.mud.yahoo.com>
References: <20060830012702.92362.qmail@web32410.mail.mud.yahoo.com>
Message-ID: <op.thn223u5kc9f7k@localhost.localdomain>

Hi,

On Wed, 30 Aug 2006 02:27:02 +0100, Luc Van Deuren  
<luc_van_deuren at yahoo.com> wrote:

> Hello,
>
> I just needed #CDATA and comment into my xml output.
> making a cdata or comment node did not seem to work,
> so i made a quick patch,  (cdata_comment_patch.zip)
>

Yes, this is another problematic area, so thanks for the patch :) I'll get  
that applied shortly.

>
> Question: does the XML::Node.new_cdata and XML::Node.new_comment
> seems a good idea?
> or is there a more sofisticated solution?
>

Currently, I'm looking at quite a few API feature and fix requests for  
0.4, which will also change quite a bit under the hood to (hopefully)  
address some of the issues we've had with memory handling and so on, so it  
may be that these methods are renamed or altered slightly to fit with  
that, but otherwise I think it's fine.

Thanks again,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From stuart.hungerford at anu.edu.au  Thu Oct 19 19:13:13 2006
From: stuart.hungerford at anu.edu.au (Stuart Hungerford)
Date: Fri, 20 Oct 2006 09:13:13 +1000
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
Message-ID: <45380689.6040400@anu.edu.au>

Hi,

Firstly -- thanks to Masashi Shimbo for his patch and advice.

Here's a transcript of my installation process.  Apologies for
such a long post! With a clean gem install and the following process
things seem to work if I do a 'require "xml/libxml_so"'.  On OS/X
and Ubuntu though I was able to get things working with an extra
"make install" and can use 'require "xml/libxml" instead.

I'm not sure why my Centos installation is like this, although it
may be needed libraries in non-standard places.


----------------- basic gem install -------------------------------

$ sudo gem install libxml-ruby
Need to update 5 gems from http://gems.rubyforge.org
.....
complete
Building native extensions.  This could take a while...
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
ruby extconf.rb install libxml-ruby
checking for socket() in -lsocket... no
checking for gethostbyname() in -lnsl... yes
checking for atan() in -lm... no
checking for atan() in -lm... yes
checking for inflate() in -lz... yes
checking for iconv_open() in -liconv... no
checking for iconv_open() in -lc... yes
checking for xmlParseDoc() in -lxml2... yes
checking for libxml/xmlversion.h... no
checking for libxml/xmlversion.h... yes
checking for xmlDocFormatDump() in -lxml2... yes
checking for docbCreateFileParserCtxt()... yes
creating extconf.h
creating Makefile

make
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_parser_context.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_sax_parser.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpath.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_schema.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_ns.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_document.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_attr.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpath_context.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c cbg.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_node.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_dtd.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_node_set.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_parser.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_tree.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c libxml.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_attribute.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpointer_context.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_input_cbg.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xinclude.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpointer.c
gcc -shared -rdynamic -Wl,-export-dynamic   -L'/opt/ruby-1.8.4/lib' 
-Wl,-R'/opt/ruby-1.8.4/lib' -L'/opt/ruby-1.8.4/lib' 
-Wl,-R'/opt/ruby-1.8.4/lib' -o libxml_so.so ruby_xml_parser_context.o 
ruby_xml_sax_parser.o ruby_xml_xpath.o ruby_xml_schema.o ruby_xml_ns.o 
ruby_xml_document.o ruby_xml_attr.o ruby_xml_xpath_context.o cbg.o 
ruby_xml_node.o ruby_xml_dtd.o ruby_xml_node_set.o ruby_xml_parser.o 
ruby_xml_tree.o libxml.o ruby_xml_attribute.o 
ruby_xml_xpointer_context.o ruby_xml_input_cbg.o ruby_xml_xinclude.o 
ruby_xml_xpointer.o  -lxml2 -lxml2 -lc -lz -lm -lnsl  -ldl -lcrypt -lm   -lc

make install
make: Nothing to be done for `install'.

make clean
Successfully installed libxml-ruby-0.3.8
Installing ri documentation for libxml-ruby-0.3.8...

...

----------------- check gem status --------------------------
		
$ gem check -t libxml-ruby

EXPECTING: TWO ERRORS:
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>
                  ^

----------------- apply patch -------------------------------

$ patch -d libxml-ruby-0.3.8 -p1 < fix.patch
patching file ext/xml/extconf.rb
patching file ext/xml/libxml.rb
patching file lib/xml/libxml.rb
patching file Rakefile


----------------- re-run make -------------------------------

$ cd libxml-ruby-0.3.8/ext/xml
$ sudo make install
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
make: *** No rule to make target `../xml/libxml.rb', needed by 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml/libxml.rb'. 
  Stop.

----------------- try Rake install instead --------------------

$ sudo rake install
(in /opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8)
/opt/ruby-1.8.4/bin/ruby extconf.rb
checking for socket() in -lsocket... no
checking for gethostbyname() in -lnsl... yes
checking for atan() in -lm... no
checking for atan() in -lm... yes
checking for inflate() in -lz... yes
checking for iconv_open() in -liconv... no
checking for iconv_open() in -lc... yes
checking for xmlParseDoc() in -lxml2... yes
checking for libxml/xmlversion.h... no
checking for libxml/xmlversion.h... yes
checking for xmlDocFormatDump() in -lxml2... yes
checking for docbCreateFileParserCtxt()... yes
creating extconf.h
creating Makefile
make: Nothing to be done for `all'.
/usr/bin/install -c -m 0755 libxml_so.so 
/opt/ruby-1.8.4/lib/ruby/site_ruby/1.8/x86_64-linux/xml

----------------- try using it ---------------------------------

$ irb
 >> require "rubygems"
=> true
 >> require "xml/libxml"
LoadError: no such file to load -- xml/libxml
         from 
/opt/ruby-1.8.4/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require'
         from 
/opt/ruby-1.8.4/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`require'
         from (irb):2
 >> require "xml/libxml_so"
=> true


TIA,

Stu

From shimbo at is.naist.jp  Thu Oct 19 21:58:41 2006
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Fri, 20 Oct 2006 10:58:41 +0900
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <45380689.6040400@anu.edu.au>
References: <45380689.6040400@anu.edu.au>
Message-ID: <87mz7rwxwu.wl%shimbo@is.naist.jp>

Hello,

From the transcript you provided, it seems that the patch is not
necessary for your CentOS system.

    >> ----------------- basic gem install -------------------------------

    >> $ sudo gem install libxml-ruby
    >> Need to update 5 gems from http://gems.rubyforge.org

...

    >> make clean
    >> Successfully installed libxml-ruby-0.3.8
    >> Installing ri documentation for libxml-ruby-0.3.8...

    >> ...

I'd like to know if you have libxml_so.so in
/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml/
at this point (i.e., after 'gem install libxml-ruby').

In my Ubuntu system, the original gem erases that shared library file
after 'make clean'.  

I'm curious because the following log

    >> ----------------- check gem status --------------------------
		
    >> $ gem check -t libxml-ruby

    >> EXPECTING: TWO ERRORS:
    >> 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>
    >>                   ^

suggests that you already have a working libxml-ruby here!!!

So the patch I submitted is not necessary for your CentOS system...
probably the patch is incorrect or at least incomplete.

I'm sorry if my patch confused you... but I've also verified that I need
to apply and rebuild a gem package to install it on an Ubuntu, a Gentoo,
and a MacOS X - so there seems to be a problem with the current gem
package anyway.  Witout the patch, they all fail the 'gem check -t libxml-ruby' 
test after issuing a message: no such file to load -- xml/libxml_so

I'll recheck the patch later to see what makes the difference.

Best Regards,

Masashi Shimbo

From stuart.hungerford at anu.edu.au  Thu Oct 19 22:19:16 2006
From: stuart.hungerford at anu.edu.au (Stuart Hungerford)
Date: Fri, 20 Oct 2006 12:19:16 +1000
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <87mz7rwxwu.wl%shimbo@is.naist.jp>
References: <45380689.6040400@anu.edu.au> <87mz7rwxwu.wl%shimbo@is.naist.jp>
Message-ID: <45383224.3010800@anu.edu.au>

Masashi Shimbo wrote:

 > [...]
> I'd like to know if you have libxml_so.so in
> /opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml/
> at this point (i.e., after 'gem install libxml-ruby').
> 
> In my Ubuntu system, the original gem erases that shared library file
> after 'make clean'.  

    Here's a transcript of the "plain" gem installation.  Once
    again I apologize for the length of this message!


$ sudo gem uninstall libxml-ruby
Password:
Successfully uninstalled libxml-ruby version 0.3.8
$ sudo gem install libxml-ruby
Need to update 1 gems from http://gems.rubyforge.org
.
complete
Building native extensions.  This could take a while...
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:116: warning: overriding commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
Makefile:114: warning: ignoring old commands for target 
`/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml'
ruby extconf.rb install libxml-ruby
checking for socket() in -lsocket... no
checking for gethostbyname() in -lnsl... yes
checking for atan() in -lm... no
checking for atan() in -lm... yes
checking for inflate() in -lz... yes
checking for iconv_open() in -liconv... no
checking for iconv_open() in -lc... yes
checking for xmlParseDoc() in -lxml2... yes
checking for libxml/xmlversion.h... no
checking for libxml/xmlversion.h... yes
checking for xmlDocFormatDump() in -lxml2... yes
checking for docbCreateFileParserCtxt()... yes
creating extconf.h
creating Makefile

make
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_parser_context.cgcc -fPIC 
-g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_sax_parser.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpath.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_schema.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_ns.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_document.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_attr.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpath_context.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c cbg.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_node.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_dtd.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_node_set.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_parser.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_tree.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c libxml.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_attribute.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpointer_context.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_input_cbg.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xinclude.c
gcc -fPIC -g -O2 -Wall -I. -I/usr/include/libxml2  -I. 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux 
-I/opt/ruby-1.8.4/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H 
-DHAVE_DOCBCREATEFILEPARSERCTXT  -c ruby_xml_xpointer.c
gcc -shared -rdynamic -Wl,-export-dynamic   -L'/opt/ruby-1.8.4/lib' 
-Wl,-R'/opt/ruby-1.8.4/lib' -L'/opt/ruby-1.8.4/lib' 
-Wl,-R'/opt/ruby-1.8.4/lib' -o libxml_so.so ruby_xml_parser_context.o 
ruby_xml_sax_parser.o ruby_xml_xpath.o ruby_xml_schema.o ruby_xml_ns.o 
ruby_xml_document.o ruby_xml_attr.o ruby_xml_xpath_context.o cbg.o 
ruby_xml_node.o ruby_xml_dtd.o ruby_xml_node_set.o ruby_xml_parser.o 
ruby_xml_tree.o libxml.o ruby_xml_attribute.o 
ruby_xml_xpointer_context.o ruby_xml_input_cbg.o ruby_xml_xinclude.o 
ruby_xml_xpointer.o  -lxml2 -lxml2 -lc -lz -lm -lnsl  -ldl -lcrypt -lm   -lc

make install
make: Nothing to be done for `install'.

make clean
Successfully installed libxml-ruby-0.3.8
Installing ri documentation for libxml-ruby-0.3.8...

Enclosing class/module 'mXML' for class Attribute not known

No definition for input_callbacks_register_input_callbacks

No definition for input_callbacks_add_scheme

No definition for input_callbacks_remove_scheme

Enclosing class/module 'mXML' for class Attribute not known

No definition for input_callbacks_register_input_callbacks

No definition for input_callbacks_add_scheme

No definition for input_callbacks_remove_scheme
Installing RDoc documentation for libxml-ruby-0.3.8...

Enclosing class/module 'mXML' for class Attribute not known

No definition for input_callbacks_register_input_callbacks

No definition for input_callbacks_add_scheme

No definition for input_callbacks_remove_scheme

Enclosing class/module 'mXML' for class Attribute not known

No definition for input_callbacks_register_input_callbacks

No definition for input_callbacks_add_scheme

No definition for input_callbacks_remove_scheme
$

-------------------------- Now check for .so ----------------

$ ls /opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml/
./               ruby_xml_attr.h       ruby_xml_node_set.h 
ruby_xml_tree.h
../              ruby_xml_attribute.c  ruby_xml_ns.c 
ruby_xml_xinclude.c
cbg.c            ruby_xml_attribute.h  ruby_xml_ns.h 
ruby_xml_xinclude.h
extconf.h        ruby_xml_document.c   ruby_xml_parser.c 
ruby_xml_xpath.c
extconf.rb       ruby_xml_document.h   ruby_xml_parser_context.c 
ruby_xml_xpath_context.c
gem_make.out     ruby_xml_dtd.c        ruby_xml_parser_context.h 
ruby_xml_xpath_context.h
libxml.c         ruby_xml_dtd.h        ruby_xml_parser.h 
ruby_xml_xpath.h
libxml.h         ruby_xml_input_cbg.c  ruby_xml_sax_parser.c 
ruby_xml_xpointer.c
libxml.rb        ruby_xml_input_cbg.h  ruby_xml_sax_parser.h 
ruby_xml_xpointer_context.c
Makefile         ruby_xml_node.c       ruby_xml_schema.c 
ruby_xml_xpointer_context.h
mkmf.log         ruby_xml_node.h       ruby_xml_schema.h 
ruby_xml_xpointer.h
ruby_xml_attr.c  ruby_xml_node_set.c   ruby_xml_tree.c 
sax_parser_callbacks.inc

-------------------------- Usage ----------------

This may be an unrelated issue, but here's two XML files I
use with libxml-ruby on Ubuntu and OS/X successfully:

$ wc *.xml
  1229094  1370730 19273537 big.xml
     1229     2466    42956 small.xml
  1230323  1373196 19316493 total

On the patched and unpatched Centos version though this
happens:

 >> doc = XML::Document.file("small.xml")
[...]
 >> doc = XML::Document.file("big.xml")
(irb):5: [BUG] Segmentation fault
ruby 1.8.4 (2005-12-24) [x86_64-linux]

Aborted

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

Thanks,

Stu

-- 

Stuart Hungerford
ANUSF Data Intensive Projects


From rosco at roscopeco.co.uk  Fri Oct 20 08:38:01 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 20 Oct 2006 13:38:01 +0100
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <87mz7rwxwu.wl%shimbo@is.naist.jp>
References: <45380689.6040400@anu.edu.au> <87mz7rwxwu.wl%shimbo@is.naist.jp>
Message-ID: <op.thpz1nsykc9f7k@localhost.localdomain>

Hi Masashi,

On Fri, 20 Oct 2006 02:58:41 +0100, Masashi Shimbo <shimbo at is.naist.jp>  
wrote:

> I'm sorry if my patch confused you... but I've also verified that I need
> to apply and rebuild a gem package to install it on an Ubuntu, a Gentoo,
> and a MacOS X - so there seems to be a problem with the current gem
> package anyway.  Witout the patch, they all fail the 'gem check -t  
> libxml-ruby'
> test after issuing a message: no such file to load -- xml/libxml_so
>
> I'll recheck the patch later to see what makes the difference.
>

I've applied your patch in CVS head, and made a couple of minor  
adjustments to keep 'rake install' working properly. Basically, libxml.rb  
remains in the ext/xml directory, but is installed by the install-rb  
target. This seems to work fine here when using 'rake install' (just calls  
'make install' anyway, going to site_ruby) and when run under gems (with  
overriden targets). I'm hoping that'll fix this issue with the gem on the  
various platforms.

Thanks again for this!

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Fri Oct 20 08:55:03 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 20 Oct 2006 13:55:03 +0100
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <45383224.3010800@anu.edu.au>
References: <45380689.6040400@anu.edu.au> <87mz7rwxwu.wl%shimbo@is.naist.jp>
	<45383224.3010800@anu.edu.au>
Message-ID: <op.thp0t1l6kc9f7k@localhost.localdomain>

Hi Stuart,

On Fri, 20 Oct 2006 03:19:16 +0100, Stuart Hungerford  
<stuart.hungerford at anu.edu.au> wrote:

> Masashi Shimbo wrote:
>
>  > [...]
>> I'd like to know if you have libxml_so.so in
>> /opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/libxml-ruby-0.3.8/ext/xml/
>> at this point (i.e., after 'gem install libxml-ruby').
>>
>> In my Ubuntu system, the original gem erases that shared library file
>> after 'make clean'.
>

I've applied Masashi's patch so hopefully this will be fixed now (it seems  
to work here - Previously it worked anyway, but only because I had a  
forgotten copy of libxml.rb kicking around in site_ruby :( ).

Could you try the current CVS head? If it works for you I'd like to get a  
maintenance release out (there've been a few other fixes since 0.3.8 too).

>
> This may be an unrelated issue, but here's two XML files I
> use with libxml-ruby on Ubuntu and OS/X successfully:
>
> $ wc *.xml
>   1229094  1370730 19273537 big.xml
>      1229     2466    42956 small.xml
>   1230323  1373196 19316493 total
>
> On the patched and unpatched Centos version though this
> happens:
>
>  >> doc = XML::Document.file("small.xml")
> [...]
>  >> doc = XML::Document.file("big.xml")
> (irb):5: [BUG] Segmentation fault
> ruby 1.8.4 (2005-12-24) [x86_64-linux]
>
> Aborted
>

Hmm, I don't like the look of this. Is the Centos box the only x86_64  
machine in the equation here? It's possible that this is just another  
surfacing of the known memory-handling problems I'm working on, and there  
have been a couple of segfaults during GC reported and fixed since 0.3.8  
so you may have more joy with the CVS version, but I'm not so sure on that  
to be honest...

Thanks,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From stuart.hungerford at anu.edu.au  Fri Oct 20 18:46:10 2006
From: stuart.hungerford at anu.edu.au (Stuart Hungerford)
Date: Sat, 21 Oct 2006 08:46:10 +1000
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <op.thp0t1l6kc9f7k@localhost.localdomain>
References: <45380689.6040400@anu.edu.au> <87mz7rwxwu.wl%shimbo@is.naist.jp>
	<45383224.3010800@anu.edu.au>
	<op.thp0t1l6kc9f7k@localhost.localdomain>
Message-ID: <453951B2.2000609@anu.edu.au>

Ross Bamford wrote:

> [...]
> 
> I've applied Masashi's patch so hopefully this will be fixed now (it 
> seems to work here - Previously it worked anyway, but only because I had 
> a forgotten copy of libxml.rb kicking around in site_ruby :( ).
> 
> Could you try the current CVS head? If it works for you I'd like to get 
> a maintenance release out (there've been a few other fixes since 0.3.8 
> too).

    Okay -- thanks, I'll give it a try.

> [...]
>>  >> doc = XML::Document.file("small.xml")
>> [...]
>>  >> doc = XML::Document.file("big.xml")
>> (irb):5: [BUG] Segmentation fault
>> ruby 1.8.4 (2005-12-24) [x86_64-linux]
>>
>> Aborted
>>
> 
> Hmm, I don't like the look of this. Is the Centos box the only x86_64 
> machine in the equation here? It's possible that this is just another 
> surfacing of the known memory-handling problems I'm working on, and 
> there have been a couple of segfaults during GC reported and fixed since 
> 0.3.8 so you may have more joy with the CVS version, but I'm not so sure 
> on that to be honest...

    Yes -- the Ubuntu is an old Pentium system and the OS/X a PowerPC.

Stu


From shimbo at is.naist.jp  Sun Oct 22 11:13:06 2006
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Mon, 23 Oct 2006 00:13:06 +0900
Subject: [libxml-devel] Installing 0.8.3 Gem on CentOS Linux...
In-Reply-To: <op.thpz1nsykc9f7k@localhost.localdomain>
References: <45380689.6040400@anu.edu.au> <87mz7rwxwu.wl%shimbo@is.naist.jp>
	<op.thpz1nsykc9f7k@localhost.localdomain>
Message-ID: <989032930610220813r7c7079edr6826b2c600d9ffa9@mail.gmail.com>

Hi Ross,

> I've applied your patch in CVS head, and made a couple of minor
> adjustments to keep 'rake install' working properly. Basically, libxml.rb
> remains in the ext/xml directory, but is installed by the install-rb
> target.

Thanks for fixing and applying the patch.
(Certainly, my original patch was too gem-centric.)

Keep up a good work!

Masashi Shimbo

From bill at dueber.com  Tue Oct 24 09:43:48 2006
From: bill at dueber.com (Bill Dueber)
Date: Tue, 24 Oct 2006 09:43:48 -0400
Subject: [libxml-devel] Newbie help: simple namespace example
Message-ID: <acf139530610240643h4b57ece5t6485d6b18f886ae9@mail.gmail.com>

I've looked through the docs, the tests, and the archives of this
list, but I still can't figure out how to pull out a namespaced node
using xpath.

I've got a document that looks much like this -- a metadata wrapper
around a MARC-XML-namespaced internal record.

<?xml version = "1.0" encoding = "UTF-8"?>
<source_full_info>
  <source_internal_number>000000668</source_internal_number>
  <record xmlns="http://www.loc.gov/MARC21/slim"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.loc.gov/MARC21/slim
   http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd">
      <controlfield tag="001">UMI00003</controlfield>
      <datafield tag="245" ind1="1" ind2=" ">
        <subfield code="a">International Political Science Abstracts</subfield>
      </datafield>
  </record>
</source_full_info>

...and can't for the life of me figure out how to get at the <record>.
The docs seem to claim that if I don't give a namespace it'll match
any namespace, but this seems to not be the case.

I know this is a "devel" list, but any help would be appreciated.

  -Bill Dueber-
-- 
Bill Dueber
Web Services Programmer
University of Michigan Library

From transfire at gmail.com  Fri Oct 27 23:17:32 2006
From: transfire at gmail.com (TRANS)
Date: Fri, 27 Oct 2006 23:17:32 -0400
Subject: [libxml-devel] Just wanted to get these figure out there.
Message-ID: <4b6f054f0610272017g17cdae1co6e7cc4258af198ae@mail.gmail.com>

Performance is very impressive compared to rexml:

    <div style="padding: 5px; background: rgb(238, 238, 238) none
repeat scroll 0%; float: right; -moz-background-clip: -moz-initial;
-moz-background-origin: -moz-initial; -moz-background-inline-policy:
-moz-initial; margin-left: 20px;">
    &nbsp;&nbsp;<b>Speed Comparison libxml vs. rexml</b>&nbsp;&nbsp;
    <table id="chart" border="1">
      <tbody><tr><td><i>in seconds</i></td><th>libxml  </th><th>rexml
 </th></tr>
      <tr><th>opening       </th><td>0.003954</td><td>0.104750</td></tr>
      <tr><th>attribute_add </th><td>0.001895</td><td>0.011114</td></tr>
      <tr><th>subelems      </th><td>0.000585</td><td>0.004729</td></tr>
      <tr><th>xpath         </th><td>0.013269</td><td>2.981499</td></tr>
    </tbody></table>
    </div>

From rosco at roscopeco.co.uk  Sat Oct 28 06:10:50 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sat, 28 Oct 2006 11:10:50 +0100
Subject: [libxml-devel] 0.4.0 development
Message-ID: <op.th4mkcskkc9f7k@localhost.localdomain>

Hi,

I've made a start on 0.4 development, in a new DEV_0_4 branch in CVS. I've  
started out by trying to address the memory handling problems centered  
around XML::Node, which is used pretty much throughout the library, and so  
far the tests, and my own experiments, suggest a promising start.

The main effect of the changes so far is:

	* Totally reworked node allocation and wrapping, we still don't copy nodes
	  unless required, but we now track how many ruby_xml_nodes wrap a given
	  xmlNode. This is currently done using _private data - I know someone  
asked
	  about exposing that member for app use but I can't see where else to  
store
	  the data needed by the binding. Also, this will break compatibility with
	  libxsl-ruby 0.3.x, but that's to be expected anyway - once this branch  
is
	  moving a bit more I'll introduce a parallel branch into libxsl-ruby.
	
	* Changed the way nodes are handled WRT. their documents and parent nodes,
	  to better fit with libxml2's memory model for the tree. We leave memory
	  management with the library as much as possible, only stepping in where  
we
	  need to. This should fix up myriad problems that occur when copying  
nodes
	  between documents and adding new nodes. It's slightly less efficient  
now,
	  but once it's more stable we can probably streamline things a bit.

	* Thread safety: After going through the code and making the changes I've  
made,
	  I'm now a lot happier that the binding is thread safe - as long as  
libxml2
	  is compiled using the --with-threads option. Note though that this  
doesn't
	  apply to custom parser error handlers - it's up to you to be thread-safe
	  there. Later on I'd like to devise some specific tests for threadsafe  
use.

	* Error handler procs - won't get GC'd while you're not looking any
	  more (oops :->). This was causing a seemingly-random segfault.

I need people to look over the changes, try the new stuff out, play with  
it, and generally try to break it - let me know if it works/doesn't work,  
could be done better, or whatever. I'm hoping to really attack the bugs we  
know about, and root out those we don't, but I won't be able to do it  
without feedback as the work progresses...

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Sat Oct 28 06:21:00 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sat, 28 Oct 2006 11:21:00 +0100
Subject: [libxml-devel] Just wanted to get these figure out there.
In-Reply-To: <4b6f054f0610272017g17cdae1co6e7cc4258af198ae@mail.gmail.com>
References: <4b6f054f0610272017g17cdae1co6e7cc4258af198ae@mail.gmail.com>
Message-ID: <op.th4m1agfkc9f7k@localhost.localdomain>

On Sat, 28 Oct 2006 04:17:32 +0100, TRANS <transfire at gmail.com> wrote:

> Performance is very impressive compared to rexml:
>

Ahh, that reminds me - I never got those benchmarks up on the website!  
Sorry about that, I'll get to it shortly.

I wonder if you'd mind running those benchmarks against the new DEV_0_4  
branch, just to get a performance metric with the changes so far. Probably  
there's going to be a drop during development but I think we can work  
toward comparable performance for the 0.4.0 release.

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From transfire at gmail.com  Sun Oct 29 07:43:55 2006
From: transfire at gmail.com (TRANS)
Date: Sun, 29 Oct 2006 07:43:55 -0500
Subject: [libxml-devel] Newbie help: simple namespace example
In-Reply-To: <acf139530610240643h4b57ece5t6485d6b18f886ae9@mail.gmail.com>
References: <acf139530610240643h4b57ece5t6485d6b18f886ae9@mail.gmail.com>
Message-ID: <4b6f054f0610290443n790e5332i2907a5cfa5b12249@mail.gmail.com>

I suspect you've already worked it out. But just in case I'll point
out that your record doesn;t seem to be valid XML, or more correctly
the intended XML:

>   <record xmlns="http://www.loc.gov/MARC21/slim"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://www.loc.gov/MARC21/slim
>    http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd">

Also, I'm not quite sure what the problem. How are yo not able to
access record? Do you mean via XPath?

T.

From shimbo at is.naist.jp  Sun Oct 29 08:56:17 2006
From: shimbo at is.naist.jp (Masashi Shimbo)
Date: Sun, 29 Oct 2006 22:56:17 +0900
Subject: [libxml-devel] Return value of XML::Node#<<
Message-ID: <87d58b1b0e.wl%shimbo@is.naist.jp>

Hello,

I noticed that libxml-ruby 0.3.8's method XML::Node#<<(child)
returns 'child' instead of 'self'.

This is inconsistent with the typical behavior one would expect from the
<< operator; '<<' for Array, IO, and Set all return 'self', which makes
it easy to add multiple elements with a one-liner like 

  parent << child1 << child2 << child3

However, if 'parent' is an XML::Node, 'child2' will be its grandchild
instead of its second child.

Wouldn't it be better to change the behavior of XML::Node#<< to follow
the convention and return 'self'?

I'm not sure whether this is a big API change, but the current libxml
doc says nothing about the return value of <<.

Regards,

Masashi Shimbo


From rosco at roscopeco.co.uk  Sun Oct 29 09:47:41 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sun, 29 Oct 2006 14:47:41 -0000
Subject: [libxml-devel] Newbie help: simple namespace example
In-Reply-To: <acf139530610240643h4b57ece5t6485d6b18f886ae9@mail.gmail.com>
References: <acf139530610240643h4b57ece5t6485d6b18f886ae9@mail.gmail.com>
Message-ID: <op.th6t1rt5kc9f7k@localhost.localdomain>

On Tue, 24 Oct 2006 14:43:48 +0100, Bill Dueber <bill at dueber.com> wrote:

> I've looked through the docs, the tests, and the archives of this
> list, but I still can't figure out how to pull out a namespaced node
> using xpath.
>
> I've got a document that looks much like this -- a metadata wrapper
> around a MARC-XML-namespaced internal record.
>
> <?xml version = "1.0" encoding = "UTF-8"?>
> <source_full_info>
>   <source_internal_number>000000668</source_internal_number>
>   <record xmlns="http://www.loc.gov/MARC21/slim"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://www.loc.gov/MARC21/slim
>    http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd">
>       <controlfield tag="001">UMI00003</controlfield>
>       <datafield tag="245" ind1="1" ind2=" ">
>         <subfield code="a">International Political Science  
> Abstracts</subfield>
>       </datafield>
>   </record>
> </source_full_info>
>
> ...and can't for the life of me figure out how to get at the <record>.
> The docs seem to claim that if I don't give a namespace it'll match
> any namespace, but this seems to not be the case.
>
> I know this is a "devel" list, but any help would be appreciated.
>

I believe the problem here stems from the default namespace declaration  
you have on the record element - Xpath doesn't play too well with that.  
There might be a better way (it gets a bit vague and  
implementation-dependent here, I'll have to look into how libxml2 handles  
this) but one workaround is:

	doc.find('//*[local-name()="record"]')

(Select everything, then subselect stuff whose local (i.e. non-prefixed)  
name matches what you're after).

-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Sun Oct 29 09:48:03 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sun, 29 Oct 2006 14:48:03 -0000
Subject: [libxml-devel] Return value of XML::Node#<<
In-Reply-To: <87d58b1b0e.wl%shimbo@is.naist.jp>
References: <87d58b1b0e.wl%shimbo@is.naist.jp>
Message-ID: <op.th6t2dkukc9f7k@localhost.localdomain>

On Sun, 29 Oct 2006 13:56:17 -0000, Masashi Shimbo <shimbo at is.naist.jp>  
wrote:

> Hello,
>
> I noticed that libxml-ruby 0.3.8's method XML::Node#<<(child)
> returns 'child' instead of 'self'.
>
> This is inconsistent with the typical behavior one would expect from the
> << operator; '<<' for Array, IO, and Set all return 'self', which makes
> it easy to add multiple elements with a one-liner like
>
>   parent << child1 << child2 << child3
>
> However, if 'parent' is an XML::Node, 'child2' will be its grandchild
> instead of its second child.
>
> Wouldn't it be better to change the behavior of XML::Node#<< to follow
> the convention and return 'self'?
>

I agree. This does seem pretty inconsistent.

> I'm not sure whether this is a big API change, but the current libxml
> doc says nothing about the return value of <<.
>

If anything, I'd lean toward the opinion that this is 'probably a bug' in  
0.3x and should be fixed. IMO this should be done in 0.4 though, in case  
any code is relying on the current behaviour.

Any thoughts / objections?

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Sun Oct 29 09:48:51 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sun, 29 Oct 2006 14:48:51 -0000
Subject: [libxml-devel] Just wanted to get these figure out there.
In-Reply-To: <op.th4m1agfkc9f7k@localhost.localdomain>
References: <4b6f054f0610272017g17cdae1co6e7cc4258af198ae@mail.gmail.com>
	<op.th4m1agfkc9f7k@localhost.localdomain>
Message-ID: <op.th6t3pivkc9f7k@localhost.localdomain>

On Sat, 28 Oct 2006 11:21:00 +0100, Ross Bamford <rosco at roscopeco.co.uk>  
wrote:

> On Sat, 28 Oct 2006 04:17:32 +0100, TRANS <transfire at gmail.com> wrote:
>
>> Performance is very impressive compared to rexml:
>>
>
> Ahh, that reminds me - I never got those benchmarks up on the website!
> Sorry about that, I'll get to it shortly.

Done. Thanks again, Trans :)

-- 
Ross Bamford - rosco at roscopeco.co.uk

From transfire at gmail.com  Sun Oct 29 11:38:26 2006
From: transfire at gmail.com (TRANS)
Date: Sun, 29 Oct 2006 11:38:26 -0500
Subject: [libxml-devel] Just wanted to get these figure out there.
In-Reply-To: <op.th6t3pivkc9f7k@localhost.localdomain>
References: <4b6f054f0610272017g17cdae1co6e7cc4258af198ae@mail.gmail.com>
	<op.th4m1agfkc9f7k@localhost.localdomain>
	<op.th6t3pivkc9f7k@localhost.localdomain>
Message-ID: <4b6f054f0610290838o7332578dg8925996305ffa65d@mail.gmail.com>

On 10/29/06, Ross Bamford <rosco at roscopeco.co.uk> wrote:
> On Sat, 28 Oct 2006 11:21:00 +0100, Ross Bamford <rosco at roscopeco.co.uk>
> wrote:
>
> > On Sat, 28 Oct 2006 04:17:32 +0100, TRANS <transfire at gmail.com> wrote:
> >
> >> Performance is very impressive compared to rexml:
> >>
> >
> > Ahh, that reminds me - I never got those benchmarks up on the website!
> > Sorry about that, I'll get to it shortly.
>
> Done. Thanks again, Trans :)

Cool.

Unfortuantely I can't update those benchmarks anytime soon. I don't
think I have the script even, but I should be able to look into it
again when I get back to working on my CherryXML project --I have a
few other things I have to finsh first however.

Later on,
T.

From ruby at thomaszone.com  Sun Oct 29 13:12:49 2006
From: ruby at thomaszone.com (Mark Thomas)
Date: Sun, 29 Oct 2006 13:12:49 -0500
Subject: [libxml-devel] 0.4.0 development
In-Reply-To: <op.th4mkcskkc9f7k@localhost.localdomain>
References: <op.th4mkcskkc9f7k@localhost.localdomain>
Message-ID: <4544EF21.4020300@thomaszone.com>

Thanks for the update. Any progress on exposing libxml2's ability to 
create a DOM from HTML?

- Mark.

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


From mvanholstyn at gmail.com  Sun Oct 29 17:19:00 2006
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Sun, 29 Oct 2006 17:19:00 -0500
Subject: [libxml-devel] Return value of XML::Node#<<
In-Reply-To: <op.th6t2dkukc9f7k@localhost.localdomain>
References: <87d58b1b0e.wl%shimbo@is.naist.jp>
	<op.th6t2dkukc9f7k@localhost.localdomain>
Message-ID: <e45a289c0610291419o79c768flb35e1ba1587c284c@mail.gmail.com>

I agree with this change. I think it would be one step to make the API a
little nice and more consistent.

Mark

On 10/29/06, Ross Bamford <rosco at roscopeco.co.uk> wrote:
>
> On Sun, 29 Oct 2006 13:56:17 -0000, Masashi Shimbo <shimbo at is.naist.jp>
> wrote:
>
> > Hello,
> >
> > I noticed that libxml-ruby 0.3.8's method XML::Node#<<(child)
> > returns 'child' instead of 'self'.
> >
> > This is inconsistent with the typical behavior one would expect from the
> > << operator; '<<' for Array, IO, and Set all return 'self', which makes
> > it easy to add multiple elements with a one-liner like
> >
> >   parent << child1 << child2 << child3
> >
> > However, if 'parent' is an XML::Node, 'child2' will be its grandchild
> > instead of its second child.
> >
> > Wouldn't it be better to change the behavior of XML::Node#<< to follow
> > the convention and return 'self'?
> >
>
> I agree. This does seem pretty inconsistent.
>
> > I'm not sure whether this is a big API change, but the current libxml
> > doc says nothing about the return value of <<.
> >
>
> If anything, I'd lean toward the opinion that this is 'probably a bug' in
> 0.3x and should be fixed. IMO this should be done in 0.4 though, in case
> any code is relying on the current behaviour.
>
> Any thoughts / objections?
>
> Cheers,
> --
> Ross Bamford - rosco at roscopeco.co.uk
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel
>



-- 
Mark Van Holstyn
mvette13 at gmail.com
http://lotswholetime.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20061029/aadbb1e3/attachment.html 

From rosco at roscopeco.co.uk  Sun Oct 29 18:17:07 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sun, 29 Oct 2006 23:17:07 -0000
Subject: [libxml-devel] 0.4.0 development
In-Reply-To: <4544EF21.4020300@thomaszone.com>
References: <op.th4mkcskkc9f7k@localhost.localdomain>
	<4544EF21.4020300@thomaszone.com>
Message-ID: <op.th7hmtvlkc9f7k@localhost.localdomain>

On Sun, 29 Oct 2006 18:12:49 -0000, Mark Thomas <ruby at thomaszone.com>  
wrote:

> Thanks for the update. Any progress on exposing libxml2's ability to
> create a DOM from HTML?
>

I've just merged both the new HTMLParser and the reimplemented SaxParser  
to the DEV_0_4 branch. Now you can do:

$ irb -r libxml_so.so

htp = XML::HTMLParser.string('<html><body>Hi there<br><hr  
width=30></html>')
# => #<XML::HTMLParser:0xb7eb9954>

doc = htp.parse
# => <?xml version="1.0" standalone="yes"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"  
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
   <body>Hi there<br/><hr width="30"/></body>
</html>

doc.find('//hr').to_a
# => [<hr width="30"/>]

__END__

Currently it only supports parsing from a string, but file and io parsing  
should be doable too. It's in need of testing and bug reports!

I toyed with the idea of handling HTML with a flag to the XML parser, but  
it wasn't much fun handling the parser contexts, and this way seems more  
'right' to me :).

-- 
Ross Bamford - rosco at roscopeco.co.uk

From bryant.doug at gmail.com  Mon Oct 30 11:38:36 2006
From: bryant.doug at gmail.com (Doug Bryant)
Date: Mon, 30 Oct 2006 11:38:36 -0500
Subject: [libxml-devel] 0.4.0 development
In-Reply-To: <op.th4mkcskkc9f7k@localhost.localdomain>
References: <op.th4mkcskkc9f7k@localhost.localdomain>
Message-ID: <78cf1ade0610300838m50e3e2b6y59278bea9b7c4b90@mail.gmail.com>

Ross,

It's working good for me so far.  The xml merging problem has disappeared in
my application and performance is on par with the previous version.  I have
not done any performance benchmarks, but it does not feel any slower than
before.

Thanks for all your hard work on this project.

Doug

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

From rosco at roscopeco.co.uk  Mon Oct 30 12:26:37 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 30 Oct 2006 17:26:37 -0000
Subject: [libxml-devel] cdata comment patch
In-Reply-To: <20060830012702.92362.qmail@web32410.mail.mud.yahoo.com>
References: <20060830012702.92362.qmail@web32410.mail.mud.yahoo.com>
Message-ID: <op.th8v2nxbkc9f7k@localhost.localdomain>

On Wed, 30 Aug 2006 02:27:02 +0100, Luc Van Deuren  
<luc_van_deuren at yahoo.com> wrote:

> I just needed #CDATA and comment into my xml output.
> making a cdata or comment node did not seem to work,
> so i made a quick patch,  (cdata_comment_patch.zip)
>

Thanks, this is now applied in DEV_0_4. Sorry it took a while.

Thanks again,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Mon Oct 30 12:26:44 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 30 Oct 2006 17:26:44 -0000
Subject: [libxml-devel] Return value of XML::Node#<<
In-Reply-To: <87d58b1b0e.wl%shimbo@is.naist.jp>
References: <87d58b1b0e.wl%shimbo@is.naist.jp>
Message-ID: <op.th8v2ulxkc9f7k@localhost.localdomain>

On Sun, 29 Oct 2006 13:56:17 -0000, Masashi Shimbo <shimbo at is.naist.jp>  
wrote:

> Hello,
>
> I noticed that libxml-ruby 0.3.8's method XML::Node#<<(child)
> returns 'child' instead of 'self'.
>

Okay, this is now fixed up in DEV_0_4.

Thanks again,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Mon Oct 30 12:28:46 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 30 Oct 2006 17:28:46 -0000
Subject: [libxml-devel] Win32 compatibility
Message-ID: <op.th8v58ntkc9f7k@localhost.localdomain>

Hi,

Is anyone out there successfully using libxml-ruby on Win32? I _was_  
pretty sure the answer was 'yes' but I still see a few people in the  
forums and on blogs saying that they just can't get it to work. The  
problem is, I really don't have the facilities (i.e. an available win32  
machine) to test this, or to work on any problems that might exist, so I'd  
like to know if anyone else has had success with it.

Going on from that, for 0.4 I'd really like to be able to claim win32  
compatibility out of the box, and have it as easy as possible to install  
over there. I gather though that it's something of a nightmare compiling  
extensions on win32, so perhaps we should provide precompiled binaries  
that will work with the one-click ruby installer? Or Mingw32? Or something  
else?

Obviously that would rely on having someone willing to take new release  
candiates, test them, and either report back or compile up the binaries (I  
tried cross-compiling but can't get it to find the dependencies properly  
for some reason) - any takers on that?

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rosco at roscopeco.co.uk  Mon Oct 30 13:19:36 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 30 Oct 2006 18:19:36 -0000
Subject: [libxml-devel] 0.4.0 development
In-Reply-To: <78cf1ade0610300838m50e3e2b6y59278bea9b7c4b90@mail.gmail.com>
References: <op.th4mkcskkc9f7k@localhost.localdomain>
	<78cf1ade0610300838m50e3e2b6y59278bea9b7c4b90@mail.gmail.com>
Message-ID: <op.th8yiym9kc9f7k@localhost.localdomain>

On Mon, 30 Oct 2006 16:38:36 -0000, Doug Bryant <bryant.doug at gmail.com>  
wrote:

> Ross,
>
> It's working good for me so far.  The xml merging problem has  
> disappeared in
> my application and performance is on par with the previous version.  I  
> have
> not done any performance benchmarks, but it does not feel any slower than
> before.
>

Glad to hear it. I actually just got around yesterday to integrating the  
testcase you posted with that bug into the regression tests, and was happy  
to see it all looks good.

The inefficiency I talked about probably doesn't make that much difference  
here - it's mainly that there's a bit more object churn when you do things  
like:

	xmldoc.root << XML::Node.new('foo')

In the merging case it might actually be a bit more efficient than it was,  
since most nodes will be created by libxml2 when parsing the documents,  
and now they'll only be copied the once (between documents).

> Thanks for all your hard work on this project.
>

Most welcome! Thanks for the feedback.

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk