You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kristian Hogsberg <ho...@users.sourceforge.net> on 2003/06/26 20:48:05 UTC

State of ruby bindings?

Hi all,

I've recently installed subversion 0.24.2 - it's working nicely, and
it really is a great tool.  Looking around in the source tree, I
discovered the ruby bindings, but I couldn't figure out how to build
them and I found out that they weren't even mentioned in build.conf.
Do I have to write my own Makefile for this, and are they at all
up-to-date?

Anyway, thanks for building such a great tool and good luck on
retiring CVS :-)

Kristian



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 01, 2003 at 10:30:14PM -0400, Russell Yanofsky wrote:
> Kristian Hogsberg wrote:
> > Garrett Rooney <ro...@electricjellyfish.net> writes:
> > Yeah, I realize the SWIG bindings are easier to maintain, but I looked
> > at the python bindings and I wasn't too impressed.  The subversion C
> > API appears to be object-oriented C, in much the same way as the Gtk+
> > toolkit, but the python bindings doesn't really reflect this.  For
> > example, the following code (from svnlook.py)
> >
> >         txn_ptr = fs.open_txn(self.fs_ptr, txn, pool)
> >
> > should be (in my opinion, of course):
> >
> >         txn_obj = fs_obj.open_txn(txn, pool)
> >
> > where the pointers are wrapped in python objects so you can say
> > obj.method(args) instead of method(obj, args) as you would in C.
> 
> It's possible to use swig to make a more object oriented interface. See the
> "Adding member functions to C structures" section of the swig documentation at
> http://www.swig.org/Doc1.3/SWIG.html#n37 .

Not only that, but the idea behind the Python bindings is to expose the raw
C functions, then build the extended functionality all in Python. i.e. you
build a sweet object system in Python. No need to continually update C
code... do it in nice, fast-to-code Python.

Seriously... expose functionality in SWIG and build on top.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Kristian Hogsberg <ho...@users.sourceforge.net>.
Ben Collins-Sussman <su...@collab.net> writes:

> Kristian Hogsberg <ho...@users.sf.net> writes:
> 
> > Yeah, I realize the SWIG bindings are easier to maintain, but I looked
> > at the python bindings and I wasn't too impressed.  The subversion C
> > API appears to be object-oriented C, in much the same way as the Gtk+
> > toolkit,
> 
> Huh?  There ain't no C objects anywhere in subversion.  We have no
> "classes" or "inheritance" the way GTK does.  We just have some tables
> of functions and opaque contexts.

I didn't mean to say that subversion has a complex oo-runtime with
inheritance, virtual functions or signals or whatnot, just that the
APIs seems to follow the same conventions about function naming and
parameters.  When a group of functions operate on the same "opaque
context" they are all named with a common prefix and take the context
as their first parameter, e.g.:

        svn_error_t *svn_fs_make_dir (svn_fs_root_t *root,
                                      const char *path,
                                      apr_pool_t *pool);
                              
        svn_error_t *svn_fs_delete (svn_fs_root_t *root,
                                    const char *path,
                                    apr_pool_t *pool);

unless a function returns data, in which case the return arguments
precede the context argument.  Whether or not this is object oriented
is another discussion, but my point was that bindings for a
object-oriented scripting lanugage should take advantage of this
convention and provide a python class such as svn.fs.Root with methods
make_dir and delete so you could say:

        root.make_dir("branches/2.7", pool)
        root.delete("README~")

which is what I think the ruby binding does.

best regards,
Kristian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Ben Collins-Sussman <su...@collab.net>.
Kristian Hogsberg <ho...@users.sf.net> writes:

> Yeah, I realize the SWIG bindings are easier to maintain, but I looked
> at the python bindings and I wasn't too impressed.  The subversion C
> API appears to be object-oriented C, in much the same way as the Gtk+
> toolkit,

Huh?  There ain't no C objects anywhere in subversion.  We have no
"classes" or "inheritance" the way GTK does.  We just have some tables
of functions and opaque contexts.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Russell Yanofsky <re...@columbia.edu>.
Kristian Hogsberg wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> Yeah, I realize the SWIG bindings are easier to maintain, but I looked
> at the python bindings and I wasn't too impressed.  The subversion C
> API appears to be object-oriented C, in much the same way as the Gtk+
> toolkit, but the python bindings doesn't really reflect this.  For
> example, the following code (from svnlook.py)
>
>         txn_ptr = fs.open_txn(self.fs_ptr, txn, pool)
>
> should be (in my opinion, of course):
>
>         txn_obj = fs_obj.open_txn(txn, pool)
>
> where the pointers are wrapped in python objects so you can say
> obj.method(args) instead of method(obj, args) as you would in C.

It's possible to use swig to make a more object oriented interface. See the
"Adding member functions to C structures" section of the swig documentation at
http://www.swig.org/Doc1.3/SWIG.html#n37 .

- Russ




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Kristian Hogsberg <ho...@users.sourceforge.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:

> Kristian Hogsberg wrote:
> > Hi all,
> > I've recently installed subversion 0.24.2 - it's working nicely, and
> > it really is a great tool.  Looking around in the source tree, I
> > discovered the ruby bindings, but I couldn't figure out how to build
> > them and I found out that they weren't even mentioned in build.conf.
> > Do I have to write my own Makefile for this, and are they at all
> > up-to-date?
> 
> If you wanted to try to build them, you'd use the extconf.rb in the
> bindings/ruby directory...  

Ah, I missed that one. I'll give it a try.

> But that would be rather futile, as they are horribly out of date.
> If you're looking for something to do, you could try to update them,
> or better yet, try to write us some SWIG based ruby bindings, which
> would have a better chance of staying up to date.

Yeah, I realize the SWIG bindings are easier to maintain, but I looked
at the python bindings and I wasn't too impressed.  The subversion C
API appears to be object-oriented C, in much the same way as the Gtk+
toolkit, but the python bindings doesn't really reflect this.  For
example, the following code (from svnlook.py)

        txn_ptr = fs.open_txn(self.fs_ptr, txn, pool)

should be (in my opinion, of course):

        txn_obj = fs_obj.open_txn(txn, pool)

where the pointers are wrapped in python objects so you can say
obj.method(args) instead of method(obj, args) as you would in C.  I've
browsed through the ruby bindings and they do this already.  After
all, I'm only planning to use the bindings for some server-side
scripting, so I'll only need to update bindings for core, fs and
repos... I guess?

thanks,
Kristian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: State of ruby bindings?

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Kristian Hogsberg wrote:
> Hi all,
> 
> I've recently installed subversion 0.24.2 - it's working nicely, and
> it really is a great tool.  Looking around in the source tree, I
> discovered the ruby bindings, but I couldn't figure out how to build
> them and I found out that they weren't even mentioned in build.conf.
> Do I have to write my own Makefile for this, and are they at all
> up-to-date?

If you wanted to try to build them, you'd use the extconf.rb in the 
bindings/ruby directory...  But that would be rather futile, as they are 
horribly out of date.  If you're looking for something to do, you could 
try to update them, or better yet, try to write us some SWIG based ruby 
bindings, which would have a better chance of staying up to date.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org