Re: [Plplot-devel] Problem builiding the Python bindings on Windows using MS VC/C++

[Alan W. I. <ir...@be...>]

On 2013-10-21 22:34+0100 Andrew Ross wrote:

>
> I now understand why the code is different. The typemap for mapform_func
> mapform has a default clause which controls what happens if the argument is
> omitted. It seems that once swig has encountered an optional argument all
> subsequent arguments are also counted as optional so are wrapped with an if
> statement. The subsquent arguments do not have a default value though, hence
> the uninitialized variable warning. If the function is correctly called then
> the variables _will_ be defined, but if not then it would cause an error.
>
> To see this just comment out the lines
>
> // you can omit the mapform func
> %typemap( default ) mapform_func mapform {
>    python_mapform = 0;
>    $1             = NULL;
> }
>
> in plplotcmodule.i and all will compile without warnings. It seems that plmap
> and plmeridian are the only functions where one of these callback functions is
> used early on in the option list before other more standard options.
>
> I'm not sure quite what the best way of fixing this is. It seems like a swig
> "feature". One could probably work round by including a default statement for
> every typemap, but we don't particularly want to do that. Ideas Alan?

I had no further ideas at all before you asked that, but I got a bit
more inspiration from reading the swig-2.0 documentation.

That documentation of default typemaps says the following:

<quote>
10.5.5 "default" typemap
  The "default" typemap is used to turn an argument into a default
argument. For example:
%typemap(default) int flags {
    $1 = DEFAULT_FLAGS;
    }
    ...
    int foo(int x, int y, int flags);

     The primary use of this typemap is to either change the wrapping
of default arguments or specify a default argument in a language where
they aren't supported (like C). Target languages that do not support
optional arguments, such as Java and C#, effectively ignore the value
specified by this typemap as all arguments must be given.
  Once a default typemap has been applied to an argument, all arguments
that follow must have default values. See the  Default/optional
arguments section for further information on default argument wrapping.
</quote>

That last paragraph explains why we are getting peculiar behaviour for
all other arguments of plmap and plmeridians.  Those additional
arguments are all PLFLT for plmeridians and char* and PLFLT for plmap.
So I think you might be able to fix that by changing those additional
arguments to unique names and defining ordinary and default typemaps
for those unique names that works just like the nondefault PLFLT we
use everywhere else (i.e., Python throws an error if the user omits
the argument).

I also followed the default/optional arguments link in the above
documentation which might yield another possibility of dealing with
this issue.  For example, what happens if you change
bindings/swig-support/plplotcapi.i so plmeridians is treated like this:

plmeridians( mapform_func mapform,
              PLFLT dlong, PLFLT dlat,
              PLFLT minlong, PLFLT maxlong, PLFLT minlat, PLFLT maxlat );


#ifdef SWIG_PYTHON
plmeridians( mapform_func mapform=NULL,
              PLFLT dlong, PLFLT dlat,
              PLFLT minlong, PLFLT maxlong, PLFLT minlat, PLFLT maxlat );
#endif

and the default typemap is removed for mapform_func mapform?  That
documentation implies NULL will be propagated to the C call (which is
what we want), but I am not sure how the swig-generated python
interface will distinguish between when a user specifies a mapform
argument or not and whether the above logic for
bindings/swig-support/plplotcapi.i should be changed so that plmeridians
only has one definition for python (or any other language).

Anyhow, I hope I have given you some more food for thought.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________