John Hunter wrote:
Andrew, since you are the original author of the isnan port, could you
patch the branch and the trunk to take care of this?
Done in r6791 and r6792.
Sorry for the trouble.
Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of
<stdint.h>, so I should think this is more portable on sane platforms.
This one of many reasons why I stick to Python...
-Andrew
···
JDH
On Fri, Jan 16, 2009 at 8:07 AM, George <gwg@...685...> wrote:
Hello.
I am terribly sorry. I was mistaken last night. I had the latest Matplotlib
version 0.98.5.2 and I thought the bug was fixed but it hasn't. Let me explain.
In the file MPL_isnan.h line 26 there is a declaration:
typedef long int MPL_Int64
This is fine for Linux 64-bit, but NOT for Windows XP 64-bit! For Windows the
declaration should be:
typedef long long MPL_Int64
This bug has caused me a LOT of late nights and last night was one of them. The
declaration is correct for Linux 64-bit and I guess Matplotlib was developed on
Linux because of this declaration. That is also why I thought the bug was fixed
but this morning I realised that I was looking at the wrong console.
So, in summary. For Matplotlib 0.98.5.2 and Numpy 1.2.1 to work without any
problems. This means compiling and using Numpy and Matplotlib on Windows XP
64-bit using AMD 64-bit compile environment, change line 26 in the file
MPL_isnan.h from long int to long long.\
I also previously suggested switching MKL and ACML etc. but with this change
everything is fine. One can choose any math library and it works.
Writing a small test application using sizeof on different platforms highlights
the problem.
Thanks.
George.
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@...336...
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Thanks Andrew for applying this, and Georg, I forgot to mention in my
last post thanks especially for tracking down this nasty bug. Andrew,
for future reference, when fixing a bug on the branch, it is best to
svnmerge it onto the rather than committing it separately since
subsequent merges will bring it over an confuse the commit log.
Instructions at
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
Thanks again!
JDH
···
On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw <strawman@...36...> wrote:
John Hunter wrote:
Andrew, since you are the original author of the isnan port, could you
patch the branch and the trunk to take care of this?
Done in r6791 and r6792.
Sorry for the trouble.
Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of
<stdint.h>, so I should think this is more portable on sane platforms.
This one of many reasons why I stick to Python...
Hmm, I tried "svnmerge.py avail" from the branch after committing to the
trunk. I see now that I should have committed to the branch first (which
seems an inversion to me). Duly noted for the future, though.
Still working on seamless git-svn and svnmerge.py integration,
Andrew
John Hunter wrote:
···
On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw <strawman@...36...> wrote:
John Hunter wrote:
Andrew, since you are the original author of the isnan port, could you
patch the branch and the trunk to take care of this?
Done in r6791 and r6792.
Sorry for the trouble.
Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of
<stdint.h>, so I should think this is more portable on sane platforms.
This one of many reasons why I stick to Python...
Thanks Andrew for applying this, and Georg, I forgot to mention in my
last post thanks especially for tracking down this nasty bug. Andrew,
for future reference, when fixing a bug on the branch, it is best to
svnmerge it onto the rather than committing it separately since
subsequent merges will bring it over an confuse the commit log.
Instructions at
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
Thanks again!
JDH