matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:
 >> 
 Baptiste> That sounds like a good syntax. Its not a problem the
 Baptiste> share the x/ylims. As long as you can get the lazy
 Baptiste> values at Axes creation, you can set the transforms
 Baptiste> correctly. The question is whether or not to share the
 Baptiste> Axis instance. If you do, you will have trouble drawing,
 Baptiste> if you don't, you have trouble when you want to change
 Baptiste> the attributes (see below). I got away with this only
 Baptiste> because I have to draw only one "physical" axis.
Hi Baptiste,
After reading your email and studying your patch more, I now see how
to generalize this to the case of non-overlapping axes which share
either the x or y axis, eg ganged plots.
I have added some changes to CVS to support sharex and sharey kwargs
(I thought this was a better name than twinx and twiny). I had to
make some minor changes to axis to support sharing tick locators and
formatters, but nothing substantial. You can now instantiate an axes
with, eg
 subplot(212, sharex=ax1)
and ditto for sharey. The view limits, transform function, and tick
Locator and Formatter are shared. This allows you to pan and zoom on
one axes and have the others follow, which is very nice. There is a
new example showing how to use this example/shared_axis_demo.py.
I was able to remove the TwinAxes class altogether and use the shared
kwargs in its stead, which is cleaner. I preserved the "twin"
convenience function (naming it twinx) and all it does is pass the
proper kwargs and make the calls to tick_right.
examples/two_scales.py is updated
 Baptiste> I'm starting to wonder which properties of Axis we
 Baptiste> really want to share between axes: limits, scale
 Baptiste> (linear/log), fmtdata, label, tick positions (thus a
 Baptiste> common "tick factory"), tick label texts, viewLim,
 Baptiste> dataLim (we need to think about update_datalim).
 Baptiste> and which we do *not* want to share: all graphic
 Baptiste> objects, visibility of labels (ticks ?), style of ticks
 Baptiste> and tick labels (you may want smaller fonts in an
 Baptiste> inset), type of axis (XAxis, YAxis, ThetaAxis, Color,
 Baptiste> ..., for ex. we may want to plot z(x,y) as pcolor and
 Baptiste> z(x) as line with shared z lims)
 Baptiste> Maybe we want to split an axis into 2 objects ? I need
 Baptiste> to think more about this.
I don't think the datalim need to be shared because they are
responsible only for autoscaling. The new approach allows the
different axes to have different properties on their labels, eg font
size as you mentioned. While you cannot turn off labels selectively
on one axes with 
 set(ax2, xticklabels=[])
because this changes the Formatter which is shared, you can achieve
the same effect by setting the visibility property, which is not
shared
 set( ax2.get_xticklabels(), visible=False)
examples/ganged_plots.py, examples/two_scales.py, and
examples/shared_axis_demo.py show off the new features.
Let me know if this design covers the use cases you can think of.
 Baptiste> This is uncorrelated, and probably easier than the one
 Baptiste> above. We would need to modify event.inaxes to be a list
 Baptiste> (in backend_bases), and act upon all those axes in
 Baptiste> pan/zoom. When only one axes can be used (for ex. the
 Baptiste> coordinates of the mouse in the status bar), we would
 Baptiste> use event.inaxes[0], or maybe the most recently used
 Baptiste> axes (more difficult, but maybe more consistent...we'll
 Baptiste> see at implementation time).
Yes, this needs to be fixed and it is not very hard to do. There are
three event variables affected, inaxes, xdata and ydata, the latter
two give the data coords of the point in the axes the mouse is over.
As you know, the problem is that the current implementation only
registers the first axes and then breaks out of the loop. It would be
easy to fix this but I'm worried about two things: backward
compatibility (not a huge problem since only power users are using
this feature) and ease of use. It is really a corner case to be over
multiple axes, and I am hesitant to force the newbie to deal with this
in the typical case when there are no overlapping axes.
One possibility is to leave inaxes, xdata and ydata alone which
satisfies both problems above. And then to add a new attribute, axseq
which is a list of (ax, xdata, ydata ) tuples to handle the
overlapping axes case. Internally, we could use axseq so that pan/zoom
will be handled properly in the two_scales case. The draw back here
is that having more than one obvious way to do it may also confuse
people down the road. For clarity, the two interfaces I'm discussing are
def callback1(event): # current impl.
 if event.inaxes is not None:
 do_something with event.inaxes, event.xdata, event.ydata
def callback2(event): # candidate impl.
 for ax, xdata, ydata in event.axseq:
 do_something with ax, xdata, ydata
I'm weakly inclined to break backward compatibility and go with the
cleaner, comprehensive design in callback2, which on the face of it
doesn't look too hard to use. 
Suggestions?
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> John, this looks like an much improved interactive.py, is
 Steve> it OK to use it to replace interactive.py in cvs, and if so
 Steve> should the '-pylab' option be left as it is or removed to
 Steve> be compatible with the current interactive.py?
Hey Steve,
I probably just forgot to update interactive.py last time Fernando
sent it to me. Feel free to do update interactive.py and its
interface and command line args (eg, pylab or not) as you see fit.
Just update the changelog so I can include them in the next release
notes. 
After you're done, you may want to take a look at interactive.html
and/or \section{Interactive} of the user's guide, and make updates as
you see fit.
Thanks!
JDH

Steve Chaplin wrote:
> On Tue, 2005年01月25日 at 22:25 -0700, Fernando Perez wrote:
> 
>>In case anyone is interested, here's a lightweight, standalone (non-ipython) 
>>GTK threaded interactive interpreter with matplotlib support. This code is 
>>also based on the same ASPN recipe, it's basically the prototype I used to 
>>understand that recipe when I was adding the matplotlib support to IPython.
> 
> Thanks, its a good example of code.InteractiveConsole, when I saw codeop in 
> the ASPN recipe I wondered why code.py was not used.
> 
> I noticed a few small points:
> - GTKInterpreter says "Run a gtk mainloop() in a separate thread.", yet
> gtk.main() runs in the main thread, and the interpreter/console runs in
> a separate thread.
> - gtk.timeout_add() is now deprecated in favour of gobject.timeout_add()
> 
> - runsource() and runcode() are synchronised using wait()/notify() so
> they deal with one code object at a time. If self.code_to_run is changed
> to a code queue (using list.append() and list.pop(0)) then the wait
> ()/notify() could be removed and the interpreter thread would return
> immediately it adds the code to self.code_to_run and not when the main
> thread has executed the code.
I am _really_ ignorant of thread issues, and so I have avoided touching the 
threading part of this code at all, though I've always suspected it could be 
cleaner. Would you mind applying these fixes and sending it back my way 
(including the GTK stuff)? I could then port your improvements over to the 
code in ipython proper which implements this same functionality.
Cheers,
f

On Tue, 2005年01月25日 at 22:25 -0700, Fernando Perez wrote:
> In case anyone is interested, here's a lightweight, standalone (non-ipython) 
> GTK threaded interactive interpreter with matplotlib support. This code is 
> also based on the same ASPN recipe, it's basically the prototype I used to 
> understand that recipe when I was adding the matplotlib support to IPython.
Thanks, its a good example of code.InteractiveConsole, when I saw codeop in 
the ASPN recipe I wondered why code.py was not used.
I noticed a few small points:
- GTKInterpreter says "Run a gtk mainloop() in a separate thread.", yet
gtk.main() runs in the main thread, and the interpreter/console runs in
a separate thread.
- gtk.timeout_add() is now deprecated in favour of gobject.timeout_add()
- runsource() and runcode() are synchronised using wait()/notify() so
they deal with one code object at a time. If self.code_to_run is changed
to a code queue (using list.append() and list.pop(0)) then the wait
()/notify() could be removed and the interpreter thread would return
immediately it adds the code to self.code_to_run and not when the main
thread has executed the code.
> I think I sent this to John a while back so he could replace the 
> interactive.py shipped with matplotlib. I fully acknowledge in the header the 
> ASPN recipe as the origin of the threading solution.
John, this looks like an much improved interactive.py, is it OK to use
it to replace interactive.py in cvs, and if so should the '-pylab'
option be left as it is or removed to be compatible with the current
interactive.py?
Steve

John Hunter a =E9crit :
> Here is what I think would be ideal, and I wanted to sketch some of
> these ideas in hopes that you might have some ideas on how to apply
> them. Basically, the idea is that we want one axes to be able to
> share the x or y limits with another axes in a more general way. Your
> approach works fine as long as the two axes are overlayed. It would
> be nice if we could do something like
>=20
> # separate axes
> ax1 =3D subplot(211)
> plot([1,2,3])
>=20
> ax2 =3D subplot(212, twinx=3Dax1)
> plot([4,5,6])
>=20
That sounds like a good syntax.
Its not a problem the share the x/ylims. As long as you can get the lazy=20
values at Axes creation, you can set the transforms correctly. The=20
question is whether or not to share the Axis instance. If you do, you=20
will have trouble drawing, if you don't, you have trouble when you want=20
to change the attributes (see below). I got away with this only because=20
I have to draw only one "physical" axis.
> To do overlayed axes, you could do
>=20
> # overalyed axes
> ax1 =3D subplot(111)
> plot([1,2,3])
>=20
> ax2 =3D subplot(111, twinx=3Dax1, yticks=3D'right')
> plot([4,5,6])
>=20
OK, you also have to set the frame to off, we'll see the details later.=20
Maybe we can keep just the twin function in pylab.py as a shortcut.
> I think this would be a nice consistent interface and in both cases
> ax2 would share the xlim with ax1. As far as I can see, the only
> thing getting in the way of extending your approach to handle this
> case are the tick labels, since they would be in the wrong place for
> ax2 in the separate axes case. For the separate axes case, you would
> typically want tick labeling on the lower axes, but it would be ideal
> to be able to control that as well.
>=20
> I've been meaning to decouple the axis line and tick locations from
> the main axes frame so that you could have offset labels and ticks.
> Perhaps this would be a good time to make both changes together.
>=20
That one is more tricky. All of matplotlib drawing model is based on the=20
premise that one objet draws at one given place. This has many=20
advantages. It allows the object to draw itself, which is good design.=20
It is also necessary for the cases where the final size matters (fonts,=20
linewidth). I don't think we want to change that.
< I stopped here, thought about it for some time, went back later >
I'm starting to wonder which properties of Axis we really want to share=20
between axes: limits, scale (linear/log), fmtdata, label, tick positions=20
(thus a common "tick factory"), tick label texts, viewLim, dataLim (we=20
need to think about update_datalim).
and which we do *not* want to share: all graphic objects, visibility of=20
labels (ticks ?), style of ticks and tick labels (you may want smaller=20
fonts in an inset), type of axis (XAxis, YAxis, ThetaAxis, Color, ...,=20
for ex. we may want to plot z(x,y) as pcolor and z(x) as line with=20
shared z lims)
Maybe we want to split an axis into 2 objects ? I need to think more=20
about this.
> The other problem in the current implementation (and in your patch)
> stems from the fact that for event handling, only one axes gets the
> event. So in your two_scales.py example, if you pan/zoom the xlimits
> behave correctly but only one axes gets the pan/zoom event for y. It
> would be nice to pass these events on to all the axes the user is over
> to handle the case of overlapping axes.
>=20
This is uncorrelated, and probably easier than the one above. We would=20
need to modify event.inaxes to be a list (in backend_bases), and act=20
upon all those axes in pan/zoom. When only one axes can be used (for ex.=20
the coordinates of the mouse in the status bar), we would use=20
event.inaxes[0], or maybe the most recently used axes (more difficult,=20
but maybe more consistent...we'll see at implementation time).
> Just some thoughts on what I think the proper behavior should be. If
> you have any ideas on how to handle these, let me know. =20
>=20
well, we need to discuss that a little bit more, so we'll get a clearer=20
view of where we go :-)
Cheers,
Baptiste

Steve Chaplin a =E9crit :
> Regarding Baptiste's patch
> - I'm not too keen on the idea of wrapping gtk.gdk.threads_enter() /
> gtk.gdk.threads_leave() around every GDK function call.
> - I share Fernando's concern with possible problems when adding new
> widgets or embedding a matplotlib window into something else.
>=20
> My understanding is that wrapping gtk.gdk.threads_enter() /
> gtk.gdk.threads_leave() around GDK functions is not necessary if all th=
e
> GDK calls occur in the same thread. So I think a simpler solution is to
> arrange for all gui calls to go to a single thread and do away with
> enter()/leave().
>=20
This is mostly a question of taste.
A bug in the handling of threads_enter()/threads_leave() leads to a=20
deadlock, while a bug with a gui thread yields "Xlib async reply".=20
Choose which ugly death you prefer !
> I created a module that allows interactive matplotlib access from a
> python shell, its a modified version of
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109
>=20
In fact your module fits well into the framework of my proposal: all you=20
have to do is rename your gui_cmd to gtk_protect, and change a few=20
things like passing the function directly, passing the arguments, and=20
returning the value. Then you will have a drop-in replacement for=20
protect_mutex.py.
> This method seems to work for me (on Linux) and is not very intrusive t=
o
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
>=20
This is where the real beef is.
There are several strategies:
* wrap everything: this is the examples/interactive.py strategy, simple,=20
but the gui freezes on long calculations
* wrap all gui calls: this is the gui_thread strategy: elegant, but=20
difficult
* wrap only pylab functions (draw_if_interactive etc), as you seem to=20
suggest in your second email: imho this is not acceptable because it=20
breaks method calls of matplotlib objects
* draw the line somewhere in the backend: this is what I proposed.
In the end, the backends developpers have the final say, because they=20
will have to do the day-to-day maintenance.
> Any comments?
>=20
> Regards
> Steve
>=20
Cheers, BC
PS: tell me if I need to CC you or not

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:
 Baptiste> Hello, I tried to improve the way of plotting two scales
 Baptiste> (cf examples/two_scales.py). The attached patch contains
 Baptiste> the following changes:
Hi Baptiste -- I applied your patch and am very impressed. It takes a
lot of hacking through matplotlib internals to get everything working
right together with transform, axis limits and the like. Your
approach is also a significant improvement over what we currently
have.
Here is what I think would be ideal, and I wanted to sketch some of
these ideas in hopes that you might have some ideas on how to apply
them. Basically, the idea is that we want one axes to be able to
share the x or y limits with another axes in a more general way. Your
approach works fine as long as the two axes are overlayed. It would
be nice if we could do something like
 # separate axes
 ax1 = subplot(211)
 plot([1,2,3])
 ax2 = subplot(212, twinx=ax1)
 plot([4,5,6])
To do overlayed axes, you could do
 # overalyed axes
 ax1 = subplot(111)
 plot([1,2,3])
 ax2 = subplot(111, twinx=ax1, yticks='right')
 plot([4,5,6])
I think this would be a nice consistent interface and in both cases
ax2 would share the xlim with ax1. As far as I can see, the only
thing getting in the way of extending your approach to handle this
case are the tick labels, since they would be in the wrong place for
ax2 in the separate axes case. For the separate axes case, you would
typically want tick labeling on the lower axes, but it would be ideal
to be able to control that as well.
I've been meaning to decouple the axis line and tick locations from
the main axes frame so that you could have offset labels and ticks.
Perhaps this would be a good time to make both changes together.
The other problem in the current implementation (and in your patch)
stems from the fact that for event handling, only one axes gets the
event. So in your two_scales.py example, if you pan/zoom the xlimits
behave correctly but only one axes gets the pan/zoom event for y. It
would be nice to pass these events on to all the axes the user is over
to handle the case of overlapping axes.
Just some thoughts on what I think the proper behavior should be. If
you have any ideas on how to handle these, let me know. 
I just applied your two scales patch to CVS as an improved interim
solution.
Thanks!
JDH

On Wed, 2005年01月26日 at 12:17 +0800, Steve Chaplin wrote:
> I created a module that allows interactive matplotlib access from a
> python shell, its a modified version of
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109
> 
> This method seems to work for me (on Linux) and is not very intrusive to
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
I may not have clearly explained my idea. I'm not proposing another
Python shell/interpreter to run matplotlib. The mt.py module is to test
an idea without needing to modify any matplotlib code. 
To use it as intended would involve moving it into matplotlib and
getting matplotlib to call gui_cmd() to execute interactive gtk/gdk
calls in their own thread.
This is the part I'm not sure about - what is the minimal set of
functions to wrap with gui_cmd() to ensure that it encloses all gtk/gdk
functions?
gui_cmd() could be called from draw_if_interactive() and maybe
new_figure_manager(), I'm not sure where else it might be needed.
Also it would need to be fed import commands.
Steve

Steve Chaplin wrote:
> I created a module that allows interactive matplotlib access from a
> python shell, its a modified version of
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109
> 
> This method seems to work for me (on Linux) and is not very intrusive to
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
> 
> Any comments?
In case anyone is interested, here's a lightweight, standalone (non-ipython) 
GTK threaded interactive interpreter with matplotlib support. This code is 
also based on the same ASPN recipe, it's basically the prototype I used to 
understand that recipe when I was adding the matplotlib support to IPython.
The threading tricks are the gold in that recipe, but the rest of the code is 
rather messy. I pretty much rewrote it when studying it (while keeping the 
threading core). Perhaps this may be of use to others. The ASPN recipe 
duplicates a lot of the functionality in the code.py module from the standard 
library, which is completely unnecessary (it's guaranteed to be there in any 
python installation). By using code.py, the whole thing can be rewritten much 
more cleanly (and you benefit from a good implementation in the stdlib for all 
the interpreter emulation parts).
I think I sent this to John a while back so he could replace the 
interactive.py shipped with matplotlib. I fully acknowledge in the header the 
ASPN recipe as the origin of the threading solution.
The pylab support in current ipython is basically this same idea, but 
generalized to work with either GTK or WX, and blended into the IPython code 
structure (that wasn't too bad, since ipython itself is based on code.py).
Cheers,
f

Regarding Baptiste's patch
- I'm not too keen on the idea of wrapping gtk.gdk.threads_enter() /
gtk.gdk.threads_leave() around every GDK function call.
- I share Fernando's concern with possible problems when adding new
widgets or embedding a matplotlib window into something else.
My understanding is that wrapping gtk.gdk.threads_enter() /
gtk.gdk.threads_leave() around GDK functions is not necessary if all the
GDK calls occur in the same thread. So I think a simpler solution is to
arrange for all gui calls to go to a single thread and do away with
enter()/leave().
I created a module that allows interactive matplotlib access from a
python shell, its a modified version of
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109
This method seems to work for me (on Linux) and is not very intrusive to
matplotlib code - it just requires that 'gui_cmd()' is used to execute
all gui commands when in interactive mode.
Any comments?
Regards
Steve

Hi John and Fernando,
John, here is the quick answer to your questions:
* the patch does almost nothing (a few calls to a dummy function) except 
when the gui_protect rcParam is enabled
* when enabled the overhead is acceptable (on my Pentium III 500MHz), 
but import time of pylab is a little longer, because most of the work 
happens there. Also, only the functions and methods defined by 
matplotlib are protected. The idea is that if you call functions or 
methods from the gtk module, you ought to know what you're doing anyway 
(for that matter, I am not as ambitious as gui_thread).
* the patch currently doesn't work with wx because I've not finished the 
work, but it is doable. The GTK or WX mainloop is launched at the time 
the backend is imported, and only the one for the backend you are using 
will be launched.
* if you use interactive.py, or the code in IPython, you'd better not 
enable gui_protect. If you do, 2 GTK mainloops will be launched. This is 
allowed in GTK, but doesn't make sense.
* the GTK mainloop (probably same for WX) can run concurrently with tk. 
This means no problem plotting GTK from IDLE. You can even switch 
backends at runtime by reloading matplotlib.backends and matplotlib.pylab
* the GTK and WX mainloops cannot run concurrently. This is because, at 
least on Linux, WX itself launches a GTK mainloop (it's called WxGTK for 
a reason :). It might be possible to use this very mainloop to also 
display GTK figures, but I've had no luck with this until now.
Fernando, I've been looking again at gui_thread. I now understand the 
beauty and power of it, but it is also more brittle, which means a lot 
of work and testing. It might prove the best solution in the end, though.
I took no offense at all about IPython, so neither should you :-)
I just mentioned it because it is the advised solution in matplotlib doc.
Have a nice day,
BC
PS: You don't have to CC me, I'm subscribed to the list.

John Hunter wrote:
>>>>>>"Baptiste" == Baptiste Carvello <bap...@al...> writes:
> 
> 
> Baptiste> I know the patch is intrusive, though maybe not as much
> Baptiste> as it looks (everything except protect_mutex.py is
> Baptiste> pretty trivial). I didn't expected it to be accepted
> Baptiste> right away, I see it more as a contribution to the whole
> Baptiste> gui thread discution.
> 
> Baptiste> As for gui_thread, I looked at it last year, I just
> Baptiste> remember I didn't like that code that much. Maybe I
> Baptiste> should get another look...
> 
> Most of what I've heard of gui thread (caveat, the situation may be
> different now but this was the last I heard) was that the code was
> hairy, required scipy distutils to build, was wx specific and had
> problems that required significant work to fix. In that context, a
> patch, even an intrusive one, that allowed gtk* and wx* to work from
> an arbitrary python shell would be most welcome. While I think
> ipython is the one true shell, there are many other shells in
> existence and that won't change. If for example, this patch allowed
> gtk* to be used from within IDLE or pycrust in addition to the
> standard python shell, that would be a big win.
I certainly have never been a fan of digging too deep into gui_thread myself, 
I admit that much :) Last time I looked at the code, I got a bit scared. On 
the other hand, Prabhu recently did a bunch of work on it, so it may be 
cleaner/better, I just don't know.
And as I said, I really was not speaking from the ipython side of things at 
all, I don't know why Baptiste took it that way (I didn't even mention ipython 
in my post). My opinion was strictly based on the generic approach offered by 
gui_thread, and the potential benefit of doing things that way.
> The problem we need to solve is substantially easier than the one
> gui_thread wants to solve, if I understand the issues correctly. gui
> thread enables you to interact with general wx apps from a general
> python shell. We want gtk* and wx* backends to work from a general
> python shell. If this patch addresses that, it's worth a close look.
One thing that I like about gui_thread is that it works in a generic manner. 
What happens with this patch if someone uses matplotlib but adds new widgets? 
Or if they embed a matplotlib window into something else? Are such usage cases 
covered automatically, or do they require special handling by third-party code?
There certainly are benefits to a matplotlib-based self-contained solution, 
and gui_thread comes with its own baggage, so I'll let you guys judge where 
the balance rests.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Just a minor comment: insert(0) is an expensive (O(N))
 Fernando> operation on lists. This kind of problem might be better
 Fernando> addressed with a deque
 Fernando> (http://www.python.org/dev/doc/devel/lib/module-collections.html,
 Fernando> could be backported to py2.3).
If I read the patch correctly, usage_stack is being used as a simple
counter. 
I think the data structure we want is a class derived from dict that
pops elements off (preferably intelligently, ie pops the ones which
haven't been accessed in a while) when the dict length gets too long. 
In other words, we don't need to structures (cached and usage_stack)
to do the work of one
There must be such a beast in the cookbook or elsewhere, a cache
object which works like a dict but has a max size...
JDH 

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:
 Baptiste> I know the patch is intrusive, though maybe not as much
 Baptiste> as it looks (everything except protect_mutex.py is
 Baptiste> pretty trivial). I didn't expected it to be accepted
 Baptiste> right away, I see it more as a contribution to the whole
 Baptiste> gui thread discution.
 Baptiste> As for gui_thread, I looked at it last year, I just
 Baptiste> remember I didn't like that code that much. Maybe I
 Baptiste> should get another look...
Most of what I've heard of gui thread (caveat, the situation may be
different now but this was the last I heard) was that the code was
hairy, required scipy distutils to build, was wx specific and had
problems that required significant work to fix. In that context, a
patch, even an intrusive one, that allowed gtk* and wx* to work from
an arbitrary python shell would be most welcome. While I think
ipython is the one true shell, there are many other shells in
existence and that won't change. If for example, this patch allowed
gtk* to be used from within IDLE or pycrust in addition to the
standard python shell, that would be a big win.
The problem we need to solve is substantially easier than the one
gui_thread wants to solve, if I understand the issues correctly. gui
thread enables you to interact with general wx apps from a general
python shell. We want gtk* and wx* backends to work from a general
python shell. If this patch addresses that, it's worth a close look.
Baptiste, have you have a chance to test with other shells? Would
your patch break gtk* or wx* under ipython? Does it work in IDLE
and/or pycrust? Do you have any ideas on how this would affect
performance? Obviously it adds some function call overhead -- with
collections the cases where there are large numbers of calls to the
backend renderers is reduced.
Another thought spoken as a threading newbie: could this be done more
simply by, eg subclassing RendererGTK and automating the protect
wrapping. This latter approach would satisfy a couple of points: it
would not be intrusive in the base class, could be made optional via
interactive setting or rc, and would not adversely impact performance
when it was not needed (on my quick read of the patch, it looks like
the last point is already handled by the call)
 if is_interactive():
 import_protect()
I'll give your patches a test-drive. Perhaps Steve could also comment
on the gtk changes.
JDH

Baptiste Carvello wrote:
> Hello,
> 
> I'm just making a proposal. As long as the documentation points to 
> IPython for interactive use, you can't say we have a perfect solution on 
> our own :-) (this is not meant to criticize your work on IPython, it's 
> just that I feel more confortable with the usual python interface)
> 
> I know the patch is intrusive, though maybe not as much as it looks 
> (everything except protect_mutex.py is pretty trivial). I didn't 
> expected it to be accepted right away, I see it more as a contribution 
> to the whole gui thread discution.
> 
> As for gui_thread, I looked at it last year, I just remember I didn't 
> like that code that much. Maybe I should get another look...
I actually didn't have ipython in mind at all in my comment. I agree that a 
generic, shell-independent solution is a good thing to have. I just think 
that gui_thread provides a cleaner approach (if not clean code :) to the 
overall problem. gui_thread is messy, but it allows general (meaning, beyond 
matplotlib) access to gui elements from a command line. I quickly tested it 
with matplotlib and it crashed, so there's work to be done...
I was just trying to point out an alternate direction, ultimately if John is 
happy with this approach, it's his call (he gets to maintain it :)
Cheers,
f

Hello,
I'm just making a proposal. As long as the documentation points to=20
IPython for interactive use, you can't say we have a perfect solution on=20
our own :-) (this is not meant to criticize your work on IPython, it's=20
just that I feel more confortable with the usual python interface)
I know the patch is intrusive, though maybe not as much as it looks=20
(everything except protect_mutex.py is pretty trivial). I didn't=20
expected it to be accepted right away, I see it more as a contribution=20
to the whole gui thread discution.
As for gui_thread, I looked at it last year, I just remember I didn't=20
like that code that much. Maybe I should get another look...
Cheers,
BC
Fernando Perez a =E9crit :
> Just a note: are you aware of the gui_thread module in scipy? It was=20
> written exactly to do this (though it's currently WX-specific, I think)=
,=20
> and it has seen a pretty extensive amount of work. I would much rather=
=20
> see a generic, external solution be tested and improved than a=20
> matplotlib-specific rather intrusive patch. Don't take it badly, I can=
=20
> tell you've put a lot of work into this, but this kind of problem is=20
> IMHO best addressed by a more generic mechanism. The kind of attribute=
=20
> access which python allows opens the door for such a solution, as=20
> gui_thread has shown.
>=20
> gui_thread currently needs testing and improvements, but I think in the=
=20
> long run it is a cleaner, better alternative.
>=20
> Just my 2 cents.
>=20
> Cheers,
>=20
> f
>=20

Baptiste Carvello wrote:
> Hello,
> 
> here is an imporved version of the patch (minor bug corrected + diffed 
> against latest CVS).
Just a note: are you aware of the gui_thread module in scipy? It was written 
exactly to do this (though it's currently WX-specific, I think), and it has 
seen a pretty extensive amount of work. I would much rather see a generic, 
external solution be tested and improved than a matplotlib-specific rather 
intrusive patch. Don't take it badly, I can tell you've put a lot of work 
into this, but this kind of problem is IMHO best addressed by a more generic 
mechanism. The kind of attribute access which python allows opens the door 
for such a solution, as gui_thread has shown.
gui_thread currently needs testing and improvements, but I think in the long 
run it is a cleaner, better alternative.
Just my 2 cents.
Cheers,
f

Hello,
here is an imporved version of the patch (minor bug corrected + diffed 
against latest CVS).
By the way, it looks like the web interface is cutting off the patch. 
Probably the right thing given its size. Providing a link to the 
attached file would be nicer, though...
Cheers,
BC

Fernando Perez wrote:
> Just a minor comment: insert(0) is an expensive (O(N)) operation on lists. 
> This kind of problem might be better addressed with a deque 
> (http://www.python.org/dev/doc/devel/lib/module-collections.html, could be 
> backported to py2.3).
Sorry for the extra msg, here's a pure python backport of deque by R. 
Hettinger, the author of the C collections module in py2.4:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/259179
Cheers,
f

Hello,
here is the corrected patch, sorry for the noise.
Cheers,
BC

Joe wrote:
> Hello John and other devels,
> 
> John, you were right on the money in relation to the memory leak that I wrote 
> about in the previous message. Here's a rough draft of an attempt to patch 
> that up. This is my first (meaningful) attempt to submit a patch anywhere, 
> so please forgive any errors in the process. It was made with >patch -p ... 
> I think that is the accepted way to make a patch, but I'm not sure.
> *** text.py	Tue Jan 18 21:03:16 2005
> --- /root/text.py	Tue Jan 18 20:58:56 2005
> *************** class Text(Artist):
> *** 44,49 ****
> --- 44,50 ----
> 
> Artist.__init__(self)
> self.cached = {}
> + 	self.usage_stack = []
> self._x, self._y = x, y
> 
> if color is None: color = rcParams['text.color']
> *************** class Text(Artist):
> *** 193,198 ****
> --- 194,203 ----
> 
> ret = bbox, zip(lines, whs, xs, ys)
> self.cached[key] = ret
> + 	self.usage_stack.insert(0, key)
> + 	if len(self.usage_stack) > 128:
> + 	 self.usage_stack.pop()
> + 	 del self.cached[key]
> return ret
Just a minor comment: insert(0) is an expensive (O(N)) operation on lists. 
This kind of problem might be better addressed with a deque 
(http://www.python.org/dev/doc/devel/lib/module-collections.html, could be 
backported to py2.3).
Cheers,
f

Hello John and other devels,
John, you were right on the money in relation to the memory leak that I wrote 
about in the previous message. Here's a rough draft of an attempt to patch 
that up. This is my first (meaningful) attempt to submit a patch anywhere, 
so please forgive any errors in the process. It was made with >patch -p ... 
I think that is the accepted way to make a patch, but I'm not sure.
At first I wanted to plug this up by resuing the "cached" variable (by 
removing the last key from the .keys() method if the number of entries got 
too big), but I didn't like how that turned out so I decided to add a list 
which was sorted by last use. Removal when there became too many items was 
performed on the least recently used entry. I think that this way turned out 
for the better.
What might improve things is if there was a way to check how big the data 
structures which we are caching are in memory. The first thought that came 
to my mind was to dump the structures to a Python string via cPickle and 
count the bytes used, but this would be too slow I think. At the very least, 
the value could be supplied by the .matplotlibrc file, but I'm not very sure 
where all those values are read in.
Anyways too much talk for such a small fix,
Take care and happy coding,
Joe

Hello,
I got confused with my two patches. The pylab.py chunk from the other 
patch actually belongs here.
Sorry for that, I'll send a corrected version tomorrow, I need some sleep :)
Cheers,
BC

Hello,
here is a proposition of a new strategy for interactive plotting in GTK 
(probably also WX), that doesn't need IPython, and runs the mainloop in 
a separate thread from the calculations.
It has no impact on the user unless he chooses to make use of it, and a 
small impact on the backend developper.
It works in two parts:
matplotlib/__init__.py imports a gtk_protect function that returns a 
wrapper around "dangerous" functions or methods.
The one proposed here (protect_mutex.py) encloses the actual function 
call in a gtk.threads_enter() / gtk.threads_leave() pair in order to 
acquire the GTK mutex.
The same strategy seems possible in WX, though I encountered a lot of 
annoying little problems with WX 2.4. If someone is interested in taking 
over that part, please ask me (I usually don't use WX).
For the non-interactive case, matplotlib defines a dummy gtk_protect 
function which returns its own input, i.e. nothing is changed in that case.
Then all the backend as to do is call gtk_protect on dangerous functions 
or methods in order to replace them with a wrapper. The wrapper has 
little overhead, so I may have protected more than needed.
How to use:
after applying the patch, you have to change your rc params to actually 
use it. Change your .matplotlibrc to contain the following:
backend : GTKAgg # or GTK or GTKCairo
interactive : True
gui_protect : Mutex
Afterwards, you can run most of the examples with python -i, and modify 
the plots to your liking :-)
Cheers,
BC

Hello,
I tried to improve the way of plotting two scales (cf 
examples/two_scales.py). The attached patch contains the following changes:
in axis.py: allow right side label, so both y axes can get one. axis 
instances get a new property: label_position, which is left or right for 
yaxis, top or bottom for xaxis.
in axes.py: a new Axes subclass (TwinAxes) that shares the x axis with 
another. Transforms are set accordingly (lazy values for x lims are 
shared). This avoids having to change the xlim or xlabel (and so on) 2 
times.
in pylab.py: a new command (twin) that returns the twin of an axes 
instance (the current one by default), thus making it into a two scales 
plot.
How to use: see the new examples/two_scales.py for the typical use case.
Cheers,
BC