matplotlib-devel Mailing List for matplotlib

Jeff,

Jeff Whitaker wrote:
> Eric Firing wrote:
> 
>> Jeff, John,
>>
>> I have committed to CVS a set of changes that fix the recent bug in 
>> contourf when called with the colors kwarg, and that I hope will make 
>> contour.py and everything that uses it easier to understand and use. 
>> The CHANGELOG entry is:
>>
> Eric:  That's great - thanks a lot.  I'll be out of town this week, so 
> if you could commit that basemap patch I'd appreciate it.

Done!  Thanks for the fast response.  I hope your trip goes well.

Eric

Jeff, John,

I have committed to CVS a set of changes that fix the recent bug in 
contourf when called with the colors kwarg, and that I hope will make 
contour.py and everything that uses it easier to understand and use. 
The CHANGELOG entry is:

2005-09-25 contour.py modified to use a single ContourSet class
            that handles filled contours, line contours, and labels;
            added keyword arg (clip_ends) to contourf.
            Colorbar modified to work with new ContourSet object;
            if the ContourSet has lines rather than polygons, the
            colorbar will follow suit. Fixed a bug introduced in
            0.84, in which contourf(...,colors=...) was broken - EF

and the API_CHANGES entry is:


     Changed the internal structure of contour.py to a more OO style.
     Calls to contour or contourf in axes.py or pylab.py now return
     a ContourSet object which contains references to the
     LineCollections or PolyCollections created by the call,
     as well as the configuration variables that were used.
     The ContourSet object is a "mappable" if a colormap was used.

     Added a clip_ends kwarg to contourf. From the docstring:
              * clip_ends = True
                If False, the limits for color scaling are set to the
                minimum and maximum contour levels.
                True (default) clips the scaling limits.  Example:
                if the contour boundaries are V = [-100, 2, 1, 0, 1, 2, 
100],
                then the scaling limits will be [-100, 100] if clip_ends
                is False, and [-3, 3] if clip_ends is True.

     Changed Figure.colorbar():
         kw argument order changed;
         if mappable arg is a non-filled ContourSet, colorbar() shows
                 lines instead of polygons.
         if mappable arg is a filled ContourSet with clip_ends=True,
                 the endpoints are not labelled, so as to give the
                 correct impression of open-endedness.

     Changed LineCollection.get_linewidths to get_linewidth, for
     consistency.

-----------------------------------

The change in contour and contourf output breaks basemap.  I have made 
the necessary changes in my working copy; the diff against CVS is 
attached.  If it is OK with you, Jeff, I will commit this change.  Or if 
you would rather make the modifications yourself, let me know.

What all this implies is that the next time there is a release of mpl 
there needs to be a simultaneous basemap release, and users will need to 
be warned to update both.

Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Jordan, Correct.  I sent John a patch to fix that, but it
    Eric> didn't make it in time for 0.84.  It was a fairly large
    Eric> patch, not a quick fix, so John may want to ponder it, or
    Eric> ask me to change some things, before committing it to CVS.

Thanks for the reminder here.  I was unaware that there was an
outstanding patch on this one.  Would it be too much trouble to roll
up a new one against CVS, or even just resent the original one,
because you've sent me a number of patches and I'm not sure which one
this one is.

Or better yet, send me an sf ID and I'll add you to the commit list.

Thanks!
JDH

On Sun, 2005-09-18 at 16:45 -0400, Abraham Schneider wrote:
> Currently matplotlib already draws its widgets on the canvas, so this 
> would allow a method to instead use native widgets in place of the 
> matplotlib widgets when possible. Using native widgets has the advantage 
> of response time and having a larger library at one's disposal. Even 
> without the mapping of matplotlib->native widgets, it can be useful to 
> easily put more controls to allow the plot to be altered (e.g. playing a 
> movie, rerunning a sim, etc.) This can also be accomplished (at least 
> with GTK) by adding another toolbar, but isn't always optimal.
> 
> Is there an easy method to place widgets outside of the figure widget? 
Use the usual GTK+ widget placement methods - create a gtk.Window, add a
VBox/HBox/Table etc and place the figure widget and other widgets in the
container. This would be using the matplotlib OO interface like in
examples/embedding_in_gtk2.py

> Also, does this mean that matplotlib widgets should also not be drawn on 
> the canvas?
Should matplotlib have turned itself into a widget library / GUI toolkit?
I know that for a long time John resisted the temptation to add widgets
to matplotlib and wanted matplotlib to focus on being a plotting
library. I agree with this view and think the danger now is that
matplotlib will become too big and bloated and harder to install (like
the old SciPy?).

I would prefer to see a 'matplotlib-core' which is a minimal module that
focuses purely on plotting graphs. Other optional modules (like
'matplotlib-toolkits', 'matplotlib-widgets', etc) could then extend
'matplotlib-core' by providing extra features.

> I checked on the link you gave, and it appears the problem occurs when 
> scrolling is involved. Currently with how things are done, I don't think 
> this will happen.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

SGVsbG8sCgpJJ3ZlIHJlYWQgdGhlIHVzZXIncyBndWlkZSB0aGlzIHdlZWsgKHdoaWNoIGlzIGdy
ZWF0LCBieSB0aGUgd2F5KSwgYW5kCndyb3RlIHRoZSBzbWFsbCBtaXN0YWtlcyBJJ3ZlIGVuY291
bnRlcmVkLiBIZXJlIGFyZSBteSBzdWdnZXN0aW9uczoKCnAuIDI3OiB0aHVzIHlvdSBjYW4gY2Fs
bCAqYW55KiBBeGVzLi4uCnAuIDI4OiB0aGUgYXhlcyBjb21tYW5kICppcyogaW5pdGlhbGl6ZWQu
Li4KcC4gMzY6ICJPZnRlbiB0aW1lcyIgZG9lc24ndCBzb3VuZCBjb3JyZWN0IHRvIG1lLgpwLiAz
NzogKnRoZSogY29sb3IgbWFwcGVyIHRyYW5zZm9ybXMKcC4gNDM6ICJjbGljaykiIChubyAifS4i
KQpwLiA0OTogc2hvdWxkIHRoZXJlIGJlIGFsc28gInltaW5vckxvY2F0b3IiPwpwLiA1MjogInBv
aW50cyBhcmUgc3BlY2nvrIFlZCB1c2luZyBhIHB5dGhvbidzIGRhdGV0aW1lIG1vZHVsZSIgLT4g
ImJ5CnVzaW5nIHB5dGhvbidzIGRhdGV0aW1lIG1vZHVsZSIKcC4gNjM6ICJ5b3UgY2FuIGNyZWF0
ZSBhbnkgcGxvdHMgdXNpbmcgcHVyZSBPTyBjb2RlIHRoYXQgeW91IGNvdWxkCmNyZWF0ZSB3aXRo
IHRoZSBweWxhYiBpbnRlcmZhY2UiIC0+ICJ5b3UgY2FuIGNyZWF0ZSwgdXNpbmcgcHVyZSBPTwpj
b2RlLCBhbnkgcGxvdCB0aGF0IHlvdSBjb3VsZCBjcmVhdGUgd2l0aCB0aGUgcHlsYWIgaW50ZXJm
YWNlIgpwLiA2MzogaW5mbyAzIHBhcnRzOiB0aGUgKnB5bGFiKiBpbnRlcmZhY2UgKHBlcmhhcHMg
YWxzbyBjaGFuZ2UgMyBpbnRvCiJ0aHJlZSIsIGlmIEkgdGhpbmsgYWJvdXQgaXQpCnAuIDYzOiAi
Y2FsbHMgdG8gdGhlIGJhY2tlbmQgcmVuZGVyZXIiIC0+ICJjYWxscyB0aGUgYmFja2VuZCByZW5k
ZXJlciIKcC4gNjM6IHdoaWNoIGluIHR1cm4gKmtub3dzKiBub3RoaW5nIGFib3V0CnAuIDY0OiBp
dCBpcyBwb3RlbnRpYWxseSB1c2VmdWwgKmZvciogZGV2ZWxvcGVycwpwLiA2Njogd2hpY2ggKnVz
ZXMqIHRoZSByYyBpbmZvcm1hdGlvbgpwLiA2NjogInZlcmJvc2UuZXJybyIgLT4gInZlcmJvc2Uu
ZXJyb3IiIChJIHByZXN1bWUpCnAuIDY3OiBpZiBhbiBleGNlcHRpb24gaXMgKnJhaXNlZCoKcC4g
NzE6IHB1dCBhIHBlcmlvZCBhZnRlciAiY29uZmlndXJhdGlvbiBmaWxlIgpwLiA3MTogKnRoYXQq
IGlzLCB3aGVyZSBtYXRwbG90bGliIGluc3RhbGxzICppdHMqIGRhdGEgZmlsZXMuCgpJIGhvcGUg
dGhpcyBoZWxwcywKTm9hbQo=

Jordan,

Correct.  I sent John a patch to fix that, but it didn't make it in time 
for 0.84.  It was a fairly large patch, not a quick fix, so John may 
want to ponder it, or ask me to change some things, before committing it 
to CVS.

Eric


Jordan Dawe wrote:
> contourf appears to be broken in matplotlib-0.84 when one attempts to 
> use the 'colors=' kwarg.  I just updated from 0.83.2, and ran a script 
> that worked fine before.
> 
> This command fails:
> 
> contourf( var1[0,:,:], colors=(.2,.35,.5,.65,.85,1.) )

contourf appears to be broken in matplotlib-0.84 when one attempts to 
use the 'colors=' kwarg.  I just updated from 0.83.2, and ran a script 
that worked fine before.

This command fails:

contourf( var1[0,:,:], colors=(.2,.35,.5,.65,.85,1.) )

while this command:

contourf( var1[0,:,:] )

succeeds.  The failure message is:

Traceback (most recent call last):
  File "./kuroshio_surface_plus.py", line 24, in ?
    contourf(var1[0,:,:], colors=contourlist)
  File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 
1807, in contourf
    ret =  gca().contourf(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1255, 
in contourf
    return self._contourHelper.contourf(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 
779, in contourf
    mappable.level_upper = lev[-1]
AttributeError: 'NoneType' object has no attribute 'level_upper'

any ideas?

Jordan Dawe

I did take a look at the wiki, but for some reason I couldn't get it 
working first pass. I'll try again. I also realized that the Animation 
classes will have to be a bit more complex than I originally though, as 
they are essentially iterators, so they should be broken up into: 
ForwardAnimation, BidirectionalAnimation, and RandomAnimation.

Also, perhaps of general interest, my method of creating .MPG files with 
convert failed recently due to my movies being too long, and the huge 
number of frames cause convert to break (too many parameters on command 
line). Having no other options, I created a wrapper for FFMPEG. To save 
time (and so perhaps a better/more complete method would be better..) I 
have attached the library to this message, in case it helps anyone else. 
Of the many caveats:

(1) Only three functions are exposed, instead of the full functionality 
of FFMPEG. On the plus side, it's pretty easy to make a movie now.
(2) Most of the code is copied from output_example.c, from the FFMPEG 
source. This is in part because there is little to no documentation that 
comes with the library. To save time I kept most of the source code the 
same, but just encapsulated in with a C++ class. There are a couple 
things done in it, which I have left alone, but have no clue what they 
do (if anyone has any suggestions as to what they do [e.g. how to 
determine the size of video_outbuf_size], it would be greatly appreciated).
(3) I've never touched anything related to video before, so there's a 
good chance I messed up a bunch of other stuff.
(4) I used Boost::Python instead of SWIG, mainly because I know 
Boost::Python, and I don't know SWIG.
(5) You will  need (of course) FFMPEG installed on your computer (the 
CVS version is considered the most correct version to run)

With that said, it seems to work fairly well. Along with the library, I 
included a small test python program that shows how to use it 
(simulating the game of life). One things I've noticed, is that with 
graphs, to get any decent quality from the MPEG, you have to set the 
bitrate extremely high..

Abe

>Hey Abraham,
>
>While longer term a cross platform animation mpeg wrapper toolkit
>would indeed be nice, in the short term I think that classes like this
>can be very useful to make animation easier.  One thing I would like
>to see is support for the recent matplotlib bbox/blit animation
>features, which can make animation an order of magnitude faster.  Have
>you perused the animation wiki?
>
>Beyond that, you may want to look at the RectangleSelector and
>HorizontalSpanSelector in the widgets.py file to see how they handle
>connections to draw_events, etc....
>
>Thanks,
>JDH
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>  
>

I'm having two problems after moving from 0.8 to 0.84:

1. One grid bar is missing. It is there in some graphs
and not there in others.
2. The other problem is that the first bar is now on
the y axis. 

Good:
http://www.eswap.com/goodlabels.png

Problem:
http://www.eswap.com/badlabels2.png

Thanks,

VJ

João Luís Silva wrote:
> Hello,
> 
> When upgrading from mpl 0.82 to 0.83.2 an application I made stopped 
> working. When displaying two plots simultaneously, the second plot does 
> not respond, neither to the toolbar, nor to direct changes from the 
> program. If one keeps trying interacting with the toolbar python will 
> also freeze (or enter an infinity loop or something). It worked well on 
> mpl 0.82. I made an example script that reproduces this behaviour.
> 

I just tested with mpl 0.84 and this bug no longer occurs. I have no 
idea why, but at least it works now.

JS

Hi all,

This is a quick release in advance of scipy this Thursday.  I'm short
on time right now so I'll just paste in the CHANGELOG since the last
release.  I also have not been able to make a binary build for
python2.3 on win32, but there is a 2.4 version.  I'll get this all
sorted out next week.


2005-09-14 Added a new 'resize_event' which triggers a callback with a
           backend_bases.ResizeEvent object.  Not implemented on all
           backends - JDH

2005-09-14 font_manager.py: removed chkfontpath from x11FontDirectory() - SC

2005-09-14 Factored out auto date locator/formatter factory code into
           matplotlib.date.date_ticker_factory; applies John Bryne's
           quiver patch.

2005-09-13 Added Mark's axes positions history patch #1286915

2005-09-09 Added support for auto canvas resizing with
           fig.set_figsize_inches(9,5,forward=True) # inches
           OR
           fig.resize(400,300)  # pixels

2005-09-07 figure.py: update Figure.draw() to use the updated
           renderer.draw_image() so that examples/figimage_demo.py works again.
           examples/stock_demo.py: remove data_clipping (which no longer
           exists) - SC

2005-09-06 Added Eric's tick.direction patch: in or out in rc

2005-09-06 Added Martin's rectangle selector widget

2005-09-04 Fixed a logic err in text.py that was preventing rgxsuper
           from matching - JDH

2005-08-29 Committed Ken's wx blit patch #1275002

2005-08-26 colorbar modifications - now uses contourf instead of imshow
           so that colors used by contourf are displayed correctly.
           Added two new keyword args (cspacing and clabels) that are
           only relevant for ContourMappable images - JSWHIT

2005-08-24 Fixes a PS image bug reported by Darren - JDH

2005-08-23 colors.py: change hex2color() to accept unicode strings as well as
           normal strings. Use isinstance() instead of types.IntType etc - SC

2005-08-16 removed data_clipping line and rc property - JDH

2005-08-22 backend_svg.py: Remove redundant "x=0.0 y=0.0" from svg element.
           Increase svg version from 1.0 to 1.1. Add viewBox attribute to svg
           element to allow SVG documents to scale-to-fit into an arbitrary
           viewport - SC

2005-08-16 Added Eric's dot marker patch - JDH

2005-08-08 Added blitting/animation for TkAgg - CM

2005-08-05 Fixed duplicate tickline bug - JDH

2005-08-05 Fixed a GTK animation bug that cropped up when doing
           animations in gtk//gtkagg canvases that had widgets packed
           above them

2005-08-05 Added Clovis Goldemberg patch to the tk save dialog

2005-08-04 Removed origin kwarg from backend.draw_image.  origin is
           handled entirely by the frontend now.

2005-07-03 Fixed a bug related to TeX commands in backend_ps

2005-08-03 Fixed SVG images to respect uppoer and lower origins.

2005-08-03 Added flipud method to image and removed it from to_str.

2005-07-29 Modified figure.figaspect to take an array or number;
           modified backend_svg to write utf-8 - JDH

2005-07-30 backend_svg.py: embed png image files in svg rather than linking
           to a separate png file, fixes bug #1245306 (thanks to Norbert Nemec
           for the patch) - SC

Hello,

When upgrading from mpl 0.82 to 0.83.2 an application I made stopped 
working. When displaying two plots simultaneously, the second plot does 
not respond, neither to the toolbar, nor to direct changes from the 
program. If one keeps trying interacting with the toolbar python will 
also freeze (or enter an infinity loop or something). It worked well on 
mpl 0.82. I made an example script that reproduces this behaviour.

    I was not able to identify the cause, but neither the toolbar nor 
the specific type of graph is to blame (in my application I use imshow, 
here I use plot).

My system has Debian Sarge (stable), python 2.3.5 and pygtk 2.0.0

Best regards,
João Silva

Currently matplotlib already draws its widgets on the canvas, so this 
would allow a method to instead use native widgets in place of the 
matplotlib widgets when possible. Using native widgets has the advantage 
of response time and having a larger library at one's disposal. Even 
without the mapping of matplotlib->native widgets, it can be useful to 
easily put more controls to allow the plot to be altered (e.g. playing a 
movie, rerunning a sim, etc.) This can also be accomplished (at least 
with GTK) by adding another toolbar, but isn't always optimal.

Is there an easy method to place widgets outside of the figure widget? 
Also, does this mean that matplotlib widgets should also not be drawn on 
the canvas?

I checked on the link you gave, and it appears the problem occurs when 
scrolling is involved. Currently with how things are done, I don't think 
this will happen.

Abe

Steve Chaplin wrote:

>On Wed, 2005-09-14 at 20:32 -0700, John Hunter wrote:
>  
>
>>        OK, great.  Steve could you take a look at this when you get a
>>        minute
>>        and give some feedback about whether you think this is a god
>>        idea.
>>    
>>
>
>The patch works OK when I tried it, and the example displayed a button
>in the FigureCanvas. How is it extremely useful to place a widget on top
>of a FigureCanvas?
>
>I think a figure widget should just show figures, extra widgets can
>always be placed outside the figure widget.
>Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by
>GnomeCanvas) is more complicated and has a higher overhead.
>
>This week I read that the widget item in gnome-canvas does not work very
>well
>http://blogs.gnome.org/view/alexl/2005/09/14/0
>
>Steve
>
>Send instant messages to your online friends http://au.messenger.yahoo.com 
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>  
>

On Wed, 2005-09-14 at 20:32 -0700, John Hunter wrote:
>         OK, great.  Steve could you take a look at this when you get a
>         minute
>         and give some feedback about whether you think this is a god
>         idea.

The patch works OK when I tried it, and the example displayed a button
in the FigureCanvas. How is it extremely useful to place a widget on top
of a FigureCanvas?

I think a figure widget should just show figures, extra widgets can
always be placed outside the figure widget.
Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by
GnomeCanvas) is more complicated and has a higher overhead.

This week I read that the widget item in gnome-canvas does not work very
well
http://blogs.gnome.org/view/alexl/2005/09/14/0

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
    Abraham> suggested from previous posts). On my current system I
    Abraham> couldn't get mencoder to work correctly (or mplayer, for
    Abraham> that matter), so I had to use 'convert', but it's fairly
    Abraham> easy to change it. Of course, ideally using the FFMPEG
    Abraham> library would be best, but I don't have time to write the
    Abraham> necessary SWIG files just now.

    Abraham> Also included is a quick example of phase-shifting
    Abraham> sine-waves.

Hey Abraham,

While longer term a cross platform animation mpeg wrapper toolkit
would indeed be nice, in the short term I think that classes like this
can be very useful to make animation easier.  One thing I would like
to see is support for the recent matplotlib bbox/blit animation
features, which can make animation an order of magnitude faster.  Have
you perused the animation wiki?

Beyond that, you may want to look at the RectangleSelector and
HorizontalSpanSelector in the widgets.py file to see how they handle
connections to draw_events, etc....

Thanks,
JDH

>>>>> "shay" == shay ben michael <sha...@wa...> writes:

    shay>    I want to find out how can I capture events (mouse
    shay> clicks)from embeded plot in wxAgg. I was looking for that
    shay> information in the 'axes' documentation but didn't find the
    shay> event I was looking for.  is it possible to catch mouse
    shay> clicks events in embeded plot?

This question is more appropriate on matplotlib-users.  

Cheers,
JDH

Hi. I have the need to both display animations real time and to save 
them as files. Unfortunately, currently there doesn't seem a good 
unified method (although code currently exists on the web page to do 
both). I decided to try to unify animations with a couple of simple 
Python classes:

AnimationController - attached to an already drawn plot, and determines 
how specific plot will change over time (this is base class, so the 
functions: reset(), next(), prev(), and data() have to be overridden)
Animation - A collection of plots and AnimationControllers (1-to-1). 
Each cycle will have AnimationController update their corresponding 
plots (this is base class, so the function run() has to be overridden)

Then I have two backends for the Animation:
GTKAnimation - creates a 'live' animation
FileAnimation - creates an MPEG file

so all you need to do, is create your own AnimationController, and you 
can automatically create an MPEG file, or display the data live.

I thought I would throw this out there, and see if maybe other people 
were interested (and if maybe a toolkit should be created). Theres still 
some work to make it more flexible, and have more backends. Also, the 
FileAnimation is really a bad hack (using techniques suggested from 
previous posts). On my current system I couldn't get mencoder to work 
correctly (or mplayer, for that matter), so I had to use 'convert', but 
it's fairly easy to change it. Of course, ideally using the FFMPEG 
library would be best, but I don't have time to write the necessary SWIG 
files just now.

Also included is a quick example of phase-shifting sine-waves.

Abe

Nadia Dencheva wrote:

> I dont' understand this. It looks like it failed to find any of the 
> fonts, but then
> why does the same setup work with python?
> And the same setup works with mpl 0.83.2 and ipython, it crashes only 
> with
> mpl from cvs

Just to say that I'm keeping an eye on this, but I have no ipython-specific 
ideas I can contribute.  I looked at the log you sent, but no bulb went off in 
my head, sorry.

f

>
>  * from ipython do you get the crash if you set your backend to be Agg
>    and issue
>
>     In [1]: plot([1,2,3])
>     Out[1]: [<matplotlib.lines.Line2D instance at 0xb6cad26c>]
>
>     In [2]: savefig('test')
>
>     do you see the crash?  Of course no figure will be plotted to the
>     screen, but the png should be created

This works and the figure looks good.

>  * If you set VERBOSE=True in setup.py and verbose : 'debug' in rc,
>    and issue the plot commands in tkagg from ipython that generates
>    the crash, what does the verbose output generate, particularly the
>    last 100 lines or so?
>
Attached is the log file from

ipython -pylab myscript.py  >& log.verb.debug

with VERBOSE = True and verbose=debug.
I dont' understand this. It looks like it failed to find any of the 
fonts, but then
why does the same setup work with python?
And the same setup works with mpl 0.83.2 and ipython, it crashes only 
with
mpl from cvs


Nadia

>>>>> "Nadia" == Nadia Dencheva <den...@st...> writes:

    Nadia> So, ipython does not recognize --verbose-debug, I didn't
    Nadia> know that.

    Nadia> python myscript.py --verbose-debug >& log

Oh you're right, I forgot.  And this is an ipython only bug.  You can
set the verbose setting to debug in your rc file and then run your
example from ipython to get the verbose output from ipython.

So to clarify after this recent confusion, here are the two things
that it would help to know:

 * from ipython do you get the crash if you set your backend to be Agg
   and issue

    In [1]: plot([1,2,3])
    Out[1]: [<matplotlib.lines.Line2D instance at 0xb6cad26c>]

    In [2]: savefig('test')

    do you see the crash?  Of course no figure will be plotted to the
    screen, but the png should be created.

 * If you set VERBOSE=True in setup.py and verbose : 'debug' in rc,
   and issue the plot commands in tkagg from ipython that generates
   the crash, what does the verbose output generate, particularly the
   last 100 lines or so?

JDH

> From your verbose output it looks like a ft2font error.  Could you use
> --verbose-debug which may indicate which font is being loaded before
> the crash.  We have seen some strangeness with OS X fonts.
>
So,  ipython does not recognize --verbose-debug, I didn't know that.

python myscript.py --verbose-debug >& log

log is attached.

Thanks,
Nadia

>>>>> "Nadia" == Nadia Dencheva <den...@st...> writes:

    Nadia> I am using the TkAgg backend and was hesitant to post this
    Nadia> since everyone agrees that it works, but I rebuilt mpl from
    Nadia> cvs this morning with VERBOSE =True, and confirmed that
    Nadia> ipython still crashes. Python works fine.

    Nadia> I am using python 2.4.1, freetype 2.9 on MacOSX with the
    Nadia> X11 version of Tk.  Here's some of the output of plot().

    Nadia> FT2Font::getattr FT2Font::clear FT2Font::getattr Value::get
    Nadia> FT2Font::set_size FT2Font::getattr FT2Font::set_text Bus
    Nadia> error

So you get this with tkagg.  I assume you get this with plain-ol agg
too?

From your verbose output it looks like a ft2font error.  Could you use
--verbose-debug which may indicate which font is being loaded before
the crash.  We have seen some strangeness with OS X fonts.

JDH

I am using the TkAgg backend and was hesitant to post this since  
everyone agrees that it works,
but I rebuilt mpl from cvs this morning with VERBOSE =True, and  
confirmed that ipython
still crashes. Python works fine.

I am using python 2.4.1, freetype 2.9 on MacOSX  with the X11 version  
of Tk.
Here's some of the output of plot().

Nadia

SeparableTransformation::eval_scalars
Affine::eval_scalars
Affine::eval_scalars DONE
Affine::operator
SeparableTransformation::operator
/Users/dencheva/cvs-matplotlib/test-crash/install/matplotlib/ 
font_manager.py:984: UserWarning: Could not match sans-serif, normal,  
normal.  Returning  
/Users/dencheva/cvs-matplotlib/test-crash/install/matplotlib/share/ 
matplotlib/Vera.ttf
   warnings.warn('Could not match %s, %s, %s.  Returning %s' % (name,  
style, variant, self.defaultFont))
ft2font_module::new_ft2font
FT2Font::FT2Font
FT2Font::clear
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::setattr
FT2Font::getattr
FT2Font::clear
FT2Font::getattr
Value::get
FT2Font::set_size
FT2Font::getattr
FT2Font::set_text
Bus error

On Sep 14, 2005, at 3:47 PM, John Hunter wrote:

>>>>>> "John" == John Hunter <jdh...@ac...> writes:
>
>     John> OK, I just checked the archives.  This definitely has
>     John> cropped up before on ipython w/ matplotlib under 0.83.2.
>     John> Steve Schmerler reported it on the user's list and we had
>     John> some extensive discussions on and off list and never found
>     John> the cause.  He eventually just started using the debian
>     John> package at which point the bug hunt was terminated.
>
>     John> Fernando, if you can replicate it on your box with your
>     John> current install, maybe you can set me up with an account and
>     John> I'll log in and see if I can trace it.  It looks like it's
>     John> going to be a gtk/ipython/matplotlib/threading multi-headed
>     John> monster.
>
> OK, this is getting thornier by the minute.  Fernando gave me an
> account on his system running mpl 0.83.2 and ipython CVS and I logged
> in over X11 and was unable to reproduce the bug.  He then logged in as
> me locally so we had the same environment and got the crash.
>
> The only two differences I can see are that I have a different X11
> server on my local machine and that the delays may be different since
> he is local and I am remote over ssh.  So it could be some kind of
> nasty GUI timing threading thingie.
>
> If anyone has any ideas that these facts inspirec, fire away.
>
> JDH
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.  
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> OK, I just checked the archives.  This definitely has
    John> cropped up before on ipython w/ matplotlib under 0.83.2.
    John> Steve Schmerler reported it on the user's list and we had
    John> some extensive discussions on and off list and never found
    John> the cause.  He eventually just started using the debian
    John> package at which point the bug hunt was terminated.

    John> Fernando, if you can replicate it on your box with your
    John> current install, maybe you can set me up with an account and
    John> I'll log in and see if I can trace it.  It looks like it's
    John> going to be a gtk/ipython/matplotlib/threading multi-headed
    John> monster.

OK, this is getting thornier by the minute.  Fernando gave me an
account on his system running mpl 0.83.2 and ipython CVS and I logged
in over X11 and was unable to reproduce the bug.  He then logged in as
me locally so we had the same environment and got the crash. 

The only two differences I can see are that I have a different X11
server on my local machine and that the delays may be different since
he is local and I am remote over ssh.  So it could be some kind of
nasty GUI timing threading thingie.

If anyone has any ideas that these facts inspirec, fire away.

JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Abraham Schneider wrote:
    >> Just tried the 'rm -fr ...../site-packages/matplotlib', and I
    >> still get the same behavior. Also, if that were the cause, then
    >> shouldn't it also crash outside of ipython as well?

    Fernando> I should note that I'v also seen this same crash with
    Fernando> 0.83.2 official.

    Fernando> I haven't bothered to track it down, because I hardly
    Fernando> ever use GTK except when testing for problems on the
    Fernando> list.

    Fernando> It may not happen outside of ipython, if somehow the
    Fernando> crash is triggered by the threading tricks which ipython
    Fernando> uses to enable GTK interactive use.  Nasty...

OK, I just checked the archives.  This definitely has cropped up
before on ipython w/ matplotlib under 0.83.2.  Steve Schmerler
reported it on the user's list and we had some extensive discussions
on and off list and never found the cause.  He eventually just started
using the debian package at which point the bug hunt was terminated.

Fernando, if you can replicate it on your box with your current
install, maybe you can set me up with an account and I'll log in and
see if I can trace it.  It looks like it's going to be a
gtk/ipython/matplotlib/threading multi-headed monster.


JDH