[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Multiple problems with svn python bindings

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-08-30 23:42:44 CEST

On Fri, Aug 30, 2002 at 12:28:05AM -0500, Jon Trowbridge wrote:
>...
> Here are the problems I've found so far:
>
> * svn_client_commit, svn_client_log and svn_client_diff are %ignored
> in svn_client.i. A comment in that file says that the problem has
> to do with apr_array_header_t and pools.

Ah. Now I understand your offlist email. I was hoping to get back to that,
and ask what you meant about "commit", "log", and "diff" :-)

The issue here is that we need to accept a (Python) list and construct an
apr_array_header_t for passing into those functins. To do *that*, we need a
pool for that construction. So what needs to happen with those functions is
to somehow tell SWIG that the pool to use is "arg6" or whatever.

I'm not yet sure what the cleanest approach would be for this. Hardcode it
for each function that takes an array? Is there some other approach?

> * A number of functions take a svn_wc_notify_func_t and a notify baton
> as arguments. While the comments in svn_client.h say that the
> notify function can be NULL, passing in None for the notify function
> causes a segfault. As far as I can tell, there is no way to construct
> a non-NULL svn_wc_notify_func_t from inside of python. Am I missing
> something?

Note that I just kind of "turned on" the bindings for libsvn_client/wc a few
weeks ago. "hey, they compile, if I disable <this>". And that was it. Across
the board, we need to flesh out mechanisms for the callbacks. I did some of
that with the editor stuff. But for each and every callback, we need some
"thunk" types of layers.

Thankfully, every callback in SVN also has a piece of context associated
with that. So what we do for these cases is accept a single callable at the
Python scripting level, and underneath, we pass that callable as the
context, and the function is something that we write explicitly in
swig_util_py.c.

>...
> * When calling svn_client_checkout or svn_client_update, a TypeError
> is produced if the xml_src is None.

Take a look at svn_repos.i. I changed the argument parsing character for
"src_entry" to "z". That allows None to be passed, so NULL will be passed to
the underlying function.

A similar situation could be defined in svn_client.i to allow None for any
parameter named "xml_src".

(you can also attach them to specific functions and whatnot, but I suspect
 that *any* parameter named xml_src will have that behavior.)

> * svn_client_proplist segfaults when I call it on a file that actually
> has properties set. (If no properties are set, it correctly returns
> an empty array.)

The proplist conversion code has never been exercised. See svn_client.i for
that code. There is (obviously) a bug in there somewhere.

> * I don't see how to access the data returned by svn_client_propget.
> The values of the hash that comes back are not strings, but instead are
> things like: <read-only buffer ptr 0x8179f80, size 111 at 0x81740d8>

Buffer objects are string-like. You can use them in most places as a string.
But if something doesn't like that, then just do str(ob).

Regardless, I have a comment in the code about whether it is wise to use
buffer objects in this scenario. It is possible that the underlying memory
might drop out. Thus, using a true string object would be safer.

> I have no idea if these things are easy or hard to fix, or if I've
> just misunderstood how the bindings are supposed to work. Any and all
> suggestions are appreciated.

Mostly, it is simply that you're treading into uncharted waters :-)

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
Received on Fri Aug 30 23:37:49 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.