On Sat, 2 Feb 2002, Greg Stein wrote:
> On Sat, Feb 02, 2002 at 07:39:08PM -0500, Daniel Berlin wrote:
> > On Sat, 2 Feb 2002, Daniel Berlin wrote:
> >...
> > > Most of it was fighting swig and various bugs in the version needed (I was
> > > using 1.3.10), that appear to cause it to ignore typemaps with the ignore
> > > keyword (which is really supposed to ignore the argument passed in), and
>
> %ignore foo;
>
> Is used to avoid generating code for a function, or possibly for a type. You
> have to use %typemap(ignore) to ignore parameters.
Yes, i know.
In 1.3.10 only the first %typemap(ignore) it sees does code replacement.
There's a bug in swig's emit.cxx. It'll still ignore the arguments, but
never output the actual code inside the typemap except for the first one.
This of course, results in unitialized values (since it never does the $1
= &temp usually inside)
>
> >...
> > This bug is now fixed in swig 1.3.11 (It was doing exactly as i had
> > thought, which is only output the code for the first ignore typemap it
> > saw, because it would ask for the next default typemap sibling, rather
> > than ignore typemap sibling), which was released today, so the kludges are
> > no longer needed.
>
> I'm not sure that I follow :-) ... I've been working with the CVS version of
> SWIG to try and get past some of the problems. Had to upgrade to 1.3.10 to
> get the two-arg typemaps, but that brought in some problems (1.3.9 is table,
> 1.3.10 is alpha). Glad to hear 1.3.11 was released and fixes some of the
> problems you saw.
Yes, i noticed when i went to go file a bug report.
Of course, the fix wasn't mentioned in the changelog, but diffing the
emit.cxx files from 1.3.10 and 1.3.11 shows it's there.
>
> > I'll post the additions to the bindings necessary to use streams with
> > python file objects (which you need to construct proper deltas from
> > python), and the cvs2svn.py diffs, in a few minutes.
>
> Very cool! I look forward to the patches.
>
> > For kicks, i also made the svn_string* conversions requiring a
> > stringpool work .
>
> The intent here is to eliminate the stringbuf usage from the APIs where
> possible. When that is done, I hope that we don't need a temporary pool at
> all (other than, of course, the pools to pass down into functions).
Okeydokey.
>
> If not, then we may want to think about your approach of passing in tuples.
> However, I'd think in most of the cases where a pool is needed to allocate a
> stringbuf or whatnot, there is already a pool available as another parameter
> which can be used.
Hopefully.
> Cheers,
> -g
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:03 2006