matplotlib-devel Mailing List for matplotlib

If I initialize an AxesImage using a np.zeros array and then set the
axes data later to a np.memmap array, I get a RuntimeError when
matplotlib tries to autoscale the image. The errors continue to fill
my console and I'm forced to close the shell. This bug was introduced
when I switched from numpy v1.0.3.1 to the trunk v1.0.5.dev4815
The two hacks to get around this are:
1) Setting any array element to something other than zero fixes the error:
 zdata[0,0] = 1
2) Specify the extent and max/min values when creating the image:
 imgaxes = pylab.imshow(zdata, extent=(0, data_shape[1],
data_shape[0], 0), vmin=0, vmax=1)
Unfortunately, due to the way this errors I'm having a difficult time
debugging it. I'm hoping someone with in-depth knowledge of
masked_arrays will have some insight.
Code and output are below.
Thanks!
Chris
---- script to reproduce the bug ----
import pylab
import numpy as np
def printinfo(imgaxes):
 a = imgaxes.get_array()
 print '\nimgaxes array info:'
 print 'type', type(a)
 print 'shape', a.shape
 print 'dtype', a.dtype
 print 'has _mmap', hasattr(a, '_mmap')
data_type = 'float32'
data_shape = (30, 40)
zdata = np.zeros(data_shape, dtype=data_type)
#zdata[0,0] = 1 # No exception raised if this line is executed
imgaxes = pylab.imshow(zdata)
printinfo(imgaxes)
mmdata = np.memmap('foo.dat', dtype=zdata.dtype, shape=zdata.shape, mode='w+')
imgaxes.set_data(mmdata)
printinfo(imgaxes) # imgaxes array now has a _mmap
pylab.show()
---- version info ----
In [2]: pylab.matplotlib.__version__
Out[2]: '0.91.2'
In [4]: numpy.version.version
Out[4]: '1.0.5.dev4817'
---- error ----
In [26]: run memmap_reassign.py
imgaxes array info:
type <class 'numpy.ma.core.MaskedArray'>
shape (30, 40)
dtype float32
has _mmap False
imgaxes array info:
type <class 'numpy.ma.core.MaskedArray'>
shape (30, 40)
dtype float32
has _mmap True
Exception exceptions.RuntimeError: 'maximum recursion depth exceeded'
in ignored
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (10, 0))
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.pyc
in _onPaint(self, evt)
 1079 self.realize()
 1080 # Render to the bitmap
-> 1081 self.draw(repaint=False)
 1082 # Update the display using a PaintDC
 1083 self.gui_repaint(drawDC=wx.PaintDC(self))
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/backends/backend_wxagg.pyc
in draw(self, repaint)
 59 """
 60 DEBUG_MSG("draw()", 1, self)
---> 61 FigureCanvasAgg.draw(self)
 62
 63 self.bitmap =
_convert_agg_to_wx_bitmap(self.get_renderer(), None)
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.pyc
in draw(self)
 356
 357 self.renderer = self.get_renderer()
--> 358 self.figure.draw(self.renderer)
 359
 360 def get_renderer(self):
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/figure.pyc
in draw(self, renderer)
 622
 623 # render the axes
--> 624 for a in self.axes: a.draw(renderer)
 625
 626 # render the figure text
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/axes.pyc in
draw(self, renderer, inframe)
 1303 mag = renderer.get_image_magnification()
 1304 ims = [(im.make_image(mag),0,0)
-> 1305 for im in self.images if im.get_visible()]
 1306
 1307
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/image.pyc
in make_image(self, magnification)
 129 im.is_grayscale = False
 130 else:
--> 131 x = self.to_rgba(self._A, self._alpha)
 132 im = _image.fromarray(x, 0)
 133 if len(self._A.shape) == 2:
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/cm.pyc in
to_rgba(self, x, alpha, bytes)
 74 x = ma.asarray(x)
 75 x = self.norm(x)
---> 76 x = self.cmap(x, alpha=alpha, bytes=bytes)
 77 return x
 78
/Users/cburns/local/lib/python2.5/site-packages/matplotlib/colors.pyc
in __call__(self, X, alpha, bytes)
 431 vtype = 'array'
 432 xma = ma.asarray(X)
--> 433 xa = xma.filled(0)
 434 mask_bad = ma.getmask(xma)
 435 if xa.dtype.char in npy.typecodes['Float']:
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
filled(self, fill_value)
 1542 m = self._mask
 1543 if m is nomask or not m.any():
-> 1544 return self._data
 1545 #
 1546 if fill_value is None:
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
_get_data(self)
 1472
 1473 """
-> 1474 return self.view(self._baseclass)
 1475 _data = property(fget=_get_data)
 1476 data = property(fget=_get_data)
/Users/cburns/local/lib/python2.5/site-packages/numpy/core/memmap.pyc
in __array_finalize__(self, obj)
 204 self._mmap = obj._mmap
 205 else:
--> 206 raise ValueError, 'Cannot create a memmap from
object %s'%obj
 207 else:
 208 self._mmap = None
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
__str__(self)
 1614 m = self._mask
 1615 if m is nomask:
-> 1616 res = self._data
 1617 else:
 1618 if m.shape == ():
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
_get_data(self)
 1472
 1473 """
-> 1474 return self.view(self._baseclass)
 1475 _data = property(fget=_get_data)
 1476 data = property(fget=_get_data)
/Users/cburns/local/lib/python2.5/site-packages/numpy/core/memmap.pyc
in __array_finalize__(self, obj)
 204 self._mmap = obj._mmap
 205 else:
--> 206 raise ValueError, 'Cannot create a memmap from
object %s'%obj
 207 else:
 208 self._mmap = None
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
__str__(self)
 1614 m = self._mask
 1615 if m is nomask:
-> 1616 res = self._data
 1617 else:
 1618 if m.shape == ():
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
_get_data(self)
 1472
 1473 """
-> 1474 return self.view(self._baseclass)
 1475 _data = property(fget=_get_data)
 1476 data = property(fget=_get_data)
/Users/cburns/local/lib/python2.5/site-packages/numpy/core/memmap.pyc
in __array_finalize__(self, obj)
 204 self._mmap = obj._mmap
 205 else:
--> 206 raise ValueError, 'Cannot create a memmap from
object %s'%obj
 207 else:
 208 self._mmap = None
.... [snip]
/Users/cburns/local/lib/python2.5/site-packages/numpy/ma/core.pyc in
_get_data(self)
 1472
 1473 """
-> 1474 return self.view(self._baseclass)
 1475 _data = property(fget=_get_data)
 1476 data = property(fget=_get_data)
RuntimeError: maximum recursion depth exceeded
Exception exceptions.AttributeError: "'memmap' object has no attribute
'_mmap'" in ignored
Exception exceptions.AttributeError: "'memmap' object has no attribute
'_mmap'" in ignored
[snip]
Exception exceptions.AttributeError: "'memmap' object has no attribute
'_mmap'" in <bound method memmap.__del__ of memmap([ 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0.])> ignored
Exception exceptions.AttributeError: "'memmap' object has no attribute
'_mmap'" in <bound method memmap.__del__ of memmap([ 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0.])> ignored
[snip]

Erik Tollerud wrote:
> I use the scatter(x,y) command to make scatter plots, but I noticed
> today (on the SVN version of mpl) that when I call legend() after
> giving scatter(x,y,label='somelabel') , the legend doesn't show the
> marker symbols - it only has a square patch colored in the color that
> was used for the scatter plot. Is this a bug, or intended behavior?
> (and is there a work-around to show the marker symbols in the legend?)
Hi Erik,
I would say it's neither a bug nor an intended bahavior. It's just not 
implemented -- so you might call it a misbehaviour ;-)
I too hope that this will be fixed/added, since it's an issue open some 
time now (I guess since scatter was implemented !?)
Manuel

John Hunter wrote:
> On Feb 19, 2008 5:45 PM, Paul Kienzle <pki...@ni...> wrote:
> 
>> I didn't provide any masked array checks in any of the contains methods
>> that I wrote. Do any of these need to be fixed?
> 
> They do need to be fixed, but this is not a high priority item. Let's
> wait until the new maskedarray code that is now in a numpy branch goes
> live and official before we invest too much energy in getting masked
> arrays working properly here.
The maskedarray branch has been merged into the svn trunk and will 
therefore be in the 1.05 release, coming within days.
Eric

On Feb 19, 2008 5:45 PM, Paul Kienzle <pki...@ni...> wrote:
> I didn't provide any masked array checks in any of the contains methods
> that I wrote. Do any of these need to be fixed?
They do need to be fixed, but this is not a high priority item. Let's
wait until the new maskedarray code that is now in a numpy branch goes
live and official before we invest too much energy in getting masked
arrays working properly here.
JDH

On Tue, Feb 19, 2008 at 10:55:14AM -0500, Michael Droettboom wrote:
> 2) The picking code for a line assumes non-masked arrays. Since the 
> Line class already keeps around a "compressed" version of the data for 
> drawing, it is easy enough to use that instead of the raw data.
I didn't provide any masked array checks in any of the contains methods
that I wrote. Do any of these need to be fixed?
I won't have a lot of time over the next few months, and I will be
slow to fix them.
	- Paul

Thanks for finding this. I just committed a slightly less band-aid-like 
fix in SVN r4979.
There were really two bugs here:
1) A masked array is created for a line plot whenever only y values are 
provided, even if there are no masked values in the data. That would 
only be a performance bug if it weren't for...
2) The picking code for a line assumes non-masked arrays. Since the 
Line class already keeps around a "compressed" version of the data for 
drawing, it is easy enough to use that instead of the raw data.
By fixing 1), 2) is no longer even an issue in your example. However, 
for a plot that really does have gaps, 2) needs to be fixed as well.
Cheers,
Mike
Andrew Straw wrote:
> I just ran into a bug with picking of lines. I changed the line style in
> figure 1, subplot 1 to 'o-' (from 'o') and ripped out most of everything
> else in examples/pick_event_demo.py to create pick_event_demo3.py
> (attached). When I run this and I attempt to click on points, I get
> 
> Traceback (most recent call last):
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
> line 193, in button_press_event
> FigureCanvasBase.button_press_event(self, x, y, event.button)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backend_bases.py",
> line 915, in button_press_event
> self.callbacks.process(s, mouseevent)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/cbook.py",
> line 157, in process
> func(*args, **kwargs)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backend_bases.py",
> line 849, in pick
> self.figure.pick(mouseevent)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
> line 220, in pick
> for a in self.get_children(): a.pick(mouseevent)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/axes.py",
> line 2155, in pick
> martist.Artist.pick(self,args[0])
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
> line 220, in pick
> for a in self.get_children(): a.pick(mouseevent)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
> line 214, in pick
> inside,prop = self.contains(mouseevent)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/lines.py",
> line 327, in contains
> ind = segment_hits(mouseevent.x,mouseevent.y,xt,yt,pixels)
> File
> "/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/lines.py",
> line 100, in segment_hits
> candidates = candidates & ~point_hits[:-1] & ~point_hits[1:]
> TypeError: bad operand type for unary ~: 'MaskedArray'
> 
> Anyhow, I spent a little while tracking this down and came up with the
> attached patch. I guess there's a more direct solution to the issue that
> this band-aid, but I hope this will jump-start someone to fix this. In
> the meantime, this appears to work sufficiently for my purposes...
> 
> FWIW, my numpy is SVN from 16 december 2007 (after 1.0.4 and thus on the
> way to 1.0.5) and I'm using the old ma module.
> 
> BUILDING MATPLOTLIB
> matplotlib: 0.98pre
> python: 2.5.1 (r251:54863, Oct 5 2007, 13:50:07) [GCC
> 4.1.3 20070929 (prerelease) (Ubuntu
> 4.1.2-16ubuntu2)]
> platform: linux2
> 
> REQUIRED DEPENDENCIES
> numpy: 1.0.5.dev
> freetype2: 9.16.3
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I just ran into a bug with picking of lines. I changed the line style in
figure 1, subplot 1 to 'o-' (from 'o') and ripped out most of everything
else in examples/pick_event_demo.py to create pick_event_demo3.py
(attached). When I run this and I attempt to click on points, I get
Traceback (most recent call last):
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
line 193, in button_press_event
 FigureCanvasBase.button_press_event(self, x, y, event.button)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 915, in button_press_event
 self.callbacks.process(s, mouseevent)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/cbook.py",
line 157, in process
 func(*args, **kwargs)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 849, in pick
 self.figure.pick(mouseevent)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
line 220, in pick
 for a in self.get_children(): a.pick(mouseevent)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/axes.py",
line 2155, in pick
 martist.Artist.pick(self,args[0])
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
line 220, in pick
 for a in self.get_children(): a.pick(mouseevent)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/artist.py",
line 214, in pick
 inside,prop = self.contains(mouseevent)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/lines.py",
line 327, in contains
 ind = segment_hits(mouseevent.x,mouseevent.y,xt,yt,pixels)
 File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/lines.py",
line 100, in segment_hits
 candidates = candidates & ~point_hits[:-1] & ~point_hits[1:]
TypeError: bad operand type for unary ~: 'MaskedArray'
Anyhow, I spent a little while tracking this down and came up with the
attached patch. I guess there's a more direct solution to the issue that
this band-aid, but I hope this will jump-start someone to fix this. In
the meantime, this appears to work sufficiently for my purposes...
FWIW, my numpy is SVN from 16 december 2007 (after 1.0.4 and thus on the
way to 1.0.5) and I'm using the old ma module.
BUILDING MATPLOTLIB
 matplotlib: 0.98pre
 python: 2.5.1 (r251:54863, Oct 5 2007, 13:50:07) [GCC
 4.1.3 20070929 (prerelease) (Ubuntu
 4.1.2-16ubuntu2)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.0.5.dev
 freetype2: 9.16.3

It seems this change was made after the latest 0.91.2 release. I don't 
know of any maintenance releases planned in the near future, but John 
and Charlie would know better than I.
The changeset in question is r4874:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=4874
Cheers,
Mike
Bryce Hendrix wrote:
> I found this subject in the archives:
> 
> http://news.gmane.org/find-root.php?message_id=%3c88e473830801162014h2401e19en166daebe0d7b3ed7%40mail.gmail.com%3e
> 
> We at Enthought are looking at packaging up a new release of matplotlib early 
> next week (or sooner). I would like the new release to have the fix for this, 
> is there a maintenance release with this patch expected soon, or should we 
> apply the patch ourselves?
> 
> Thanks,
> Bryce
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I found this subject in the archives:
http://news.gmane.org/find-root.php?message_id=%3c88e473830801162014h2401e19en166daebe0d7b3ed7%40mail.gmail.com%3e
We at Enthought are looking at packaging up a new release of matplotlib early 
next week (or sooner). I would like the new release to have the fix for this, 
is there a maintenance release with this patch expected soon, or should we 
apply the patch ourselves?
Thanks,
Bryce

Hi,
i have found a strange behaviour of the figure size. At least for some 
cases it looks like the figure size is changed by a small amount after 
calling pylab.show.
The attached script saves the same figure before and after calling 
savefig. The figure saved after the call to show is a different in 
number of pixels.
Here comes a printout from running the script in ipython:
In [1]: %run figsize_truncation.py
desired figsize: (3.1496062992125986, 3.1496062992125986)
actual figsize: [ 3.1496063 3.1496063]
desired figsize: (3.1496062992125986, 3.1496062992125986)
actual figsize: [ 3.2875 3.2875]
As you can see on the last line the last figure becomes something else.
/Jörgen
Versions I use:
python version = 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 
32 bit (Intel)]
numpy __version__ = 1.0.5.dev2304
scipy __version__ = 0.7.0.dev3422
ipython __version__ = 0.8.3.svn.r3001 __revision__ = 3001
matplotlib __version__ = 0.98pre __revision__ = $Revision: 4894 $

I did. But there's no manual, and the 'under construction'
placeholders in the 'how do I?' and tutorial didn't give a great first
impression. I see now there's a link to some example code, but it's a
lot more intimidating than the matplotlib introductory stuff.
>
> Did you find http://code.enthought.com/chaco/ ?
>
> Not that we are trying to drive you away <wink>, we'd love to have you
> stay. As I mentioned in my earlier post, when we migrate to traits
> for matplotlib artist properties, we will get a pretty rich
> interactive UI configuration layer.
>
> JDH
>

On Wed, Feb 13, 2008 at 11:04:13AM -0500, Paul Kienzle wrote:
> Is there anybody outside of enthought who are deploying applications
> based on TraitsUI for Windows/Mac/Linux? I would love to hear about 
> successful examples before committing to more dependencies in our own 
> applications.
I, in the lab. People at Airbus research labs (Bristol, UK), people at
Estimages (http://www.estimages.com/), people at jgeophysics, and quite a
few other researchers, for in house applications in labs (just have a
look at the enthought-dev mailing list. Airbus have actually paying a
former Enthought employee (Martin Chilvers) to develop Envisage3, and
have payed Phil Thompson (author of PyQT) to do the QT backend. This
backend is working now quite well as they are using it for their 
day-to-day work.
> A specific concern we had when investigating Traits a couple of
> years ago was long start up times.
I don't really think this has improved a lot. You would have to try it
out to see. However my experience is that if you are not loading Wx,
traits by itself is fast, if you are loading Wx, you are limited by the
cost of loading Wx. I may be wrong, as I have no hard numbers.
> The lack of clear boundaries between traits and other parts of
> enthought was a further concern, since it would make deployment more
> difficult.
That's pretty much solved. The Enthought Tool Suite has been split in
projects, each of them that can be further split in packages (just a look
at their SVN structure will tell you exactly how it is done:
https://svn.enthought.com/enthought/browser ).
Cheers,
Gaël

On Feb 13, 2008 10:04 AM, Paul Kienzle <pki...@ni...> wrote:
> On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:
> > As I mentioned in my earlier post, when we migrate to traits
> > for matplotlib artist properties, we will get a pretty rich
> > interactive UI configuration layer.
>
> Any sense of when this might happen?
There is no specific timeline, but Darren did a bunch of the hard work
getting a traits enabled rc configuration option (off by default) in
0.91.2. The plan is to turn get this turned on by default in the next
release of the trunk (0.98) so we can get as much pain in at once
rather than in doses. Since migrating apps to the trunk requires some
changes in the API (transformations, bounding boxes) already, this
would probably be a good time to migrate the rc configuration too.
> Is there anybody outside of enthought who are deploying applications
> based on TraitsUI for Windows/Mac/Linux? I would love to hear about
> successful examples before committing to more dependencies in our own
> applications.
Well, we are already installing enthought.traits and have not
experienced any significant user problems, so I don't think we will be
introducing a significant dependency here. This can be done so that
users who have a UI enabled traits will get the UI benefits and those
who don't will get the basic traits benefits minus the UI. So we
wouldn't need to depend on the UI components, and we have already
(mostly) solved the dependency problem on the non UI component (see
matplotlib/lib/enthought).
I say mostly because there is a problem that Gael first reported
recently that having our enthought traits installed ahead of
enthought's version can break some enthought apps, so we need to
address this. And yes, there are some startup time problems with a
namespace enabled version of enthought's packages that have caused
some concern.
> What's going to happen with Qt/Gtk/Tkinter backends? We are already
> using wx so this isn't an issue for us, but last time I looked TraitsUI
> only had wx support.
As far as I understand, there is a fully featured wx version and qt is
coming along nicely. Again, matplotlib would continue to work as
before with the other UI backends, your just wouldn't get the traits
dialogs.
> A specific concern we had when investigating Traits a couple of
> years ago was long start up times. The lack of clear boundaries
> between traits and other parts of enthought was a further concern,
> since it would make deployment more difficult.
This is getting much better, but it is still a work in progress.
traits is now in debian, for example.
JDH

On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:
> As I mentioned in my earlier post, when we migrate to traits
> for matplotlib artist properties, we will get a pretty rich
> interactive UI configuration layer.
Any sense of when this might happen?
Is there anybody outside of enthought who are deploying applications
based on TraitsUI for Windows/Mac/Linux? I would love to hear about 
successful examples before committing to more dependencies in our own 
applications.
What's going to happen with Qt/Gtk/Tkinter backends? We are already
using wx so this isn't an issue for us, but last time I looked TraitsUI 
only had wx support.
A specific concern we had when investigating Traits a couple of
years ago was long start up times. The lack of clear boundaries 
between traits and other parts of enthought was a further concern,
since it would make deployment more difficult.
- Paul

On Feb 13, 2008 8:05 AM, Neil Crighton <nei...@gm...> wrote:
> Another big difference between matplotlib and chaco: matplotlib has
> online documentation, examples and tutorials. I couldn't find any
> documentation on Chaco when I was looking around for a python plotting
> program. If I had, who knows, maybe I'd be using Chaco now instead of
> matplotlib :)
Did you find http://code.enthought.com/chaco/ ?
Not that we are trying to drive you away <wink>, we'd love to have you
stay. As I mentioned in my earlier post, when we migrate to traits
for matplotlib artist properties, we will get a pretty rich
interactive UI configuration layer.
JDH

Another big difference between matplotlib and chaco: matplotlib has
online documentation, examples and tutorials. I couldn't find any
documentation on Chaco when I was looking around for a python plotting
program. If I had, who knows, maybe I'd be using Chaco now instead of
matplotlib :)

On Feb 12, 2008 10:31 PM, Erik Tollerud <eri...@gm...> wrote:
> While doing some further testing, I'm getting another bug in the svn
> code - whenever I try to right-click and drag to zoom out when using
> the toolbar, an Exception is raised complaining about an unbound
> local. I traced the problem to what appears to be a typo in
> backend_bases.py where someone must have renamed some variables and
> didn't go and change them further up or something. Changing the
> variable name in a couple places seems to make it all work on my
> setup. The diff is attached.
Good catch -- applied to r4959.
Thanks,
JDH

After a little testing on the subversion repository, the attached diff
seems to work.
On Feb 10, 2008 12:12 AM, Erik Tollerud <eri...@gm...> wrote:
> I noticed while making some plots with upper bound error bars that
> whenever Axes.errorbars is called with any of the errorbars chosen as
> upper or lower bounds, that the color cycle was off, skipping over 2
> colors each time another errorbar plot was made (e.g. the first would
> be green and the second would be cyan instead of blue,green,red,cyan).
> Looking into the axes class, it appears that if you don't specify a
> color and want the markers to be drawn over the errorbars, the color
> cycle has already been skipped over one because of calls to draw the
> markers into the plot. The solution is to change all the lines that
> say " ls='None' " in the errorbar method to instead say " ls='k' " -
> this will prevent those calls from cycling the colors, and hence only
> the call to actually draw the markers will do so. Can this patch be
> committed to svn?
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

While doing some further testing, I'm getting another bug in the svn
code - whenever I try to right-click and drag to zoom out when using
the toolbar, an Exception is raised complaining about an unbound
local. I traced the problem to what appears to be a typo in
backend_bases.py where someone must have renamed some variables and
didn't go and change them further up or something. Changing the
variable name in a couple places seems to make it all work on my
setup. The diff is attached.
On Feb 12, 2008 6:11 PM, John Hunter <jd...@gm...> wrote:
> On Feb 12, 2008 7:02 PM, Erik Tollerud <eto...@uc...> wrote:
> > You're absolutely correct - I wrote the original patch against 91.2,
> > and forgot to test it against the new trunk. Below is a new patch
> > that HAS been tested against the trunk version. It includes another
> > fix for some API changes in the Rectangle object. Note that there's
> > also a fix in the RectangleSelector to prevent it from raising an
> > exception under the new API.
>
> OK, thanks Erik, I committed this to the trunk as svn r4956. It seems
> to be working fine, so thanks for the patch. I'm not sure right now
> wha the problem is with useblit=False that you are experiencing, but
> if you make any headway on this let us know.
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

On Feb 12, 2008 7:02 PM, Erik Tollerud <eto...@uc...> wrote:
> You're absolutely correct - I wrote the original patch against 91.2,
> and forgot to test it against the new trunk. Below is a new patch
> that HAS been tested against the trunk version. It includes another
> fix for some API changes in the Rectangle object. Note that there's
> also a fix in the RectangleSelector to prevent it from raising an
> exception under the new API.
OK, thanks Erik, I committed this to the trunk as svn r4956. It seems
to be working fine, so thanks for the patch. I'm not sure right now
wha the problem is with useblit=False that you are experiencing, but
if you make any headway on this let us know.
JDH

You're absolutely correct - I wrote the original patch against 91.2,
and forgot to test it against the new trunk. Below is a new patch
that HAS been tested against the trunk version. It includes another
fix for some API changes in the Rectangle object. Note that there's
also a fix in the RectangleSelector to prevent it from raising an
exception under the new API.
I've also noticed that both the SpanSelector and RectangleSelector
don't seem to draw the rectangle with useblit=False on my machine -
I'm only using useblit=True, though, and it works fine there with the
alterations in this patch.
Index: widgets.py
===================================================================
--- widgets.py	(revision 4953)
+++ widgets.py	(working copy)
@@ -827,16 +827,14 @@
 assert direction in ['horizontal', 'vertical'], 'Must choose
horizontal or vertical for direction'
 self.direction = direction
- self.ax = ax
+ self.ax = None
+ self.canvas = None
 self.visible = True
- self.canvas = ax.figure.canvas
- self.canvas.mpl_connect('motion_notify_event', self.onmove)
- self.canvas.mpl_connect('button_press_event', self.press)
- self.canvas.mpl_connect('button_release_event', self.release)
- self.canvas.mpl_connect('draw_event', self.update_background)
+ self.cids=[]
 self.rect = None
 self.background = None
+ self.pressv = None
 self.rectprops = rectprops
 self.onselect = onselect
@@ -847,8 +845,23 @@
 # Needed when dragging out of axes
 self.buttonDown = False
 self.prev = (0, 0)
-
- if self.direction == 'horizontal':
+
+ self.new_axes(ax)
+
+
+ def new_axes(self,ax):
+ self.ax = ax
+ if self.canvas is not ax.figure.canvas:
+ for cid in self.cids:
+ self.canvas.mpl_disconnect(cid)
+
+ self.canvas = ax.figure.canvas
+
+ self.cids.append(self.canvas.mpl_connect('motion_notify_event',
self.onmove))
+ self.cids.append(self.canvas.mpl_connect('button_press_event',
self.press))
+	 self.cids.append(self.canvas.mpl_connect('button_release_event',
self.release))
+	 self.cids.append(self.canvas.mpl_connect('draw_event',
self.update_background))
+	if self.direction == 'horizontal':
 trans = blended_transform_factory(self.ax.transData,
self.ax.transAxes)
 w,h = 0,1
 else:
@@ -859,9 +872,8 @@
 visible=False,
 **self.rectprops
 )
-
+
 if not self.useblit: self.ax.add_patch(self.rect)
- self.pressv = None
 def update_background(self, event):
 'force an update of the background'
@@ -931,10 +943,10 @@
 minv, maxv = v, self.pressv
 if minv>maxv: minv, maxv = maxv, minv
 if self.direction == 'horizontal':
- self.rect.xy[0] = minv
+ self.rect.set_x(minv)
 self.rect.set_width(maxv-minv)
 else:
- self.rect.xy[1] = minv
+ self.rect.set_y(minv)
 self.rect.set_height(maxv-minv)
 if self.onmove_callback is not None:
@@ -1155,8 +1167,8 @@
 miny, maxy = self.eventpress.ydata, y # click-y and actual mouse-y
 if minx>maxx: minx, maxx = maxx, minx # get them in the right order
 if miny>maxy: miny, maxy = maxy, miny
- self.to_draw.xy[0] = minx # set lower left of box
- self.to_draw.xy[1] = miny
+ self.to_draw.set_x(minx) # set lower left of box
+ self.to_draw.set_y(miny)
 self.to_draw.set_width(maxx-minx) # set width and height of box
 self.to_draw.set_height(maxy-miny)
 self.update()
On Feb 11, 2008 7:48 AM, John Hunter <jd...@gm...> wrote:
> On Feb 10, 2008 5:12 PM, Erik Tollerud <eri...@gm...> wrote:
> > I've been working on an application that uses matplotlib as its
> > plotting library, and I've been noticing a steady decrease in
>
> It looks like there is some confusion in your patch vis-a-vis the
> migration from the old matplotlib transformation architecture (no on a
> branch) to the new (now in the trunk). I'm attaching the migration
> document. For example, your patch removes
> blended_transform_factory lines (new transforms call on the trunk) and
> adds blend_xy_sep_transform lines (old transforms call on the 0.91
> maintenance branch).
>
> You can patch either the maintenance branch or the trunk or both, but
> I think the patch as submitted is a little mixed up if I am reading
> this correctly.
>
> JDH
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

Gael Varoquaux wrote:
> * pylab: I love the pylab API. I want (and I am not the only one) to
> be able to construct a plot with a pylab script, or on the command
> line. I would like to be able to modify it interactively
> afterwards. Chaco's pylab equivalent is orders of magnitude below
> the real pylab.
I wonder why -- it sure looks doable.
> * Output quality. Things like laTeX support, pdf and eps output,
hmm -- I thought Kiva was designed around DisplayPDF, which you'd think 
would give you pdf support easily!
> just an constant attention to small details like the tick size,
> etc... give matplotlib an excellent output quality.
Interesting, the examples I've seen of Chaco output sure look nice, but 
maybe it takes more tweaking to get there.
> the two projects have different goals.
The goals I see here seem to match pretty well:
https://svn.enthought.com/enthought/wiki/ChacoProject
Indeed, under PyCon2008 toDo, I see:
"Fully verify PDF and SVG backends"
also:
"seemless install for chaco2 and chaco2demo packages for Win32, OS X, 
Ubuntu, Redhat"
I did just find this (with some of your stuff, Gael), for a bit more info:
http://code.enthought.com/chaco/docs/faq.shtml#comparison
Some thoughts of mine:
A few years back, before MPL, I was very excited about Chaco. however, 
at that time, Enthought ended up focusing on their needs, and things 
like non-Windows platforms, etc, were simple not supported.
However, it looks like enthought is making a lot of effort to have their 
stuff play well with the open source community -- being able to use 
individual packages (traits, etc.), more support for other platforms, etc.
So it comes a bit down to code base -- I think the goals of Chaco and 
MPL overlap a LOT -- I think different priorities have been put on them 
(more focus on GUI interactivity in Chaco, more focus on easy scripting 
in MPL), but both projects want to be able to do the same things in the 
long run.
So it comes down to architecture, I guess -- which has the better 
architecture to build on in the future? I ahve no clue, I don't know 
either one well enough to comment.
I guess it's time for me to dig into Chaco more.
-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 Mon, Feb 11, 2008 at 09:45:28AM -0800, Christopher Barker wrote:
> Gael Varoquaux wrote:
> > I am so happy to hear you say this. With Traits in MPL, it would be
> > possible to build an interactive plotting application based around
> > envisage, using other envisage plugins ....
> I'm really not trying to be a troll, but tell me again what MPL has that 
> Chaco doesn't? It seems there is a bit of "we want MPL to be more like 
> Chaco", but Chaco is open source, and at least nominally back-end 
> independent, so why is there this duplicate effort?
You are not at all a troll. I think this is a very important question to
ask one self. I have thought about it a lot.
Here is my answer:
 * pylab: I love the pylab API. I want (and I am not the only one) to
 be able to construct a plot with a pylab script, or on the command
 line. I would like to be able to modify it interactively
 afterwards. Chaco's pylab equivalent is orders of magnitude below
 the real pylab.
 * Output quality. Things like laTeX support, pdf and eps output, or
 just an constant attention to small details like the tick size,
 etc... give matplotlib an excellent output quality. I got used to
 it and I want to use it for all my publications, and actually I am
 quite happy having it for my day to day work to.
I would love to see MPL and Chaco merge, to be able to get the best of
both worlds, but I don't see it happening any soon, as the two projects
have different goals.
My 2 cents,
Gaël

Gael Varoquaux wrote:
> I am so happy to hear you say this. With Traits in MPL, it would be
> possible to build an interactive plotting application based around
> envisage, using other envisage plugins ....
I'm really not trying to be a troll, but tell me again what MPL has that 
Chaco doesn't? It seems there is a bit of "we want MPL to be more like 
Chaco", but Chaco is open source, and at least nominally back-end 
independent, so why is there this duplicate effort?
 From a glance, it sure looks like you could write a pylab work-alike 
around Chaco -- at least for wx -- other back-ends would be more work.
-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 Feb 10, 2008 5:12 PM, Erik Tollerud <eri...@gm...> wrote:
> I've been working on an application that uses matplotlib as its
> plotting library, and I've been noticing a steady decrease in
It looks like there is some confusion in your patch vis-a-vis the
migration from the old matplotlib transformation architecture (no on a
branch) to the new (now in the trunk). I'm attaching the migration
document. For example, your patch removes
blended_transform_factory lines (new transforms call on the trunk) and
adds blend_xy_sep_transform lines (old transforms call on the 0.91
maintenance branch).
You can patch either the maintenance branch or the trunk or both, but
I think the patch as submitted is a little mixed up if I am reading
this correctly.
JDH