You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2003/02/28 14:45:26 UTC
Re: svn commit: rev 5143 - trunk/subversion/bindings/swig
gstein@tigris.org writes:
> Log:
> Fix the string typemaps and fix svn_fs_commit_txn.
Thanks, Greg!
Question: does this portion
> --- trunk/subversion/bindings/swig/svn_fs.i (original)
> +++ trunk/subversion/bindings/swig/svn_fs.i Thu Feb 27 19:44:45 2003
> @@ -120,6 +122,22 @@
> $result = t_output_helper(
> $result,
> svn_swig_py_convert_hash(*$1, SWIGTYPE_p_svn_fs_path_change_t));
> +}
> +
> +/* -----------------------------------------------------------------------
> + Fix the return value for svn_fs_commit_txn(). If the conflict result is
> + NULL, then t_output_helper() is passed Py_None, but that goofs up
> + because that is *also* the marker for "I haven't started assembling a
> + multi-valued return yet" which means the second return value (new_rev)
> + will not cause a 2-tuple to be manufactured.
> +
> + The answer is to explicitly create a 2-tuple return value.
> +*/
> +%typemap(python, argout) (const char **conflict_p, svn_revnum_t *new_rev) {
> + /* this is always Py_None */
> + Py_DECREF($result);
> + /* build the result tuple */
> + $result = Py_BuildValue("zi", *$1, (long)*$2);
> }
... imply that we'll need to make a similar special-case for any other
Subversion function that returns multiple output parameters, where the
first one could return NULL by reference?
Obviously your change is a big improvement over the previous
workaround, no argument there :-). I'm just thinking there's still a
bug in SWIG itself (in t_output_helper), would you concur?
If so, I might spend an hour working up a patch for SWIG, unless
there's some deep theoretical reason why None has to mean what it
currently does in t_output_helper().
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5143 - trunk/subversion/bindings/swig
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Heh... Ignore this, I see you guys are waaaaay ahead of me in this
discussion already :-) :
Karl Fogel <kf...@newton.ch.collab.net> writes:
> ... imply that we'll need to make a similar special-case for any other
> Subversion function that returns multiple output parameters, where the
> first one could return NULL by reference?
>
> Obviously your change is a big improvement over the previous
> workaround, no argument there :-). I'm just thinking there's still a
> bug in SWIG itself (in t_output_helper), would you concur?
>
> If so, I might spend an hour working up a patch for SWIG, unless
> there's some deep theoretical reason why None has to mean what it
> currently does in t_output_helper().
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5143 - trunk/subversion/bindings/swig
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 28, 2003 at 08:45:26AM -0600, Karl Fogel wrote:
> gstein@tigris.org writes:
>...
> > +%typemap(python, argout) (const char **conflict_p, svn_revnum_t *new_rev) {
> > + /* this is always Py_None */
> > + Py_DECREF($result);
> > + /* build the result tuple */
> > + $result = Py_BuildValue("zi", *$1, (long)*$2);
> > }
>
> ... imply that we'll need to make a similar special-case for any other
> Subversion function that returns multiple output parameters, where the
> first one could return NULL by reference?
Well, technically it is where the type mapping results in Py_None for the
first value in a multi-valued return. NULL pointers map to that, but we
could envision others.
In any case... yes, the same problem could occur elsewhere. I'm not sure how
many of those exist.
> Obviously your change is a big improvement over the previous
> workaround, no argument there :-). I'm just thinking there's still a
> bug in SWIG itself (in t_output_helper), would you concur?
Yup, as I similarly explained in another email to Marshall.
> If so, I might spend an hour working up a patch for SWIG, unless
> there's some deep theoretical reason why None has to mean what it
> currently does in t_output_helper().
Right now, SWIG initializes the result to Py_None so that you have something
to return. You could probably initialize that to NULL to indicate nothing so
far, and a t_output_helper replacement would differentiate between NULL and
"already got a return value".
But at the point that "return resultobj;" is performed, you'd need to do
something like:
if (resultobj)
return resultobj;
Py_INCREF(Py_None);
return Py_None;
I bet SWIG has a way to alter the return processing, but I don't know it off
the top of my head. I also hope there is a way to alter that initial value
for the result object. In the worst case, those might be hard-coded into the
SWIG Python "language" mechanism, which would then require a patch to SWIG.
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