matplotlib-users Mailing List for matplotlib

Jeff Whitaker wrote:
> Chris: Never noticed this before, but apparently the parent axes 
> instance is attached to the Line2d instance:
> 
> >>> from pylab import *
> >>> l = plot([1,2,3])
> >>> l[0].axes
> <matplotlib.axes.Subplot instance at 0x3240e90>
cool! That could be handy.
thanks,
-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...

Christopher Barker wrote:
> The MPL build system uses a nifty utility that comes with wx called 
> wx-config to find the wx libs. However, Apple delivered an old version 
> of wxPython with it's Python2.3. By default, the MPL build find the old 
> wx-config, and you end up building the wxAgg back-end against that 
> version of wx, which is not the one you want. Try this:
Yes, thank you for figuring that out! That's the part that I forgot about.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Christopher Barker wrote:
> Jeff Whitaker wrote:
>
>> Chris: In the pylab interface, figure() returns a figure instance 
>> and plot(x,y) returns a list of Line2d instances.
>
> yes, but it's the axis instance that you are most likely to need!
>
> - Chris
>
>
Chris: Never noticed this before, but apparently the parent axes 
instance is attached to the Line2d instance:
 >>> from pylab import *
 >>> l = plot([1,2,3])
 >>> l[0].axes
<matplotlib.axes.Subplot instance at 0x3240e90>
 >>>
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Jeff Whitaker wrote:
> Chris: In the pylab interface, figure() returns a figure instance and 
> plot(x,y) returns a list of Line2d instances.
yes, but it's the axis instance that you are most likely to need!
- 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...

Eric Firing wrote:
> I think this may be a slippery slope. The problem is that for it to 
> work well, there has to be a clear distinction between methods that are 
> endpoints, requiring a redraw, and methods that will be used by other 
> methods. For example, errorbar makes multiple calls to plot, vline, 
> etc. 
I agree -- I don't mind a call to Draw() or something now and then. 
maybe I can put them in my hypothetical OOlab (see prev. msg.) some day, 
so that there are a few calls that do the draw, but not every call to 
plot().
 > by including an additional kwarg ("redraw=False"),
That's the question -- in my wxPython FloatCanvas, I decided that 
NOTHING redraws, and you have to make a call to Draw(0 to get a re-draw. 
In fact, that won't even work if the Canvas thinks nothing has changed, 
so you sometimes need to call Draw(force=True). In that case, I was 
optimizing for fast drawing of lots of stuff, and for embedding in a 
program -- not interactive use.
I do like the default redraw of False that can be overridden -- but how 
many places will that have to be added to the code?
-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...

belinda thom wrote:
> reports no differences. So, I went back and retried the plotting w/wx as 
> a backend and discovered that wx FAILS with PYTHONW and PYTHON (appended).
That's what I expected.
> If you saw how many notes I've collected on the different installs I've 
> tried you'd laugh (except that its not funny).
no, it's not -- but good for you for keeping notes!
> 3) Using Robert's install-from-source method (this install used 
> gfortran.bin.tar.gz, with the caveat that the expected WXAgg doesn't work)
I do think I know what the problem is there.
> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
> MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
> wx.Bitmap
the current, default, wxAgg back end uses some C++ code to efficiently 
create wxBitmaps from the Agg buffer. since it's at the C++ level, MPL 
needs to be compiled against the version of wx you want to use.
The MPL build system uses a nifty utility that comes with wx called 
wx-config to find the wx libs. However, Apple delivered an old version 
of wxPython with it's Python2.3. By default, the MPL build find the old 
wx-config, and you end up building the wxAgg back-end against that 
version of wx, which is not the one you want. Try this:
$ wx-config --version
I get "2.5.3" -- the version delivered by Apple.
now this:
$ which wx-config
/usr/bin/wx-config
It's in /usr/bin -- where apple puts stuff.
$ locate wx-config
I have a bunch -- these are a few:
/usr/bin/wx-config
/usr/local/lib/wxPython-unicode-2.6.3.3/bin/wx-config
/usr/local/lib/wxPython-unicode-2.8.0.1/bin/wx-config
The first is Apples.
The second is the 2.6 version I have installed with Python2.4
The third is the 2.8 version I have installed with Python2.5
Pick the one you want to build with, then set an environment variable to 
point to it:
WX_CONFIG=/usr/local/lib/wxPython-unicode-2.8.0.1/bin/wx-config
then run:
setup.py build.
If you look in setupext.py, you'll see a function:
find_wx_config()
Now that I look at it, it should be able to be beefed up to look for a 
wx-config that matches the default wxPython installed in the Python that 
you're running setup.py with. Maybe I'll do that the next time I build.
Come to think of it, if I just sat down and did all this it would 
probably take less time than writing all these helpful messages to the 
newsgroups!
-Chris
PS: I have not tested this recently, but it all should work!
PPS: Belinda, now that you've done all this work, I do hope you can go 
the extra mile and figure out how to make a binary package of it all for 
others!
-- 
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...

Christopher Barker wrote:
> Eric Firing wrote:
> 
>> Even without the automatic-redraw difference, the OO interface requires 
>> more typing, and more mental record-keeping, than the pylab interface.
>> 
>
> Yes, but I don't think that's inherent in an OO interface, it's just 
> that the quickie utilities are missing from the current OO interface.
>
> oh, and it's not mental record keeping -- it's explicit record keeping, 
> which is why I like it:
>
> F1 = OOlab.Figure()
> F2 = OOlab.Figure()
>
> Isn't that better than trying to remember which is the current figure?
>
> 
>> Typing "plot(x,y)" is easier to do and remember than creating a figure, 
>> adding axes, and then typing "ax1.plot(x,y)".
>> 
>
> Why couldn't plot(x,y) create and return a figure object? Or an axis 
> object? -- I haven't thought it out too much yet.
> 
Chris: In the pylab interface, figure() returns a figure instance and 
plot(x,y) returns a list of Line2d instances.
 >>> from pylab import *
 >>> l = plot([1,2,3])
 >>> l
[<matplotlib.lines.Line2D instance at 0x3dcf738>]
 >>> f = figure()
 >>> f
<matplotlib.figure.Figure instance at 0x3dcf710>
 >>>
I guess I agree with Eric, I don't really see much benefit for the OO 
interface for interactive use.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Eric Firing wrote:
> Even without the automatic-redraw difference, the OO interface requires 
> more typing, and more mental record-keeping, than the pylab interface.
Yes, but I don't think that's inherent in an OO interface, it's just 
that the quickie utilities are missing from the current OO interface.
oh, and it's not mental record keeping -- it's explicit record keeping, 
which is why I like it:
F1 = OOlab.Figure()
F2 = OOlab.Figure()
Isn't that better than trying to remember which is the current figure?
> Typing "plot(x,y)" is easier to do and remember than creating a figure, 
> adding axes, and then typing "ax1.plot(x,y)".
Why couldn't plot(x,y) create and return a figure object? Or an axis 
object? -- I haven't thought it out too much yet.
 > For interactive use, I really don't see any advantage to an OO 
interface.
Well, for *just* interactive use, I agree, but I see some very large 
advantages to an OO style for embedding in programs and larger projects. 
However, I don't want to use one style for one use, and a different 
style for another.
Part of this might be from my style -- I actually found that I didn't 
make much use of interactive mode in Matlab -- and I was a heavy Matlab 
user -- six years of grad school and a dissertation's worth.
As handy as it is to have a command line to play with, if I'm writing 
more than four or five lines (and I usually am!), I'm happier putting 
them in a file and running them as a script. Even in that case, I don't 
mind a little extra typing.
What I'm envisioning for "OOlab" is a set of utility functions that do 
make some of the pylab stuff easy -- not well thought out yet, but 
something like:
F = ooLab.figure(1) # I often need to plot more than one figure anyway, 
so I don't mind having to type that.
ax = F.plot(x,y) # there could be this and subplot
ax.set_title = "A title for the plot"
# or better yet: ax.title = "A title for the plot"
# I'd like to see more properties in MPL too!
ax.grid(True)
.
.
.
Whatever.
Note that some of this comes from my love of namespaces -- I really 
don't like "import*" -- the way that can work is using more OO, so you 
don't need to type the module name everywhere.
I don't see much advantage to keeping the idea of a "current figure" or 
"current axis" -- it's just not that hard to keep a reference. Maybe it 
does help for quickie command line stuff, but I think for even quickie 
scripts, it's clearer to name your axes, etc.
However, the proof is in the pudding -- what needs to be done is for 
someone to sit down and start using MPL in interactive/quickie script 
use without pylab, and write something for OOlab whenever something is 
harder to do than it should be. Then we'll see how it works out.
I'd like that person to be me, but I actually haven't been using MPL for 
much lately, and the little I am has been embedded in a wxPython app.
-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 2007年1月11日, John Hunter wrote:
> Hmm, what version of wx are you using?
 wxPython-2.6.3.2-i486-1asz (on Slackware)
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日, John Hunter wrote:
> Can you
>
> import matplotlib.backends._wxagg
>
> successfully?
 Yes.
> matplotlib.backends.backend_wxagg still supports using the older,
> slower, python transfer. If you edit backend_wxagg.py and edit the
> bottom of the file replacing the block
>
> try:
> import _wxagg
> except ImportError:
> _wxagg = None
>
> with simply
>
> _wxagg = None
>
> does the segfault go away?
 Yes.
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日, John Hunter wrote:
> I didn't see the attachment.
John,
 Mea culpa! I forgot to stick them on.
> > python myscript.py --verbose-debug -dAgg >& runagg.out
> > python myscript.py --verbose-debug -dPS >& runps.out
> > python myscript.py --verbose-debug -dGTK >& rungtk.out
> You may want to move this conversation over to the devel list.
 I just returned the subscription confirmation, and will append the output
files in a response to that list.
 Quick summary: the first two above just ran; the third ran and displayed a
window with the plot. No segfaults on any of them.
 Then I ran simple_plot.py a fourth time -- using WXAgg. That generated the
segfault.
Many 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

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 Rich> simple_plot.py and the output (matplot.log) are
 Rich> attached. It is when the show() command is run that the
 Rich> problem appears.
I didn't see the attachment.
 Rich> How do I specify the backend for a run of the script?
Create a minimal script:
 from pylab import plot, savefig, show
 plot([1,2,3])
 savefig('test')
 show()
and run it with 
 > python myscript.py --verbose-debug -dAgg >& runagg.out
 > python myscript.py --verbose-debug -dPS >& runps.out
 > python myscript.py --verbose-debug -dGTK >& rungtk.out
You may want to move this conversation over to the devel list.
JDH

On 2007年1月11日, John Hunter wrote:
> If you recompiled cleanly (ie removed the build subdir) with VERBOSE=True
> as instructed, you should be getting tons and tons of output whenever you
> run a script (eg can you run simple_plot.py?).
John,
 I was looking for verbose output during the build rather than when the
script ran. Now I'm on the same page as you are.
> If you do get the output, post it along with the script and the command
> line. Also, try running with different backends, eg, PS, Agg. DO both
> segfault?
 simple_plot.py and the output (matplot.log) are attached. It is when the
show() command is run that the problem appears.
 How do I specify the backend for a run of the script?
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

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 >> If that shed additional light, again flush the build and
 >> install dirs, and try setting VERBOSE=True in setup.py before
 >> doing a clean install. The VERBOSE setting will generate lots
 >> of extra output and may help indicate where the segfault is
 >> occurring
 Rich> No extra messages indicating any problems.
 Rich> I did discover that there were two pkgconfig/
 Rich> directories. I moved the few newer *.pc files from
 Rich> /usr/local/lib/pkgconfig/ to /usr/lib/pkgconfig/, removed
 Rich> the now empty directory, and rebuilt/installed from the
 Rich> source tarball.
 Rich> No joy. It still segfaults when I try to 'show()' the
 Rich> plot.
If you recompiled cleanly (ie removed the build subdir) with
VERBOSE=True as instructed, you should be getting tons and tons of
output whenever you run a script (eg can you run simple_plot.py?). If
you are not getting the output, you are probably not running the
matplotlib you think you are. If you do get the output, post it along
with the script and the command line. Also, try running with
different backends, eg, PS, Agg. DO both segfault?
JDH

On 2007年1月11日, John Hunter wrote:
> # How to diagnose where a segfault is occurring
> Try importing these packages individually
>
> import matplotlib._image
> import matplotlib._transforms
> import matplotlib.backends._ns_backend_agg # for numpy
> import matplotlib.backends._tkagg
> import matplotlib._agg
 All import without complaint.
> If that shed additional light, again flush the build and install dirs, and
> try setting VERBOSE=True in setup.py before doing a clean install. The
> VERBOSE setting will generate lots of extra output and may help indicate
> where the segfault is occurring
 No extra messages indicating any problems.
 I did discover that there were two pkgconfig/ directories. I moved the few
newer *.pc files from /usr/local/lib/pkgconfig/ to /usr/lib/pkgconfig/,
removed the now empty directory, and rebuilt/installed from the source
tarball.
 No joy. It still segfaults when I try to 'show()' the plot.
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

Hello all,
I am a new matplotlib user and am trying to plot simple polygons in 3D. Such as cubes and tetrahedra.
As a start I began exploring the axes3D example listed on the scipy page. 
There are two errors that occur one is a missed tab on line 364 - 365 before the if statement. Removing this error then provides the following problem when running the axes3d.py code. I followed the call through axes.py module and cannot figure out why the class objects in the collections.py module are not being read properly. The error is shown below.
Thanks,
Andrew
---------------------------------------------------
Traceback (most recent call last):
 File "C:\Python25\Lib\site-packages\matplotlib\axes3d.py", line 15, in <module>
 from axes import Axes
 File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 18, in <module>
 from collections import RegularPolyCollection, PolyCollection, LineCollection, QuadMesh, \
ImportError: cannot import name RegularPolyCollection

On 2007年1月11日, John Hunter wrote:
> If that shed additional light, again flush the build and install dirs, and
> try setting VERBOSE=True in setup.py before doing a clean install. The
> VERBOSE setting will generate lots of extra output and may help indicate
> where the segfault is occurring
 Nothing different. No errors, but the same warnings that _POSIX_C_SOURCE
is redefined, for example:
gcc: src/_ns_image.cpp
In file included from /usr/include/python2.4/Python.h:8,
 from src/_ns_image.cpp:8:
/usr/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from
/usr/include/c++/3.3.6/i486-slackware-linux/bits/os_defines.h:39,
 from
/usr/include/c++/3.3.6/i486-slackware-linux/bits/c++config.h:35,
 from /usr/include/c++/3.3.6/iostream:44,
 from src/_ns_image.cpp:2:
/usr/include/features.h:150:1: warning: this is the location of the previous
definition
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日, John Hunter wrote:
> # How to diagnose where a segfault is occurring
> Try importing these packages individually
[rshepard@salmo ~]$ ipython
In [1]: import matplotlib._image
In [2]: import matplotlib._transforms
In [3]: import matplotlib.backends._ns_backend_agg
In [4]: import matplotlib.backends._tkagg
In [5]: import matplotlib._agg
 So far, so good.
> If that shed additional light, again flush the build and install dirs, and
> try setting VERBOSE=True in setup.py before doing a clean install. The
> VERBOSE setting will generate lots of extra output and may help indicate
> where the segfault is occurring
 Will do.
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日, Simson Garfinkel wrote:
> Perhaps you have a second installation that you are not aware of.
 Good thought, Simon. I have the new /usr/local/matplotlib-0.87.7,
/usr/share/matplotlib (with images and fonts), and another directory with
docs and examples. That's all. There are no other copies of matplotlib
except in the build directory and in ../site-packages/.
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

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 Rich> Is matplotlib-0.87.7 dependent on specific versions of
 Rich> gcc or glibc?
Not that I know of... I'm pasting in our "SEGFAULTS" instructions
below, which are located in the svn repository
# How to diagnose where a segfault is occurring
First thing to try is simply rm -rf the site-packages/matplotlib and
build subdirs and get a clean install. Installing a new version over
a pretty old version has been known to cause trouble, segfault, etc.
Try importing these packages individually
 import matplotlib._image
 import matplotlib._transforms
 #one of these three depending on which numerix package you are using
 import matplotlib.backends._na_backend_agg # for numarray
 import matplotlib.backends._nc_backend_agg # for Numeric
 import matplotlib.backends._ns_backend_agg # for numpy
 import matplotlib.backends._tkagg
 import matplotlib._agg
If the last two work and the others don't, it is likely you need to
upgrade your gcc, because on some platforms (OS X for sure) old
versions of gcc cannot compile new versions of pycxx, which matplotlib
uses for building some but not all of it's extensions. Report back
which if any work or segfault or raise tracebacks,
If that shed additional light, again flush the build and install dirs,
and try setting VERBOSE=True in setup.py before doing a clean install.
The VERBOSE setting will generate lots of extra output and may help
indicate where the segfault is occurring 

Perhaps you have a second installation that you are not aware of.
On Jan 11, 2007, at 12:18 PM, Rich Shepard wrote:
> On 2007年1月11日, John Hunter wrote:
>
>> sudo rm -rf your build dir and site-packages/matplotlib and
>> rebuild/reinstall.
>
> John,
>
> Rats! That did not change the result.
>
> Is matplotlib-0.87.7 dependent on specific versions of gcc or 
> glibc?
>
> 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
>
> ---------------------------------------------------------------------- 
> ---
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 2007年1月11日, John Hunter wrote:
> sudo rm -rf your build dir and site-packages/matplotlib and
> rebuild/reinstall.
John,
 Rats! That did not change the result.
 Is matplotlib-0.87.7 dependent on specific versions of gcc or glibc?
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

>>>>> "Nils" == Nils Wagner <nw...@ia...> writes:
 Nils> Is this a bug ? ax1.xlabel(r'Frequency $f$ (Hz)')
 Nils> AttributeError: Subplot instance has no attribute 'xlabel'
Yes, but it is a bug in your code (wink). See help(ax1). The method
is ax1.set_xlabel.
KDJ

Is this a bug ?
 ax1.xlabel(r'Frequency $f$ (Hz)')
AttributeError: Subplot instance has no attribute 'xlabel'
>>> ax1
<matplotlib.axes.Subplot instance at 0x2aaab468d3f8>
Nils

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 Rich> In [3]: show() Segmentation fault
sudo rm -rf your build dir and site-packages/matplotlib and
rebuild/reinstall.
JDH