matplotlib-devel Mailing List for matplotlib

John Hunter a =E9crit :
> 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
>=20
> subplot(212, sharex=3Dax1)
>=20
> 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.
>=20
Hi John,
I like this implementation a lot. Cool stuff !
> 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
>=20
you also need to call tick_left on the original axis, but that is a=20
minor correction.
> I don't think the datalim need to be shared because they are
> responsible only for autoscaling.
>
There is still a problem because autoscaling is disabled on the second=20
axes. I have an idea on how to solve this, I'll try it and send a patch=20
later in the week.
> 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.
>=20
This sounds reasonable to me. I don't think it is confusing. If people=20
know what to do with multiple axes, they'll go with axseq, if not=20
inaxes, xdata and ydata will provide the most reasonable choice for them.
I'll play a little bit with this, and see if it breaks anything I use.
Cheers,
BC

Baptiste Carvello wrote:
> Hi,
>=20
> Steve Chaplin a =E9crit :
>>When thinking about using threads for interactive mode I had been
>>assuming people using the interactive mode would be using the pylab
>>interface, does anyone use the matplotlib class interface in interactiv=
e
>>mode?
>>
>=20
> I sometimes do.
Agreed.
One should also be able to execute interactively large scripts which may =
have=20
 been written to the OO interface. I know that I routinely test 10k LOC=
=20
modules from within ipython (though not matplotlib based). It would be I=
MHO=20
poor design to put all sorts of special-case warnings, where certain feat=
ures=20
of matplotlib would only be available in certain ways of using it. Speci=
al=20
cases lead to madness...
Note that I haven't followed the details close enough to vouch for any=20
particular approach. I just would like to see any solution implemented t=
o be=20
as clean and general as possible. As far as users are concerned, these=20
details should be, where possible, totally irrelevant (internal implement=
ation=20
only). As a reference, ipython tries mightily hard to make sure that _an=
y_=20
code which can be executed at a system command line as 'python foo.py'=20
produces identical behavior at an ipython prompt via 'run foo'. There ar=
e=20
special options to 'run' for modifying this, but the default attempts to=20
emulate python very faitfully, just with better tracebacks, debug support=
,=20
etc. And I consider deviations from this bevavior as bugs. It's not 100=
%=20
perfect, but it really works fairly well in most cases.
Regards,
f

Hi,
Steve Chaplin a =E9crit :
> What situation would yield an "Xlib async reply"?
> =20
using your mt module:
 >>> import mt
 >>> mt.gui_cmd('print "OK"')
 OK
 >>> import matplotlib
 >>> matplotlib.interactive(1)
 >>> import pylab
 Xlib: unexpected async reply (sequence 0x4b)!
This is on linux, I don't know what you get on other platforms, but I=20
guess it's just as bad.
> How does it break method calls of matplotlib objects? In interactive
> mode the gtk backend does not work (by itself) so there's nothing to
> break
Well, it depends on how ambitious you are :-)
> When thinking about using threads for interactive mode I had been
> assuming people using the interactive mode would be using the pylab
> interface, does anyone use the matplotlib class interface in interactiv=
e
> mode?
>=20
I sometimes do. However, I've painted the situation worse than it is. I=20
almost only use the setter/getter methods, which are not dangerous.
One annoying thing though: error_msg will hang the gui:
 >>> import mt
 >>> mt.gui_cmd('from pylab import *')
 >>> mt.gui_cmd('plot([1,2])')
 >>> mt.gui_cmd('plot([1,2],"0r")')
 *** gui hangs here, you get the prompt back, but no gui commands will=20
 work ***
> In import_gtk() there is time.sleep(1) - what is that for?
>=20
This is an attempt to avoid a race condition were a proxy function would=20
be called before the GTK thread is initialized. I don't know if this=20
would lead to a real problem. 1s wait not that bad anyway.
> Shouldn't widget creation be protected as well by wrapping things like
> new_figure_manager() and FigureCanvasGTK(). I know __init__ is wrapped
> but objects may have __new__ methods which call gdk/gtk functions befor=
e
> __init__ is called.
>=20
I didn't think of that. Most GTK object are not dangerous until they are=20
shown.
> How about if a widgets standard methods such as show(), present() etc
> are used - they are not protected (unless called from a protected
> method). I think this just applies to using the class interface in
> interactive mode, so it may be rarely encountered but might be a
> problem.
>=20
As I stated, I didn't try to protect methods inherited from GTK objects=20
(ie not defined in matplotlib). Which means people using them are on=20
their own. You have to draw the boundary somewhere, unless you want to=20
implement a full gui_thread.
> Why use gtk_protect(), exec() and GTK_TEMPLATE, when you could use:
>=20
> def gtk_protect (fun):
> def decorator (*args, **kwargs):
>
Well this was a try to set the proxy function name as the real function=20
name, in order to avoid weirdeness when reading object help. But I could=20
not set the argument spec correctly, so I ended up adding the 'proxy=20
from' line to the docstring. So I think all the GTK_TEMPLATE machinery=20
serves no purpose now.
As a final note, I have to say that the latest version of interactive.py=20
is good enough for my needs, so I'm no longer very motivated for pushing=20
this patch.
If you just need the pylab interface, you can also do it without=20
patching matplotlib. Just create a protected_pylab.py module, where you=20
would start the gui thread, define the gtk_protect function, import=20
pylab and define command=3Dgtk_protect(pylab.command) for every command i=
n=20
pylab. Then doing 'from protected_pylab import *' would give you a=20
working pylab interface, with just the error_msg problem.
Cheers,
Baptiste

Steve Chaplin wrote:
> To run a background process as a thread you would need to redirect its
> stdout somewhere (StringIO for example). The problem with using threads
> for this is that they share the stdout with the main thread, so if you
> redirect the background threads stdout you will redirect the python
> interpreters stdout too!
> You could run a background process as an actual process and not a thread
> (and Python 2.4 has a new subprocess module which unifies the previous
> solutions of os.system, os.spawn*, os.popen*, popen2.*, commands.*). It
> lets you redirect stdout, but is used for running executables, not
> calling python functions.
> 
> It has me stumped too, how can you call a python function and redirect
> its stdout independent of the python interpreters stdout?
Not as far as I know. That's why I think the only solution for the whole 
'backgrounding' problem with stdout is to put everything into a gui window (a 
la mathematica notebooks). I've been thinking about it, and the proper way to 
write it is probably with _two_ python processes. One would be the gui 
environment, and the other would be just a 'kernel' executing commands. The 
stdout of the kernel would then be connected to an object capable of putting 
the results of each command next to the input cell which generated them. I 
bet that's pretty much how Mathematica is organized, simply because it looks 
like the only reasonable way to deal with the issue.
Cheers,
f

On Fri, 2005年01月28日 at 21:36 +0100, Sigve Tjora wrote: 
> Hi,
> I have written a basic QtAgg backend for Matplot-lib. It is only tested
> on Windows, so some more testing should be done, but it is my hope that
> it can some day be included in the matplotlib distribution. I will test
> on linux when I get the time, but all the code is python so it should
> probably work ok.
Well done. I tried it out on Linux (Fedora 3) and it works reasonably
well.
I noticed a few things:
It puts the toolbar at the top rather than the bottom of the window.
The graph is smaller and the colours are different than that produced
with GTKAgg, which is strange since they both use Agg rendering.
I think it would be better to have a 'backend_qt.py' file used as a base
class (with a FigureCanvasQtAgg.draw() method that raises
NotImplementedError), and with backend_qtagg.py overriding just those
functions/methods which are specific to drawing using Agg. This would
allow backend_qt.py code to be used to produce a QtCairo backend at a
later date.
I copied the file into cvs so other people can try it out.
Regards
Steve

On Wed, 2005年01月26日 at 22:18 +0100, Baptiste Carvello wrote:
I've finally got round installing the interactive gui thread patch to
have a look at it. It worked quite well for a few simple plots I tried.
> A bug in the handling of threads_enter()/threads_leave() leads to a 
> deadlock, while a bug with a gui thread yields "Xlib async reply". 
> Choose which ugly death you prefer !
What situation would yield an "Xlib async reply"?
 
> There are several strategies:
...
> * wrap only pylab functions (draw_if_interactive etc), as you seem to 
> suggest in your second email: imho this is not acceptable because it 
> breaks method calls of matplotlib objects
How does it break method calls of matplotlib objects? In interactive
mode the gtk backend does not work (by itself) so there's nothing to
break, and in non-interactive mode the gui_cmd() function would not be
used.
When thinking about using threads for interactive mode I had been
assuming people using the interactive mode would be using the pylab
interface, does anyone use the matplotlib class interface in interactive
mode?
I have a few questions about patch itself:
In import_gtk() there is time.sleep(1) - what is that for?
Shouldn't widget creation be protected as well by wrapping things like
new_figure_manager() and FigureCanvasGTK(). I know __init__ is wrapped
but objects may have __new__ methods which call gdk/gtk functions before
__init__ is called.
How about if a widgets standard methods such as show(), present() etc
are used - they are not protected (unless called from a protected
method). I think this just applies to using the class interface in
interactive mode, so it may be rarely encountered but might be a
problem.
Why use gtk_protect(), exec() and GTK_TEMPLATE, when you could use:
def gtk_protect (fun):
 def decorator (*args, **kwargs):
	if IN_GTK or threading.currentThread() is Thread:
 return fun(*args, **kwargs)
 IN_GTK.append (fun)
 gtk.threads_enter()
 try:
 res = fun(*args, **kwargs)
 finally:
 gtk.threads_leave()
 IN_GTK.pop()
 return res 
 return decorator
Steve

On Thu, 2005年01月27日 at 17:14 -0700, Fernando Perez wrote: 
> > - 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.
> 
> On second thought, I don't think this is a good idea in general. The problem 
> I see is the serialization of output. Imagine you start a long running job 
> and you get the prompt back right away. If your job prints to stdout along 
> the way (as is very common with scientific codes), your input line will get 
> clobbered by this output.
> 
> If you could run in a gui window where you could associate the stdout for each 
> input 'cell' with its own output one, it would be different. This is exactly 
> how Mathematica notebooks work, they stack a queue of cells for running 
> sequentially, you get your typing prompt back immediately, but the output of 
> each command is collected in an Out[] cell next to the corresponding In[] one. 
> In a plain terminal, I don't see how we can make this work (in fact, in a 
> terminal Mathematica also serializes output for this very reason).
> 
> I have been toying with the idea of adding a way to 'background' processes 
> automatically to ipython, by creating a list of worker threads for long 
> running jobs. But the problem of handling stdout has me stumped.
> 
> I'm open to comments, though, or perhaps I'm missing something obvious here.
So removing wait()/notify() would not be such a good idea, it might be
useful if you are only running gui code, but not when the command prints
to stdout.
To run a background process as a thread you would need to redirect its
stdout somewhere (StringIO for example). The problem with using threads
for this is that they share the stdout with the main thread, so if you
redirect the background threads stdout you will redirect the python
interpreters stdout too!
You could run a background process as an actual process and not a thread
(and Python 2.4 has a new subprocess module which unifies the previous
solutions of os.system, os.spawn*, os.popen*, popen2.*, commands.*). It
lets you redirect stdout, but is used for running executables, not
calling python functions.
It has me stumped too, how can you call a python function and redirect
its stdout independent of the python interpreters stdout?
Steve