Re: [matplotlib-devel] patch for adding manual label location selection to clabel
John Hunter wrote: On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan [EMAIL PROTECTED] wrote: Thanks for the submission -- I await more informed commentary from those who actually use contouring 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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
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'm lookgin forward to heard back from you soon. Thanks in advance, Sandro On Wed, Jul 2, 2008 at 13:46, Sandro Tosi [EMAIL PROTECTED] wrote: Hi guys, in Debian we finally find a nice way to let the documentation be compiled at package build-time so we are ready for a real new release of matplotlib (more that the source-only you kindly provided me last week), so when you're ready :) For sure, I won't upload a new one in the next 2/3 days or so, because I want to let 0.98.1 transit from unstable to testing (the Debian staging area used to release lenny), so from the weekend on I'd be glad to upgrade matplotlib and bother the release team to include it in the next release :) Thank a lot for the great support you gave/giving me, Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi [EMAIL PROTECTED] 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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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 [EMAIL PROTECTED] 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
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Thursday 17 July 2008 10:59:23 am John Hunter wrote: On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan [EMAIL PROTECTED] 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! - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Thu, 2008-07-17 at 07:47 -0700, [EMAIL PROTECTED] 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 ** - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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.01,10.03]]) 1% 2.5% 5% 10.03% - Paul - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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.01,10.03]]) 1% 2.5% 5% 10.03% - Paul How *** did I miss that !? Can't believe it ... - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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 ** - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] quadmesh bug
Anyone have any idea what changes may be causing this new bug in quadmesh on non agg backends? [EMAIL PROTECTED]: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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Search functionality in Sphinx docs
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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
John Hunter wrote:
On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi [EMAIL PROTECTED] 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
#!/usr/bin/env python
Example: simple line plots with NaNs inserted.
from pylab import *
t = arange(0.0, 1.0+0.01, 0.01)
s = cos(2*2*pi*t)
t[41:60] = NaN
subplot(2,1,1)
plot(t, s, '-', lw=2)
xlabel('time (s)')
ylabel('voltage (mV)')
title('A sine wave with a gap of NaNs between 0.4 and 0.6')
grid(True)
subplot(2,1,2)
t[0] = NaN
t[-1] = NaN
plot(t, s, '-', lw=2)
xlabel('time (s)')
ylabel('voltage (mV)')
title('More NaNs at 0.0 and 1.0')
grid(True)
show()
-
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=100url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Search functionality in Sphinx docs
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. - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Search functionality in Sphinx docs
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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] dot warnings when build docs
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:
[EMAIL PROTECTED]: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...
-
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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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 ** - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Thu, Jul 17, 2008 at 2:44 PM, David M. Kaplan [EMAIL PROTECTED] 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
-
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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot_date doesn't pass tz to AutoDateFormater (patch 2020934 submitted)
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=detailaid=2020934group_id=80706atid=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 [EMAIL PROTECTED] - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] plot_date doesn't pass tz to AutoDateFormater (patch 2020934 submitted)
On Thu, Jul 17, 2008 at 3:44 PM, Vineet Kumar [EMAIL PROTECTED] 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 - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] (Wind) Barbs
John Hunter wrote: On Tue, Jul 15, 2008 at 5:37 PM, Ryan May [EMAIL PROTECTED] wrote: I welcome any comments/criticism to help improve this. Hey Ryan, I have looked at this code briefly and have a few minor comments. I think Eric, who did the bulk of the current quiver implementation, and as an oceanographer is in a field much closer to yours than mine, will provide more useful feedback and should ultimately handle the patch submission. My first comment is that the code looks very good -- it is well thought out and commented, and t is definitely suitable for inclusion in the main line. Certainly the Barbs class can live in the collections module. You note in the driver code that you are worried about pollution of the axes namespace by including a domain specific method, and this is a reasonable worry, but the axes namespace is currently so polluted with plotting methods that it is a small worry. I think it would be fine for you to rework your code into a patch which provides the Barbs collection in matplotlib.collections, an Axes method, and a pyplot interface function (with a pylab module level docstring entry). The overloading of the Axes namespace is not ideal, but it's what we've got. Thanks. My question then is how do I add a pyplot interface, since it appears from the comments that many of those are just generated boilerplate? My second comment has to do with your comment at the end of the example: #Showing colormapping with uniform grid. Unfortunately, only the flags #on barbs get colormapped this way. On a cursory read of the code, it looks like you have implemented everything as a single poly collection, and the reason the flags only get colored is that the varicolored is black. It seems like there are two solutions: write your class as a combination of poly collection (for the flags) and line collection (for the barbs) and colormap both (there are some line collection colormapping examples in the examples subdir courtesy of Eric). The 2nd alternative, which I haven't explored, is to set the edgecolor equal to the facecolor and support colormapping of the edgecolors. Yeah, the comment went more to explain expected results. There was no mystery to me why the edgecolors didn't get colormapped, it was pretty clear from the collections code. I had started down the road of combining lines and polygons in a PatchCollection, but that created a bunch of separate objects for each wind barb that had to each be transformed and have an offset applied. I took the lazy way out and created (admittedly) degenerate polygons. :) I hadn't actually thought (call it a brain fart) about actually going ahead and adding colormapping for the edgecolors. Should I follow Mike's suggestion and possibly take a go at adding it to the general Collections class? (Granted, if someone else took a stab at it, it might land in SVN sooner, I'm sure I still have a learning curve to go here). Overall this is very promising, and I wish you the best trying to make mpl serviceble to the meteorology community. Jeff Whitaker has done a phenomenal job with basemap providing extensions for those needing cartographic projections as a toolkit. Depending on how far you want to go with meteorological support, we can include the changes in the mainline or fold them into a toolkit if they become hyper-specialized. I still have a few more things to add (on top of what Whitaker already fixed for me): * Need to plot something (empty circle) for vector magnitude 5. (I did a plot the other day and was befuddled for a bit by seeing only 6 barbs) * Need to fix support for masked arrays. The way the iteration goes right now, masked values end up being iterated over, which is bad. * Probably should add a set_uv(c) method, like quiver We'll see about the possibility of a toolkit. If I can keep up the momentum, I might end up with significant functionality. I'd also have to see how much of it really ends up being more than just simple example scripts. And I agree, huge props to Whitaker for Basemap. Hopefully I can get more people around me to use it instead of the abominations used now. :) (I'd have things sooner if it weren't for the stupid Google CodeJam :) ) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] (Wind) Barbs
Jeff Whitaker wrote: Ryan May wrote: Hi, I've got (what seems to me) a nice clean, self-contained implementation of wind barbs plots. I'd like to see if I can get this into matplotlib, as it would be very useful to the meteorology community. I've borrowed heavily from Quiver for rounding out rough edges (like multiple calling signatures) as for templates for documentation. The base implementation, though, seems much simpler (thanks to Mike's transforms) and is based more on scatter. Right now it monkey-patches Axes so that it can be a stand-alone file. Just running the file should give a good example of the expected output. My only concern up front is if a new axes method is appropriate, since this is somewhat domain specific. But I'd like to at least get the new Collections class included, since otherwise, I have no idea how to get this distributed to the community at large. I welcome any comments/criticism to help improve this. Ryan Ryan: This looks great! I fixed one typo (the length keyword was mis-identified as scale in the docstring) and replace your example with an adaption of the quiver_demo.py basemap example. Thanks. When this finally lands in matplotlib svn, do you need me to do the patch to add it to basemap? If so, anything I should know? Or will you just take care of it? I noticed that ticks on the barbs are so close that they are hard to discern unless the linewidth is reduced. I wonder if the spacing of the ticks could be added as a keyword, perhaps as a fraction of the wind barb length? It's already coded up as such, it's just a matter of exposing it as a keyword. I didn't do it already because I didn't want the alphabet soup. But I guess since I'm already parsing the **kw dictionary, popping off a few more values isn't too bad... This will be a wonderful addition to matplotlib. Thanks! -Jeff P.S. eagerly awaiting your Skew-T implementation You and every other met I know...It's a good thing I want this so badly, because having struggled with it I understand why there's so few implementations out there. Wind barbs actually came as a nice little distraction to learn a bit of the matplotlib API before trying to get the Skew-T right again. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote: I think we could do a 0.98.3 release. I am right now implementing a wx frontend to ipython, and I can see in the near future a score of people complaining that from pylab import *; show() crashes it because it calls the wrong backend. Do people mind if I prepare a patch that does some magic as pylab is loaded to: a) Look if 'wx' is in sys.module b) Check if the wx mainloop is running, and if so changes the backend automatically to wx and wxAgg. I could not sleep and do this tonight to get it ready for the release, but I would like people's feedback... (Famous last words) Gaël - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Thu, Jul 17, 2008 at 04:55:42PM -0400, Paul Kienzle wrote: 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. +1 one that. Also, I don't think a exception is a good idea. Simply a warnings.warn should be enough. Gaël - 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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
