Lele Gaifax <lele@nautilus.homeip.net> writes:
> This is just an opinion, not supported by the reality. Can you show a
> single example of a library that was swigged into multiple language
> and provides good bindings?
I've only ever used the Python SWIG bindings, but in general, our
coverage is pretty good for functions used on either side of the RA
layer. I've written both server-side and client-side programs (even
wrote a basic GUI client) with few problems at all.
> Ben, *please*: a callback is as simple as calling whatever other
> function/method, it's not the bottleneck of the matter. And I do not
> see how the automatic garbage collection should make this more
> difficult. Python do little magics, and is perfectly prevedible. See
> where PyObjC has gone, and in that case, there are two distinct
> garbage collectors at work, not only Python's....
Lele, I get the sense that you haven't actually tried to implement
Subversion bindings in Python. That, or Pyrex is just a gift from
Heaven that is far more intelligent than I could ever imagine.
At least in the case of the SWIG bindings, there are a few real
bottlenecks:
- callbacks (of which there are a *bunch*)
- vtables (thankfully these are few)
- non-native datatypes used in read-write interfaces.
I imagine that anyone who has worked in any real way with the SWIG
bindings would has run into one of these problems. But generally
speaking, the rest of the work is cake, and SWIG (quite mightily) does
it for us.
> Well, do it, and you will recognize that, as simple as it can be for
> you, it will require you to tweak a method for every language, thus
> loosing the swig benefit you cited right from the beginning.
On this you are correct. The problem here is that we have this client
context structure which contains read-write complex datatypes. To set
the --no-autoprops stuff, you have to:
1. get an svn_client_ctx_t via svn_client_create_context()
2. set the configuration structure for that object by setting
ctx.config with svn_config_get_config().
3. get the actual config hash from that configuration structure with
svn_config_get_config()
4. finally, set the autoprops-related item in that hash.
Step 1, no sweat. Our bindings return a Python svn_client_ctx_t
object. That's great.
Step 2 even works, sorta. svn_config_get_config() returns a SWIG
pointer object that represents an apr_hash_t. Here's where problems
start to show up. See, for passing ctx into interfaces that need it,
this is perfect because so far it only contains easily-mappable native
types and SWIG pointer objects. But that means we can't modify
ctx.config as a dictionary object from inside Python.
Of course, we instead write svn_config_get_config so that it returns a
Python dictionary instead of a SWIG apr_hash_t pointer, we get the
opposite effect -- modifying the returned config in Python will be
mindless, but any Subversion interfaces expecting ctx.config to be an
apr_hash_t will instead find a Python dictionary object.
Steps 3 and 4 just further complicate things.
The only way I can think of to solve this problem completely involves,
as you said, writing custom tweaks for each language. And yes, that
loses the SWIG benefit. Of course, no one has claimed that SWIG can
gracefully solve all the problems automatically, and the fact of the
matter is that these kinds of painful scenarios are, I think, the
exception rather than the rule. So, please don't imply that because
you've found one of several cases where the elegance of SWIG falls
apart that the whole effort is a bust.
I should also state that I know nothing of Pyrex. I will be shocked
if it can deal with this gracefully and efficiently. The problem is
just a hard one.
> I did not ask you or anybody else to do that. You seem in confort with
> the current bindings sit, and this is very good for you. But do not
> waste your time trying convince everybody that the same should apply
> for them.
I too got the sense (originally) that you wished to ditch the SWIG
Python bindings and go with Pyrex. If that's not the case, and you
instead wanted to go the Pyrex route, go for it. Apparently unlike
Greg Stein, though, I frown heavily on the duplicated effort on the
Java front within our own tree. There should be, IMO, exactly one set
of official Subversion [language here] bindings. And we already have
one of these for Python that mostly works.
So go do the work (and by all means, please end this thread). If
Pyrex turns out to be a smokin' solution to the problem, present that
fact (with real code) to the community here. I mean, I'm not so bound
to the SWIG bindings that I wouldn't ditch them *in a heartbeat* for a
different approach that a) covered all the ground already covered by
our SWIG bindings, and b) promised to help us cover the remaining
ground more easily. You can even contact me privately about hosting a
Subversion repository for your efforts if you wish.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 12 16:50:09 2004