On Jun 30, 2009, at 1:10 PM, David James wrote:
> On Tue, Jun 30, 2009 at 5:55 AM, Hyrum K.
> Wright<hyrum_at_hyrumwright.org> wrote:
>> John, Nik,
>> I know it's been a while since either of you did much with the perl
>> swig bindings, but I think you're still the domain experts around
>> here, so this plea goes to you. (If anybody else can fix this,
>> though, feel free to do so.)
>>
>> I rev'd an API in libsvn_wc the other day, and now the perl swig
>> bindings won't build. Specifically, I added svn_wc_get_ignores2(),
>> and inside the generated wrapper, I see the following error:
>>
>> svn_wc.c: In function ‘_wrap_svn_wc_get_ignores2’:
>> svn_wc.c:28992: error: ‘_global_pool’ undeclared (first use in this
>> function)
>> svn_wc.c:28992: error: (Each undeclared identifier is reported only
>> once
>> svn_wc.c:28992: error: for each function it appears in.)
>
> Hi Hyrum,
>
> I haven't looked at the Perl bindings in a long time, but I have a
> suggestion. It looks like your new function gets rid of the simple
> "pool" argument and replaces it with two new arguments, result_pool,
> and scratch_pool. I don't think any of the bindings have been taught
> how to handle functions that accept multiple pool arguments, or to
> understand the meaning of the words "result_pool" and "scratch_pool".
>
> Teaching the Perl bindings to just treat the result_pool and
> scratch_pool as a regular pool is relatively easy -- there's an %apply
> statement in svn_types.swg that looks like this:
>
> #ifdef SWIGPERL
> %apply apr_pool_t *pool {
> apr_pool_t *dir_pool,
> apr_pool_t *file_pool,
> apr_pool_t *node_pool
> };
> #endif
>
> It's not really the best idea, though, to treat result_pool and
> scratch_pool as regular pools, since they aren't regular pools. Our
> bindings would be much happier if you just stuck with a single pool
> argument, and used that pool as our result pool. If you need to create
> a subpool from your result pool to work as a scratch pool, that is no
> problem.
Providing two pools is actually a much more efficient memory
strategy. The main idea is that the caller of a function, not the
function itself, can better manage the temporary memory which that
function needs. For instance, if several functions are called in
succession, and they all create, use and destroy their own subpools,
this introduces a fair amount of both space and runtime overhead.
However, if the calling function can create one subpool, and let each
of the called functions use it, that overhead is greatly reduced.
We've been using this paradigm for several months within libsvn_wc,
with good results, and as we start pushing our changes into the public
API, more instances of scratch_pool/result_pool will arise. You can
find a more thorough discussion of this method, and its rationale, in
this thread: http://svn.haxx.se/dev/archive-2008-10/0268.shtml
In any case, I don't think that the limitations of our binding
framework should drive API decisions within the core Subversion
libraries.
(I'm curious, though. In what way aren't scratch_pool or result_pool
"regular" pools?)
> The Python / Ruby bindings may compile, but I doubt that they will
> work properly with your function. The bindings assume that each
> function only accepts a single pool argument, so if you have multiple
> pool arguments they will likely get very confused.
>
> You could also teach all three sets of bindings to understand the
> difference between result pools and scratch pools, but that would be a
> much bigger project.
>
> In general, it is quite confusing and hard to maintain that our SWIG
> bindings are trying to make general decisions about how to handle
> function wrapping based on the names of variables in function
> declarations. Unfortunately, the current design of our SWIG bindings
> requires this type of trickery. In the ctypes python bindings, we
> simply wrap functions "as is", so there is no need for any fancy rules
> based on variable names. This type of design, I think, is much more
> maintainable for the long term, because it allows Subversion API
> designers to write their functions any way they want without needing
> to think about how our fancy SWIG rules will interpret your changes.
You make a good point: relying upon bindings which depend on parameter
names to work properly is brittle, and error-prone over the long
term. Unfortunately, I don't have any good suggestions for
eliminating this problem.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2366800
Received on 2009-06-30 20:32:26 CEST