[matplotlib-devel] Error in circle
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: [EMAIL PROTECTED], w: http://pong.tamu.edu - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better support for setuptools, WAS: building with python-2.3
On 4/5/07, Robert Kern <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Error in circle
Robert Hetland <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to follow the bug tracker?
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] MPL segfault...
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 (Sun, 01 Apr 2007) Properties Last Updated: 2006-07-08 22:39:32 -0600 (Sat, 08 Jul 2006) 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
On 4/6/07, Fernando Perez <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
On 4/6/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scatter behavior for color field
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
Fernando Perez wrote:
> On 4/6/07, Darren Dale <[EMAIL PROTECTED]> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
Fernando Perez wrote:
> On 4/6/07, Darren Dale <[EMAIL PROTECTED]> 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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
On 4/6/07, Eric Firing <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scatter behavior for color field
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
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 (Sun, 01 Apr 2007) > Properties Last Updated: 2006-07-08 22:39:32 -0600 (Sat, 08 Jul 2006) > > > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MPL segfault...
On 4/6/07, Eric Firing <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scatter behavior for color field
Matthieu Brucher wrote: > 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. OK, I thought that might be the case. The behavior you want was not actually supported by scatter--at least it was contrary to the docstring--but it is reasonable, so I have made changes that I think will do what you want. I also changed the docstring to reflect this. Eric - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
