matplotlib-devel Mailing List for matplotlib

On 4/6/07, Eric Firing <ef...@ha...> wrote:
> I have fixed this in two ways: by raising an exception in _image.cpp if
> the input to frombyte lacks 3 dimensions--this prevents the
> segfault--and by checking uint8 arrays for 3 dimensions in image.py
> before sending them to frombyte in the first place.
>
> The problem cropped up recently because of another change I made.
> cm.ScalarMappable.set_array had been making all float arrays float32,
> and all int arrays int16. This was causing problems with int32 arrays,
> of course, and I could not figure out any reason why it was needed, so
> I eliminated it. (I think I put that conversion in in the first place a
> long time ago; presumably I had a reason, and I hope I am correct that
> if it ever was necessary, it no longer is. The backend_driver tests are
> happy with the present state of affairs.)
Many thanks, Eric. Greatly appreciated.
Not only does the toy code work, but the real codes where I originally
got the segfaults are working fine as well, so what ever you did was
good.
Regards,
f

Fernando Perez wrote:
> Hi all,
> 
> 
> I'm getting:
> 
> planck[examples]> python pylab_segfault.py
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> 
> 
> with this trivial code
> 
> planck[examples]> cat pylab_segfault.py
> import sys
> import numpy as N
> import pylab as P
> 
> print "Numpy version:",N.__version__
> sys.stdout.flush()
> 
> P.imshow(N.ones((4,4),dtype=N.uint8))
> P.show()
> 
> # EOF
I have fixed this in two ways: by raising an exception in _image.cpp if 
the input to frombyte lacks 3 dimensions--this prevents the 
segfault--and by checking uint8 arrays for 3 dimensions in image.py 
before sending them to frombyte in the first place.
The problem cropped up recently because of another change I made. 
cm.ScalarMappable.set_array had been making all float arrays float32, 
and all int arrays int16. This was causing problems with int32 arrays, 
 of course, and I could not figure out any reason why it was needed, so 
I eliminated it. (I think I put that conversion in in the first place a 
long time ago; presumably I had a reason, and I hope I am correct that 
if it ever was necessary, it no longer is. The backend_driver tests are 
happy with the present state of affairs.)
Eric
> 
> Is anyone else seeing this? My matplotlib build is SVN:
> 
> planck[scipy]> svn info matplotlib/
> Path: matplotlib
> URL: https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
> Repository Root: https://svn.sourceforge.net/svnroot/matplotlib
> Repository UUID: f61c4167-ca0d-0410-bb4a-bb21726e55ed
> Revision: 3141
> Node Kind: directory
> Schedule: normal
> Last Changed Author: efiring
> Last Changed Rev: 3141
> Last Changed Date: 2007年04月01日 18:19:08 -0600 (2007年4月01日)
> Properties Last Updated: 2006年07月08日 22:39:32 -0600 (2006年7月08日)
> 
> 
> And I get the above error with all GUI backends I've tested so far
> (Tk, GTK, Qt and WX).
> 
> 
> planck[examples]> python pylab_segfault.py -dWXAgg
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dTkAgg
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dQtAgg
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dGTKAgg
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dGTK
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dQt
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> planck[examples]> python pylab_segfault.py -dTk
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> 
> 
> The TkAgg and the GTKAgg get as far as making the pylab window, but
> then they crash.
> 
> I should add that this same example ran fine for me about a week ago;
> I can try to track down the exact versions of numpy and matplotlib I
> was using at the time, but if someone has a fix for this, it would be
> enormously appreciated.
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>
> This is done (with corresponding simplification of the code and improved
> error checking and reporting), and I have made slight changes to
> scatter, but there is still an ambiguity in scatter's argument handling.
> It was and is resolved in favor of treating the c argument as an array
> rather than an rgb or rgba sequence in any case where it could be
> either. (To be safe, if you want c to be an mpl color, use a string
> form of colorspec as specified in the scatter docstring.) I don't know
> whether this ambiguity, or possibly a bug in its resolution, was what
> prompted your original message. In any case, please try the svn version
> and see if it does what you want. If it does not, then please say
> exactly what c you are passing in to scatter, what scatter is doing, and
> what you think it should do instead. I never understood that from your
> previous messages.
>
> Eric
>
Thanks for the update, I'll try it tuesday from work, but I don't think it
will change anything. I'll post some pictures/data if you want.
What I'm passing as argument for c is a numpy array of dimension (N, 3) with
floats between 0 and 1. When I get rid of the check at line 3777, I can have
a good scatter plot with the correct colors.
This is why I proposed to check that the argument was string like or num
like, because my argument for c is not string-like.
One question that may arise is why do I use such colors and not mpl colors.
The doc says that I can have color given by a tuple. In fact, the code can
handle color in an array, and as the colors for each point in the scatter
plot is generated by the coordinates of the point, the colors are stored in
a numpy array. I do not want to transform them into strings or tuples if the
code can handle numpy arrays. And it is more simple to officially allow the
use of such color array for an average user.
I hope you understand my point a little better now :|
Matthieu

On 4/6/07, Eric Firing <ef...@ha...> wrote:
> OK, but I don't have any record of Nick Young's email address--if
> someone knows it, please send it to me.
I found this in my gmail archive:
Nicholas Young <mat...@su...>
Cheers,
f

Fernando Perez wrote:
> Hi Eric,
> 
>> Unless I hear shortly that someone else is already fixing this, or that
>> I am misdiagnosing the problem, I will proceed. It may be that checking
>> for 3-D needs to be done earlier in the mpl python code as well, but it
>> certainly seems like it should be done here.
> 
> I was just on the phone with John when your email came, he has no
> computer access right now.
> 
> He says to go ahead, his only comment is that you might want to CC
> Nick Young, who's the only other person likely to have worked on this
> particular part of the code recently.
OK, but I don't have any record of Nick Young's email address--if 
someone knows it, please send it to me.
Thanks.
Eric

Hi Eric,
> Unless I hear shortly that someone else is already fixing this, or that
> I am misdiagnosing the problem, I will proceed. It may be that checking
> for 3-D needs to be done earlier in the mpl python code as well, but it
> certainly seems like it should be done here.
I was just on the phone with John when your email came, he has no
computer access right now.
He says to go ahead, his only comment is that you might want to CC
Nick Young, who's the only other person likely to have worked on this
particular part of the code recently.
Many thanks!
f

Fernando Perez wrote:
> On 4/6/07, Darren Dale <dd...@co...> wrote:
>> On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:
>>> import sys
>>> import numpy as N
>>> import pylab as P
>>>
>>> print "Numpy version:",N.__version__
>>> sys.stdout.flush()
>>>
>>> P.imshow(N.ones((4,4),dtype=N.uint8))
>>> P.show()
>> Yep, I also see it, with svn 3163. It looks like the problem is only with the
>> uint8 data type, I cant reproduce it with any other types.
char _image_module_frombyte__doc__[] =
"frombyte(A, isoutput)\n"
"\n"
"Load the image from a byte array.\n"
"By default this function fills the input buffer, which can subsequently\n"
"be resampled using resize. If isoutput=1, fill the output buffer.\n"
"This is used to support raw pixel images w/o resampling."
;
Py::Object
_image_module::frombyte(const Py::Tuple& args) {
 _VERBOSE("_image_module::frombyte");
 args.verify_length(2);
 Py::Object x = args[0];
 int isoutput = Py::Int(args[1]);
 PyArrayObject *A = (PyArrayObject *) 
PyArray_ContiguousFromObject(x.ptr(), PyArray_UBYTE, 3, 3);
 if (A->dimensions[2]<3 || A->dimensions[2]>4)
 throw Py::ValueError("Array dimension 3 must have size 3 or 4");
It looks to me like the return from PyArray_ContiguousFromObject needs 
to be checked, and an exception thrown if necessary.
Unless I hear shortly that someone else is already fixing this, or that 
I am misdiagnosing the problem, I will proceed. It may be that checking 
for 3-D needs to be done earlier in the mpl python code as well, but it 
certainly seems like it should be done here.
Eric

Fernando Perez wrote:
> On 4/6/07, Darren Dale <dd...@co...> wrote:
>> On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:
>>> import sys
>>> import numpy as N
>>> import pylab as P
>>>
>>> print "Numpy version:",N.__version__
>>> sys.stdout.flush()
>>>
>>> P.imshow(N.ones((4,4),dtype=N.uint8))
>>> P.show()
>> Yep, I also see it, with svn 3163. It looks like the problem is only with the
>> uint8 data type, I cant reproduce it with any other types.
>
uint8 is treated very differently from anything else:
 def set_data(self, A, shape=None):
 """
 Set the image array
 ACCEPTS: numeric/numarray/PIL Image A"""
 # check if data is PIL Image without importing Image
 if hasattr(A,'getpixel'): X = pil_to_array(A)
 else: X = ma.asarray(A) # assume array
 if (typecode(X) != UInt8
 or len(X.shape) != 3
 or X.shape[2] > 4
 or X.shape[2] < 3):
 cm.ScalarMappable.set_array(self, X)
 else:
 self._A = X
 self._imcache =None
and
 def make_image(self, magnification=1.0):
 if self._A is None:
 raise RuntimeError('You must first set the image array or 
the image attribute')
 if self._imcache is None:
 if typecode(self._A) == UInt8:
 im = _image.frombyte(self._A, 0)
 im.is_grayscale = False
 else:
so presumably _image.frombyte is what is choking. It looks like you 
want colormapping, but that uint8 is serving as a flag incorrectly 
indicating that you are passing in some special pre-made image type instead.
Eric
> Yup. I'm trying to work around the crash in the original code by
> recasting to some other type, but no luck so far...
> 
> John: my build scripts always do a full clean, so I'm pretty sure that
> it's not picking up stray extensions. They remove all traces of the
> previous build as well as the currently installed code...
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Matthieu Brucher wrote:
> I don't quite understand: what kind of "c" are you passing in, what is
> the original code doing with it, and what should it do with it? (I find
> both the original and the suggested code hard to understand, which makes
> me think that neither is actually what we want.)
> 
> 
> 
> c is a named argument of the scatter method for the colors, but it is 
> modified to get the real "colors" argument.
> 
> 
> I think that what we want may be the following:
> 
> try:
> colors = colorConverter.to_rgba_list(c, alpha)
> except TypeError:
> colors = None # generate colors later by applying a colormap to c
> 
> Part of what makes all this hard to understand is that in the None
> case,
> colors are generated from c far down in the code, out of sight of this
> initial processing. Hence the comment.
Now I don't think that the above is what we really want; see below.
> 
> OK, now I see that what I proposed won't work until I rip out the
> long-deprecated float-as-grey option. Looks like a good time for me to
> do it.
This is done (with corresponding simplification of the code and improved 
error checking and reporting), and I have made slight changes to 
scatter, but there is still an ambiguity in scatter's argument handling. 
 It was and is resolved in favor of treating the c argument as an array 
rather than an rgb or rgba sequence in any case where it could be 
either. (To be safe, if you want c to be an mpl color, use a string 
form of colorspec as specified in the scatter docstring.) I don't know 
whether this ambiguity, or possibly a bug in its resolution, was what 
prompted your original message. In any case, please try the svn version 
and see if it does what you want. If it does not, then please say 
exactly what c you are passing in to scatter, what scatter is doing, and 
what you think it should do instead. I never understood that from your 
previous messages.
Eric

On 4/6/07, Darren Dale <dd...@co...> wrote:
> On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:
> > import sys
> > import numpy as N
> > import pylab as P
> >
> > print "Numpy version:",N.__version__
> > sys.stdout.flush()
> >
> > P.imshow(N.ones((4,4),dtype=N.uint8))
> > P.show()
>
> Yep, I also see it, with svn 3163. It looks like the problem is only with the
> uint8 data type, I cant reproduce it with any other types.
Yup. I'm trying to work around the crash in the original code by
recasting to some other type, but no luck so far...
John: my build scripts always do a full clean, so I'm pretty sure that
it's not picking up stray extensions. They remove all traces of the
previous build as well as the currently installed code...
Cheers,
f

On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:
> import sys
> import numpy as N
> import pylab as P
>
> print "Numpy version:",N.__version__
> sys.stdout.flush()
>
> P.imshow(N.ones((4,4),dtype=N.uint8))
> P.show()
Yep, I also see it, with svn 3163. It looks like the problem is only with the 
uint8 data type, I cant reproduce it with any other types.
Darren

On 4/6/07, Fernando Perez <fpe...@gm...> wrote:
> planck[examples]> python pylab_segfault.py
> Numpy version: 1.0.3.dev3651
> Segmentation fault (core dumped)
> sudo rm -rf build
> sudo python setup.py install
let us know....

Hi all,
I'm getting:
planck[examples]> python pylab_segfault.py
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
with this trivial code
planck[examples]> cat pylab_segfault.py
import sys
import numpy as N
import pylab as P
print "Numpy version:",N.__version__
sys.stdout.flush()
P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()
# EOF
Is anyone else seeing this? My matplotlib build is SVN:
planck[scipy]> svn info matplotlib/
Path: matplotlib
URL: https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
Repository Root: https://svn.sourceforge.net/svnroot/matplotlib
Repository UUID: f61c4167-ca0d-0410-bb4a-bb21726e55ed
Revision: 3141
Node Kind: directory
Schedule: normal
Last Changed Author: efiring
Last Changed Rev: 3141
Last Changed Date: 2007年04月01日 18:19:08 -0600 (2007年4月01日)
Properties Last Updated: 2006年07月08日 22:39:32 -0600 (2006年7月08日)
And I get the above error with all GUI backends I've tested so far
(Tk, GTK, Qt and WX).
planck[examples]> python pylab_segfault.py -dWXAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTkAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQtAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTKAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTK
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQt
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTk
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
The TkAgg and the GTKAgg get as far as making the pylab window, but
then they crash.
I should add that this same example ran fine for me about a week ago;
I can try to track down the exact versions of numpy and matplotlib I
was using at the time, but if someone has a fix for this, it would be
enormously appreciated.
Cheers,
f

I just noticed there was a bug report about the pdf backend in the
tracker, but that was just by accident, since the reported had not
sent email to either of the mailing lists. Is there any way of getting
email about new bugs from Sourceforge, or maybe an RSS feed or
something?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Robert Hetland <he...@ta...> writes:
> It appears Circle has lost it's verts attribute, but not all of the 
> references.
Fixed in svn revision 3162 by replacing .verts with .get_verts(). 
However get_verts() indicates that it is "[n]ot actually used for 
rendering", so perhaps this is not the right fix?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 4/5/07, Robert Kern <rob...@gm...> wrote:
> Oh, you're requiring setuptools now? I didn't notice that. Cool.
>
> I'd point them here for up-to-date instructions and downloads:
>
> http://cheeseshop.python.org/pypi/setuptools
Thanks Robert for the insight! I updated the installation
instructions for setuptools in setup.py to point to the link you
mentioned.
Unfortunately, the official docs for setuptools
(http://peak.telecommunity.com/DevCenter/setuptools) point to
downloading ez_setup.py --- nowhere near mentioning it's deprecated.
Still, being able to point users to download one file (ez_setup.py),
and run it to install setuptools on *every* system is very tempting.
Especially, when you can point them to just run:
python ez_setup.py matplotlib
to install the latest version of matplotlib.
Edin

It appears Circle has lost it's verts attribute, but not all of the 
references.
-r
PyMate r6190 running Python 2.5 (/usr/bin/env python)
 >>> picker_demo.py
Exception in Tkinter callback
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/lib-tk/Tkinter.py", line 1403, in __call__
 return self.func(*args)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_tkagg.py", line 
151, in resize
 self.show()
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_tkagg.py", line 
154, in draw
 FigureCanvasAgg.draw(self)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_agg.py", line 
392, in draw
 self.figure.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/figure.py", line 574, in draw
 for a in self.axes: a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/axes.py", line 1281, in draw
 a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/patches.py", line 764, in draw
 tverts = self.get_transform().seq_xy_tups(self.verts) # center 
is first vert
AttributeError: Circle instance has no attribute 'verts'
-----
Rob Hetland, Associate Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Robert Kern wrote:
> Oh, you're requiring setuptools now? I didn't notice that. Cool.
> 
Just for Python 2.3 so that we could sanitize the setup.py a little.
(Namely for the backport of the package_data field to setup().) It's not
required for Python >= 2.4 since package_data is already in stock
distutils there.