> -----Original Message-----
> From: John Peacock [mailto:firstname.lastname@example.org]
> Sent: Thursday, January 11, 2007 9:04 AM
> To: Miller, Eric
> Cc: email@example.com
> Subject: Re: Perl swig bindings starting to smell
> Miller, Eric wrote:
> > Is anyone working on, or interested in working on bringing the perl
> > bindings up to date?
> > They look like they are well past their expiration date.
> Are you using trunk code or 1.4.x? The reason I ask is that there has
> been a lot of activity to improved both the interface (adding new
> methods that have been added) as well as the documentation. If the
> bindings seem stale, it is primarily because there isn't a core
> developer to champion them at the moment. The nature of SWIG (as I
> understand) it is that mostly maintenance work needs to be done
> sure that new interfaces are added to the Perl-level exports), since
> SWIG is doing all of the heavy lifting already. I know that there
> a bunch of commits in the middle of December to make sure that SVK had
> access to the faster ra_replay code.
> Nik Clayton was working with adding named parameter support (but I've
> lost track of where that stands). Mattias Engdegard recently
> a patch to add a bunch more client functions, but it doesn't appear to
> have been committed. I don't think your characterization of the code
> really all that accurate. It's clear that the core committers need to
> get back to the practice of keeping on top of submitted patches.
I am looking at the trunk code. You are right, swig provides most of
the heavy lifting. Most functions appear as they get added to the svn
libraries since the majority of type mapping has already been done.
However, things like the svn_wc_status2_t typedef have been around for
awhile and haven't made it into the perl swig wrappers yet. This was
actually a pretty easy hack into the source code*. Other functions like
client lock/unlock need to be added and deprecated functions like
notify_func need to be moved to notify_func2.
I disagree that the perl swig documentation has been updated, the trunk
contains barely any updates to Client.pm from 1.4.2. Unless there is a
patch not yet commited of course.
It is definitely all maintenance related. No major changes needed that
I can see.
It looks like both Ruby and Python have been updated recently though, so
maybe I am just a little early.
* I am unable to build the libsvn-perl shared library using the devel
trunk for some reason so I had to hack on 1.4.2 code, else I would offer
up a patch for my meager updates.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jan 12 00:15:46 2007