On Tue, Jun 30, 2009 at 12:10:31PM -0700, David James wrote:
> Perl bindings, Ruby bindings: Just add "result_pool" to the list of
> variables in the %apply statement. The "scratch_pool" should not be
> added to the apply statement, because we don't want the perl bindings
> to associate the returned variables with the scratch_pool. It would
> look like this:
>
> #if def SWIGPERL
> %apply apr_pool_t *pool {
> apr_pool_t *dir_pool,
> apr_pool_t *file_pool,
> apr_pool_t *node_pool,
> apr_pool_t *result_pool
> };
> #endif
>
> #if def SWIGRUBY
> %apply apr_pool_t *pool {
> apr_pool_t *dir_pool,
> apr_pool_t *file_pool,
> apr_pool_t *node_pool,
> apr_pool_t *result_pool
> };
> #endif
OK that's easy to do.
> Python bindings: Create a specialized typedef for scratch_pool, but
Do you mean typemap instead of typedef?
> leave result_pool alone so that it will be caught by the existing
> wrapper for apr_pool_t *. In this case, the important part about
> wrapping scratch_pool separately is that we make sure that the
> existing wrapper for apr_pool_t * does not grab the scratch pool and
> think that it is being used to store variables. We would also want to
> write a test case to make sure that the returned variables are
> associated with the right pool.
Can you explain this in more detail? Where is the pool wrapper defined?
And once I have that, do I just copy that and rename pool to scratch_pool?
It seems like quite a bit of domain knowledge is required to
work with this stuff :(
Stefan
Received on 2009-07-02 16:10:13 CEST