matplotlib-devel Mailing List for matplotlib

>>>>> "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

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?
I should note that I'v also seen this same crash with 0.83.2 official.
I haven't bothered to track it down, because I hardly ever use GTK except when 
testing for problems on the list.
It may not happen outside of ipython, if somehow the crash is triggered by the 
threading tricks which ipython uses to enable GTK interactive use. Nasty...
Cheers,
f

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?
John Hunter wrote:
>>>>>>"Abraham" == Abraham Schneider <ab...@cn...> writes:
>>>>>> 
>>>>>>
>
> Abraham> Okay, here's the patch. I'm also including a quick demo
> Abraham> with a button that gets added directly to the canvas.
>
>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.
>
> Abraham> On a side note, I can't get the CVS version to work under
> Abraham> ipython, and get this error (it was working fine with
> Abraham> 0.83.2):
> Abraham> ---------------------------------------------------------------------------
> Abraham> exceptions.SystemError Traceback (most recent call last)
>
> Abraham> SystemError: Objects/moduleobject.c:48: bad argument to
> Abraham> internal function Segmentation fault
>
>Have you done the standard clean install
>
> > sudo rm -rf build /your/path/to/site-packages/matplotlib
> > sudo python setup.py install
>
>I recently upgraded pycxx in CVS and my first guess is you have some stale
>object code lying around.
>
>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
> 
>

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Okay, here's the patch. I'm also including a quick demo
 Abraham> with a button that gets added directly to the canvas.
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.
 Abraham> On a side note, I can't get the CVS version to work under
 Abraham> ipython, and get this error (it was working fine with
 Abraham> 0.83.2):
 Abraham> ---------------------------------------------------------------------------
 Abraham> exceptions.SystemError Traceback (most recent call last)
 Abraham> SystemError: Objects/moduleobject.c:48: bad argument to
 Abraham> internal function Segmentation fault
Have you done the standard clean install
 > sudo rm -rf build /your/path/to/site-packages/matplotlib
 > sudo python setup.py install
I recently upgraded pycxx in CVS and my first guess is you have some stale
object code lying around.
JDH

Okay, here's the patch. I'm also including a quick demo with a button 
that gets added directly to the canvas.
On a side note, I can't get the CVS version to work under ipython, and 
get this error (it was working fine with 0.83.2):
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most 
recent call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
Abe
John Hunter wrote:
>>>>>>"Abraham" == Abraham Schneider <ab...@cn...> writes:
>>>>>> 
>>>>>>
>
> Abraham> Is there a reason that for the GTK backend
> Abraham> gtk.DrawingArea was used instead of gtk.Layout? As far as
> Abraham> I can tell gtk.Layout can do everything that
> Abraham> gtk.DrawingArea can, but has the additional advantage
> Abraham> that you can place widgets on the canvas, which can be
> Abraham> extremely useful. I tried a quick patch (which I can send
> Abraham> if anyone wants), where I got it working fine. The main
> Abraham> changes (there aren't many) are where changes to the
> Abraham> window would be make, 'self.window' needs to be replaced
> Abraham> with 'self.bin_window', and I also found I had to connect
> Abraham> to the 'size-allocate' event to have it properly
> Abraham> redrawwhen the window size changed.
>
>
> Abraham> As a side note, one feature that this might allow, would
> Abraham> be to allow for matplotlib-widgets to be drawn using the
> Abraham> GTK if the backend were detected (much like how SWT, for
> Abraham> Eclipse works).
>
>
>This sounds useful -- could you post a patch against CVS on the
>sourceforge site (and email here when it is up) so we can test it.
>I think the only reason that this wasn't used initially was ignorance
>on my part. I was hoping I could blame version numbers, that this
>wasn't available in pygtk 1.99.16 when mpl was released, but on quick
>inspection this explanation does not appear to hold water.
>
> Abraham> Also, on a complete tanget, does anyone know of a good
> Abraham> method of saving animations done in MPL? The only two
> Abraham> methods that I can think of right now are to (1)
> Abraham> interface with matlab, or (2) save each frame, and create
> Abraham> an animated gif. As my movies are fairly large, neither
> Abraham> seem like a great option.
>
> Abraham> After searching around some, I found pymedia, but when I
> Abraham> try to import it, all it manages to do is crash. While a
> Abraham> SWIG interface could be created for FFMPEG, it would be
> Abraham> nice if there were some other option.
>
>Something like this could usefully be placed in a toolkit following
>the basemap model, where adding an extra layer of extension code
>doesn't pose any installation or distribution woes for the core. I
>think it would be useful.
>
>In the meantime, I typically save a series of PNGs and convert them to
>MPEG using image magick's "convert" or mencoder.
>
> http://matplotlib.sourceforge.net/faq.html#MOVIE
>
>See also examples/movie_demo.py.
>
>If you come up with other/better alternatives, let us know.
>
>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
> 
>

There is a new method in the figure canvas in CVS that I would like
the maintainers of the various GUI backends to implement 
class FigureCanvasYourBackend
 def resize(self, w, h):
 """
 set the canvas size in pixels
 """
 pass
This should set the canvas (not window) size and trigger a GUI resize
event so that the window is resized accordingly. There is a reference
implementation in backend_gtk.py. You should be able to lift the
logic for computing the new canvas size directly from that code.
Among other things, this will allow better control of the canvas size
from a script or shell. Eg, the following works with GTKAgg in an
interactive session:
 In [1]: fig = figure()
 In [2]: fig.set_figsize_inches(3,4,forward=True)
 In [3]: fig.canvas.resize(500,600)
Ie, you can set the canvas size either in pixels or inches depending
on which method you choose. 
Also, I added a new connect signal 'resize_event' that triggers a
backend_bases.ResizeEvent on a canvas.resize. You should call
 self.resize_event()
from the part of your code that handles GUI configure events (see for
example the GTK and GTKAgg backends). Note depending on your toolkit,
you may not want to call this from the FigureCanvas.resize method.
Eg, in GTK* calling "canvas.resize" triggers a call to
canvas.configure_event, which in turn sets the new figure size
properties and once all this is done, calls canvas.resize_event.
Here is some test code
 from pylab import figure, connect, show
 fig = figure()
 def resize(event):
 print 'resize canvas', event.width, event.height
 connect('resize_event', resize)
 show()
Checking in lib/matplotlib/backend_bases.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backend_bases.py,v <-- backend_bases.py
new revision: 1.69; previous revision: 1.68
Thanks!
JDH

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Is there a reason that for the GTK backend
 Abraham> gtk.DrawingArea was used instead of gtk.Layout? As far as
 Abraham> I can tell gtk.Layout can do everything that
 Abraham> gtk.DrawingArea can, but has the additional advantage
 Abraham> that you can place widgets on the canvas, which can be
 Abraham> extremely useful. I tried a quick patch (which I can send
 Abraham> if anyone wants), where I got it working fine. The main
 Abraham> changes (there aren't many) are where changes to the
 Abraham> window would be make, 'self.window' needs to be replaced
 Abraham> with 'self.bin_window', and I also found I had to connect
 Abraham> to the 'size-allocate' event to have it properly
 Abraham> redrawwhen the window size changed.
 Abraham> As a side note, one feature that this might allow, would
 Abraham> be to allow for matplotlib-widgets to be drawn using the
 Abraham> GTK if the backend were detected (much like how SWT, for
 Abraham> Eclipse works).
This sounds useful -- could you post a patch against CVS on the
sourceforge site (and email here when it is up) so we can test it.
I think the only reason that this wasn't used initially was ignorance
on my part. I was hoping I could blame version numbers, that this
wasn't available in pygtk 1.99.16 when mpl was released, but on quick
inspection this explanation does not appear to hold water.
 Abraham> Also, on a complete tanget, does anyone know of a good
 Abraham> method of saving animations done in MPL? The only two
 Abraham> methods that I can think of right now are to (1)
 Abraham> interface with matlab, or (2) save each frame, and create
 Abraham> an animated gif. As my movies are fairly large, neither
 Abraham> seem like a great option.
 Abraham> After searching around some, I found pymedia, but when I
 Abraham> try to import it, all it manages to do is crash. While a
 Abraham> SWIG interface could be created for FFMPEG, it would be
 Abraham> nice if there were some other option.
Something like this could usefully be placed in a toolkit following
the basemap model, where adding an extra layer of extension code
doesn't pose any installation or distribution woes for the core. I
think it would be useful.
In the meantime, I typically save a series of PNGs and convert them to
MPEG using image magick's "convert" or mencoder.
 http://matplotlib.sourceforge.net/faq.html#MOVIE
See also examples/movie_demo.py.
If you come up with other/better alternatives, let us know.
JDH