matplotlib-devel Mailing List for matplotlib

On Thu, Jul 17, 2008 at 09:44:48PM +0200, David M. Kaplan wrote:
> Another option would be to create a start_event_loop function like Paul
> suggested and overload that function in those backends that aren't
> interactive so that it returns an error, but this requires writing one
> such function for each non-interactive backend.
Either create a deeper hierarchy:
 FigureCanvasBase:
 def start_event_loop(self, ...): 
 raise NotImplemented
 FigureCanvasInteractive:
 def start_event_loop(self, ...):
 generic interactive using time.sleep
 MyInteractiveBackend(FigureCanvasInteractive):
 def start_event_loop(self, ...):
 specialized interactive code using GUI 
or a mix-in class:
 FigureCanvasBase:
 def start_event_loop(self, ...): 
 raise NotImplemented
 FigureCanvasEventLoopMixin:
 def start_event_loop(self, ...):
 generic interactive using time.sleep
 MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
 ... no start_event_loop since using the generic mixin ...
I prefer the latter, particularly since it won't be needed once the
existing interactive backends are implemented.
> Also, is there any case
> where an event loop would be useful for a graphically non-interactive
> backend? If so, this would again mean that this problem would be easier
> to deal with once in the Blocking* classes.
No reason to. While you could prompt for graph coordinates at the 
command line on a call to ginput, you could also simply prompt for
the coordinates without bothering with ginput.
 - Paul

On Thu, Jul 17, 2008 at 3:44 PM, Vineet Kumar <vi...@go...> wrote:
> It's a pretty trivial 2-line patch to make this work, which I've
> tested internally. It doesn't affect any case where the user has
> already specified their own Formatter.
>
> Please let me know if there's any other information or assistance I can provide.
Thanks Vineet -- committed to svn r5784, so it will be included in
our next bug fix release due out soon.
JDH

Hello,
In working with matplotlib to render some time-based data series, I
noticed that specifying a timezone as a kwarg to plot_date doesn't
affect the rendering of tick labels as I expected.
I've submitted a patch on sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=2020934&group_id=80706&atid=560722
It's a pretty trivial 2-line patch to make this work, which I've
tested internally. It doesn't affect any case where the user has
already specified their own Formatter.
Please let me know if there's any other information or assistance I can provide.
Thanks,
Vineet
-- 
Vineet Kumar <vi...@go...>

On Thu, Jul 17, 2008 at 2:44 PM, David M. Kaplan <Dav...@ir...> wrote:
> Hi all,
>
> I committed to svn (revision 5782) a version of the patch for clabel and
> waitforbuttonpress. I haven't perfected label rotation yet, but it
> works at the moment. I also haven't yet followed Paul Kienzle's
> suggestions (though I think they are a good idea), as I wanted to get a
> bit more information in relation to one of Gael's comments below.
Just reading through the blocking_inpu with comments mostly unrelated
to those you are raising here, and I was just reading for style rather
than logic. Some of this stuff may not be your code but here is what
I found:
 def __init__(self, fig, eventslist=()):
 self.fig = fig
 assert isinstance(eventslist, tuple), "Requires a tuple of
event name strings"
 self.eventslist = eventslist
It is rarely necessary to require *a tuple* though in some cases it
might be. Wouldn't a list work here? We use duck typing in mpl: eg
if you want to make sure the input is iterable and it contains strings
 import matplotlib.cbook
 if not cbook.iterable(eventslist):
 raise ValueError('events list must be iterable')
 if cbook.is_string_like(eventslist):
 raise ValueError('eventslist cannot be a string')
 for event in eventslist:
 if not cbook.is_string_like(event):
 raise ValueError('events list must be a list of strings')
I would probably write a cbook method is_sequence_of_strings and just
call that since it will be more readable and reusable...
I notice there are some residual print statements in the code -- these
should be replaced by the verbose handler in matplotlib/__init__.py,
eg in
 if timeout > 0 and counter > timeout/0.01:
 print "Timeout reached";
 break;
and
 if self.verbose:
 print "input %i: %f,%f" % (len(self.clicks),
 event.xdata, event.ydata)
and others in contour.py
You can replace these with
 import matplotlib
 matplotlib.verbose.report('something')
and
 matplotlib.verbose.report('some nitty gritty details', 'debug')
There should be no prints in mpl.
In contour.py, we have
 xmax = np.amax(np.array(linecontour)[:,0])
 xmin = np.amin(np.array(linecontour)[:,0])
 ymax = np.amax(np.array(linecontour)[:,1])
 ymin = np.amin(np.array(linecontour)[:,1])
which needlessly repears the array creation. I would create it once
and reuse it.
That's all for now. Thanks.
JDH

Hi all,
I committed to svn (revision 5782) a version of the patch for clabel and
waitforbuttonpress. I haven't perfected label rotation yet, but it
works at the moment. I also haven't yet followed Paul Kienzle's
suggestions (though I think they are a good idea), as I wanted to get a
bit more information in relation to one of Gael's comments below.
My responses to Gael's comments are mixed in below.
Cheers,
David 
On Thu, 2008年07月17日 at 17:19 +0200, Gael Varoquaux wrote:
> OK, a few comment from quickly glancing at the patch:
> 
> * What happens if twe are in a non interactive terminal, such as
> postscript? If this thing is running on a headless server, we don't
> want to hang the script because the manual option has been selected.
> 
The current answer is don't do that. In my opinion, all of these
functions should probably return an error if not in an interactive
terminal or graphical backend. I looked around a bit for a backend
neutral way to ask that question, but didn't find anything.
isinteractive seems like it should be relevant, but for Agg backend,
which doesn't display a graphical window, it was true, so this doesn't
seem to fit the bill. I imagine there is a way and one of you can tell
me what it is. If so, I will add it in the right place.
Another option would be to create a start_event_loop function like Paul
suggested and overload that function in those backends that aren't
interactive so that it returns an error, but this requires writing one
such function for each non-interactive backend. Also, is there any case
where an event loop would be useful for a graphically non-interactive
backend? If so, this would again mean that this problem would be easier
to deal with once in the Blocking* classes.
> * Putting this argument in "*args" seems like a bad style (it looks like
> matlab). Why don't you use a "label_pos='auto'" keyword argument. This
> would be much more robust to the addition of other options, and more in
> agreement with the rest of the style of pylab's arguments.
> 
Originally I intended to allow either the v argument or manual, but both
ended up hanging around - think of it as a comfort food for matlab
users. But you're right and I have now placed it in a keyword argument
"manual".
> I have to run. I haven't reviewed the patch very well. I think you should
> address those two comments and send it again to the list for review.
> You'll probably get useful advice and maybe learn more about Python.
> 
> Thanks,
> 
> Gaël
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

I am trying to do a clean rebuild of the docs, and am seeing warnings
from dot/digraph when I do the latex part. Looks like this is coming
from the inheritance diagram support:
jdhunter@bic128:doc> dot -V
dot - Graphviz version 2.14.1 (Fri Sep 7 12:22:15 UTC 2007)
# here is the build output
dumping search index...
build succeeded, 4 warnings.
Sphinx v0.3, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
processing Matplotlib.tex... index users/index users/intro
users/installing users/pyplot_tutorial users/navigation_toolbar
users/customizing users/index_text users/text_intro users/text_props
users/mathtext users/usetex users/annotations users/artists
users/event_handling faq/index faq/installing_faq
faq/troubleshooting_faq faq/howto_faq faq/environment_variables_faq
devel/index devel/coding_guide devel/documenting_mpl
devel/release_guide devel/transformations devel/add_new_projection
devel/outline api/index api/matplotlib_configuration_api api/afm_api
api/artist_api api/figure_api api/axes_api api/axis_api api/cbook_api
api/cm_api api/collections_api api/colorbar_api api/colors_api
api/pyplot_api api/index_backend_api api/backend_bases_api
api/backend_gtkagg_api api/backend_qt4agg_api api/backend_wxagg_api
glossary/index
resolving references...
writing... Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
WARNING: unusable reference target found:
https://sourceforge.net/project/admin/?group_id=80706
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
done
finishing...

Michael Droettboom wrote:
> Should be fixed in r5775.
> 
> It seems Agg doesn't like MOVETO commands and the end of a path. Since
> the update is in a C++ header file, you will need to force a full
> rebuild (by removing your build directory, for instance.)
Thanks, I tested and this fixes the issue for me.
-Andrew

It seems one of the static JavaScript files changed. Deleting my 
installation of Sphinx in site-packages and reinstalling fixed the problem.
Cheers,
Mike
Darren Dale wrote:
> On Thursday 17 July 2008 01:07:27 pm Michael Droettboom wrote:
> 
>> I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be
>> having trouble with the search functionality. The links that searching
>> generates do not have an .html extension, so they don't actually work.
>> For example this:
>>
>>
>> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight
>> =histogram
>>
>> When it should be this:
>>
>>
>> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?high
>> light=histogram
>>
>> I don't see this problem with the docs at matplotlib.sf.net/doc/html/,
>> only the ones I'm generating locally. Before I take this to the Sphinx
>> list, are others seeing this (with a SVN Sphinx updated today?)
>> 
>
> Yep, I see it too.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thursday 17 July 2008 01:07:27 pm Michael Droettboom wrote:
> I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be
> having trouble with the search functionality. The links that searching
> generates do not have an .html extension, so they don't actually work.
> For example this:
>
>
> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight
>=histogram
>
> When it should be this:
>
>
> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?high
>light=histogram
>
> I don't see this problem with the docs at matplotlib.sf.net/doc/html/,
> only the ones I'm generating locally. Before I take this to the Sphinx
> list, are others seeing this (with a SVN Sphinx updated today?)
Yep, I see it too.

Should be fixed in r5775.
It seems Agg doesn't like MOVETO commands and the end of a path. Since 
the update is in a C++ header file, you will need to force a full 
rebuild (by removing your build directory, for instance.)
Cheers,
Mike
Michael Droettboom wrote:
> I'm looking into it.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
> 
>> John Hunter wrote:
>> 
>> 
>>> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
>>> 
>>> 
>>> 
>>>> Hi All,
>>>> I'd like to "resubmit" the request below: any new version to be
>>>> released soon? in the process to generate the doc in Debian, something
>>>> got fixed upstream, so a new release would be really helpful to have
>>>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>>>> strange chars in it).
>>>> 
>>>> 
>>>> 
>>> I think we could do a 0.98.3 release. There have been several bugs
>>> fixed. Could you do me a favor and check svn r5722 and see if it
>>> meets all your requirements for debian before we actually do the
>>> release?
>>> 
>>> 
>>> 
>> I just checked r5772 and found that a problem when plotting nans. I know
>> that masked arrays are preferred to nans, but considering that this used
>> to work in 0.91 and earlier, this is a regression.
>>
>> I've modified nan_test.py in examples/pylab_examples to illustrate the
>> bug in r5773 (also attached), but I think Eric would probably be vastly
>> more efficient than I when it comes to fixing properly.
>>
>> -Andrew
>> 
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm looking into it.
Cheers,
Mike
Andrew Straw wrote:
> John Hunter wrote:
> 
>> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
>> 
>> 
>>> Hi All,
>>> I'd like to "resubmit" the request below: any new version to be
>>> released soon? in the process to generate the doc in Debian, something
>>> got fixed upstream, so a new release would be really helpful to have
>>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>>> strange chars in it).
>>> 
>>> 
>> I think we could do a 0.98.3 release. There have been several bugs
>> fixed. Could you do me a favor and check svn r5722 and see if it
>> meets all your requirements for debian before we actually do the
>> release?
>> 
>> 
> I just checked r5772 and found that a problem when plotting nans. I know
> that masked arrays are preferred to nans, but considering that this used
> to work in 0.91 and earlier, this is a regression.
>
> I've modified nan_test.py in examples/pylab_examples to illustrate the
> bug in r5773 (also attached), but I think Eric would probably be vastly
> more efficient than I when it comes to fixing properly.
>
> -Andrew
> 
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sorry. That's my bad. I accidentally committed some testing code for 
log-scaled quad meshes (which works for Agg, but not for other 
backends). I'll revert the example, and see what's breaking.
Cheers,
Mike
John Hunter wrote:
> Anyone have any idea what changes may be causing this new bug in
> quadmesh on non agg backends?
>
> jdhunter@bic128:mpl> python examples/pylab_examples/quadmesh_demo.py -dPS
> Traceback (most recent call last):
> File "examples/pylab_examples/quadmesh_demo.py", line 47, in <module>
> savefig("quadmesh_demo")
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py",
> line 306, in savefig
> return fig.savefig(*args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
> line 1043, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
> line 1301, in print_figure
> **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 840, in print_ps
> return self._print_ps(outfile, 'ps', *args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 869, in _print_ps
> orientation, isLandscape, papertype)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 943, in _print_figure
> self.figure.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
> line 842, in draw
> for a in self.axes: a.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py",
> line 1549, in draw
> a.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
> line 533, in draw
> self._showedges)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
> line 153, in draw_quad_mesh
> meshWidth, meshHeight, coordinates)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
> line 484, in convert_mesh_to_paths
> ), axis=2)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/numpy/ma/core.py",
> line 1307, in __array_finalize__
> self._mask.shape = self.shape
> AttributeError: incompatible shape for a non-contiguous array
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
> 
>> Hi All,
>> I'd like to "resubmit" the request below: any new version to be
>> released soon? in the process to generate the doc in Debian, something
>> got fixed upstream, so a new release would be really helpful to have
>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>> strange chars in it).
>> 
>
> I think we could do a 0.98.3 release. There have been several bugs
> fixed. Could you do me a favor and check svn r5722 and see if it
> meets all your requirements for debian before we actually do the
> release?
> 
I just checked r5772 and found that a problem when plotting nans. I know
that masked arrays are preferred to nans, but considering that this used
to work in 0.91 and earlier, this is a regression.
I've modified nan_test.py in examples/pylab_examples to illustrate the
bug in r5773 (also attached), but I think Eric would probably be vastly
more efficient than I when it comes to fixing properly.
-Andrew

I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be 
having trouble with the search functionality. The links that searching 
generates do not have an .html extension, so they don't actually work. 
For example this:
 
file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight=histogram
When it should be this:
 
file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?highlight=histogram
I don't see this problem with the docs at matplotlib.sf.net/doc/html/, 
only the ones I'm generating locally. Before I take this to the Sphinx 
list, are others seeing this (with a SVN Sphinx updated today?)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Anyone have any idea what changes may be causing this new bug in
quadmesh on non agg backends?
jdhunter@bic128:mpl> python examples/pylab_examples/quadmesh_demo.py -dPS
Traceback (most recent call last):
 File "examples/pylab_examples/quadmesh_demo.py", line 47, in <module>
 savefig("quadmesh_demo")
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py",
line 306, in savefig
 return fig.savefig(*args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
line 1043, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
line 1301, in print_figure
 **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 840, in print_ps
 return self._print_ps(outfile, 'ps', *args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 869, in _print_ps
 orientation, isLandscape, papertype)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 943, in _print_figure
 self.figure.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
line 842, in draw
 for a in self.axes: a.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py",
line 1549, in draw
 a.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
line 533, in draw
 self._showedges)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
line 153, in draw_quad_mesh
 meshWidth, meshHeight, coordinates)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
line 484, in convert_mesh_to_paths
 ), axis=2)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/numpy/ma/core.py",
line 1307, in __array_finalize__
 self._mask.shape = self.shape
AttributeError: incompatible shape for a non-contiguous array

Hi,
This sounds like a great idea. My trunk version of matplotlib does not
have these changes. I presume you would like me to commit them? If so,
let me know and it would be great if you could give your code a test
using the wx backend afterward.
Cheers,
David
On Thu, 2008年07月17日 at 12:13 -0400, Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 09:46:16AM +0200, David M. Kaplan wrote:
> > I don't think the blocking code will be that hard to maintain. It
> > basically just depends on events, callback functions and time.sleep. If
> > those are cross-platform, then it shouldn't be a problem. But only time
> > will tell. My ability and desire to test on multiple platforms is
> > limited - I use ubuntu/gnome-gtk/linux 100%.
> 
> In addition to your patch you can put start/stop_event_loop 
> methods into the the canvas. That way backends can specialize 
> their implementation so they don't need a busy loop while waiting
> for the event.
> 
> Then you can replace the termination notice in BlockingInput:
> 
> - self.done = True
> + self.fig.canvas.stop_event_loop()
> 
> and move the busy loop to the backend:
> 
> # wait for n clicks
> - counter = 0
> - while not self.done:
> - self.fig.canvas.flush_events()
> - time.sleep(0.01)
> - 
> - # check for a timeout
> - counter += 1
> - if timeout > 0 and counter > timeout/0.01:
> - print "ginput timeout";
> - break;
> + self.fig.canvas.start_event_loop(timeout=timeout)
> 
> 
> In backend_bases.py I have a generic interactive version 
> based on sleep:
> 
> class FigureCanvasBase:
> ...
> def start_event_loop(self, timeout=0):
> """
> Run the event loop.
> 
> This call blocks until an event callback triggers
> stop_event_loop() or the timeout interval is exceeded.
> """
> if timeout == 0: timeout = npy.inf
> timestep = 0.01
> counter = 0
> self._looping = True
> while self._looping and counter*timestep < timeout:
> self.flush_events()
> time.sleep(timestep)
> counter += 1
> 
> def stop_event_loop(self):
> """
> Stop the event loop.
> 
> The function which started the event loop can now run to completion.
> """
> self._looping = False
> 
> 
> In the wx canvas this is specialized as:
> 
> class FigureCanvasWx(FigureCanvasBase, wx.Panel):
> ...
> def start_event_loop(self, timeout=0):
> """
> Run the event loop.
> 
> This call blocks until an event callback triggers
> stop_event_loop() or the timeout interval is exceeded.
> """
> root = self.GetTopLevelParent()
> bind(root, wx.EVT_CLOSE, self.stop_event_loop)
> 
> id = wx.NewId()
> timer = wx.Timer(self, id=id)
> if timeout > 0:
> timer.Start(timeout*1000, oneShot=True)
> bind(self, wx.EVT_TIMER, self.stop_event_loop, id=id)
> self._event_loop.Run()
> timer.Stop()
> 
> def stop_event_loop(self, event=None):
> """
> Stop the event loop.
> 
> The function which started the event loop can now run to completion.
> """
> if self._event_loop.IsRunning(): 
> self._event_loop.Exit()
> 
> # Event binding code changed after version 2.5
> if wx.VERSION_STRING >= '2.5':
> def bind(actor,event,action,**kw):
> actor.Bind(event,action,**kw)
> else:
> def bind(actor,event,action,id=None):
> if id is not None:
> event(actor, id, action)
> else:
> event(actor,action)
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thu, Jul 17, 2008 at 09:46:16AM +0200, David M. Kaplan wrote:
> I don't think the blocking code will be that hard to maintain. It
> basically just depends on events, callback functions and time.sleep. If
> those are cross-platform, then it shouldn't be a problem. But only time
> will tell. My ability and desire to test on multiple platforms is
> limited - I use ubuntu/gnome-gtk/linux 100%.
In addition to your patch you can put start/stop_event_loop 
methods into the the canvas. That way backends can specialize 
their implementation so they don't need a busy loop while waiting
for the event.
Then you can replace the termination notice in BlockingInput:
- self.done = True
+ self.fig.canvas.stop_event_loop()
and move the busy loop to the backend:
 # wait for n clicks
- counter = 0
- while not self.done:
- self.fig.canvas.flush_events()
- time.sleep(0.01)
- 
- # check for a timeout
- counter += 1
- if timeout > 0 and counter > timeout/0.01:
- print "ginput timeout";
- break;
+ self.fig.canvas.start_event_loop(timeout=timeout)
In backend_bases.py I have a generic interactive version 
based on sleep:
class FigureCanvasBase:
 ...
 def start_event_loop(self, timeout=0):
 """
 Run the event loop.
 This call blocks until an event callback triggers
 stop_event_loop() or the timeout interval is exceeded.
 """
 if timeout == 0: timeout = npy.inf
 timestep = 0.01
 counter = 0
 self._looping = True
 while self._looping and counter*timestep < timeout:
 self.flush_events()
 time.sleep(timestep)
 counter += 1
 def stop_event_loop(self):
 """
 Stop the event loop.
 The function which started the event loop can now run to completion.
 """
 self._looping = False
In the wx canvas this is specialized as:
class FigureCanvasWx(FigureCanvasBase, wx.Panel):
 ...
 def start_event_loop(self, timeout=0):
 """
 Run the event loop.
 This call blocks until an event callback triggers
 stop_event_loop() or the timeout interval is exceeded.
 """
 root = self.GetTopLevelParent()
 bind(root, wx.EVT_CLOSE, self.stop_event_loop)
 id = wx.NewId()
 timer = wx.Timer(self, id=id)
 if timeout > 0:
 timer.Start(timeout*1000, oneShot=True)
 bind(self, wx.EVT_TIMER, self.stop_event_loop, id=id)
 self._event_loop.Run()
 timer.Stop()
 def stop_event_loop(self, event=None):
 """
 Stop the event loop.
 The function which started the event loop can now run to completion.
 """
 if self._event_loop.IsRunning(): 
 self._event_loop.Exit()
# Event binding code changed after version 2.5
if wx.VERSION_STRING >= '2.5':
 def bind(actor,event,action,**kw):
 actor.Bind(event,action,**kw)
else:
 def bind(actor,event,action,id=None):
 if id is not None:
 event(actor, id, action)
 else:
 event(actor,action)

Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
>> Just because the discussion about clabel started, I want to post a short 
>> snipplet of code that I found useful. It was some sort of hack to get a 
>> nicer float formating for contours: contour lines represented confidence 
>> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as 
>> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
>> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
> 
> The %g format produces "nice" numbers.
> 
> For example:
> 
> >>> print " ".join(["%g%%"%v for v in [1.0,2.5,5.000001,10.03]])
> 1% 2.5% 5% 10.03%
> 
> - Paul
How *** **** did I miss that !? Can't believe it ...

On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
> Just because the discussion about clabel started, I want to post a short 
> snipplet of code that I found useful. It was some sort of hack to get a 
> nicer float formating for contours: contour lines represented confidence 
> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as 
> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
The %g format produces "nice" numbers.
For example:
 >>> print " ".join(["%g%%"%v for v in [1.0,2.5,5.000001,10.03]])
 1% 2.5% 5% 10.03%
- Paul

On Thu, Jul 17, 2008 at 04:41:36PM +0200, David M. Kaplan wrote:
> Attached is a new version of the patch that includes ginput,
> waitforbuttonpress and clabel changes. It is already quite functional,
> but there are a couple of issues that need improving that I would like
> to solicit comments on. I explain below after detailing what I have
> done.
OK, a few comment from quickly glancing at the patch:
* What happens if twe are in a non interactive terminal, such as
 postscript? If this thing is running on a headless server, we don't
 want to hang the script because the manual option has been selected.
* Putting this argument in "*args" seems like a bad style (it looks like
 matlab). Why don't you use a "label_pos='auto'" keyword argument. This
 would be much more robust to the addition of other options, and more in
 agreement with the rest of the style of pylab's arguments.
I have to run. I haven't reviewed the patch very well. I think you should
address those two comments and send it again to the list for review.
You'll probably get useful advice and maybe learn more about Python.
Thanks,
Gaël

Hi,
On Thu, 2008年07月17日 at 07:47 -0700,
mat...@li... wrote:
> Just because the discussion about clabel started, I want to post a
> short 
> snipplet of code that I found useful. It was some sort of hack to get
> a 
> nicer float formating for contours: contour lines represented
> confidence 
> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly
> as 
> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
> 
> So this was my solution:
> 
> 
> # some kind of hack: a nicer floating point formating
> class nf(float):
> def __repr__(self):
> str = '%.1f' % (self.__float__(),)
> if str[-1]=='0':
> return '%.0f' % self.__float__()
> else:
> return '%.1f' % self.__float__()
> 
> levels = [nf(val) for val in [1.0, 2.5,5.0,10.0] ]
> 
> pylab.clabel(cs, inline=True, fmt='%r \%%')
> 
> 
> As I said, it's sort of a hack but it works! It might not be worth to 
> add this to mpl, but probably as an example ...!?
> 
> Manuel
Along these lines, I have been thinking that it would be a simple
addition to allow fmt to be a dictionary (as an alternative to a string)
that matches contour levels with the desired text. This would allow
users to label contours with arbitrary strings, which is occasionally
useful. If there is interest, I will add this feature.
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thursday 17 July 2008 10:59:23 am John Hunter wrote:
> On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dm...@uc...> wrote:
> > Thanks for the comments. My sourceforge ID is dmkaplan. Please add me
>
> Hi David -- I've added you as a developer so you should be able to
> commit now. The developer's guide is here:
>
> http://matplotlib.sourceforge.net/doc/html/index.html
>
> Welcome aboard!
Welcome aboard David!

On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dm...@uc...> wrote:
> Thanks for the comments. My sourceforge ID is dmkaplan. Please add me
Hi David -- I've added you as a developer so you should be able to
commit now. The developer's guide is here:
 http://matplotlib.sourceforge.net/doc/html/index.html
Welcome aboard!
JDH

Hi,
Attached is a new version of the patch that includes ginput,
waitforbuttonpress and clabel changes. It is already quite functional,
but there are a couple of issues that need improving that I would like
to solicit comments on. I explain below after detailing what I have
done.
I decided to use a slightly different approach for adding manual label
placement ability to clabel. I created a class BlockingContourLabeler
that inherits from BlockingMouseInput. This code is in
blocking_input.py. This class is called by clabel when manual mode is
selected and does the labeling by modifying the passed ContourSet object
using ContourSet methods. This avoids clouding the ContourSet
namespace with BlockingMouseInput variables and methods. Along the way,
I generalized BlockingMouseInput so that it makes it very easy to
overload methods to create the class for clabel. 
In general, I think this approach is quite robust and efficient. Label
placement and coloring work perfectly. Label rotation and inlining are
usable, but not nearly as robust as the automatic versions. The main
reason for this is that I can't get my head around how the automatic
code (locate_labels and get_label_coords) works and this is preventing
me from abstracting that code into something that I can use for
non-automatic labeling. It looks to me like it breaks each contour into
n chunks, where n is the width of the label in pixels, and then places
the label on one of those pieces using the starting and ending points of
the chunk to define the label orientation. But this doesn't make much
sense to me, so I am hesitant to edit it. Somehow it works and
generally looks quite good. Perhaps someone who understands that code
can enlighten me.
In an ideal world, there would be a general ContourLabeler method that
would take the label location and spit out the appropriate rotation, no
matter where that label is. If I were to do it, I would transform the
contour to pixel space, calculate the pixel distance between points,
then use cumsum to find points around the label location that are just
greater than labelwidth/2 away along the contour path. These two
indices would define the label rotation and would be useful for breaking
contours. I can implement this, but I would like to have a better
understanding of how the current code works before modifying it.
I also made a slight modification to BlockingMouseInput that affects
ginput functioning. You can now exit out of ginput at any time using
the second mouse button, even if not in infinite mode. This agrees with
matlab functionality and can be quite useful if you want to select no
more than a certain number of points.
Cheers,
David
On Thu, 2008年07月17日 at 09:46 +0200, David M. Kaplan wrote:
> Hi all,
> 
> Thanks for the comments. My sourceforge ID is dmkaplan. Please add me
> as a developer. I will commit to the trunk and try to not break things,
> but I am VERY new to python and it is a possibility. If things don't
> work out, we can always fall back to creating a branch, though I admit
> that branching and merging in subversion is a pain. And please do
> notify me about stylistic issues, etc.
> 
> My contributions are likely to be a bit sporadic and selfish in the
> sense that I am just adding functionality that I use all the time in
> matlab. But if everyone did that, it wouldn't be half bad....
> 
> I don't think the blocking code will be that hard to maintain. It
> basically just depends on events, callback functions and time.sleep. If
> those are cross-platform, then it shouldn't be a problem. But only time
> will tell. My ability and desire to test on multiple platforms is
> limited - I use ubuntu/gnome-gtk/linux 100%.
> 
> I plan on spending today sprucing up the patch I sent. Unless anyone is
> against, I will probably commit and notify in stages so that each piece
> of the puzzle can be considered separately.
> 
> I have noticed that the current contour labeling code has its
> idiosyncrasies, including dealing poorly with label resizing and not
> being very friendly about unbreaking contours (i.e., it is currently not
> possible to have a true remove method for ContourSet). I don't plan on
> fixing these (at least until I have a burning desire to resize labels),
> but think a contribution that allowed people to resize labels and
> break-unbreak contours would be useful. I plan on compartmentalizing a
> bit more ContourLabeler so that each bit of functionality is a separate
> method - this should make integrating a new LabeledLine class a bit
> easier as we would just need to attach the right method of one to the
> other.
> 
> Cheers,
> David
> 
> On Wed, 2008年07月16日 at 10:10 -1000, Eric Firing wrote:
> > John Hunter wrote:
> > > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:
> > > 
> > >> The patch isn't done - manually selected labels won't be rotated or
> > >> inline. There is also a need for general cleaning up and documentation.
> > >> I just want to see what people think about the approach before investing
> > >> more time. I added this functionality by adding a class
> > >> ContourLabelerWithManual that inherits from ContourLabeler and
> > >> BlockingMouseInput (the class used by ginput to interactively select
> > >> points). ContourSet then inherits from ContourLabelerWithManual instead
> > >> of ContourLabeler. If manual is selected, then it enters interactive
> > >> mode, if not, then results should be as before.
> > > 
> > > Hi David,
> > > 
> > > I think this looks good. I would like to see it finished before
> > > inclusion (eg rotating the labels inline) but this functionality looks
> > > very useful. In general, I think it would be nice to have better
> > > support for easy interaction with figures, eg for annotations. My
> > > main question is whether blocking input is the best choice.
> > > Admitedly, most users find it more intuitive to set up blocking input
> > > rather than using non-blocking input that is terminated by a custom
> > > button press, key stroke, or command, but I am worried about how
> > > robust this is across user interfaces and environments, with all the
> > > attendant problems of GUI threads, mainloops, etc. Gael has done a
> > > nice job with ginput across backends, but this code is relatively new
> > > and lightly tested. Basically, someone (probably you and Gael) will
> > > need to be up to the task of supporting blocking input across user
> > > interfaces, which probably isn't trivial but maybe I'm overly
> > > cautious. Anyway, something to think about.
> > > 
> > >> I also had to move the classes Blocking*Input from figure.py to a
> > >> separate file blocking_input.py to avoid circular imports.
> > > 
> > > A minor nit here: when you import blocking_input, you should use
> > > 
> > > import matplotlib.blocking_input as blocking_input
> > > 
> > > rather than simply
> > > 
> > > import blocking_input
> > > 
> > > as discussed in the coding guide:
> > > http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html
> > > 
> > > On the subject of the docs, we are in the midst of a push to get beter
> > > documentation for mpl, so anything you can add while working in terms
> > > of tutorial or faq or whatever on the new code would be welcome. The
> > > docs are in the doc subdir of the svn trunk.
> > > 
> > >> Please let me know what you think. Also, I am wondering if the powers
> > >> that be would be willing to give me commit access to my own branch of
> > >> the matplotlib svn. I don't want to modify the trunk, but for my own
> > >> sanity, it would be nice to be able to keep track of my changes
> > >> somewhere. If not, I would like to here what other non-commit
> > >> developers do to best organize changes.
> > > 
> > > If you send me your sf id, I will add you to the developer list. I
> > > don't mind you committing to the trunk unless you are afraid your
> > > changes will break code. I am not a huge fan of having a lot of
> > > branches.
> > > 
> > > Thanks for the submission -- I await more informed commentary from
> > > those who actually use contouring....
> > 
> > I agree with adding the functionality provided it can be done in a 
> > robust and maintainable way; I have never looked into the arcane aspects 
> > of gui interaction across backends.
> > 
> > Unless it got fixed as part of the transforms re-write, there are 
> > problems even with the existing contour labeling, in that it does not 
> > (or did not) handle resizes well. Among the many things I have thought 
> > of but not gotten to is the idea that there should be a LabeledLine 
> > class to handle this outside of contour.py. The idea is that in 
> > addition to the ordinary line path, it would include a list of labels 
> > and positions (not sure what the right way to specify the positions is), 
> > and the class would handle breaking the path and inserting the correctly 
> > rotated text.
> > 
> > Eric
> > 
> > 
> > > 
> > > JDH
> > > 
> > > -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > > Grand prize is a trip for two to an Open Source event anywhere in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
> Hi All,
> I'd like to "resubmit" the request below: any new version to be
> released soon? in the process to generate the doc in Debian, something
> got fixed upstream, so a new release would be really helpful to have
> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
> strange chars in it).
I think we could do a 0.98.3 release. There have been several bugs
fixed. Could you do me a favor and check svn r5722 and see if it
meets all your requirements for debian before we actually do the
release?
Thanks,
JDH