matplotlib-devel Mailing List for matplotlib (Page 2)

On Sunday 20 November 2005 6:57 pm, Darren Dale wrote:
> On Sunday 20 November 2005 5:47 pm, Robert Kern wrote:
> > Darren Dale wrote:
> > > Will scipy_core ever include something like Numeric's lapack_lite?
> >
> > scipy_core does not depend on ATLAS. It already has lapack_lite.
> >
> > [svk-projects]$ ls scipy_core/scipy/corelib/lapack_lite
> > blas_lite.c dlapack_lite.c f2c_lite.c 
> > zlapack_lite.c dlamch.c f2c.h 
> > lapack_litemodule.c
Sorry, I've obviously overlooked something, but maybe I have also discovered a 
bug. I've just removed atlas/blas/lapack, updated scipy_core from svn, 
removed my build and site-packages/scipy directories, and tried to build 
scipy_core. Here is a warning message I get toward the end of the build and 
install processes:
building 'scipy.lib._dotblas' extension
compiling C sources
i686-pc-linux-gnu-gcc options: '-pthread -fno-strict-aliasing -DNDEBUG -fPIC'
creating build/temp.linux-i686-2.4/scipy/corelib
creating build/temp.linux-i686-2.4/scipy/corelib/blasdot
compile options: '-DNO_ATLAS_INFO=1 -Iscipy/corelib/blasdot 
-Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src 
-I/usr/include/python2.4 -c'
i686-pc-linux-gnu-gcc: scipy/corelib/blasdot/_dotblas.c
/usr/bin/g77 -shared 
build/temp.linux-i686-2.4/scipy/corelib/blasdot/_dotblas.o -L/usr/lib -lblas 
-lg2c -o build/lib.linux-i686-2.4/scipy/lib/_dotblas.so
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/ld: 
cannot find -lblas
collect2: ld returned 1 exit status
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/ld: 
cannot find -lblas
collect2: ld returned 1 exit status
error: Command "/usr/bin/g77 -shared 
build/temp.linux-i686-2.4/scipy/corelib/blasdot/_dotblas.o -L/usr/lib -lblas 
-lg2c -o build/lib.linux-i686-2.4/scipy/lib/_dotblas.so" failed with exit 
status 1
and here I try to import scipy:
In [1]: from scipy import *
---------------------------------------------------------------------------
exceptions.ImportError Traceback (most recent 
call last)
/home/darren/<console>
ImportError: No module named scipy
Darren

On Sunday 20 November 2005 5:47 pm, Robert Kern wrote:
> Darren Dale wrote:
> > The last couple of days, I have been thinking about scipy_core's atlas
> > dependency, which might be a big barrier for some. There is this issue
> > with getting the full lapack instead of the truncated version, for
> > example. I don't know how difficult it is to compile atlas, having been
> > screened from the process by gentoo's package manager. The mpl devs have
> > put a lot of effort into making mpl easily accessible to the newbies
> > (remember the backend issues circa 0.50?) so I am concerned about
> > erecting new barriers now. Will scipy_core ever include something like
> > Numeric's lapack_lite?
>
> scipy_core does not depend on ATLAS. It already has lapack_lite.
>
> [svk-projects]$ ls scipy_core/scipy/corelib/lapack_lite
> blas_lite.c dlapack_lite.c f2c_lite.c zlapack_lite.c
> dlamch.c f2c.h lapack_litemodule.c
Interesting. A couple days ago I removed atlas, blas and lapack, removed my 
site.cfg, and was unable to install scipy_core. I'll try again, maybe I did 
something wrong.

>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> Hi, Do you know where I can get the 0.85 package for
 Vineet> ubuntu. I installed the one in:
 Vineet> http://peds-pc311.bsd.uchicago.edu binary/
 Vineet> but that is an older version.
I just updated the repository -- try updating and then reinstalling.
JDH

Darren Dale wrote:
> The last couple of days, I have been thinking about scipy_core's atlas 
> dependency, which might be a big barrier for some. There is this issue with 
> getting the full lapack instead of the truncated version, for example. I 
> don't know how difficult it is to compile atlas, having been screened from 
> the process by gentoo's package manager. The mpl devs have put a lot of 
> effort into making mpl easily accessible to the newbies (remember the backend 
> issues circa 0.50?) so I am concerned about erecting new barriers now. Will 
> scipy_core ever include something like Numeric's lapack_lite?
scipy_core does not depend on ATLAS. It already has lapack_lite.
[svk-projects]$ ls scipy_core/scipy/corelib/lapack_lite
blas_lite.c dlapack_lite.c f2c_lite.c zlapack_lite.c
dlamch.c f2c.h lapack_litemodule.c
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

On Sunday 20 November 2005 1:55 am, Travis Oliphant wrote:
> John Hunter wrote:
> >Travis, Perry, Todd and I have been
> >discussing the benefits of changing matplotlib to work *only* with the
> >new scipy, which include faster build times, smaller binaries, less
> >complexity and pushing the community to a single array object. Since
> >the new array interface works with Numeric 24, recent numarray or the
> >new scipy, *any* of these array packages would work with a matplotlib
> >compiled just for scipy. We decided to hold off on doing this until
> >scipy installations issues were sorted out even on semi-obscure
> >platforms -- Travis, what's your sense of this?
>
> My sense is that scipy_core installation is working on as many platforms
> as Numeric did. I'd personally love to see matplotlib move to a single
> scipy core build as soon as possible. This would encourage even more
> installation and testing of the new scipy core and help us iron out any
> remaining issues even faster.
>
> However, as long as matplotlib users have a sense that this is the
> direction matplotlib is headed, I see nothing wrong with making a
> release with the 3-supported arrays (especially since somebody has done
> all of the work already :-) ), and then making a release after that
> build only with new scipy core.
>
> Just having the ability to build against new scipy will still encourage
> some to make the transition (and that will help with continued testing).
The last couple of days, I have been thinking about scipy_core's atlas 
dependency, which might be a big barrier for some. There is this issue with 
getting the full lapack instead of the truncated version, for example. I 
don't know how difficult it is to compile atlas, having been screened from 
the process by gentoo's package manager. The mpl devs have put a lot of 
effort into making mpl easily accessible to the newbies (remember the backend 
issues circa 0.50?) so I am concerned about erecting new barriers now. Will 
scipy_core ever include something like Numeric's lapack_lite?
As a staff scientist at a national lab, I will be creating tools to aid our 
users in data visualization and analysis. Some of our projects involve 
extensive outreach efforts, involving gradeschool, highschool, and colleges 
around the country. My collaborators don't care if they are using matlab, 
python or whatever, as long as it is easy to use and they can get their 
analysis done.
I suggest that mpl not commit to requiring scipy *instead* of numeric or 
numarray until scipy_core can be built without external math libraries (like 
numarray and Numeric), and has proved to be a piece of cake to install 
on the major os's/distributions known to be used in this community. For 
example, scipy/distutils is still missing a site.cfg.example. I've been around 
long enough to know about site.cfg from scipy-0.3.2, but even so, when I 
build on Gentoo, I still have to edit system_info.py for new scipy to find 
the blas libraries.
I'm impressed with scipy, and hope the numeric/numarray community will adopt 
it quickly. But I don't want to advocate using MPL as a vehicle to force such 
an adoption prematurely.
Respectfully,
Darren

Hi,
 
Do you know where I can get the 0.85 package for ubuntu. I installed the one
in:
 
http://peds-pc311.bsd.uchicago.edu binary/
 
but that is an older version.
 
Thanks,
 
VJ
 

John Hunter wrote:
.....
> So my inclination is to include your patch now, during a transition
> period, and then move over to a new scipy only build, retaining the
> numerix layer so Numeric, numarray and (new) scipy users can continue
> to use mpl transparently. In particular we need to make sure that
> basemap which uses numarray.ndimage continues to work.
> 
John:
Basemap no longer uses nd_image, I've recoded the interp function in 
pure python, so it should work with scipy_core.
-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

John Hunter wrote:
>I read over the patch and it looks like you did a very thorough job.
>Thanks! In the near term, this means that mpl would compile three
>shared object files for each of the three array objects for each
>extension module, which of course will increase compile times and
>binary distribution sizes. Travis, Perry, Todd and I have been
>discussing the benefits of changing matplotlib to work *only* with the
>new scipy, which include faster build times, smaller binaries, less
>complexity and pushing the community to a single array object. Since
>the new array interface works with Numeric 24, recent numarray or the
>new scipy, *any* of these array packages would work with a matplotlib
>compiled just for scipy. We decided to hold off on doing this until
>scipy installations issues were sorted out even on semi-obscure
>platforms -- Travis, what's your sense of this?
> 
>
My sense is that scipy_core installation is working on as many platforms 
as Numeric did. I'd personally love to see matplotlib move to a single 
scipy core build as soon as possible. This would encourage even more 
installation and testing of the new scipy core and help us iron out any 
remaining issues even faster. 
However, as long as matplotlib users have a sense that this is the 
direction matplotlib is headed, I see nothing wrong with making a 
release with the 3-supported arrays (especially since somebody has done 
all of the work already :-) ), and then making a release after that 
build only with new scipy core. 
Just having the ability to build against new scipy will still encourage 
some to make the transition (and that will help with continued testing). 
>So my inclination is to include your patch now, during a transition
>period, and then move over to a new scipy only build, retaining the
>numerix layer so Numeric, numarray and (new) scipy users can continue
>to use mpl transparently. In particular we need to make sure that
>basemap which uses numarray.ndimage continues to work.
> 
>
With the patch already submitted, I think this makes a lot of sense. 
I'd still like to encourage people to help us test scipy core, though. 
While you may still find occasional problems (which are typically fixed 
quickly), the system is working quite well. The sooner we can merge to 
one array object, the more we will be able to help each other make it a 
better object, and the sooner we will be able to ease the burden of 
third-party packages that use arrays, and eliminate the need for heroic 
efforts like the numerix layer.
Best regards,
-Travis

I just submitted a patch to add a new non-interactive backend that
produces enhanced metafiles, an OpenOffice and Microsoft Windows
scalable graphics format that can also be embedded in .rtf files.
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1361839&group_=
id=3D80706&atid=3D560722
The backend is based on my pyemf package that I finally released with
its first public beta:
http://pyemf.sourceforge.net
The API should be stable -- I'm only planning on adding to it and not
changing any existing method signatures in the version 2.0.* series.
Oh, and I didn't say so in the patch itself, but I'm happy to donate
the patch to matplotlib under the default matplotlib license.
Rob

John Hunter wrote:
>>>>>>"daishi" == daishi <da...@eg...> writes:
> 
> 
> daishi> I've submitted the following:
> daishi> http://sourceforge.net/tracker/index.php?
> daishi> func=detail&aid=1360855&group_id=80706&atid=560722
> 
> daishi> This patch allows one to use matplotlib with (just) the
> daishi> new scipy.
> 
> Just for clarification, when you say "just" the new scipy, you mean
> that it works with Numeric, numarray *and* the new scipy, not that it
> works with the new scipy and only the new scipy.
> 
> I read over the patch and it looks like you did a very thorough job.
> Thanks!
Minor fix needed to avoid unpleasant surprises for users who have the old 
scipy on their import path:
try:
 import scipy
 if hasattr(scipy,'__core_version__'):
 NUMERIX.append('scipy')
except ImportError:
 pass
You want to make sure that you only do this for users of the _new_ scipy, not 
the old one.
Cheers,
f

>>>>> "daishi" == daishi <da...@eg...> writes:
 daishi> I've submitted the following:
 daishi> http://sourceforge.net/tracker/index.php?
 daishi> func=detail&aid=1360855&group_id=80706&atid=560722
 daishi> This patch allows one to use matplotlib with (just) the
 daishi> new scipy.
Just for clarification, when you say "just" the new scipy, you mean
that it works with Numeric, numarray *and* the new scipy, not that it
works with the new scipy and only the new scipy.
I read over the patch and it looks like you did a very thorough job.
Thanks! In the near term, this means that mpl would compile three
shared object files for each of the three array objects for each
extension module, which of course will increase compile times and
binary distribution sizes. Travis, Perry, Todd and I have been
discussing the benefits of changing matplotlib to work *only* with the
new scipy, which include faster build times, smaller binaries, less
complexity and pushing the community to a single array object. Since
the new array interface works with Numeric 24, recent numarray or the
new scipy, *any* of these array packages would work with a matplotlib
compiled just for scipy. We decided to hold off on doing this until
scipy installations issues were sorted out even on semi-obscure
platforms -- Travis, what's your sense of this?
So my inclination is to include your patch now, during a transition
period, and then move over to a new scipy only build, retaining the
numerix layer so Numeric, numarray and (new) scipy users can continue
to use mpl transparently. In particular we need to make sure that
basemap which uses numarray.ndimage continues to work.
Does this sound like the right approach?
JDH

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Awesome, thanks! Out of curiousity... did you figure
 Charlie> this out visually or by comparing with something?
Let's just say I've encountered the flipy bug before :-)
JDH

Awesome, thanks! Out of curiousity... did you figure this out
visually or by comparing with something?
- Charlie
On 11/18/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> A challenge to the community! ;) Run the current
> Charlie> cursor.py example with the TkAgg backend. (blitting
> Charlie> should be on) i.e. python cursor.py -dTkAgg
>
> Charlie> Why does the blitting not update the entire axis? Any
> Charlie> help on this is greatly appreciated.
>
> THere was a flipy offset needed in _tkagg.cpp
>
> int srcheight =3D (int)aggRenderer->get_height();
> //...
> desty =3D srcheight-(int)t;
>
> I just commited this to CVS -- take it for a test drive.
>
> Checking in src/_tkagg.cpp;
> /cvsroot/matplotlib/matplotlib/src/_tkagg.cpp,v <-- _tkagg.cpp
> new revision: 1.10; previous revision: 1.9
>
> JDH
>

I've submitted the following:
	http://sourceforge.net/tracker/index.php? 
func=detail&aid=1360855&group_id=80706&atid=560722
This patch allows one to use matplotlib with (just)
the new scipy.
The matplotlib built with this patch and just
the new scipy passes the examples/backend_driver.py
test with errors only occuring on those tests which
explicitly includes numarray, and a few others which
i believe are unrelated to the patch.
There are some issues with parallel installation.
I have only tested this with a python installation that
has only the new scipy. In principle, this should be
compatible with a parallel installation of scipy and
numarray, but scipy and Numeric will not work, because
I select to build extensions only for one or the other.
d

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> A challenge to the community! ;) Run the current
 Charlie> cursor.py example with the TkAgg backend. (blitting
 Charlie> should be on) i.e. python cursor.py -dTkAgg
 Charlie> Why does the blitting not update the entire axis? Any
 Charlie> help on this is greatly appreciated.
THere was a flipy offset needed in _tkagg.cpp
 int srcheight = (int)aggRenderer->get_height();
 //...
 desty = srcheight-(int)t; 
I just commited this to CVS -- take it for a test drive.
Checking in src/_tkagg.cpp;
/cvsroot/matplotlib/matplotlib/src/_tkagg.cpp,v <-- _tkagg.cpp
new revision: 1.10; previous revision: 1.9
JDH

A challenge to the community! ;)
Run the current cursor.py example with the TkAgg backend. (blitting
should be on)
i.e. python cursor.py -dTkAgg
Why does the blitting not update the entire axis? Any help on this is
greatly appreciated.
Thanks,
 Charlie
On 11/10/05, Charlie Moad <cw...@gm...> wrote:
> So this happens with TkAgg and blitting. Here is the sample script:
>
> #!/usr/bin/env python
> import matplotlib; matplotlib.use('TkAgg')
> import pylab
> from matplotlib.widgets import SpanSelector
>
> fig =3D pylab.figure()
> ax =3D fig.add_subplot(111)
>
> ax.plot(pylab.rand(100))
> def onselect(vmin, vmax):
> print vmin, vmax
>
> span =3D SpanSelector(ax, onselect, 'horizontal', useblit=3DTrue,
> rectprops=3Ddict(alpha=3D0.5, facecolor=3D'red') )
>
> pylab.show()
>
> Adjust the subplot params then you will see the distortion. With 2
> subplots the spanselector never visually appears, but the callback is
> called.
>
> Thanks,
> Charlie
>
> On 11/9/05, Charlie Moad <cw...@gm...> wrote:
> > I will have to do more testing, but I am calling
> > figure.subplots_adjust, not adjusting with the widget. This is also
> > through the oo interface. I will try to write a sample script and get
> > back to the list.
> >
> > Thanks,
> >
> > On 11/9/05, John Hunter <jdh...@ac...> wrote:
> > > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> > >
> > > Charlie> I guess I should have mentioned TkAgg CVS. I didn't
> > > Charlie> think the problem would be specific to a backend, so I
> > > Charlie> didn't try any others. Also, when I have more than one
> > > Charlie> subplot, nothing is drawn period.
> > >
> > > tkagg works for me, as do multiple subplots. Weird. I'm using
> > > examples/span_selector.py. You too?
> > >
> > > JDH
> > >
> >
>

On Thursday 17 November 2005 10:24 pm, John Hunter wrote:
> Darren found this problem with creating a temporary dir with
> python2.2. I don't have a 2.2 install laying around. If someone
> does, could you take a minute and find what the proper way is to avoid
> this err:
>
> t = tempfile.TemporaryFile(dir=p)
> TypeError: TemporaryFile() got an unexpected keyword argument 'dir'
Here is the docstring for tempfile.TemporaryFile in python-2.2:
TemporaryFile(mode='w+b', bufsize=-1, suffix='')
 Create and return a temporary file (opened read-write by default).
Darren

If I do 
 ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True))
only the "x1e6" multiplier is rendered in mathtext, which makes the
tick labels and the multiplier look different. Is this done on
purpose, or an inadvertent omission?
The following one-line change makes the tick labels use mathtext.
--- ticker.py.orig 2005年06月14日 00:40:26.000000000 +0300
+++ ticker.py 2005年11月16日 12:11:29.055601000 +0200
@@ -337,6 +337,7 @@
 for loc in locs]
 sigfigs.sort()
 self.format = '%1.' + str(sigfigs[-1]) + 'f'
+ if self._useMathText: self.format = '$' + self.format + '$'
 
 def pprint_val(self, x):
 xp = (x-self.offset)/10**self.orderOfMagnitude
-- 
Jouni K Seppänen

Hi,
I have recently started to make plots with matplotlib. It's a great tool!
When trying to change the width of ticklines, I noticed that
axis.get_ticklines() only returns the line2D objects for the major
ticks. But one might want to change the linewidth of the minor ticks.
Hence, I propose something like
 def get_minor_ticklines(self):
 'Return the minor ticklines lines as a list of Line2D instance'
 lines =3D []
 for tick in self.minorTicks:
 lines.append(tick.tick1line)
 lines.append(tick.tick2line)
 return silent_list('Line2D minor ticklines', lines)
in class Axis. What do people think?
Also note, that, in fact, ticks are 'markers' and one has to change the
markeredgewidth (mew).
 - Christian

SGkgdGhlcmUsCkkgaGF2ZSBwcm9ibGVtIHdpdGggZW1iZWRkaW5nIE1QTCBpbnRvIG15IGFwcGxp
Y2F0aW9uLgpGbyBleGFtcGxlOgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyBxdGVtYi5weSBmaWxlCmltcG9ydCBtYXRwbG90bGli
Cm1hdHBsb3RsaWIudXNlKCdBZ2cnKSAjIG5lZWQgdG8gc2V0IGJlZm9yZSBpbXBvcnRpbmcgcHls
YWIKCmZyb20gc3lzIGltcG9ydCBhcmd2LGV4aXQKZnJvbSBweWxhYiBpbXBvcnQgKgoKZnJvbSBt
YXRwbG90bGliLmJhY2tlbmRzLmJhY2tlbmRfcXRhZ2cgaW1wb3J0IEZpZ3VyZUNhbnZhc1FUQWdn
IGFzIEZpZ3VyZUNhbnZhcwpmcm9tIG1hdHBsb3RsaWIuZmlndXJlIGltcG9ydCBGaWd1cmUKCmZy
b20gcXQgaW1wb3J0ICoKCmEgPSBRQXBwbGljYXRpb24oYXJndikKdyA9IFFXaWRnZXQoKQoKZmln
dXJlKDEpCnN1YnBsb3QoMTExKQpwbG90KFsxLDIsM10sIFswLjIsIDIuMSwgMS4xXSkKCmNhbnZh
cyA9IEZpZ3VyZUNhbnZhcyhnY2YoKSkKY2FudmFzLnJlcGFyZW50KHcsIFFQb2ludCgwLCAwKSkK
CmwgPSBRVkJveExheW91dCh3KQpsLmFkZFdpZGdldChjYW52YXMpCgphLnNldE1haW5XaWRnZXQo
dykKCncuc2hvdygpCmV4aXQoYS5leGVjX2xvb3AoKSkKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMgcXRlbWIucHkgZmlsZQoKSSBo
YXZlIHByb2JsZW1zIHdpdGggcnVubmluZyBxdGVtYi5weS1pdCByZXBvcnRzOgoKUUFwcGxpY2F0
aW9uOiBUaGVyZSBzaG91bGQgYmUgbWF4IG9uZSBhcHBsaWNhdGlvbiBvYmplY3QKCmFuZCBpdCBp
cyBpbXBvc3NpYmxlIHRvIGNsb3NlIHdpbmRvdyAoc2ltcGx5IGZyZWV6ZXMpLgoKCgpGSVg6Cldo
ZW4gY29tbWVudCBvdXQgbGFzdCBsaW5lcyBpbiBiYWNrZW5kcy9iYWNrZW5kX3F0LnB5OgoKI2Ny
ZWF0ZVFBcHAgPSBxdC5RQXBwbGljYXRpb24uc3RhcnRpbmdVcCgpCiNpZiBjcmVhdGVRQXBwOgoj
ICAgIGlmIERFQlVHOiBwcmludCAiU3RhcnRpbmcgdXAgUUFwcGxpY2F0aW9uIgojICAgIHF0YXBw
bGljYXRpb24gPSBxdC5RQXBwbGljYXRpb24oIFsiICJdICkKCgppdCB3b3JrcyBmaW5lLgoKClNv
LCBJIG15IG9waW5pb24sIGl0IG5lZWRzIGRpZmZlcmVudCBRQXBwbGljYXRpb24gcnVubmluZyBp
bnN0YW5jZSBjaGVjay4KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgaXQ/CgpSZWdhcmRzCkppcmkK

> On Tue, 2005年11月15日 at 20:30 -0800,
> mat...@li... wrote:
> > Hi,
> > 
> > With matplotlib-0.84, pythonw embedding_in_qt.py
> > returns several
> > of these messages:
> > ___
> > Traceback (most recent call last):
> > File "embedding_in_qt.py", line 54, in sizeHint
> > w, h = self.fig.get_width_height() 
> > AttributeError: Figure instance has no attribute
> > 'get_width_height'
> > ___
> > With matplotlib-0.82 the example works fine.
> > Changelog shows 
> > 2005年06月18日 Move Figure.get_width_height() to
> > FigureCanvasBase and return 
> > int instead of float. - SC 
> > Is this a bug, or am I missing something?
> > 
> > Thanks,
> > 
> > Virgil
The self.fig.get_width_height() should be
self.get_width_height(). Changed in CVS.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

Hi,
With matplotlib-0.84, pythonw embedding_in_qt.py
returns several
of these messages:
___
Traceback (most recent call last):
 File "embedding_in_qt.py", line 54, in sizeHint
 w, h = self.fig.get_width_height() 
AttributeError: Figure instance has no attribute
'get_width_height'
___
With matplotlib-0.82 the example works fine.
Changelog shows 
2005年06月18日 Move Figure.get_width_height() to
FigureCanvasBase and return 
 int instead of float. - SC 
Is this a bug, or am I missing something?
Thanks,
Virgil
	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Marco Presi wrote:
>Hi,
>
> please find here a patch by Aurelien Jarno <au...@de...>,
> that allow matplotlib to build on Debian GNU/kFreeBSD systems[1].
> 
>
Committed to CVS. Thanks.

Hi,
 please find here a patch by Aurelien Jarno <au...@de...>,
 that allow matplotlib to build on Debian GNU/kFreeBSD systems[1].
 This patch has been included in the official Debian package[2].
 We are glad to receive comments and suggestions about the Debian
 packaging of matplotlib.
 
 Regards
 Marco Presi 
[1] http://io.debian.net
[2] http://packages.debian.org/unstable/source/matplotlib
-- 
"I videogiochi non influenzano i bambini. Voglio dire, se Pac-Man avesse
influenzato la nostra generazione, staremmo tutti saltando in sale
scure, masticando pillole magiche e ascoltando musica elettronica
ripetitiva."
"Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we were all jumping in dark rooms, chomping pills and
listening to electronic repeating music."
Kristian Wilson, Nintendo Inc. 1989

So this happens with TkAgg and blitting. Here is the sample script:
#!/usr/bin/env python
import matplotlib; matplotlib.use('TkAgg')
import pylab
from matplotlib.widgets import SpanSelector
fig =3D pylab.figure()
ax =3D fig.add_subplot(111)
ax.plot(pylab.rand(100))
def onselect(vmin, vmax):
 print vmin, vmax
span =3D SpanSelector(ax, onselect, 'horizontal', useblit=3DTrue,
 rectprops=3Ddict(alpha=3D0.5, facecolor=3D'red') )
pylab.show()
Adjust the subplot params then you will see the distortion. With 2
subplots the spanselector never visually appears, but the callback is
called.
Thanks,
 Charlie
On 11/9/05, Charlie Moad <cw...@gm...> wrote:
> I will have to do more testing, but I am calling
> figure.subplots_adjust, not adjusting with the widget. This is also
> through the oo interface. I will try to write a sample script and get
> back to the list.
>
> Thanks,
>
> On 11/9/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> > Charlie> I guess I should have mentioned TkAgg CVS. I didn't
> > Charlie> think the problem would be specific to a backend, so I
> > Charlie> didn't try any others. Also, when I have more than one
> > Charlie> subplot, nothing is drawn period.
> >
> > tkagg works for me, as do multiple subplots. Weird. I'm using
> > examples/span_selector.py. You too?
> >
> > JDH
> >
>