Re: Multiple problems with svn python bindings

On Sat, 2002-08-31 at 14:53, Greg Stein wrote:
> I haven't applied enough thought or investigation to the problem. I'd be
> interested in seeing your hacky version. We might be able to reduce the Hack
> from it :-)

OK, you asked for it. :) I'm attaching a patch that implements the hack
for svn_client_diff. Since it depends on calling internal swig
functions, this approach is very fragile. Not to mention amazingly
wrong-headed.

> > Hardcoding it seems like the simplest approach. It is only three
> > functions, after all.
>
> Yup. It will end up being a little more fragile than an automated approach,
> but I'm not sure that we'll ever be able to truly automate this situation
> (without pushing apr_array_header_t construction up to Python, which is just
> wrong; any sequence ought to be fine)

I'm not sure if would be more fragile. We could just create
svn_client_workarounds.[ch] containing functions like:

svn_error_t *svn_client_diff_foo (PyObject *diff_options_py_object,
                                  ...blah blah blah...,
                                  apr_pool_t *pool)
{
  const apr_array_header_t *diff_options;

  diff_options = svn_swig_py_strings_to_array (diff_options_py_object,
                                               pool);

  return svn_client_diff (diff_options, ...blah blah blah..., pool)
}

Then in svn_client.i we would %include svn_client_workarounds.h and add
stuff like:

%rename(svn_client_diff) svn_client_diff_foo
%typemap(python,in) PyObject *diff_options_py_object {
  $1 = $input
}

In other words, we just pass the PyObject through to the workaround _foo
function unchanged.

I haven't tried this, but it seems like it should work, and it doesn't
even seem like it would be all that fragile. Massive disclaimer: I
looked at the swig docs for the first time late last night, and I don't
really know what the hell is going on. And forgive me if this is
painfully, blindingly obvious to anyone who has thought about swig for
longer than a day.

(Of course, we'd add comments explaining what was going on, pick a
better name than svn_client_diff_foo, etc.)

All of that said, Dan Berlin's proposal for modifying swig is obviously
much cleaner than this... but that would require getting the patch into
swig, having to wait for a new swig release containing the patch, etc.

-JT

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