matplotlib-devel Mailing List for matplotlib

On Thu, 2004年06月24日 at 12:41, John Hunter wrote:
> >>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
> 
> 
> Gregory> Bingo, this makes a difference : using Numeric, it works
> Gregory> (no crash, can create a plot with TkAgg), but removing
> Gregory> the Numeric matplotlib (keeping Numeric installed), and
> Gregory> reinstalling Numarray one re-introduce the same
> Gregory> crash...Hope this help, looks like it is numarray related
> Gregory> anyway!
> 
> Gregory> Yes, if you have this for windows I would be happy to
> Gregory> test!
> 
> John> OK, when I get one ready I'll post a link.
> 
> Hi Gregory,
> 
> I also built the 0.60b snapshot with numarray (Todd it's enough to set
> the NUMERIX flags in setup.py and setupext.py - no extra link stuff,
> right?)
That's all I've been doing. We're still only good for Python-2.3...
Regards,
Todd

Hi Gregory,
I also built the 0.60b snapshot with numarray (Todd it's enough to set
the NUMERIX flags in setup.py and setupext.py - no extra link stuff,
right?)
It works fine on my platform (winxp, enthought python2.3.3, numarray
0.9). Hope it helps,
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.numarra
y.win32-py2.3.exe
Sorry - still the same bug I am affraid...assertion ob_refcnt == 0
failed on line 1031 of cxx_extensions.cxx. 
Maybe if your debug version is available it is worth running it on my
computer? 
Also, a wild guess but maybe the behavior mentioned by Daniele in user
list is related? He seems to use about the same platform as me: numarray
0.9, python 2.3.4....although on win2000 where I did not observe any
problem (I did not run it for long either, only the time to plot
sin(x)...)
One thing one could also try would be to compile a version without the
assert in the destructor, not sure it will lead to problem but it could
give more information, worth considering if it is easier than providing
a "debug" version?
Best regards,
Greg.

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Bingo, this makes a difference : using Numeric, it works
 Gregory> (no crash, can create a plot with TkAgg), but removing
 Gregory> the Numeric matplotlib (keeping Numeric installed), and
 Gregory> reinstalling Numarray one re-introduce the same
 Gregory> crash...Hope this help, looks like it is numarray related
 Gregory> anyway!
 Gregory> Yes, if you have this for windows I would be happy to
 Gregory> test!
 John> OK, when I get one ready I'll post a link.
Hi Gregory,
I also built the 0.60b snapshot with numarray (Todd it's enough to set
the NUMERIX flags in setup.py and setupext.py - no extra link stuff,
right?)
It works fine on my platform (winxp, enthought python2.3.3, numarray
0.9). Hope it helps,
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.numarray.win32-py2.3.exe
JDH

I have a snapshot of the 0.60 release candidate. Perry and I have
been feverishly exchanging emails about improvements to the image
interface and these have been added to this release. Here are some of
the changes since 0.54.2
 * multiple images per axes with alpha blending - see
 examples/layer_images.py
 * multiple pixel images per figure with figimage. You can specify
 and x,y offset and the image array will be dumped to the figure
 canvas w/o resampling (but with alpha blending of previous images
 you've laid down) - see examples/figimage_demo.py
 * dynamically set rc params with the 'rc' command - see
 examples/customize_rc.py
 * set the color limits and colormap for the current image (and change
 the default colormap) with new commands clim, jet, and gray. More
 colormaps will likely be added in short order.
 * specify the origin of the image (upper or lower) with the 'origin'
 kwarg to image commands. new rc params image.aspect,
 image.interpolation, image.cmap, image.lut, image.origin
 * more minor things in the CHANGELOG
CVS is current for those with ssh checkouts. Otherwise
 sdist: http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.tar.gz
 win32 numeric build:
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.60b.win32-py2.3.exe
Because I want to send this release to the wider python world, and it
has some new features in it, I would appreciate if any and all could
try their favorite scripts and tests on it to discover any bugs.
Thanks!
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Thanks, we have already standardised on Numarray (seems
 Gregory> it will be far more active and supported than Numeric in
 Gregory> the future), so using Numeric can only be a temporary
 Gregory> measure for me...
No worries, there are a few matplotlib developers who also have more
than a passing interest in numarray :-)
Thanks for the clue - not sure what to make of it yet...
JDH

When you uninstalled and reinstalled python, did you remove all traces
of the old python dir after running the uninstaller?
Yes, I removed the directory Python23 and could not see any trace of
python anymore...Does it means there really is no more trace of python?
Well, it's windows, so...;-)
It's strikes me as very odd that the same python + numarray + matplotlib
+ operating system would generate different reference counting behavior.
Can anyone think of a possible explanation for this? 
Not me, could be c++ object destruction called in different order, but
how is it possible using the same executables on the same OS???
Another thing to test - try the numeric and numarray builds of
matplotlib.
Same problem?
Bingo, this makes a difference : using Numeric, it works (no crash, can
create a plot with TkAgg), but removing the Numeric matplotlib (keeping
Numeric installed), and reinstalling Numarray one re-introduce the same
crash...Hope this help, looks like it is numarray related anyway!
 Gregory> Yes, if you have this for windows I would be happy to
 Gregory> test!
OK, when I get one ready I'll post a link.
Thanks, we have already standardised on Numarray (seems it will be far
more active and supported than Numeric in the future), so using Numeric
can only be a temporary measure for me...
Best regards,
Greg.
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> It looks more like it is specific to my laptop, cause
 Gregory> installing exactly the same python, numarray and
 Gregory> matplotlib on another winXP laptop did not showed the
 Gregory> behavior. It will thus be a hard to reproduce bug, cause
 Gregory> I find only one computer exhibiting this behavior for now
 Gregory> (on the other hand, the behavior of this computer is very
 Gregory> reliable: systematic crash all the time, even after
 Gregory> python/nuamrray/matplotlib reinstall ). If I try to
 Gregory> install another version of python on this laptop (python
 Gregory> 2.3.3), it crashes the same...I could try older versions
 Gregory> (2.2.3 for example), but 2.3.X is required for numarray
 Gregory> 0.9 so I should go to older version there also, I prefer
 Gregory> to do it only if you find it usefull...
No, I wouldn't ask you to try python 2.2! I asked about 2.3.3 because
matplotlib has been used by many people on windows with that version
whereas 2.3.4 is comparatively new. Just a shot in the dark really.
When you uninstalled and reinstalled python, did you remove all traces
of the old python dir after running the uninstaller?
It's strikes me as very odd that the same python + numarray +
matplotlib + operating system would generate different reference
counting behavior. Can anyone think of a possible explanation for
this? 
Another thing to test - try the numeric and numarray builds of
matplotlib. Remove C:\Python23\lib\site-packages\matplotlib *and*
C:\Python23\share\matplotlib and then install and test
 * numeric build -=
 http://prdownloads.sourceforge.net/matplotlib/matplotlib-0.54.2.win32-py2.3.exe?download
 
 * remove the dirs above and then try the numarray build
 http://prdownloads.sourceforge.net/matplotlib/matplotlib-0.54.2-numarray0.9.win32-py2.3.exe?download
Same problem?
 Gregory> Yes, if you have this for windows I would be happy to
 Gregory> test!
OK, when I get one ready I'll post a link.
JDH

CXX is the python wrapper generator code used to write most of the C++
python extensions that matplotlib uses. Among other things, it helps
automate reference counting for python objects, but in many cases needs
some assistance from the operator (me). Since I've been actively
working on the reference counts in a number of parts of the code to fix
some memory leaks, there is a good chance that I screwed up somewhere.
Thanks for this explanation, it could thus be related to a hard to
reproduce bug (why hard to reproduce? see below)
There are two things that would be useful to know:
 * Is this specific to python 2.3.4? Is this the same version of
 python on all the machines you tested, or is there a difference
 between the python versions on the machines that crashed and the
 machine that worked? I also tested on Windows XP with no
 problems, using the enthought edition of python.
It looks more like it is specific to my laptop, cause installing exactly
the same python, numarray and matplotlib on another winXP laptop did not
showed the behavior. It will thus be a hard to reproduce bug, cause I
find only one computer exhibiting this behavior for now (on the other
hand, the behavior of this computer is very reliable: systematic crash
all the time, even after python/nuamrray/matplotlib reinstall ). 
If I try to install another version of python on this laptop (python
2.3.3), it crashes the same...I could try older versions (2.2.3 for
example), but 2.3.X is required for numarray 0.9 so I should go to older
version there also, I prefer to do it only if you find it usefull...
 * If instead of importing TkAgg, you simply import Agg, on a machine
 that crashes, do you still get the crash? It would be nice to
 narrow the focus.
Yes, exactly the same crash, and with PS backend also...so it does not
seems related to the backend...
I have done a fair amount of work since 0.54.2 fixing more memory leaks
- there is always a possibility that the problem has already been fixed.
If you can provide the information above, I can send you a debug build
of the current development snapshot that might provide more information.
Basically, it prints each function call to stdout which sometimes help
debug a segfault and other errors.
Yes, if you have this for windows I would be happy to test!
It's me that thanks you for your help!
Best regards,
Greg.

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> I checked on another WinXP computer, and it works on this
 Gregory> one - seems that I have to play the windows re-install
 Gregory> game, or hunt down what the exact differences between
 Gregory> these 2 WinXP computers are :-/... The fact that only
 Gregory> matplotlib exhibit this behavior is strange though, I
 Gregory> checked in the code (hence cc to the devel list) and the
 Gregory> problem is linked to an assert in the destructor of
 Gregory> PythonExtensionBase, checking that the ref counting of
 Gregory> this object is 0 and exiting Python interpreter if it is
 Gregory> not the case...Hum, obviously I do not know the code at
 Gregory> all, but could the problem be linked to a destruction
 Gregory> sequence beeing somewhat different on my computer (for
 Gregory> whatever reasons :-/)? This worry me (in addition to
 Gregory> bother me not beeing able to run matplotlib on my laptop
 Gregory> for the moment ;-) ), cause it may be the sign of
 Gregory> "difficult to solve and reproduce" installation problems
 Gregory> for a package we may use in a distributed software
 Gregory> package in the future... I will keep investigating, but
 Gregory> if there is a developer have any idea about this (like, a
 Gregory> hint about why there is this assert there and what can
 Gregory> cause it to fail), it would be great!
CXX is the python wrapper generator code used to write most of the C++
python extensions that matplotlib uses. Among other things, it helps
automate reference counting for python objects, but in many cases
needs some assistance from the operator (me). Since I've been
actively working on the reference counts in a number of parts of the
code to fix some memory leaks, there is a good chance that I screwed
up somewhere.
There are two things that would be useful to know:
 * Is this specific to python 2.3.4? Is this the same version of
 python on all the machines you tested, or is there a difference
 between the python versions on the machines that crashed and the
 machine that worked? I also tested on Windows XP with no
 problems, using the enthought edition of python.
 * If instead of importing TkAgg, you simply import Agg, on a machine
 that crashes, do you still get the crash? It would be nice to
 narrow the focus.
I have done a fair amount of work since 0.54.2 fixing more memory
leaks - there is always a possibility that the problem has already
been fixed. If you can provide the information above, I can send you
a debug build of the current development snapshot that might provide
more information. Basically, it prints each function call to
stdout which sometimes help debug a segfault and other errors.
Thanks for your help,
JDH

I checked on another WinXP computer, and it works on this one - seems
that I have to play the windows re-install game, or hunt down what the
exact differences between these 2 WinXP computers are :-/... 
The fact that only matplotlib exhibit this behavior is strange though, I
checked in the code (hence cc to the devel list) and the problem is
linked to an assert in the destructor of PythonExtensionBase, checking
that the ref counting of this object is 0 and exiting Python interpreter
if it is not the case...Hum, obviously I do not know the code at all,
but could the problem be linked to a destruction sequence beeing
somewhat different on my computer (for whatever reasons :-/)? 
This worry me (in addition to bother me not beeing able to run
matplotlib on my laptop for the moment ;-) ), cause it may be the sign
of "difficult to solve and reproduce" installation problems for a
package we may use in a distributed software package in the future...
I will keep investigating, but if there is a developer have any idea
about this (like, a hint about why there is this assert there and what
can cause it to fail), it would be great!
Thanks a lot, and congratulation for matplotlib, it looks the most
promising python plotting packages I have found yet! :-)