matplotlib-devel Mailing List for matplotlib

Hello everyone,
in my programs I need the RectangleSelector. It's quiet easy to use but I 
discovered that there isn't a really easy way to switch it off once it is 
activated. I thought about the following lines to matplotlib/widgets.py:
#--------------------------------------------------------------------------------------------
#at the beginning of RectangleSelector's __init__:
 ... docstring ...
 self.ax = ax					# like before
 self.visible = True				# like before
 self.canvas = ax.figure.canvas	# like before
 self.connect_id = [] # will contain the connection id's 
 self.active = True # for activation / deactivation
 self.is_active(True)
 ... snip ... 
#and an additional method:
#--------------------------------------------------------------------------------------------
def is_active(self, active):
 """ Use this to activate the RectangleSelector from your program.
 """
 self.active = active
 if active and len(self.connect_id) == 0: # you want to activate and it
 # isn't already active 
 self.connect_id.append(self.canvas.mpl_connect(
 'motion_notify_event', self.onmove))
 self.connect_id.append(self.canvas.mpl_connect(
 'button_press_event', self.press))
 self.connect_id.append(self.canvas.mpl_connect(
 'button_release_event', self.release))
 self.connect_id.append(self.canvas.mpl_connect(
 'draw_event', self.update_background))
 if not active and len(self.connect_id) != 0: # you want to deactivate 
 for index in self.connect_id: # and it isn't already inactive 
 self.canvas.mpl_disconnect(index)
 self.connect_id = []
#--------------------------------------------------------------------------------------------
With these changes you can check the following example:
#--------------------------------------------------------------------------------------------
from matplotlib.widgets import RectangleSelector
from pylab import *
def onselect(eclick, erelease):
 'eclick and erelease are matplotlib events at press and release'
 print 'startposition : (%f,%f)'%(eclick.xdata, eclick.ydata)
 print 'endposition : (%f,%f)'%(erelease.xdata, erelease.ydata)
 print 'used button : ', eclick.button
def toggle_Selector(event):
 print "Key pressed."
 if event.key in ["Q", "q"] and toggle_Selector.RS.active:
 print " RectangleSelector deactivated."
 toggle_Selector.RS.is_active(False)
 if event.key in ["A", "a"] and not toggle_Selector.RS.active:
 print " RectangleSelector activated."
 toggle_Selector.RS.is_active(True)
x = arange(100)/(99.0)
y = sin(x)
fig = figure
ax = subplot(111)
ax.plot(x,y)
toggle_Selector.RS = RectangleSelector(ax, onselect,drawtype='box')
connect("key_press_event", toggle_Selector)
show()
#--------------------------------------------------------------------------------------------
I hope this is usefull to someone,
Martin
PS: Maybe the above example can replace the RectangleSelector's
docstring. I think it's easier to read and understand.

>>>>> "David" == David Huard <dav...@gm...> writes:
 David> Hi, unles I'm doing something stupid, setp is buggy.
 David> I'm creating a bunch of images using imshow and I want the
 David> colormap to be consistent among images. So once they're all
 David> drawn, I want to uniformize the color scale. But
 >>>> setp(ax.images, clim= [0,1])
 David> does not work because it sets vmin to [0,1] and doesn't
 David> affect vmax.
 David> On the other hand,
 >>>> ax.images[0].set_clim([0,1])
The latter should not work. The set_clim function in
cm.ScalarMappable has the signature
 def set_clim(self, vmin=None, vmax=None):
Ie, it does not accept the sequence argument, though
 ax.images[0].set_clim(*[0,1])
should work.
The setp behavior is more of a bug with set_clim than it is with setp.
For properties to work with setp, we need to have all setters work
with a single argument, and so in this we would want to support a
single non-keyword argument which is a length two sequence mean
"[vmin, vmax]"
I just committed changes to support this so if you have svn access
give it a test drive.
JDH

Hi,
unles I'm doing something stupid, setp is buggy.
I'm creating a bunch of images using imshow and I want the colormap to be
consistent among images. So once they're all drawn, I want to uniformize the
color scale. But
>>> setp(ax.images, clim= [0,1])
does not work because it sets vmin to [0,1] and doesn't affect vmax.
On the other hand,
>>> ax.images[0].set_clim([0,1])
works fine.
Should I file a ticket ?
David
In [1]: ax = axes()
In [2]: ax.imshow(rand(10,10))
Out[2]: <matplotlib.image.AxesImage instance at 0x2aaaad22a830>
In [3]: setp(ax.images, 'clim', [0,1])
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most recent
call last)
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in
expose_event(self, widget, event)
 282 x, y, w, h = self.allocation
 283 self._pixmap_prepare (w, h)
--> 284 self._render_figure(self._pixmap, w, h)
 285 self._need_redraw = False
 286
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py
in _render_figure(self, pixmap, width, height)
 71 def _render_figure(self, pixmap, width, height):
 72 if DEBUG: print 'FigureCanvasGTKAgg.render_figure'
---> 73 FigureCanvasAgg.draw(self)
 74 if DEBUG: print 'FigureCanvasGTKAgg.render_figure pixmap',
pixmap
 75 #agg_to_gtk_drawable(pixmap, self.renderer._renderer, None)
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py in
draw(self)
 390
 391 renderer = self.get_renderer()
--> 392 self.figure.draw(renderer)
 393
 394 def get_renderer(self):
/usr/local/lib/python2.4/site-packages/matplotlib/figure.py in draw(self,
renderer)
 567
 568 # render the axes
--> 569 for a in self.axes: a.draw(renderer)
 570
 571 # render the figure text
/usr/local/lib/python2.4/site-packages/matplotlib/axes.py in draw(self,
renderer, inframe)
 1105 if len(self.images)<=1 or renderer.option_image_nocomposite
():
 1106 for im in self.images:
-> 1107 im.draw(renderer)
 1108 else:
 1109 # make a composite image blending alpha
/usr/local/lib/python2.4/site-packages/matplotlib/image.py in draw(self,
renderer, *args, **kwargs)
 179 def draw(self, renderer, *args, **kwargs):
 180 if not self.get_visible(): return
--> 181 im = self.make_image(renderer.get_image_magnification())
 182 l, b, widthDisplay, heightDisplay =
self.axes.bbox.get_bounds()
 183 renderer.draw_image(l, b, im, self.axes.bbox)
/usr/local/lib/python2.4/site-packages/matplotlib/image.py in
make_image(self, magnification)
 122 im.is_grayscale = False
 123 else:
--> 124 x = self.to_rgba(self._A, self._alpha)
 125 im = _image.fromarray(x, 0)
 126 if len(self._A.shape) == 2:
/usr/local/lib/python2.4/site-packages/matplotlib/cm.py in to_rgba(self, x,
alpha)
 54 if hasattr(x, 'shape') and len(x.shape)>2: return x
 55 x = ma.asarray(x)
---> 56 x = self.norm(x)
 57 x = self.cmap(x, alpha)
 58 return x
/usr/local/lib/python2.4/site-packages/matplotlib/colors.py in
__call__(self, value, clip)
 749 self.autoscale(val)
 750 vmin, vmax = self.vmin, self.vmax
--> 751 if vmin > vmax:
 752 raise ValueError("minvalue must be less than or equal to
maxvalue")
 753 elif vmin==vmax:
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()

Hi,
this used to work a couple of months ago.
In [1]: from pylab import *
In [2]: mappable=cm.ScalarMappable(cmap=cm.jet)
In [3]: mappable.set_array(array([0,1]))
In [4]: cb=colorbar(mappable, orientation='horizontal')
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent
call last)
/home/huardda/Conferences/Luxembourg/src/<ipython console>
/usr/local/lib/python2.4/site-packages/matplotlib/pylab.py in
colorbar(mappable, cax, **kw)
 340 if mappable is None:
 341 mappable = gci()
--> 342 ret = gcf().colorbar(mappable, cax = cax, **kw)
 343 draw_if_interactive()
 344 return ret
/usr/local/lib/python2.4/site-packages/matplotlib/figure.py in
colorbar(self, mappable, cax, **kw)
 701 if cax is None:
 702 cax, kw = cbar.make_axes(ax, **kw)
--> 703 cb = cbar.Colorbar(cax, mappable, **kw)
 704 mappable.add_observer(cb)
 705 mappable.set_colorbar(cb, cax)
/usr/local/lib/python2.4/site-packages/matplotlib/colorbar.py in
__init__(self, ax, mappable, **kw)
 474 kw['cmap'] = mappable.cmap
 475 kw['norm'] = mappable.norm
--> 476 kw['alpha'] = mappable.get_alpha()
 477 if isinstance(mappable, ContourSet):
 478 CS = mappable
AttributeError: ScalarMappable instance has no attribute 'get_alpha'
Ciao,
David

There is a bug in PolygonInteractor -- the non-existent 'verts' is 
reference. Note, there is a verts attribute in some of the inherited 
Polygon classes, but not in the Polygon class itself. This is easy 
to fix. Just remove the unnecessary line:
 self.poly.verts = list(self.poly.verts)
and change all references of poly.verts to poly.xy.
This works fine for me. I found this while creating an interactive 
polygon creator, attached for those interested. Feel free to use 
this routine however you wish.

Hi all,
Russell Owen just built an installer for MPL on OS_X for Python2.5, 
wxPython2.8.
To do it, he needed to patch
_wxagg.cpp, at line 238 as follows:
OLD:
wxBitmap *bitmap = new wxBitmap(image);
NEW
wxBitmap *bitmap = new wxBitmap(*image);
Thanks to a hint from Robin Dunn.
It now seems to work OK, except that when you use pylab.show() and then 
click on the toolbar buttons to zoom, etc, the buttons no longer display
Also, it doesn't work with Numeric 24.2 either -- I think that's a known 
issue, but I can't find a note about it at the moment.
Is anyone maintaining the wx back-end now?
Is MPL working with wxPython 2.8 on other platforms?
If anyone wants to try this binary out, it's temporarily at:
<http://www.astro.washington.edu/rowen/pythonpackages/Python%202.5/>
 >>> matplotlib.__version__
'0.87.7'
 >>> wx.__version__
'2.8.0.1'
 >>> numpy.__version__
'1.0.1'
 >>> Numeric.__version__
'24.2'
-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 Monday 15 January 2007 23:37, be...@fi... wrote:
> Hello:
> I am getting an identical error to the error encountered by Charlie Moad
> (posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
> 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
> 0.87.7. my system is:
>
> XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
>
> the error thread is exactly the same:
[...]
> File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
> in TexManager
> dvipngVersion = get_dvipng_version()
> File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
> in get_dvipng_version
> raise RuntimeError('Could not obtain dvipng version')
> RuntimeError: Could not obtain dvipng version
>
> I saw in the message thread that a fix was committed, is this universal?
I think what you are seeing is not exactly the same what Charlie reported. 
Charlie observed that texmanager was being loaded, and the dvipng version 
checked, when he had usetex : False in his rc options. dvipng is only 
required by usetex, and therefore should not have been checked. The fix from 
April 2006 fixed that problem. If you have usetex : False in your rc options, 
and are still getting this dvipng version error, then it is a bug and I need 
to investigate.
However, I suspect that you have set usetex : True in your rc settings, but 
haven't installed all the required dependencies. Do you have dvipng 
installed, and is it on your PATH? If so, opening a DOS window and 
running "dvipng --version" should yield something like:
This is dvipng 1.8 Copyright 2002-2006 Jan-Ake Larsson
dvipng 1.8
kpathsea version 3.5.5
Copyright (C) 2002-2005 Jan-Ake Larsson.
There is NO warranty. You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files
named COPYING and dvipng.c.
Darren

Hello: 
I am getting an identical error to the error encountered by Charlie Moad
(posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
0.87.7. my system is:
XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
the error thread is exactly the same:
Traceback (most recent call last):
 File "C:\Python24\test.py", line 33, in -toplevel-
 pylab.savefig(filename)#,dpi=100)
 File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 813, in
savefig
 return fig.savefig(*args, **kwargs)
 File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 682, in
savefig
 self.canvas.print_figure(*args, **kwargs)
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 456, in print_figure
 self.draw()
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 392, in draw
 self.figure.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 544, in
draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 1063, in
draw
 a.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 561, in draw
 tick.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 161, in draw
 if self.label1On: self.label1.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 838, in draw
 Text.draw(self, renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 340, in draw
 bbox, info = self._get_layout(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 187, in
_get_layout
 w,h = renderer.get_text_width_height(
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 239, in get_text_width_height
 texmanager = self.get_texmanager()
 File "C:\Python24\Lib\site-packages\matplotlib\backend_bases.py", line
413, in get_texmanager
 from matplotlib.texmanager import TexManager
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 61,
in -toplevel-
 class TexManager:
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
in TexManager
 dvipngVersion = get_dvipng_version()
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
in get_dvipng_version
 raise RuntimeError('Could not obtain dvipng version')
RuntimeError: Could not obtain dvipng version
I saw in the message thread that a fix was committed, is this universal?
many thanks,
bernard
-- 
View this message in context: http://www.nabble.com/matplotlib-vidpgn-version-error-tf3028905.html#a8415685
Sent from the matplotlib - devel mailing list archive at Nabble.com.

I want to calculate the intersection of the edge of a marker with a line
running from the center to another marker. I want to do this in order to
decorate the intersection.
I'm using the following code(derived from some code in axes.py) to try
and "divine" the size:
 node_sz=sqrt(size*(ax.figure.dpi.get()/72.0))
This is not right. Clearly, I just don't have an idea what I'm doing
(when it comes to calculating the distance along a vector(the along a
vector part is easy) of the size of scatter marker). Anyway, who can
point me in the right direction would be my hero for atleast 2 or 3
hours.
-- 
Matt

Hi All,
I am new to this list, but a real fan of matplotlib, so I thought I would
post this here. I am not sure if a bug report is more appropriate - please
let me know!
I have recently come across some font loading errors when using matplotlib
0.87.7-2 (and previous versions). I have tracked these errors down to
font_manager.py in the matplotlib distribution, which is why I am emailing
you guys (I saw your email addresses in the file).
My installation details are as follows: I am using python 2.5 with
matplotlib 0.87.7-2 on OSX 10.4 both installed with fink (
http://fink.sourceforge.net). I also encountered the same errors I will
describe with python 2.3 and an earlier version of matplotlib. I have 2
font path environment variables set TTFPATH=/sw/lib/X11/fonts/applettf, and
AFMPATH=/sw/share/texmf-dist/fonts/afm (/sw is where fink installs all
files).
The crux of the matter is that my TTFPATH directory contains a bunch of .ttf
files, while my AFMPATH directory contains subdirectories that themselves
contain .afm files. The existing version of font_manager.py does not step
through these subdirectories, and thus none of my afm fonts were being
included in the search for fonts. Furthermore, there was a problem in
parsing binary .ttf files when I was trying to load only ascii-encoded afm
files.
I tracked this down to the findSystemFonts(fontpaths,fontext) method in
font_manager.py and modified it in 2 places to step through subdirectories
(with os.walk), and to make sure it only loads the correct font with
extension fontext. Below I give a diff of my modifications (each commented
with a #JBL), and the existing file:
diff font_manager.py font_manager_broken.py
42,43d41
< #JBL import re to match to file extension
< import re
209,212c207,208
< #JBL ONLY load if the proper fontext extension
< if re.match(fontext,f):
< fontfiles[f] = 1
<
---
> fontfiles[f] = 1
>
216,225c212,217
< #JBL
< #Supposed to be searching recursively here
< # for path in fontpaths:
< # use os.walk to walk through any directories listed
< for root_path in fontpaths:
< for path, dirs, file_names in os.walk(root_path):
< files = glob.glob(os.path.join(path, '*.'+fontext))
< files.extend(glob.glob(os.path.join(path,
'*.'+fontext.upper())))
< for fname in files:
< fontfiles[os.path.abspath(fname)] = 1
---
> for path in fontpaths:
> files = glob.glob(os.path.join(path, '*.'+fontext))
> files.extend(glob.glob(os.path.join(path, '*.'+fontext.upper())))
> for fname in files:
> fontfiles[os.path.abspath(fname)] = 1
>
These changes fix all the font loading problems I noticed. I think this is
an important fix for those users that have installed fonts in non-standard
ways and who use the environment variables to point to them. Do you
recommend me contributing this fix to the matplotlib project? Should I make
a patch, or contribute via svn?
I hope this is helpful, and appreciate any feedback anyone can give.
Sincerely,
Julius B. Lucks
-----------------------------------------------------
http://openwetware.org/wiki/User:Lucks
-----------------------------------------------------

On 2007年1月16日 09:38:54 +0800
 Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007年01月15日 at 10:57 -0800,
> mat...@li... wrote:
>> Hi,
>> =20
>> I cannot install the latest matplotlib on=20
>>openSUSE10.2
>> python setup.py install yields
>> =20
> OK, I've updated _image.cpp to work on 64-bit systems=20
>with new versions
> of Python, but you will need to test it for me.
>=20
> Steve
>=20
Hi Steve,
This is to let you know that I was able to install
matplotlib via latest svn version. Thank you !
Cheers,
 Nils

Hello:
I am getting an identical error to the error encountered by Charlie Moad
(posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
0.87.7. my system is:
XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
the error thread is exactly the same:
Traceback (most recent call last):
 File "C:\Python24\test.py", line 33, in -toplevel-
 pylab.savefig(filename)#,dpi=100)
 File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 813, in
savefig
 return fig.savefig(*args, **kwargs)
 File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 682, in
savefig
 self.canvas.print_figure(*args, **kwargs)
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 456, in print_figure
 self.draw()
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 392, in draw
 self.figure.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 544, in
draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 1063, in draw
 a.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 561, in draw
 tick.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 161, in draw
 if self.label1On: self.label1.draw(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 838, in draw
 Text.draw(self, renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 340, in draw
 bbox, info = self._get_layout(renderer)
 File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 187, in
_get_layout
 w,h = renderer.get_text_width_height(
 File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 239, in get_text_width_height
 texmanager = self.get_texmanager()
 File "C:\Python24\Lib\site-packages\matplotlib\backend_bases.py", line
413, in get_texmanager
 from matplotlib.texmanager import TexManager
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 61,
in -toplevel-
 class TexManager:
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
in TexManager
 dvipngVersion = get_dvipng_version()
 File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
in get_dvipng_version
 raise RuntimeError('Could not obtain dvipng version')
RuntimeError: Could not obtain dvipng version
I saw in the message thread that a fix was committed, is this universal?
many thanks,
bernard

On Mon, 2007年01月15日 at 08:26 -0700, Fernando Perez wrote:
> Those lines also work fine from an ipython prompt:
> 
> In [1]: from matplotlib.backends import backend_cairo
> 
> In [2]: from matplotlib.backends.backend_gtk import *
They work, but they are not relevant to this problem. Darren has
confused the issue by applying a fix to backend_gtkcairo.py (with no
CHANGELOG comment) while you and I are investigating the problem. So we
are executing the workaround command and are unable to reproduce the
bug.
However, if I put the line
import matplotlib.backends.backend_cairo as be_cairo
back into backend_gtkcairo.py I can now see the problem.
$ python
Python 2.4.3 (#1, Oct 1 2006, 18:00:19) 
[GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.backends.backend_gtkcairo
$ ipython 
Python 2.4.3 (#1, Oct 1 2006, 18:00:19) 
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import matplotlib.backends.backend_gtkcairo.py
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most
recent call last)
/home/iuser/<ipython console> 
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py 
 52 
 53 # a hack to keep old versions of ipython working with mpl
 54 if 'IPython.Shell' in sys.modules:
---> 55 new_figure_manager, draw_if_interactive, show =
pylab_setup()
 56 
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
 22 backend_name = 'backend_'+backend.lower()
 23 backend_mod =
__import__('matplotlib.backends.'+backend_name,
---> 24 globals(),locals(),[backend_name])
 25 
 26 # Things we pull in from all backends
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py 
 8 
 9 #from matplotlib.backends import backend_cairo
---> 10 import matplotlib.backends.backend_cairo as be_cairo
 11 from matplotlib.backends.backend_gtk import *
 12 
AttributeError: 'module' object has no attribute 'backends'
Send instant messages to your online friends http://au.messenger.yahoo.com 

On Monday 15 January 2007 14:21, Nils Wagner wrote:
> On 2007年1月15日 14:03:47 -0500
>
> Darren Dale <dd...@co...> wrote:
> > Nils,
> >
> > Please don't post to matplotlib when you have problems
> >with svn-matplotlib.
> > Post to matplotlib-devel.
> >
> > Darren
>
> I have removed the build directory.
>
> The CHANGELOG has a new entry
>
> 2007年01月15日 src/_image.cpp combine buffer_argb32() and
> buffer_bgra32() into
> a new method color_conv(format) - SC
>
> I guess my installation problem is connected with that
> change. Do you agree ?
Yes, that was probably the cause.

On 2007年1月15日 14:03:47 -0500
 Darren Dale <dd...@co...> wrote:
> Nils,
>=20
> Please don't post to matplotlib when you have problems=20
>with svn-matplotlib.=20
> Post to matplotlib-devel.
>=20
> Darren
 =20
I have removed the build directory.
The CHANGELOG has a new entry
2007年01月15日 src/_image.cpp combine buffer_argb32() and=20
buffer_bgra32() into
 a new method color_conv(format) - SC
I guess my installation problem is connected with that
change. Do you agree ?
Nils
 =20

On 1/14/07, Steve Chaplin <ste...@ya...> wrote:
> Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My
> view is that the lines
> from matplotlib.backends import backend_cairo
> from matplotlib.backends.backend_gtk import *
> work fine when called from the Python prompt. They are using the
> absolute package path and are correct and should not be "fixed" to use
> relative imports (which is bad style). So if there is a bug it is
> elsewhere and from the traceback it looked like ipython is involved.
>
> The traceback shows that this code is being executed
> # a hack to keep old versions of ipython working with mpl
> if 'IPython.Shell' in sys.modules:
> new_figure_manager, draw_if_interactive, show = pylab_setup()
>
> which is ipython-specific code.
> I don't usually use IPython, but I installed it today and ran a few
> simple matplotlib plots with the GTKCairo backend and they worked OK! So
> I can't offer more info, perhaps Darren can produce a minimal test case
> to isolate the problem.
Those lines also work fine from an ipython prompt:
In [1]: from matplotlib.backends import backend_cairo
In [2]: from matplotlib.backends.backend_gtk import *
The point is that for some bizarre reason, /inside/ the
ipython/matplotlib initialization, Darren was seeing a problem. It
may very well be that the real culprit is ipython, but after looking
at the issue I can't see anything, and Darren also tried to understand
it and failed.
So given this, Darren found a solution by modifying matplotlib.
Unless you can suggest a proper fix, I think we'll have for now to
live with this, even if it's in principle not ideal. If none of us
can figure out the real problem, at least Darren's solution works, so
it's better than leaving the bug in place.
Cheers,
f

On Fri, 2007年01月12日 at 08:44 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> I propose this new version of buffer_bgra32 (and
> Steve> buffer_argb32). I tested it with cairo and it seems to work
> Steve> OK.
> 
> This looks good -- please test it with one of the memleak scripts, eg
> a variant of units/memleak_hawaii.py to make sure everything is being
> cleaned up properly. If you feel motivated, please port these over to
> the other buffer methods. One way to do this cleanly would be to set
> up an enum of the agg pixel formats supported by agg::color_conv and
> then simply allow the user to pass in the pixel format desired. Ie,
> support 
> 
> color_conv_rgba32_to_abgr32
> color_conv_rgba32_to_argb32
> color_conv_rgba32_to_bgra32
> 
> in a single function with a single arg.
I've replaced buffer_argb32() and buffer_bgra32() with
Image::color_conv(format) and tested it for memory leaks and it seems
OK. I think this only affects the cairo backend, since the other
backends seem to use rgba and don't need to use a color conversion
method.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On Monday 15 January 2007 12:16 am, Steve Chaplin wrote:
> On Thu, 2007年01月11日 at 00:01 -0700, Fernando Perez wrote:
> > On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > > On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
> > > > I had to alter the following lines from backend_gtkcairo, from
> > > >
> > > > import matplotlib.backends.backend_cairo as be_cairo
> > > > from matplotlib.backends.backend_gtk import *
> > > >
> > > > to
> > > >
> > > > import backend_cairo as be_cairo
> > > > from backend_gtk import *
> > > >
> > > > in order to prevent the following traceback:
> > > >
> > > > Traceback (most recent call last):
> > > > File "/usr/bin/ipython", line 27, in ?
> > > > IPython.Shell.start().mainloop()
> > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line
> > > > 1034, in start
> > > > return shell(user_ns = user_ns)
> > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line
> > > > 945, in __init__
> > > > shell_class=MatplotlibMTShell)
> > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line
> > > > 622, in __init__
> > > > on_kill=[mainquit])
> > > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line
> > > > 90, in make_IPython
> > > > embedded=embedded,**kw)
> > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line
> > > > 506, in __init__
> > > > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line
> > > > 397, in _matplotlib_config
> > > > from matplotlib import backends
> > > > File
> > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > > line 55, in ?
> > > > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > > > File
> > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > > line 23, in pylab_setup
> > > > globals(),locals(),[backend_name])
> > > >
> > > > File
> > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkca
> > > >iro.py", line 11, in ?
> > > > import matplotlib.backends.backend_cairo as be_cairo
> > > > AttributeError: 'module' object has no attribute 'backends'
> > >
> > > The original matplotlib code is correct, you should be editing IPython
> > > and correcting their bug!
> >
> > Well, I'd be delighted to correct the ipython bug, if only I
> > understood exactly what the problem was... As far as I can see, that
> > code in ipython is simply calling
> >
> > # Initialize matplotlib to interactive mode always
> > import matplotlib
> > from matplotlib import backends
> >
> > inside a function (the _matplotlib_config method). I don't see a bug
> > in that, but if you provide some pointers, I'll be happy to fix any
> > issues that are on ipython's side of the fence.
>
> Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My
> view is that the lines
> from matplotlib.backends import backend_cairo
> from matplotlib.backends.backend_gtk import *
> work fine when called from the Python prompt. They are using the
> absolute package path and are correct and should not be "fixed" to use
> relative imports (which is bad style). So if there is a bug it is
> elsewhere and from the traceback it looked like ipython is involved.
>
> The traceback shows that this code is being executed
> # a hack to keep old versions of ipython working with mpl
> if 'IPython.Shell' in sys.modules:
> new_figure_manager, draw_if_interactive, show = pylab_setup()
>
> which is ipython-specific code.
> I don't usually use IPython, but I installed it today and ran a few
> simple matplotlib plots with the GTKCairo backend and they worked OK! So
> I can't offer more info, perhaps Darren can produce a minimal test case
> to isolate the problem.
They work ok now, after changing the import statement so that it doesnt rename 
backend_cairo to be_cairo in the gtkcairo namespace. I can't think of a more 
minimal example than the one I already provided: starting IPython without the 
pylab flag and importing matplotlib.backends.backend_gtkcairo. I looked at 
this for a couple hours last week, and was not able to determine whether it 
was an IPython bug or a matplotlib bug that is exposed by IPython's magic. I 
do agree that the absolute path imports are correct and are not the source of 
the problem. Since a workaround has been committed, I don't think I should 
spend more time on this issue (unless another problem emerges).
Darren

On Thu, 2007年01月11日 at 00:01 -0700, Fernando Perez wrote: 
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
> 
> > > I had to alter the following lines from backend_gtkcairo, from
> > >
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > from matplotlib.backends.backend_gtk import *
> > >
> > > to
> > >
> > > import backend_cairo as be_cairo
> > > from backend_gtk import *
> > >
> > > in order to prevent the following traceback:
> > >
> > > Traceback (most recent call last):
> > > File "/usr/bin/ipython", line 27, in ?
> > > IPython.Shell.start().mainloop()
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > > start
> > > return shell(user_ns = user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > > __init__
> > > shell_class=MatplotlibMTShell)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > > __init__
> > > on_kill=[mainquit])
> > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > > make_IPython
> > > embedded=embedded,**kw)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > > __init__
> > > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > > _matplotlib_config
> > > from matplotlib import backends
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 55, in ?
> > > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 23, in pylab_setup
> > > globals(),locals(),[backend_name])
> > >
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > > line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
> 
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
> 
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
> 
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My
view is that the lines
from matplotlib.backends import backend_cairo
from matplotlib.backends.backend_gtk import *
work fine when called from the Python prompt. They are using the
absolute package path and are correct and should not be "fixed" to use
relative imports (which is bad style). So if there is a bug it is
elsewhere and from the traceback it looked like ipython is involved.
The traceback shows that this code is being executed
# a hack to keep old versions of ipython working with mpl
if 'IPython.Shell' in sys.modules:
 new_figure_manager, draw_if_interactive, show = pylab_setup()
which is ipython-specific code.
I don't usually use IPython, but I installed it today and ran a few
simple matplotlib plots with the GTKCairo backend and they worked OK! So
I can't offer more info, perhaps Darren can produce a minimal test case
to isolate the problem.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I propose this new version of buffer_bgra32 (and
 Steve> buffer_argb32). I tested it with cairo and it seems to work
 Steve> OK.
This looks good -- please test it with one of the memleak scripts, eg
a variant of units/memleak_hawaii.py to make sure everything is being
cleaned up properly. If you feel motivated, please port these over to
the other buffer methods. One way to do this cleanly would be to set
up an enum of the agg pixel formats supported by agg::color_conv and
then simply allow the user to pass in the pixel format desired. Ie,
support 
 color_conv_rgba32_to_abgr32
 color_conv_rgba32_to_argb32
 color_conv_rgba32_to_bgra32
in a single function with a single arg.
JDH

On 2007年1月11日, John Hunter wrote:
> Hmm, what version of wx are you using? Charlie Moad wrote some
> extension code to make the transfer from agg to the wx canvas more
> efficient. This looks like the module in question. Can you
John, et al.:
 Running 0.87.7 on my Slackware-11.0 box does not produce the segmentation
fault that it does on my Slackware-10.2 box. So, the latter will be upgraded
on Saturday and it won't be an issue any more.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On Thu, 2007年01月11日 at 09:56 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> Steve> This is the official definition from the manual:
> Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
> Steve> alpha in the upper 8 bits, then red, then green, then
> Steve> blue. The 32-bit quantities are stored
> Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
> Steve> transparent red is 0x80800000, not 0x80ff0000.)
> 
> Steve> What I think this means is: cairo ARGB32 is stored not as 4
> Steve> 8-bit quantities, but as one 32-bit int. On big-endian
> Steve> systems the byte order is ARGB, as you would expect, but on
> Steve> little-endian systems (like a PC) the byte order is BGRA.
> 
> Steve> I imagine the reason is that its easier/faster to
> Steve> read/write one 32-bit int than it is to read/write four
> Steve> bytes.
> 
> OK, I see the source of my confusion. argb determines the order but
> it doesn't determine whether the most significant bit is first or
> last....
> 
> I added a method buffer_bgra32 to the image backend. I'm not sure
> this is the right way to deal with the endianness bit it's easy and
> will probably work. I'll leave it to you guys to fix the cairo
> backend to selectively call the right method and test it across
> platforms, or propose a better solution if you don't like this one...
Thanks, I used the new buffer_bgra32 and now examples/image_demo.py
looks correct (except that sometimes it looks like the pixels right at
the edge of the image might be corrupted).
The backend_cairo.py code does look a little strange, it calls
 rows, cols, str_ = im.buffer_bgra32()
and then
 X = numx.fromstring (str_, numx.UInt8)
which is used merely to convert the (readonly) string returned from
buffer_bgra32 into a read-write buffer for cairo. If buffer_bgra32
returned a buffer (as its name suggests!) instead of a string this would
not be needed, and it would save copying the image around in memory.
I propose this new version of buffer_bgra32 (and buffer_argb32). I
tested it with cairo and it seems to work OK.
Py::Object
Image::buffer_bgra32(const Py::Tuple& args) {
 //"Return the image object as bgra32";
 _VERBOSE("RendererAgg::buffer_bgra32");
 args.verify_length(0);
 int row_len = colsOut * 4;
 PyObject* py_buffer = PyBuffer_New(row_len * rowsOut);
 if (py_buffer ==NULL)
 throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
 unsigned char* buf;
 int buffer_len;
 int ret = PyObject_AsWriteBuffer(py_buffer, (void **)&buf,
&buffer_len);
 if (ret !=0)
 throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
 agg::rendering_buffer rtmp;
 rtmp.attach(buf, colsOut, rowsOut, row_len);
 agg::color_conv(&rtmp, rbufOut, agg::color_conv_rgba32_to_bgra32());
 PyObject* o = Py_BuildValue("llN", rowsOut, colsOut, py_buffer);
 return Py::asObject(o);
}
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---------------------------------------------------------------------------
> exceptions.AttributeError Traceback (most recent
> call last)
>
> /home/darren/<ipython console>
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
> 54
> 55 # a hack to keep old versions of ipython working with mpl
> 56 if 'IPython.Shell' in sys.modules:
> ---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 58
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
> pylab_setup()
> 24 time.sleep(1)
> 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 26 globals(),locals(),[backend_name])
> 27
> 28 # Things we pull in from all backends
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
> 7 import cairo.gtk
> 8
> ----> 9 import matplotlib.backends.backend_cairo as be_cairo
> 10 from matplotlib.backends.backend_gtk import *
> 11
>
> AttributeError: 'module' object has no attribute 'backends'
I found a workaround, and committed it. I don't understand what the root of 
the problem was, probably because the AttributeError at the end of the 
Traceback is misleading. Changing this:
import matplotlib.backends.backend_cario as be_cairo
to this:
from matplotlib.backends import backend_cairo
and updating references to be_cairo was all that was needed. The fix is in svn 
2979.
Darren

On 2007年1月11日, Rich Shepard wrote:
> When I ran the script with -dWXAgg, it segfaulted.
 But, when I run with -dWX, it completes and displays the plot. Ergo,
there's something wrong with Agg here, I suppose.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On 2007年1月11日, Rich Shepard wrote:
 The last output files are attached.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863