From mvette13 at gmail.com  Wed Apr  5 01:44:26 2006
From: mvette13 at gmail.com (Mark Van Holstyn)
Date: Wed, 5 Apr 2006 01:44:26 -0400
Subject: [libxml-devel] Patches
Message-ID: <e45a289c0604042244x1e5bc45cvd78df0b6664f71ef@mail.gmail.com>

Attached are changes to two C files which include a few changes to the
XML::Node and XML::Node::Set, patches for both files, and a ruby file
implementing a couple of the same changes I made in the C files. The ruby
file is the same as the one made by Ross found here:

http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj

with my additions at the top. It would be great if these C changes could be
reviewed and added to CVS if they look alright. Let me know with anything
else you may need.

Thanks,
Mark Van Holstyn

--
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/20060405/bb871e82/attachment.htm 

From mvette13 at gmail.com  Wed Apr  5 01:45:19 2006
From: mvette13 at gmail.com (Mark Van Holstyn)
Date: Wed, 5 Apr 2006 01:45:19 -0400
Subject: [libxml-devel] Patches
In-Reply-To: <e45a289c0604042244x1e5bc45cvd78df0b6664f71ef@mail.gmail.com>
References: <e45a289c0604042244x1e5bc45cvd78df0b6664f71ef@mail.gmail.com>
Message-ID: <e45a289c0604042245l3afdcaf0qd7e5e63778329e91@mail.gmail.com>

And now the attatched file...

Mark

--
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/20060405/5f02e732/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libxml_patch.tgz
Type: application/x-gzip
Size: 11288 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060405/5f02e732/attachment-0001.bin 

From rosco at roscopeco.co.uk  Thu Apr  6 05:31:23 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Thu, 06 Apr 2006 10:31:23 +0100
Subject: [libxml-devel] Patches
In-Reply-To: <e45a289c0604042244x1e5bc45cvd78df0b6664f71ef@mail.gmail.com>
References: <e45a289c0604042244x1e5bc45cvd78df0b6664f71ef@mail.gmail.com>
Message-ID: <op.s7kx2lxxkc9f7k@jukebox.roscopeco>

Hi Mark,

On Wed, 05 Apr 2006 06:44:26 +0100, Mark Van Holstyn <mvette13 at gmail.com>  
wrote:

> Attached are changes to two C files which include a few changes to the
> XML::Node and XML::Node::Set, patches for both files, and a ruby file
> implementing a couple of the same changes I made in the C files. The ruby
> file is the same as the one made by Ross found here:
>
> http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj
>
> with my additions at the top. It would be great if these C changes could  
> be
> reviewed and added to CVS if they look alright. Let me know with anything
> else you may need.
>

Thanks for this :) I'm back now from my short break and will look over  
this today with a view to merging over the weekend. I have a few minor  
fixes in other places, too, for the next release so I'll hopefully be  
committing changes then.

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

From rosco at roscopeco.co.uk  Sat Apr  8 09:58:51 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Sat, 08 Apr 2006 14:58:51 +0100
Subject: [libxml-devel] planned stuff
Message-ID: <op.s7ozsdr9kc9f7k@jukebox.roscopeco>

Hi,

FYI, here's a list of things I'm planning to work on over the coming week.

	* SAX api - ability to register event callback procs
	* Look into disabling DTD loading
	* Make a start on libxml reader API
	* Integrate patches from Mark Van Holstyn
	* Update website, add benchmarks, xmlsoft.org link, etc.
	* Other things that escape me right now

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

From sean at gigave.com  Mon Apr 10 04:36:46 2006
From: sean at gigave.com (Sean Chittenden)
Date: Mon, 10 Apr 2006 01:36:46 -0700
Subject: [libxml-devel] planned stuff
In-Reply-To: <op.s7ozsdr9kc9f7k@jukebox.roscopeco>
References: <op.s7ozsdr9kc9f7k@jukebox.roscopeco>
Message-ID: <20060410083646.GW431@mailhost.gigave.com>

> FYI, here's a list of things I'm planning to work on over the coming week.
> 
> 	* SAX api - ability to register event callback procs
> 	* Look into disabling DTD loading
> 	* Make a start on libxml reader API
> 	* Integrate patches from Mark Van Holstyn
> 	* Update website, add benchmarks, xmlsoft.org link, etc.
> 	* Other things that escape me right now

I haven't tested it yet, but has anyone had any luck with fragments?

In case anyone's interested, I'm working on caching XML fragments in
memcache, then transforming the assembled XML doc into HTML via XSLT.
Think forum software and the suck that is phpBB.  -sc

-- 
Sean Chittenden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060410/78781e54/attachment.bin 

From rosco at roscopeco.co.uk  Wed Apr 12 12:20:12 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Wed, 12 Apr 2006 17:20:12 +0100
Subject: [libxml-devel] Patches applied
Message-ID: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>

Hi,

I've today committed changesets including Mark Van Holstyn's patches, an  
additional patch I received from Tim Yamin, and a few small fixups and  
extra tests. These fix bugs in XML::Node#content, and add several  
convenience methods to Node and Node::Set as previously discussed, as well  
as defining node equality based on the XML representation.

I am now considering implementing callback procs for the SAX parser, and  
would appreciate any ideas anyone might have. Currently I'm looking at two  
choices:

	1) Having methods for each callback supported by libxml, which
	   work like set_trace_func:

		saxparser.set_begin_document(lambda { |...| })
		saxparser.set_begin_element(lambda { |...| })
		# ...

	2) Introducing a new class (maybe XML::SaxParser::Callbacks?)
	   that provides the above API, and then having e.g.:

		saxparser.set_callbacks(the_callbacks)

	   This could also have an alternate API, e.g:

		the_callbacks[:begin_document] = lambda { |...| }
		the_callbacks[:begin_element] = lambda { |...| }

I'm just wondering which (if either - if not, then what) people think we  
should do.

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

From zdennis at mktec.com  Wed Apr 12 12:47:19 2006
From: zdennis at mktec.com (zdennis)
Date: Wed, 12 Apr 2006 12:47:19 -0400
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
Message-ID: <443D2F17.20004@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Bamford wrote:
> Hi,
> 
> I've today committed changesets including Mark Van Holstyn's patches, an  
> additional patch I received from Tim Yamin, and a few small fixups and  
> extra tests. These fix bugs in XML::Node#content, and add several  
> convenience methods to Node and Node::Set as previously discussed, as well  
> as defining node equality based on the XML representation.

does this mean? node1 === node2

> 
> I am now considering implementing callback procs for the SAX parser, and  
> would appreciate any ideas anyone might have. Currently I'm looking at two  
> choices:
> 
> 	1) Having methods for each callback supported by libxml, which
> 	   work like set_trace_func:
> 
> 		saxparser.set_begin_document(lambda { |...| })
> 		saxparser.set_begin_element(lambda { |...| })
> 		# ...

I seem to be a fan of the on_* naming convention for callbacks, since the terminology "on" itself seems to show that somethng will
happen. And I like just passing blocks.

  saxparser.on_begin_document { |doc| ... }

  # callback for all elements
  saxparser.on_begin_element { |node| ... }

  # callback for only the elements which are "mynode"s
  saxparser.on_begin_element( "mynode" ) { |mynode| ... }


> 
> 	2) Introducing a new class (maybe XML::SaxParser::Callbacks?)
> 	   that provides the above API, and then having e.g.:
> 
> 		saxparser.set_callbacks(the_callbacks)
> 
> 	   This could also have an alternate API, e.g:
> 
> 		the_callbacks[:begin_document] = lambda { |...| }
> 		the_callbacks[:begin_element] = lambda { |...| }

I think the above api adjustment will get rid of this need. With the above api I think it is more readable to. Even if you have a
long callback method

  begin_element_proc = lambda{ |node|
    # a few lines long
    # a few lines long
    # few lines long
    # etc...  }

  saxparser.on_begin_element { |node| being_element_proc.call node }

Seems more readable then:

  begin_element_proc = lambda{ |node|
    # a few lines long
    # a few lines long
    # few lines long
    # etc...  }

  # ... somewhere else in code
  hsh ||= {}
  hsh[ :begin_element ] = begin_element_proc

   #... somewhere else in code
   saxparser.set_callbacks hsh

To me it apperas more readable because you see what on_begin_element is doing upfront, rather then having to find the declaration
of the data structure you use when you pass it into 'set_callbacks', and then tracking down where you actually assign the
lambda/proc to your data structure.

just my 2 cents

Zach



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEPS8WMyx0fW1d8G0RAgLvAJ92nFcET1HV8t9iiGB+hkl4sirb9QCdGLha
CtM+/osdUvr4Kzv/4Z3HbWQ=
=cc0a
-----END PGP SIGNATURE-----

From rosco at roscopeco.co.uk  Wed Apr 12 12:56:22 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Wed, 12 Apr 2006 17:56:22 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <443D2F17.20004@mktec.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
Message-ID: <op.s7wmn8otkc9f7k@jukebox.roscopeco>

On Wed, 12 Apr 2006 17:47:19 +0100, zdennis <zdennis at mktec.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ross Bamford wrote:
>> Hi,
>>
>> I've today committed changesets including Mark Van Holstyn's patches, an
>> additional patch I received from Tim Yamin, and a few small fixups and
>> extra tests. These fix bugs in XML::Node#content, and add several
>> convenience methods to Node and Node::Set as previously discussed, as  
>> well
>> as defining node equality based on the XML representation.
>
> does this mean? node1 === node2

At the moment, it means that

	"<node1/>" (.eql?|==|===) "<node1/>" => true
	"<node1/>" (.eql?|==|===) "<node2/>" => false
	"<node1/>" (.eql?|==|===) "<node1 a='b'/>" => false

I'm open to suggestions as to how it could be put to better use (esp with  
respect to ===).

>
>>
>> I am now considering implementing callback procs for the SAX parser, and
>> would appreciate any ideas anyone might have. Currently I'm looking at  
>> two
>> choices:
>>
>> 	1) Having methods for each callback supported by libxml, which
>> 	   work like set_trace_func:
>>
>> 		saxparser.set_begin_document(lambda { |...| })
>> 		saxparser.set_begin_element(lambda { |...| })
>> 		# ...
>
> I seem to be a fan of the on_* naming convention for callbacks, since  
> the terminology "on" itself seems to show that somethng will
> happen. And I like just passing blocks.
>
>   saxparser.on_begin_document { |doc| ... }
>
>   # callback for all elements
>   saxparser.on_begin_element { |node| ... }
>
>   # callback for only the elements which are "mynode"s
>   saxparser.on_begin_element( "mynode" ) { |mynode| ... }
>

The only reason I tend to prefer the lambda syntax here is because it  
makes it easier to remove handlers (by passing nil, rather than just  
having a no-block call).

I like the 'on' naming convention, maybe I'll use that. Thanks :)

>
>>
>> 	2) Introducing a new class (maybe XML::SaxParser::Callbacks?)
>> 	   that provides the above API, and then having e.g.:
>>

Yeah, I agree with you on this one - Further consideration convinced me  
that it was a pointless abstraction however the procs themselves are  
handled.

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

From zdennis at mktec.com  Wed Apr 12 14:02:24 2006
From: zdennis at mktec.com (zdennis)
Date: Wed, 12 Apr 2006 14:02:24 -0400
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s7wmn8otkc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco>
Message-ID: <443D40B0.409@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do you like the idea of doing callbacks on specific node types? This should be possible with the SAXParser I would assume..but
maybe I am wrong?

Zach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEPUCwMyx0fW1d8G0RAqZ+AJ4z3Fg1z8Ltzr9lQwi5DZ3X0aFXjQCfYtf0
QWVpS3lpTV5vbUqBJax8hCA=
=JBZN
-----END PGP SIGNATURE-----

From rosco at roscopeco.co.uk  Fri Apr 14 05:11:53 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 14 Apr 2006 10:11:53 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <443D40B0.409@mktec.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
Message-ID: <op.s7zqh3k8kc9f7k@jukebox.roscopeco>

On Wed, 12 Apr 2006 19:02:24 +0100, zdennis <zdennis at mktec.com> wrote:

> Do you like the idea of doing callbacks on specific node types? This  
> should be possible with the SAXParser I would assume..but
> maybe I am wrong?
>

Libxml2's SAX parser doesn't (AFAIK?) support this directly, and my  
feeling is that we should stick to the thin wrapping plan to maintain  
speed for those that don't need that functionality. It would be pretty  
easy to implement node-typed callbacks on top of the basic API I guess,  
which might be something worth considering either within this project or  
in an external one...

In the end I went with the method-taking-block API you suggested (i.e. I  
figured out how to do it from C :)), right now the API is looking like  
this (some callbacks remain to be implemented, notably xxxxDecl events):

  *    parser.on_internal_subset { |name, external_id, system_id| ... } =>  
nil
  *    parser.on_is_standalone { || ... } => nil
  *    parser.on_has_internal_subset { || ... } => nil
  *    parser.on_has_external_subset { || ... } => nil
  *    parser.on_start_document { || ... } => nil
  *    parser.on_start_element { |name, attr_hash| ... } => nil
  *    parser.on_end_element { |name| ... } => nil
  *    parser.on_reference { |name| ... } => nil
  *    parser.on_characters { |chars| ... } => nil
  *    parser.on_processing_instruction { |target, data| ... } => nil
  *    parser.on_comment { |msg| ... } => nil
  *    parser.on_parser_warning { |msg| ... } => nil
  *    parser.on_parser_error { |msg| ... } => nil
  *    parser.on_parser_fatal_error { |msg| ... } => nil
  *    parser.on_cdata_block { |cdata| ... } => nil
  *    parser.on_external_subset { |name, external_id, system_id| ... } =>  
nil

I'll hopefully be committing this later today.

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

From zdennis at mktec.com  Fri Apr 14 08:24:41 2006
From: zdennis at mktec.com (zdennis)
Date: Fri, 14 Apr 2006 08:24:41 -0400
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s7zqh3k8kc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
	<443D2F17.20004@mktec.com>	<op.s7wmn8otkc9f7k@jukebox.roscopeco>
	<443D40B0.409@mktec.com> <op.s7zqh3k8kc9f7k@jukebox.roscopeco>
Message-ID: <443F9489.2070604@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Bamford wrote:
> On Wed, 12 Apr 2006 19:02:24 +0100, zdennis <zdennis at mktec.com> wrote:
> 
> 
>>Do you like the idea of doing callbacks on specific node types? This  
>>should be possible with the SAXParser I would assume..but
>>maybe I am wrong?
>>
> 
> 
> Libxml2's SAX parser doesn't (AFAIK?) support this directly, and my  
> feeling is that we should stick to the thin wrapping plan to maintain  
> speed for those that don't need that functionality. It would be pretty  
> easy to implement node-typed callbacks on top of the basic API I guess,  
> which might be something worth considering either within this project or  
> in an external one...
> 
> In the end I went with the method-taking-block API you suggested (i.e. I  
> figured out how to do it from C :)), right now the API is looking like  
> this (some callbacks remain to be implemented, notably xxxxDecl events):
> 
>   *    parser.on_internal_subset { |name, external_id, system_id| ... } =>  
> nil
>   *    parser.on_is_standalone { || ... } => nil
>   *    parser.on_has_internal_subset { || ... } => nil
>   *    parser.on_has_external_subset { || ... } => nil
>   *    parser.on_start_document { || ... } => nil
>   *    parser.on_start_element { |name, attr_hash| ... } => nil
>   *    parser.on_end_element { |name| ... } => nil
>   *    parser.on_reference { |name| ... } => nil
>   *    parser.on_characters { |chars| ... } => nil
>   *    parser.on_processing_instruction { |target, data| ... } => nil
>   *    parser.on_comment { |msg| ... } => nil
>   *    parser.on_parser_warning { |msg| ... } => nil
>   *    parser.on_parser_error { |msg| ... } => nil
>   *    parser.on_parser_fatal_error { |msg| ... } => nil
>   *    parser.on_cdata_block { |cdata| ... } => nil
>   *    parser.on_external_subset { |name, external_id, system_id| ... } =>  
> nil
> 
> I'll hopefully be committing this later today.

This is awesome!  Keep up the great work!


A while back you posted:
    http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj

And I know Mark VanHolstyn posted some pure-ruby stuff with his patches also. Will this ruby-addition to the api be included with
ruby-libxml distribution? If not, I want to petition that it is, even if it's not included by "require 'libxml'" be default, it
would be nice to say "require 'libxml/ext'" or something, because the functionality (although some is not apart of the libxml
binding itself, is really nice to have, and it would make upgrading libxml versions so much easier.

Thanks for everything thus far!

Zach

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEP5SJMyx0fW1d8G0RAvfqAJ9B/kJjYsuhnuR8RHfefENMuIxx7ACdGRBo
pOZvCfYR+Gwx3zynvP6XUiQ=
=nPIG
-----END PGP SIGNATURE-----

From rosco at roscopeco.co.uk  Fri Apr 14 10:54:51 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 14 Apr 2006 15:54:51 +0100
Subject: [libxml-devel] SAX API - first cut
Message-ID: <op.s7z6dpqmkc9f7k@jukebox.roscopeco>

Hi,

I've just committed the first-cut SAX callback interface. It's not yet  
complete (some missing callbacks I think we should support, and only  
partial error callback support) but it's in and working with a small  
testcase. If anyone wants to try it on something larger that'd be great.

Also I made a start on some of the additive changes proposed by myself and  
Mark Van Holstyn - for now this just consists of mixing Enumerable into  
Node::Set and XPath, but there will be more to come on that after I scope  
out how REXML behaves in this area ;)

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

From rosco at roscopeco.co.uk  Fri Apr 14 10:59:48 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 14 Apr 2006 15:59:48 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <443F9489.2070604@mktec.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
Message-ID: <op.s7z6lyo4kc9f7k@jukebox.roscopeco>

On Fri, 14 Apr 2006 13:24:41 +0100, zdennis <zdennis at mktec.com> wrote:

> A while back you posted:
>     http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj
>
> And I know Mark VanHolstyn posted some pure-ruby stuff with his patches  
> also. Will this ruby-addition to the api be included with
> ruby-libxml distribution? If not, I want to petition that it is, even if  
> it's not included by "require 'libxml'" be default, it
> would be nice to say "require 'libxml/ext'" or something, because the  
> functionality (although some is not apart of the libxml
> binding itself, is really nice to have, and it would make upgrading  
> libxml versions so much easier.
>

I'm not sure whether we'll be including an additional ruby library but I  
am planning to implement most of the points suggested in those prototypes  
directly in C. As I mentioned in my post a moment ago, I've today brought  
Enumerable into play on Node::Set and XPath and am hoping to get C-side  
each-xxxx methods on the Node / Attr / etc. before this week's out.

I'll admit at this point that I've not deeply studied the additions Mark  
made in the ruby code, so I may well 180 on this 'not including ruby code'  
in the near future :->

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

From zdennis at mktec.com  Fri Apr 14 11:23:17 2006
From: zdennis at mktec.com (zdennis)
Date: Fri, 14 Apr 2006 11:23:17 -0400
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s7z6lyo4kc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
	<443D2F17.20004@mktec.com>	<op.s7wmn8otkc9f7k@jukebox.roscopeco>
	<443D40B0.409@mktec.com>	<op.s7zqh3k8kc9f7k@jukebox.roscopeco>
	<443F9489.2070604@mktec.com> <op.s7z6lyo4kc9f7k@jukebox.roscopeco>
Message-ID: <443FBE65.1010602@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Bamford wrote:
> On Fri, 14 Apr 2006 13:24:41 +0100, zdennis <zdennis at mktec.com> wrote:
> 
> 
>>A while back you posted:
>>    http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj
>>
>>And I know Mark VanHolstyn posted some pure-ruby stuff with his patches  
>>also. Will this ruby-addition to the api be included with
>>ruby-libxml distribution? If not, I want to petition that it is, even if  
>>it's not included by "require 'libxml'" be default, it
>>would be nice to say "require 'libxml/ext'" or something, because the  
>>functionality (although some is not apart of the libxml
>>binding itself, is really nice to have, and it would make upgrading  
>>libxml versions so much easier.
>>
> 
> 
> I'm not sure whether we'll be including an additional ruby library but I  
> am planning to implement most of the points suggested in those prototypes  
> directly in C. As I mentioned in my post a moment ago, I've today brought  
> Enumerable into play on Node::Set and XPath and am hoping to get C-side  
> each-xxxx methods on the Node / Attr / etc. before this week's out.
> 
> I'll admit at this point that I've not deeply studied the additions Mark  
> made in the ruby code, so I may well 180 on this 'not including ruby code'  
> in the near future :->

The ruby stuff I am thinking of are just helpers/wrappers onto of the ruby-libxml bindings. Some of the changes that Mark has in
his xml_node_set.rb file are just things that make a nicer interface to ruby-libxml, but don't require it to be in C. For example:

- --------
class XML::Node::Set
	def empty?
		self.length <= 0
	end
	
	def first
		self.each { |n| return n }
	end
end

class XML::Node( *args )
	def first
		arr = self.find( args )
		return arr.first if arr and not arr.empty?
		nil
	end
end
- --------

I know Daniel Berger is currently porting alot of his win32-utils to ruby because it is becoming to cumbersome to maintain and
develolp it all in C. It seems same approach should apply with libxml. It is easier to add things in ruby to help make the
interface of libxml more friendly and usable if performance isn't an issue, like in the above example.

I am thinking outloud here, and thinking it would be easier for people to submit things to, since not everyone needs to dabble in C.

Thoughts?

Zach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEP75lMyx0fW1d8G0RAnoQAJ0RGO8SJZNbO01rE5OssIrzCa0TjQCfdQ9P
us5Uv/qOjw3z1lT4oXoP8z4=
=vWP9
-----END PGP SIGNATURE-----

From rosco at roscopeco.co.uk  Fri Apr 14 12:06:43 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Fri, 14 Apr 2006 17:06:43 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <443FBE65.1010602@mktec.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
	<op.s7z6lyo4kc9f7k@jukebox.roscopeco> <443FBE65.1010602@mktec.com>
Message-ID: <op.s7z9phr1kc9f7k@jukebox.roscopeco>

On Fri, 14 Apr 2006 16:23:17 +0100, zdennis <zdennis at mktec.com> wrote:

>> I'll admit at this point that I've not deeply studied the additions Mark
>> made in the ruby code, so I may well 180 on this 'not including ruby  
>> code'
>> in the near future :->
>
> The ruby stuff I am thinking of are just helpers/wrappers onto of the  
> ruby-libxml bindings. Some of the changes that Mark has in
> his xml_node_set.rb file are just things that make a nicer interface to  
> ruby-libxml, but don't require it to be in C. For example:
>
> - --------
> class XML::Node::Set
> 	def empty?
> 		self.length <= 0
> 	end
> 	
> 	def first
> 		self.each { |n| return n }
> 	end
> end
>
> class XML::Node( *args )
> 	def first
> 		arr = self.find( args )
> 		return arr.first if arr and not arr.empty?
> 		nil
> 	end
> end
> - --------
>
> I know Daniel Berger is currently porting alot of his win32-utils to  
> ruby because it is becoming to cumbersome to maintain and
> develolp it all in C. It seems same approach should apply with libxml.  
> It is easier to add things in ruby to help make the
> interface of libxml more friendly and usable if performance isn't an  
> issue, like in the above example.
>
> I am thinking outloud here, and thinking it would be easier for people  
> to submit things to, since not everyone needs to dabble in C.
>
> Thoughts?
>

My main concern here is the prospect of introducing bottlenecks in the  
library 'just for the sake of it' - I'm the first to agree (as the guy  
writing the code at the moment ;) that this would be nicer and easier done  
in Ruby, but particularly on this project performance is an important  
issue (or we'd all just use REXML I guess). Granted the additions are  
optional, but of course they will end up being used across the board and  
I'm loathe to see a situation where we have API docs saying (contrived  
example):

	set.empty?: Check if empty. If performance is an issue,
			don't use this in loops - use <something else>
			instead.

I think if we work to keep the whole core library as fast as possible  
(including all the things we expect to have as rubyists, like the above)  
then there won't be any unexpected gotchas that could bite in code that  
would otherwise be nice and quick.

On the other hand, I'm not necessarily adverse to having some kind of  
'easy' API built on top of the core library, if there was enough to it,  
and it was sufficiently 'easy', but then again that's probably for another  
(dependent) project. But in this sense I don't consider methods like  
'first' and 'empty?' as easy - I consider them essential parts of the core  
library.

Anyway, that's just me. Sean might have a different view...(?)

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

From sean at gigave.com  Sun Apr 16 20:35:59 2006
From: sean at gigave.com (Sean Chittenden)
Date: Sun, 16 Apr 2006 17:35:59 -0700
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s7z9phr1kc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
	<op.s7z6lyo4kc9f7k@jukebox.roscopeco> <443FBE65.1010602@mktec.com>
	<op.s7z9phr1kc9f7k@jukebox.roscopeco>
Message-ID: <20060417003559.GV2374@mailhost.gigave.com>

> possible (including all the things we expect to have as rubyists,
> like the above) then there won't be any unexpected gotchas that
> could bite in code that would otherwise be nice and quick.
> 
> On the other hand, I'm not necessarily adverse to having some kind
> of 'easy' API built on top of the core library, if there was enough
> to it, and it was sufficiently 'easy', but then again that's
> probably for another (dependent) project. But in this sense I don't
> consider methods like 'first' and 'empty?' as easy - I consider them
> essential parts of the core library.
> 
> Anyway, that's just me. Sean might have a different view...(?)

And I do!  The C library could easily include, mixin, or inherit bits
from a plain text ruby library.  As bottlenecks and performance issues
are identified (or as time permits), the ruby library could be
converted to C.  The `require 'libxml'` line should include the .so,
but if the .so includes additional ruby files, who cares... this'll
provide an easy way for us to prototype new APIs before they get
integrated into the core.

-- 
Sean Chittenden

From rosco at roscopeco.co.uk  Mon Apr 17 09:34:31 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 17 Apr 2006 14:34:31 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <20060417003600.A59132172EB@mailhost.gigave.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco> <443D2F17.20004@mktec.com>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
	<op.s7z6lyo4kc9f7k@jukebox.roscopeco> <443FBE65.1010602@mktec.com>
	<op.s7z9phr1kc9f7k@jukebox.roscopeco>
	<20060417003600.A59132172EB@mailhost.gigave.com>
Message-ID: <op.s75mntmckc9f7k@jukebox.roscopeco>

On Mon, 17 Apr 2006 01:35:59 +0100, Sean Chittenden <sean at gigave.com>  
wrote:

>> On the other hand, I'm not necessarily adverse to having some kind
>> of 'easy' API built on top of the core library, if there was enough
>> to it, and it was sufficiently 'easy', but then again that's
>> probably for another (dependent) project. But in this sense I don't
>> consider methods like 'first' and 'empty?' as easy - I consider them
>> essential parts of the core library.
>>
>> Anyway, that's just me. Sean might have a different view...(?)
>
> And I do!  The C library could easily include, mixin, or inherit bits
> from a plain text ruby library.  As bottlenecks and performance issues
> are identified (or as time permits), the ruby library could be
> converted to C.  The `require 'libxml'` line should include the .so,
> but if the .so includes additional ruby files, who cares... this'll
> provide an easy way for us to prototype new APIs before they get
> integrated into the core.
>

Okay, I've set this up in CVS. Basically, the C library is now  
xml/libxml_so, and 'xml/libxml' is a Ruby file that requires libxml_so,  
then goes on to make the modifications Mark and I put together. I'd still  
like to get empty? implemented in C at least but as you say it's a good  
way to get it in quick.

What do you think to having an 'xml/libxml2' require as well, maybe  
lightly deprecating 'xml/libxml'?

(Aside, I'll add the same setup on libxsl, to avoid the link errors when  
xml/libxsl is required without an explicit require 'xml/libxml').

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

From transfire at gmail.com  Mon Apr 17 10:43:37 2006
From: transfire at gmail.com (TRANS)
Date: Mon, 17 Apr 2006 10:43:37 -0400
Subject: [libxml-devel] Patches applied
In-Reply-To: <op.s75mntmckc9f7k@jukebox.roscopeco>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
	<op.s7z6lyo4kc9f7k@jukebox.roscopeco> <443FBE65.1010602@mktec.com>
	<op.s7z9phr1kc9f7k@jukebox.roscopeco>
	<20060417003600.A59132172EB@mailhost.gigave.com>
	<op.s75mntmckc9f7k@jukebox.roscopeco>
Message-ID: <4b6f054f0604170743u4f8ce370udd230ef986cc5aab@mail.gmail.com>

On 4/17/06, Ross Bamford <rosco at roscopeco.co.uk> wrote:
> On Mon, 17 Apr 2006 01:35:59 +0100, Sean Chittenden <sean at gigave.com>
> wrote:
>
> >> On the other hand, I'm not necessarily adverse to having some kind
> >> of 'easy' API built on top of the core library, if there was enough
> >> to it, and it was sufficiently 'easy', but then again that's
> >> probably for another (dependent) project. But in this sense I don't
> >> consider methods like 'first' and 'empty?' as easy - I consider them
> >> essential parts of the core library.
> >>
> >> Anyway, that's just me. Sean might have a different view...(?)
> >
> > And I do!  The C library could easily include, mixin, or inherit bits
> > from a plain text ruby library.  As bottlenecks and performance issues
> > are identified (or as time permits), the ruby library could be
> > converted to C.  The `require 'libxml'` line should include the .so,
> > but if the .so includes additional ruby files, who cares... this'll
> > provide an easy way for us to prototype new APIs before they get
> > integrated into the core.
> >
>
> Okay, I've set this up in CVS. Basically, the C library is now
> xml/libxml_so, and 'xml/libxml' is a Ruby file that requires libxml_so,
> then goes on to make the modifications Mark and I put together. I'd still
> like to get empty? implemented in C at least but as you say it's a good
> way to get it in quick.

Hmm... adding functionality. I would tend to give that the new name
since it is over and above the libxml binding. Perhaps the total
package could come in:

  require 'xml'

but xml/libxml could remain the pure binding.

> What do you think to having an 'xml/libxml2' require as well, maybe
> lightly deprecating 'xml/libxml'?

What's the point? Personaly I find such numberd names useless. Unless
the original libxml (not 2) is in common use, why bother? If you
really want create a file, libxml2.rb with content:

  require 'xml/libxml'

But peronally I don't want to *have* to use require 'xml/libxml2'.

2c,
T.


From rosco at roscopeco.co.uk  Mon Apr 17 12:04:10 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 17 Apr 2006 17:04:10 +0100
Subject: [libxml-devel] Patches applied
In-Reply-To: <4b6f054f0604170743u4f8ce370udd230ef986cc5aab@mail.gmail.com>
References: <op.s7wkzyg7kc9f7k@jukebox.roscopeco>
	<op.s7wmn8otkc9f7k@jukebox.roscopeco> <443D40B0.409@mktec.com>
	<op.s7zqh3k8kc9f7k@jukebox.roscopeco> <443F9489.2070604@mktec.com>
	<op.s7z6lyo4kc9f7k@jukebox.roscopeco> <443FBE65.1010602@mktec.com>
	<op.s7z9phr1kc9f7k@jukebox.roscopeco>
	<20060417003600.A59132172EB@mailhost.gigave.com>
	<op.s75mntmckc9f7k@jukebox.roscopeco>
	<4b6f054f0604170743u4f8ce370udd230ef986cc5aab@mail.gmail.com>
Message-ID: <op.s75tk8cxkc9f7k@jukebox.roscopeco>

On Mon, 17 Apr 2006 15:43:37 +0100, TRANS <transfire at gmail.com> wrote:

> On 4/17/06, Ross Bamford <rosco at roscopeco.co.uk> wrote:
>> On Mon, 17 Apr 2006 01:35:59 +0100, Sean Chittenden <sean at gigave.com>
>> wrote:
>>
>> >> On the other hand, I'm not necessarily adverse to having some kind
>> >> of 'easy' API built on top of the core library, if there was enough
>> >> to it, and it was sufficiently 'easy', but then again that's
>> >> probably for another (dependent) project. But in this sense I don't
>> >> consider methods like 'first' and 'empty?' as easy - I consider them
>> >> essential parts of the core library.
>> >>
>> >> Anyway, that's just me. Sean might have a different view...(?)
>> >
>> > And I do!  The C library could easily include, mixin, or inherit bits
>> > from a plain text ruby library.  As bottlenecks and performance issues
>> > are identified (or as time permits), the ruby library could be
>> > converted to C.  The `require 'libxml'` line should include the .so,
>> > but if the .so includes additional ruby files, who cares... this'll
>> > provide an easy way for us to prototype new APIs before they get
>> > integrated into the core.
>> >
>>
>> Okay, I've set this up in CVS. Basically, the C library is now
>> xml/libxml_so, and 'xml/libxml' is a Ruby file that requires libxml_so,
>> then goes on to make the modifications Mark and I put together. I'd  
>> still
>> like to get empty? implemented in C at least but as you say it's a good
>> way to get it in quick.
>
> Hmm... adding functionality. I would tend to give that the new name
> since it is over and above the libxml binding.

Well, my plan is that people shouldn't really need to require  
'xml/libxml_so' directly, but rather the ruby file which just really acts  
as a front. As I said before I think much of it (especially stuff like the  
various each methods) will end up implemented in C but in the meantime  
this is a way to get them in and try things out. (I've :nodoc:'d all the  
new stuff for the time being). There are no cases where the new  
functionality replaces C-side methods, so unless you deliberately use the  
undocumented methods you shouldn't need to worry about any performance or  
upward-compatibility issues.

>> What do you think to having an 'xml/libxml2' require as well, maybe
>> lightly deprecating 'xml/libxml'?
>
> What's the point? Personaly I find such numberd names useless. Unless
> the original libxml (not 2) is in common use, why bother? If you
> really want create a file, libxml2.rb with content:
>
>   require 'xml/libxml'
>
> But peronally I don't want to *have* to use require 'xml/libxml2'.
>

Yeah, that was what I was thinking of. I tend to be in agreement on this  
kind of thing but a few people have already mentioned that it's a  
potential source of confusion.

In this context, by 'lightly deprecate' I really meant refer in the docs  
to the 'xml/libxml2' name, but still support 'xml/libxml' - there would be  
no warnings or anything like that.

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

From zdennis at mktec.com  Thu Apr 20 21:49:08 2006
From: zdennis at mktec.com (zdennis)
Date: Thu, 20 Apr 2006 21:49:08 -0400
Subject: [libxml-devel] [Fwd: XML parser with file names and line numbers]
Message-ID: <44483A14.3020606@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David posted this message on ruby-talk ML.

- -----------------------------------------------------------------------
Is there a Ruby XML parser that includes the file name and line number
for elements?
- -----------------------------------------------------------------------

Does libxml doesn't this natively? Is this something we can easily wrap
in ruby-libxml?

Thanks,

Zach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFESDoUMyx0fW1d8G0RApndAJ9p7XUCV7qRa3WIUWp3+PTjJnLOAgCfXhdR
DTkoKxuaphwp10rJ6SiOELs=
=GELX
-----END PGP SIGNATURE-----

From zdennis at mktec.com  Fri Apr 21 14:22:54 2006
From: zdennis at mktec.com (zdennis)
Date: Fri, 21 Apr 2006 14:22:54 -0400
Subject: [libxml-devel] [Fwd: XML parser with file names and line
	numbers]
In-Reply-To: <44483A14.3020606@mktec.com>
References: <44483A14.3020606@mktec.com>
Message-ID: <444922FE.9060809@mktec.com>

zdennis wrote:
> David posted this message on ruby-talk ML.
> 
> -----------------------------------------------------------------------
> Is there a Ruby XML parser that includes the file name and line number
> for elements?
> -----------------------------------------------------------------------
> 
> Does libxml doesn't this natively? Is this something we can easily wrap
> in ruby-libxml?

Sweet, looks like it already does. Dave posted... libxml is sweet =)
Thanks Ross and Sean, you guys rock!

--------------------------------------------------------------
Zach,

Yep... libxml does the trick with:
XML::Parser.default_line_numbers = true
...


element.line_number
element.doc.filename

Thanks,

David

From zdennis at mktec.com  Fri Apr 21 14:36:48 2006
From: zdennis at mktec.com (zdennis)
Date: Fri, 21 Apr 2006 14:36:48 -0400
Subject: [libxml-devel] [Fwd: XML parser with file names and
	line	numbers]
In-Reply-To: <444922FE.9060809@mktec.com>
References: <44483A14.3020606@mktec.com> <444922FE.9060809@mktec.com>
Message-ID: <44492640.9050900@mktec.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

zdennis wrote:
> zdennis wrote:
> 
>>David posted this message on ruby-talk ML.
>>
>>-----------------------------------------------------------------------
>>Is there a Ruby XML parser that includes the file name and line number
>>for elements?
>>-----------------------------------------------------------------------
>>
>>Does libxml doesn't this natively? Is this something we can easily wrap
>>in ruby-libxml?
> 
> 
> Sweet, looks like it already does. Dave posted..

Wait Dave posted the below message.


. libxml is sweet =)
> Thanks Ross and Sean, you guys rock!

This is my personal opinion.

I got mixed up when typing that email.

Zach

> 
> --------------------------------------------------------------
> Zach,
> 
> Yep... libxml does the trick with:
> XML::Parser.default_line_numbers = true
> ...
> 
> 
> element.line_number
> element.doc.filename
> 
> Thanks,
> 
> David
> _______________________________________________
> libxml-devel mailing list
> libxml-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/libxml-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFESSZAMyx0fW1d8G0RAgiiAJ4lddBM+ThbuDJx3SUHR5yzPc/xwQCfXIEn
NQb4ZKLDYDUyKaTXpHQfW4A=
=s1Tc
-----END PGP SIGNATURE-----

From rosco at roscopeco.co.uk  Mon Apr 24 12:15:24 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 24 Apr 2006 17:15:24 +0100
Subject: [libxml-devel] A release?
Message-ID: <op.s8isrywukc9f7k@jukebox.roscopeco>

Hi,

I think we should release 0.3.8 fairly soon - although I didn't get to  
tackle everything I hoped for last week, we've still made good progress  
since 0.3.6 almost two months ago (see attachment) and I think at least  
some of the stuff (OSX fixes, SAX parser, etc) should be released.

We do have an open bug on Rubyforge, relating to -Wall being hardcoded in  
extconf (problems with compilers other than GCC) which I'd like to clear  
before then - I guess we can just remove it (doesn't extconf supply it  
anyway if ruby was built with it)?

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

From rosco at roscopeco.co.uk  Mon Apr 24 12:17:03 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 24 Apr 2006 17:17:03 +0100
Subject: [libxml-devel] A release?
In-Reply-To: <op.s8isrywukc9f7k@jukebox.roscopeco>
References: <op.s8isrywukc9f7k@jukebox.roscopeco>
Message-ID: <op.s8isuphpkc9f7k@jukebox.roscopeco>

On Mon, 24 Apr 2006 17:15:24 +0100, Ross Bamford <rosco at roscopeco.co.uk>  
wrote:

> we've still made good progress
> since 0.3.6 almost two months ago (see attachment)

Doh, forgot the bloody attachment... :)

-- 
Ross Bamford - rosco at roscopeco.co.uk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
Url: http://rubyforge.org/pipermail/libxml-devel/attachments/20060424/95347ab1/attachment.txt 

From sean at gigave.com  Mon Apr 24 12:39:49 2006
From: sean at gigave.com (Sean Chittenden)
Date: Mon, 24 Apr 2006 09:39:49 -0700
Subject: [libxml-devel] A release?
In-Reply-To: <op.s8isrywukc9f7k@jukebox.roscopeco>
References: <op.s8isrywukc9f7k@jukebox.roscopeco>
Message-ID: <20060424163949.GL591@mailhost.gigave.com>

> I think we should release 0.3.8 fairly soon - although I didn't get
> to tackle everything I hoped for last week, we've still made good
> progress since 0.3.6 almost two months ago (see attachment) and I
> think at least some of the stuff (OSX fixes, SAX parser, etc) should
> be released.

You mean releases lead to testing/use of features?  *shock* Works for
me.

> We do have an open bug on Rubyforge, relating to -Wall being
> hardcoded in extconf (problems with compilers other than GCC) which
> I'd like to clear before then - I guess we can just remove it
> (doesn't extconf supply it anyway if ruby was built with it)?

Optional CC flag.  If the test passes, append the -Wall, if it fails,
just continue silently.  Just a thought.  -sc

-- 
Sean Chittenden

From rosco at roscopeco.co.uk  Mon Apr 24 13:41:00 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 24 Apr 2006 18:41:00 +0100
Subject: [libxml-devel] A release?
In-Reply-To: <20060424163950.E832F216FCE@mailhost.gigave.com>
References: <op.s8isrywukc9f7k@jukebox.roscopeco>
	<20060424163950.E832F216FCE@mailhost.gigave.com>
Message-ID: <op.s8iwqmgekc9f7k@jukebox.roscopeco>

On Mon, 24 Apr 2006 17:39:49 +0100, Sean Chittenden <sean at gigave.com>  
wrote:

>> We do have an open bug on Rubyforge, relating to -Wall being
>> hardcoded in extconf (problems with compilers other than GCC) which
>> I'd like to clear before then - I guess we can just remove it
>> (doesn't extconf supply it anyway if ruby was built with it)?
>
> Optional CC flag.  If the test passes, append the -Wall, if it fails,
> just continue silently.  Just a thought.  -sc
>

Okay, I'll put that together and then bundle up a release.

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

From rosco at roscopeco.co.uk  Mon Apr 24 16:25:13 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Mon, 24 Apr 2006 21:25:13 +0100
Subject: [libxml-devel] Libxml-Ruby 0.3.8 released
Message-ID: <op.s8i4cbkzkc9f7k@jukebox.roscopeco>

Libxml-Ruby 0.3.8 is now available from Rubyforge. Libxml-Ruby provides a  
Ruby binding for the GNOME LibXML2 library, supporting high-speed,  
high-capability XML handling in Ruby. This release includes both new  
features and bugfixes.

Install:

su -c 'gem install libxml-ruby'

or download from:

http://rubyforge.org/frs/?group_id=494&release_id=5129
(and follow instructions in README)

Changes in this version include:

* Implemented SAX parser callback handling
* Defined XML::Node (hash) equality in terms of XML representation
* Fixed XML::Node#content inoperable bug
* Fixed memory leak in same
* Added convenience methods to XML::Node and XML::Node::Set
* Fixes to XML::Node::Set#to_a
* Integrated contributed XML::Parser.register_error_handler patch
* Fixed symbol defs and removed OSX -fno-common workaround
* Numerous documentation updates and fixes

Thanks to everyone who contributed patches, gave suggestions, and reported  
bugs - more of the same, please :)

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

From rajesh4it at gmail.com  Wed Apr 12 08:12:40 2006
From: rajesh4it at gmail.com (Rajesh Kumar)
Date: Wed, 12 Apr 2006 17:42:40 +0530
Subject: [libxml-devel] XML in Ruby
Message-ID: <610522710604120512i340bb308gfbe6ab49a831cc6@mail.gmail.com>

Dear Sir,
Can I have a step-by-step tutorial for coding a XML file in ruby?

thank you
rajesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060412/fb5a5edf/attachment.htm 

From gtdev at spearhead.de  Wed Apr 26 12:29:50 2006
From: gtdev at spearhead.de (Nicos Gollan)
Date: Wed, 26 Apr 2006 18:29:50 +0200
Subject: [libxml-devel] Closing files from XML::Document.file
Message-ID: <200604261829.58376.gtdev@spearhead.de>

Hi,

is it intentional that XML::Document.file doesn't seem to close files?

With mod_ruby, I'm getting a lot of open files from calls to that method, and 
I haven't found a way to close those files again.

In theory, it should not be necessary to keep a file open after the parser is 
done with it, right?

-- 
Got Backup?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060426/1919c0ce/attachment.bin 

From rosco at roscopeco.co.uk  Thu Apr 27 03:44:44 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Thu, 27 Apr 2006 08:44:44 +0100
Subject: [libxml-devel] Closing files from XML::Document.file
In-Reply-To: <200604261829.58376.gtdev@spearhead.de>
References: <200604261829.58376.gtdev@spearhead.de>
Message-ID: <op.s8no4uhjkc9f7k@jukebox.roscopeco>

On Wed, 26 Apr 2006 17:29:50 +0100, Nicos Gollan <gtdev at spearhead.de>  
wrote:

> Hi,
>
> is it intentional that XML::Document.file doesn't seem to close files?
>
> With mod_ruby, I'm getting a lot of open files from calls to that  
> method, and
> I haven't found a way to close those files again.
>

The behaviour I'm observing here is that the XML::Parser keeps files open  
until it's garbage collected. Since XML::Document.file uses a parser  
behind the scenes, this is holding the file open:

x = XML::Document.file  
'/home/rosco/workspace/libxml/tests/model/rubynet.xml'
# => <?xml version="1.0"?> ...

puts `/usr/sbin/lsof /home/rosco/workspace/libxml/tests/model/rubynet.xml`
COMMAND   PID  USER   FD   TYPE DEVICE SIZE     NODE NAME
irb     25366 rosco    3r   REG  253,2 3021 10997895  
/home/rosco/workspace/libxml/tests/model/rubynet.xml
# => nil

GC.start
# => nil

puts `/usr/sbin/lsof /home/rosco/workspace/libxml/tests/model/rubynet.xml`
# => nil

> In theory, it should not be necessary to keep a file open after the  
> parser is
> done with it, right?
>

I'd tend to agree, though at this point I'm not sure whether it's  
something we can fix (obviously I'll look into it :)).

For now, here's a workaround you might try:

doc =  
File.open('/home/rosco/workspace/libxml/tests/model/rubynet.xml','r') do  
|f|
   XML::Parser.io(f).parse
end
# => <?xml version="1.0"?> ...

puts `/usr/sbin/lsof /home/rosco/workspace/libxml/tests/model/rubynet.xml`
# => nil

Hope that helps,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From gtdev at spearhead.de  Thu Apr 27 10:47:03 2006
From: gtdev at spearhead.de (Nicos Gollan)
Date: Thu, 27 Apr 2006 16:47:03 +0200
Subject: [libxml-devel] Closing files from XML::Document.file
In-Reply-To: <op.s8no4uhjkc9f7k@jukebox.roscopeco>
References: <200604261829.58376.gtdev@spearhead.de>
	<op.s8no4uhjkc9f7k@jukebox.roscopeco>
Message-ID: <200604271647.21268.gtdev@spearhead.de>

On Thursday April 27 2006 09:44, you wrote:
> > In theory, it should not be necessary to keep a file open after the
> > parser is
> > done with it, right?
>
> [...]
>
> For now, here's a workaround you might try:
>
> doc =
> File.open('/home/rosco/workspace/libxml/tests/model/rubynet.xml','r') do |f|
>    XML::Parser.io(f).parse
> end

Yes, that seems to help, thanks a lot :-)

-- 
Got Backup?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060427/75e82779/attachment.bin 

From rosco at roscopeco.co.uk  Thu Apr 27 12:13:25 2006
From: rosco at roscopeco.co.uk (Ross Bamford)
Date: Thu, 27 Apr 2006 17:13:25 +0100
Subject: [libxml-devel] XML in Ruby
In-Reply-To: <610522710604120512i340bb308gfbe6ab49a831cc6@mail.gmail.com>
References: <610522710604120512i340bb308gfbe6ab49a831cc6@mail.gmail.com>
Message-ID: <op.s8oconffkc9f7k@jukebox.roscopeco>

On Wed, 12 Apr 2006 13:12:40 +0100, Rajesh Kumar <rajesh4it at gmail.com>  
wrote:

> Dear Sir,
> Can I have a step-by-step tutorial for coding a XML file in ruby?
>

Sure, as soon as we've got one :)

About the best examples we have right now are in the docs:

	http://libxml.rubyforge.org/doc/files/README.html

Hope that helps,
-- 
Ross Bamford - rosco at roscopeco.co.uk

From rikkus at gmail.com  Fri Apr 28 04:30:44 2006
From: rikkus at gmail.com (Rik Hemsley)
Date: Fri, 28 Apr 2006 09:30:44 +0100
Subject: [libxml-devel] Adding 'previous' node, adding doctype to doc.
Message-ID: <868dee660604280130kae91572t79d762e065e8f00b@mail.gmail.com>

Hi,

I have a couple of small questions:

I have XML like this:

<a><b/></a>
I would like to add a node before <b/>, i.e.:
<a><c/><b/></a>

With the C library of libxml2, I could use xmlAddPrevSibling()
Is there an equivalent for ruby-libxml?

I would also like to know how it is possible to add a Dtd to a
Document. There seems to be no dtd= or equivalent.

Thanks,
Rik