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

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

On 2013-10-18 09:30-0700 Alan W. Irwin wrote:

> On 2013-10-18 01:03-0700 Alan W. Irwin wrote:
>
>> On 2013-10-18 07:07-0000 Arjen Markus wrote:
>>> I removed the #define NPY_NO_DEPRECATED_API ... line from
>> plplotcmodule.i, even though this has been in there for a long time,
>> and that helped a bit: the complaints about PyArray_FLOAT are gone.
>>
>> You will probably want to restore
>>
>> #define NPY_NO_DEPRECATED_API    NPY_1_7_API_VERSION
>>
>> later once you figure everything out for the MSVC case. See
>> http://docs.scipy.org/doc/numpy-dev/reference/c-api.deprecations.html
>> for why we will want that #define in place.
>
> I have looked a bit more at this. That #define was put in by Andrew in
> revision 12340 in May this year as part of his large numeric removal
> and accompanying numpy fixup change.  So it is not that old a change.
>> From his commit message it helped insure the code was clean (no
> compiler warnings) when compiled with numpy version 1.7, but, of
> course, that would only be a check of the part of our Python/numpy
> interface that is used in the Linux case, and from your experiences
> there appear to be other bits left for the Windows case that are not
> yet clean for numpy 1.7.  For my previous tests of Python/numpy on my
> Debian wheezy platform, numpy is version 1.6.1, and for the
> MinGW/MSYS/Wine platform I chose to use numpy-1.5 so I have
> effectively bypassed all numpy API checks on both Linux and
> MinGW/MSYS/Wine. But when I move to numpy-1.7 for my python/numpy
> tests on MinGW/MSYS wine (hopefully later today) I anticipate I will
> run into the same warnings you encountered about code not being
> numpy-1.7 clean.  With luck I should be able to fix all of those and
> as a result we should be clean against numpy-1.7 API in the Windows case.

I did install python-2.7.5 and numpy-1.7.1, and immediately
encountered the PyArray_FLOAT build errors Arjen encountered.  I created
a proper fix for those as of revision 12606.  That allowed me to do a
full test of MinGW/MSYS/Wine.  The Python diff summary was the same as
I got before:

python
   Missing examples            :
   Differing postscript output :  00 03 04 05 06 08 09 11 12 14 14a 15 16 17 18 19 20 21 22 23 25 26 27 29 33
   Missing stdout              :
   Differing stdout            :  23

However, when I looked in detail at those results before and now, they
mostly consist of small rounding errors.  The exceptions in the
previous test were the major differences for 17, 19, 20, 22, and 25,
but for this test example 19 has improved to just a few minor
differences. That substantial improvement in example 19 was the result
of an actual precision bug fix for the mapform case that occurred as
part of revision 12606.

But I am still completely stumped as to why 32-bit python still has the
major differences for the four remaining "bad" examples, and minor
differences for many of the rest of the examples when all other
languages I have tested on Wine produce perfectly clean results.

So the next step in trying to figure out the cause of these problems
should be to do some additional platform checks for 32-bit Python.
Arjen is moving ahead with those for both the MinGW/MSYS and MSVC
Microsoft Windows cases, and I am hoping Andrew will be able to check
the 32-bit Python case on Linux.

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
__________________________