matplotlib-devel Mailing List for matplotlib (Page 2)

On 4/10/07, John Hunter <jd...@gm...> wrote:
> On 4/9/07, Tim Leslie <tim...@gm...> wrote:
>
> >
> > The other is a speedup, normalising an entire array at once, rather
> > than element by element, speeding up the attached script by a factor
> > of 6x (and upgrading my actual application from 'too slow' to 'quite
> > reasonable' :-)
>
> Thanks Tim, I just committed this. I see that my sinister plan of
> releasing the 3d stuff w/o support in hopes of reeling in contributers
> is starting to work....
>
> <laughs maniacally>
Here's another patch. This one cleans up the line2d_seg_dist function
and also speeds it up by a factor of ~2.
Cheers,
Tim
>

Hi all,
I'm having trouble getting an MPL 0.90.0 working with wxPython 2.8 on OS-X.
Does anyone know what the egg on the sourceforge site is built with?
Is that documented somewhere?
As I understand it, Ken made some changes for wxPython 2.8 in svn, but I 
don't see any mention of them in the 0.90.0 CHANGELOG, so it looks like 
they haven't made it into the distribution yet. darn.
oh well, off to set things up to compile.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 4/10/07, John Hunter <jd...@gm...> wrote:
> On 4/9/07, Tim Leslie <tim...@gm...> wrote:
>
> >
> > The other is a speedup, normalising an entire array at once, rather
> > than element by element, speeding up the attached script by a factor
> > of 6x (and upgrading my actual application from 'too slow' to 'quite
> > reasonable' :-)
>
> Thanks Tim, I just committed this. I see that my sinister plan of
> releasing the 3d stuff w/o support in hopes of reeling in contributers
> is starting to work....
Well I've got a bit of work to do which involves 3D stuff in the
coming week or so, so if I run up against anything else I'll keep the
patches coming. Thanks for the quick commit.
Cheers,
Tim
>
> <laughs maniacally>
>

On 4/9/07, Tim Leslie <tim...@gm...> wrote:
>
> The other is a speedup, normalising an entire array at once, rather
> than element by element, speeding up the attached script by a factor
> of 6x (and upgrading my actual application from 'too slow' to 'quite
> reasonable' :-)
Thanks Tim, I just committed this. I see that my sinister plan of
releasing the 3d stuff w/o support in hopes of reeling in contributers
is starting to work....
<laughs maniacally>

Hi All,
I've attached a patch which addresses two small issues. The first is a
bug in patches.py. When doing 3d scatter plots
xs, ys = zip(*self.xy) (line 480)
crashes, as the right hand side expands to 3 values.
The other is a speedup, normalising an entire array at once, rather
than element by element, speeding up the attached script by a factor
of 6x (and upgrading my actual application from 'too slow' to 'quite
reasonable' :-)
Cheers,
Tim

On Monday 09 April 2007 07:40:35 am Jouni K. Sepp=E4nen wrote:
> I just committed the beginnings of draw_tex for the pdf backend, which
> uses the dvi reader in the new file dviread.py. This is all in a very
> rudimentary stage, but I'm committing now since I won't likely have
> much time to work on this in the near future. In the meantime, if
> anyone's interested in developing it further, take a look at
> backend_pdf.py for caveats and how to enable it.
>
> The following script produces the attached output; note that the
> \alpha is broken (must be some encoding issues) but the underscore
> command \_ works, unlike in plain mathtext.
>
> #!/usr/bin/env python
> import matplotlib
> matplotlib.use('PDF')
> from pylab import *
> rc('text', usetex=3DTrue)
> rc('font', serif=3D'Computer Modern Roman', size=3D10)
> subplot(111)
> setp(gca(), xticks=3D[], yticks=3D[])
> text(0.5, 0.5, r'$f(x)=3D\alpha\_1$', fontsize=3D10)
> savefig('foobar.pdf')
This looks like a great start, Jouni. At least three times in the past, I h=
ave=20
tried to get started on writing a dvi parser for exactly this purpose, and =
I=20
never could make any real progress on it in the amount of time I had=20
available. Plus, I was in over my head and had to relearn a lot each time I=
=20
started over. I'm really impressed with what you have done. Nice work!
Darren

I just committed the beginnings of draw_tex for the pdf backend, which
uses the dvi reader in the new file dviread.py. This is all in a very
rudimentary stage, but I'm committing now since I won't likely have
much time to work on this in the near future. In the meantime, if
anyone's interested in developing it further, take a look at
backend_pdf.py for caveats and how to enable it.
The following script produces the attached output; note that the
\alpha is broken (must be some encoding issues) but the underscore
command \_ works, unlike in plain mathtext.
#!/usr/bin/env python
import matplotlib
matplotlib.use('PDF')
from pylab import *
rc('text', usetex=True)
rc('font', serif='Computer Modern Roman', size=10)
subplot(111)
setp(gca(), xticks=[], yticks=[])
text(0.5, 0.5, r'$f(x)=\alpha\_1$', fontsize=10)
savefig('foobar.pdf')
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

There have been some complaints about leaking FT2Font objects: it
seems that if you make too many plots, mpl crashes because it has
opened the same font files too many times. I think this is a symptom
of the same GUI memory leaks that have been discussed earlier.
Inspired by http://www.python.org/~jeremy/weblog/030410.html, I wrote
a script that lists what kind of objects are leaking. You need a
debugging build of Python to use it, and have to compile all
extensions for the debugging build. To call the script, give the
backend on the command line, as in "python whatsleaking.py Agg". 
Here is the output for Agg:
--- 0
--- 1
{<type 'str'>: 1, <type 'dict'>: 1, <type 'int'>: 24}
--- 2
{<type 'dict'>: 1, <type 'int'>: 24}
--- 3
{}
--- 4
{}
--- 5
{}
--- 6
{}
--- 7
{}
--- 8
{}
--- 9
{}
On round 0 there is never any output, but the script memorizes how
many objects of each type exist. On round 1 there is one more string,
one more dict, and 24 more ints. On round 2, in addition to these,
there is one more dict and 24 more ints. Thereafter the numbers stay
constant so there is no output. (There is also some code for chasing
references to FT2Font objects, but it's commented out.)
So pure Agg is not leaking. The output for TkAgg is different:
--- 0
--- 1
{<type 'set'>: 3, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'function'>: 1, <type 'str'>: 253, <type 'dict'>: 395, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 38, <type 'instance'>: 204, <type 'RendererAgg'>: 1, <type 'float'>: 192, <type 'tkapp'>: 1, <type 'Func'>: 10}
--- 2
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 395, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 39, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 3
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 15, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 4
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 14, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 5
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 13, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 6
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 13, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 7
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 14, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 8
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 14, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
--- 9
{<type 'Func'>: 10, <type 'cell'>: 1, <type 'builtin_function_or_method'>: 12, <type 'Point'>: 216, <type 'numpy.ndarray'>: 416, <type 'instancemethod'>: 4, <type 'Affine'>: 75, <type 'Bbox'>: 108, <type 'set'>: 3, <type 'Interval'>: 16, <type 'tuple'>: 208, <type 'numpy.float64'>: 12, <type 'list'>: 112, <type 'dict'>: 394, <type 'str'>: 253, <class 'matplotlib.cbook.maxdict'>: 34, <type 'BinOp'>: 331, <type 'int'>: 14, <type 'RendererAgg'>: 1, <type 'function'>: 1, <type 'instance'>: 204, <type 'float'>: 192, <type 'tkapp'>: 1}
I'm not a GUI person, but it seems suspicious to me that a tkapp is
created on every round. Maybe that's a useful clue?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

>
> > 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
>
Thanks a lot for the update, I appreciate the patience you had to understand
what I wanted.
Matthieu

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

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