On Sat, Aug 31, 2002 at 07:39:44PM -0400, Daniel Berlin wrote:
> On Sat, 31 Aug 2002, Greg Stein wrote:
>...
> > Using obj9 directly was the idea that I had in mind, actually :-) That's
> > why I said it was fragile. If SWIG changed how it generated code, then it
> > would break (and I've already seen changes in the generated output, in the
> > past, which would have broken this kind of construct).
>
> Um, IIRC, when i tried this, it placed the initialization of obj9 (it was
> obj6 in the function i was looking at) after the call we needed it for.
> IE it didn't work.
Hmm. Seems like there would have to be some slot to hook it in... oh well.
>...
> > Right. I'm not entirely sure what that change would be, nor did I really
> > understand what Dan wrote. I imagine something along the lines of enabling
> > parameters to the typemaps. You could then define one typemap to invoke the
> > other pameterized-typemap (e.g. pass the name of the pool arg).
>
> This isn't as hard as one would think.
Cool. I know a bit about SWIG, but obviously you're the local pro :-)
> It should only require modifying cwrap.c and typemap.c
>
> You should just be able to change Swig_typemap_apply to merge the param
> attribute, then in Swig_cargs (which outputs the argument handling), set
> the value.
>
> It actually already does something like this for reference parameters,
> setting a default value.
>
> The parameters you pass to a typemap are just set as attributes, so you
> don't need to do anything special to pass a new parameter to a typemap.
>
> I'll work up a patch in a moment.
Cool! I bet if it's clean, we can wrangle Beazley to add it. Or at least use
it as a demonstration of our particular problem, and have him ponder on a
"SWIGgish solution" if he doesn't like yours.
So then the question would become how to tackle the problem? Apply my patch
for now, then rip it back out when we get a new SWIG? Is there a middle
ground to avoid the add/rip while waiting on a new 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
Received on Sun Sep 1 02:26:11 2002