Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
Christopher Barker wrote: > arrg! > > When am I going to learn not to click "send" until after I've read the > entire thread! > > Jeff Whitaker wrote: > >> John: I just contacted NCAR again, and it seems that they have >> relicensed the software under an OSI-based license similar to the >> University of Illinois/NCSA: >> > ... > >> What do you think? If it's OK I say we use the natgrid package in >> matplotlib, since it's more bulletproof than the scikits package (it >> passes Robert's degenerate triangulation test, and has been pounded on >> by user of NCAR graphics since the 1980's). >> > > that would be nice, but while it is a good solution to the re-gridding > problem, it doesn't appear to provide a general purpose delauney > triangulation solution, which is too bad -- it would be nice to have > that in MPL. > > -Chris > > > Chris: I've now added a griddata function to matplotlib.mlab that uses Robert Kern's scikit.delaunay code (which is now included in matplotlib as matplotlib.delaunay). The more bulletproof natgrid code, with the dubious license, is included as a toolkit (mpl_toolkits.natgrid), which griddata is configured to automatically use if installed. -Jeff - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] TextCollection
On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > Has anyone ever thought about creating a TextCollection class? The > purpose would be similar to the other collections, to group a bunch of > text objects with similar properties. This probably couldn't inherit > from Collection as of now though, since Collection assumes things like > edgecolor and facecolor. The bigger question to me is, could the > backends make use of this to any improvement? Or would this simply > serve as an API to eliminate having to loop yourself (which would pretty > much make this useless). > > My own personal use case is (once again) in meteorology, where we do > station plots. This involves printing the actual value of observed > variables relative to the location of the station. This isn't hard to > do right now (especially since I have offset_copy back, thanks Mike!). > I just wasn't sure if the batch functionality of a Collection might > serve some purpose to the users at large. I've thought of it many times and it would definitely be useful, eg for tick labels. Treating every label as a separate instance definitely slows things down. 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 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 Tue, Jul 22, 2008 at 6:30 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote:
> Chris: I've now added a griddata function to matplotlib.mlab that uses
> Robert Kern's scikit.delaunay code (which is now included in matplotlib
> as matplotlib.delaunay). The more bulletproof natgrid code, with the
> dubious license, is included as a toolkit (mpl_toolkits.natgrid), which
> griddata is configured to automatically use if installed.
Jeff, thanks for the extra effort to do it this way -- I know it was a
pain. But at least now we get
* commercial users can rely on our license as iron-clad
* griddata will work transparently out of the box for regular users
* we provide a path to the more bullet proof code for those who need it
I have a few comments I'll include below.
* Let's move the try/except natgrid/griddata import to the griddata
function itself so users not using griddata will not have to pay for
the import, since this will likely be 99% of the mpl users
* Expose griddata to the pylab interface and add it to the pylab and
mlab module doc strings
* We should provide some help for those who may want to try the
natgrid code, eg if you plan on releasing it on the sf site as a
toolkit, which I think is best, then we can link to the download page
in the docstring. If not, perhaps just provide an svn checkout line
for folks.
* Let's report which package is being used at the verbose helpful
level, preferably with some version info if it is available. When
questions come in on the mailing list later, we will want to know
which package griddata is using. You might set a flag on the griddata
function along the lines of
def griddata(blah)
if not griddata._reported:
if _use_natgrid:
verbose.report('using natgrid version blah')
else:
verbose.report('using delaunay version blah')
natgrid._reported = True
griddata._reported = False
* After the next release, let's remember to update the cookbook entry
- http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data
Anyway, this is a great piece of additional functionality that we've
literally been waiting years for, so thanks for taking the extra time
to do it so thoroughly.
And enterprising developers everywhere, it would still be extremely
useful to follow Robert's suggestions to improve the delaunay code
along the lines discussed in this thread earlier. Not for the faint
of heart, but users for generations to come will thank you.
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support
On Mon, Jul 21, 2008 at 04:42:39PM -0700, Ted Drain wrote: > The public layer would just do conversions and then pass through to the > private layer. Any code in the public layer would have to concern itself > with possible different types (numpy vs lists, units vs floats, color names > vs rgb). Any code written in the private layer could be assured of having > some specific input types and would be much easier to write. Keep in mind that public units need to be tied to font in order to get nice looking results. I commented on this earlier: http://www.nabble.com/font-troubles-td16601826.html#a16601826 I'm not sure all the necessary information to transform to pixels will be available at the time the units are parsed, and we may need to carry them into the private layer. > Of course this would be a lot work and would require refactoring axis and > maybe some of the collections. In theory it should be possible, but only > you guys can decide if it's actually worthwhile or not. One of the things I miss from Tcl/Tk is the ability to use units on values. The link above shows that you can simulate units from outside, but the code is ugly. - 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=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] TextCollection
John Hunter wrote: > On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Has anyone ever thought about creating a TextCollection class? The >> purpose would be similar to the other collections, to group a bunch of >> text objects with similar properties. This probably couldn't inherit >> from Collection as of now though, since Collection assumes things like >> edgecolor and facecolor. The bigger question to me is, could the >> backends make use of this to any improvement? Or would this simply >> serve as an API to eliminate having to loop yourself (which would pretty >> much make this useless). >> >> My own personal use case is (once again) in meteorology, where we do >> station plots. This involves printing the actual value of observed >> variables relative to the location of the station. This isn't hard to >> do right now (especially since I have offset_copy back, thanks Mike!). >> I just wasn't sure if the batch functionality of a Collection might >> serve some purpose to the users at large. > > I've thought of it many times and it would definitely be useful, eg > for tick labels. Treating every label as a separate instance > definitely slows things down. > Ok, good to know. I'll put it on my todo list then. Do you think this can inherit from Collection at all? It seemed like a lot of the methods in the Collection base class were specific to polygons or other geometry and don't really make sense in the case of text. Anyone else have thoughts on how this should be implemented? 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=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Scale independent drawing
Hi, I'll continue my current flood of emails to the list. :) I'm finally getting back to my work on Skew-T plots, and I have a semi-working implementation (attached.) It runs, and as is, plots up some of the grid, with the x-value grid lines skewed 45 degrees to the right (as they should be.) The problem is as you resize the plot horizontally, some weird things happen. First, some of the lines that start overlaid end up separating as you expand the plot. The difference is between what is added using ax.plot and what is added using ax.vlines. The former adds Line2D objects while the latter adds a LineCollection which is holding path objects. I'm really not sure what's going on there. I'm not done checking it out yet, but I'm curious if anyone has any ideas off the top of their head. The second issue, which is more pressing, is when you resize vertically, the axes limits of the plot don't change (good), but unfortunately the lines don't stay connected to their lower y-coordinate in data space (bad). I'm really needing to draw things in a coordinate system that's independant of the data scale but also doesn't depend on the aspect ratio of the axes, so that I can get lines (and data plots) where the x gridlines are always at a 45 degree angle and the lower Y-value point stays fixed. By problem right now is that while I can find the lower left corner in pixel space and use that to do the proper adjustments, this changes when you resize. This changing is especially important in the y-direction. What I need is either of: 1) Axes space adjusted for aspect ratio (and updated with resizes) 2) Pixel space relative to some corner of the axes Or something similar that I don't know about. Any thoughts, or do I just need to come up with some magical combination of transforms that works? You can see what I have so far in my attached file. Thanks in advance, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma from matplotlib.axes import Axes from matplotlib.path import Path from matplotlib.lines import Line2D from matplotlib.ticker import Formatter, Locator, NullLocator, FixedLocator, NullFormatter, AutoLocator, ScalarFormatter from matplotlib import transforms from matplotlib.projections import register_projection import numpy as np # This example projection class is rather long, but it is designed to # illustrate many features, not all of which will be used every time. # It is also common to factor out a lot of these methods into common # code used by a number of projections with similar characteristics # (see geo.py). class SkewXAxes(Axes): # The projection must specify a name. This will be used be the # user to select the projection, i.e. ``subplot(111, # projection='skewx')``. name = 'skewx' ##def __init__(self, *args, **kwargs): ##Axes.__init__(self, *args, **kwargs) #self.set_aspect(1.0, adjustable='box', anchor='C') #self.cla() def _set_lim_and_transforms(self): """ This is called once when the plot is created to set up all the transforms for the data, text and grids. """ # There are three important coordinate spaces going on here: # #1. Data space: The space of the data itself # #2. Axes space: The unit rectangle (0, 0) to (1, 1) # covering the entire plot area. # #3. Display space: The coordinates of the resulting image, # often in pixels or dpi/inch. self.transAxes = transforms.BboxTransformTo(self.bbox) self.transScale = transforms.TransformWrapper( transforms.IdentityTransform()) self.transLimits = transforms.BboxTransformFrom( transforms.TransformedBbox(self.viewLim, self.transScale)) # This shifts to the lower left corner in pixel space shift = transforms.ScaledTranslation(0, 0, self.transAxes + transforms.Affine2D().scale(-1,-1)) # Shift to the lower left corner, do the skew, and shift back self.transProjection = shift + self.SkewXTransform() + shift.inverted() # Normal transform for things _non_skewed = self.transScale + (self.transLimits + self.transAxes) # Full data transform self.transData = _non_skewed + self.transProjection self._xaxis_transform = transforms.blended_transform_factory( _non_skewed, self.axes.transAxes) self._yaxis_transform = transforms.blended_transform_factory( self.axes.transAxes, _non_skewed) # Now, the transforms themselves. class SkewXTransform(transforms.Transform): """ The base skew transform. """ input_dims = 2 output_dims = 2 is_separable = False def __init__(self): """ Create a new skew transform. x,y -> x+y,y
Re: [matplotlib-devel] Scale independent drawing
Ryan May wrote: > Hi, > > I'll continue my current flood of emails to the list. :) I'm finally > getting back to my work on Skew-T plots, and I have a semi-working > implementation (attached.) It runs, and as is, plots up some of the > grid, with the x-value grid lines skewed 45 degrees to the right (as > they should be.) The problem is as you resize the plot horizontally, > some weird things happen. First, some of the lines that start overlaid > end up separating as you expand the plot. The difference is between > what is added using ax.plot and what is added using ax.vlines. The > former adds Line2D objects while the latter adds a LineCollection which > is holding path objects. I'm really not sure what's going on there. I'm > not done checking it out yet, but I'm curious if anyone has any ideas > off the top of their head. > > The second issue, which is more pressing, is when you resize vertically, > the axes limits of the plot don't change (good), but unfortunately the > lines don't stay connected to their lower y-coordinate in data space > (bad). I'm really needing to draw things in a coordinate system that's > independant of the data scale but also doesn't depend on the aspect > ratio of the axes, so that I can get lines (and data plots) where the x > gridlines are always at a 45 degree angle and the lower Y-value point > stays fixed. By problem right now is that while I can find the lower > left corner in pixel space and use that to do the proper adjustments, > this changes when you resize. This changing is especially important in > the y-direction. What I need is either of: > > 1) Axes space adjusted for aspect ratio (and updated with resizes) > 2) Pixel space relative to some corner of the axes > > Or something similar that I don't know about. Any thoughts, or do I > just need to come up with some magical combination of transforms that > works? You can see what I have so far in my attached file. > Ryan, based only on your description of the problems, and of what you need, I think the answer, or at least part of it, may be in good old quiver. Look at the way the transform is being generated depending on the units chosen, and note that preserving a specified angle on the page is part of it. Also note that the transform has to be regenerated on resize events, so a custom draw method is required. (Mike D. translated my original quiver code to use his transforms framework.) It seems like there should be an easier-to-use and more general way to do these sorts of things, and maybe there is--or maybe it can be ginned up. This reminds me of a thread a long time ago regarding adding hooks so that classes could register methods to be executed before their artists are rendered but after things like window and axes sizes have been determined. Eric - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] TextCollection
On Jul 22, 2008, at 6:26 PM, Ryan May <[EMAIL PROTECTED]> wrote: > John Hunter wrote: >> On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> Has anyone ever thought about creating a TextCollection class? The >>> purpose would be similar to the other collections, to group a >>> bunch of >>> text objects with similar properties. This probably couldn't >>> inherit >>> from Collection as of now though, since Collection assumes things >>> like >>> edgecolor and facecolor. The bigger question to me is, could the >>> backends make use of this to any improvement? Or would this simply >>> serve as an API to eliminate having to loop yourself (which would >>> pretty >>> much make this useless). >>> >>> My own personal use case is (once again) in meteorology, where we do >>> station plots. This involves printing the actual value of observed >>> variables relative to the location of the station. This isn't >>> hard to >>> do right now (especially since I have offset_copy back, thanks >>> Mike!). >>> I just wasn't sure if the batch functionality of a Collection might >>> serve some purpose to the users at large. >> >> I've thought of it many times and it would definitely be useful, eg >> for tick labels. Treating every label as a separate instance >> definitely slows things down. >> > > Ok, good to know. I'll put it on my todo list then. Do you think > this > can inherit from Collection at all? It seemed like a lot of the > methods > in the Collection base class were specific to polygons or other > geometry > and don't really make sense in the case of text. > > > > - There's some precedent for treating text as a collection of paths; for instance, many eps exporters allow 'as path' or 'as text' as options. I think most vector drawing apps treat the text color as a face color, and support an additional edge color for doing outline effects. So on that conceptual basis a collection seems appropriate, even if the renderer treats it differently than a polygon. -Eric - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scale independent drawing
Eric Firing wrote: > Ryan May wrote: >> Hi, >> >> I'll continue my current flood of emails to the list. :) I'm finally >> getting back to my work on Skew-T plots, and I have a semi-working >> implementation (attached.) It runs, and as is, plots up some of the >> grid, with the x-value grid lines skewed 45 degrees to the right (as >> they should be.) The problem is as you resize the plot horizontally, >> some weird things happen. First, some of the lines that start >> overlaid end up separating as you expand the plot. The difference is >> between what is added using ax.plot and what is added using >> ax.vlines. The former adds Line2D objects while the latter adds a >> LineCollection which is holding path objects. I'm really not sure >> what's going on there. I'm not done checking it out yet, but I'm >> curious if anyone has any ideas off the top of their head. >> >> The second issue, which is more pressing, is when you resize >> vertically, the axes limits of the plot don't change (good), but >> unfortunately the lines don't stay connected to their lower >> y-coordinate in data space (bad). I'm really needing to draw things >> in a coordinate system that's independant of the data scale but also >> doesn't depend on the aspect ratio of the axes, so that I can get >> lines (and data plots) where the x gridlines are always at a 45 degree >> angle and the lower Y-value point stays fixed. By problem right now >> is that while I can find the lower left corner in pixel space and use >> that to do the proper adjustments, this changes when you resize. This >> changing is especially important in the y-direction. What I need is >> either of: >> >> 1) Axes space adjusted for aspect ratio (and updated with resizes) >> 2) Pixel space relative to some corner of the axes >> >> Or something similar that I don't know about. Any thoughts, or do I >> just need to come up with some magical combination of transforms that >> works? You can see what I have so far in my attached file. >> > > Ryan, based only on your description of the problems, and of what you > need, I think the answer, or at least part of it, may be in good old > quiver. Look at the way the transform is being generated depending on > the units chosen, and note that preserving a specified angle on the page > is part of it. Also note that the transform has to be regenerated on > resize events, so a custom draw method is required. I'll take a look and see what I come up with, thanks for the tip. > > (Mike D. translated my original quiver code to use his transforms > framework.) > > It seems like there should be an easier-to-use and more general way to > do these sorts of things, and maybe there is--or maybe it can be ginned up. That's kind of what I was thinking and hoping. I would think this would be useful in a lot of places, especially where orientation relative to the screen is important, since that's not preserved when the axes are resized. > > This reminds me of a thread a long time ago regarding adding hooks so > that classes could register methods to be executed before their artists > are rendered but after things like window and axes sizes have been > determined. Yeah it seems like this comes up a lot. What would be nice though, instead of hooks, would be to fetch the necessary values when the transform is actually needed, instead of being notified of when the transform itself needs to be regenerated. Notifications would seem to add needless boilerplate code. 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=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scale independent drawing
On Tue, Jul 22, 2008 at 6:55 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Ryan May wrote: >> Hi, >> >> I'll continue my current flood of emails to the list. :) I'm finally >> getting back to my work on Skew-T plots, and I have a semi-working >> implementation (attached.) It runs, and as is, plots up some of the >> grid, with the x-value grid lines skewed 45 degrees to the right (as >> they should be.) The problem is as you resize the plot horizontally, >> some weird things happen. First, some of the lines that start overlaid >> end up separating as you expand the plot. The difference is between >> what is added using ax.plot and what is added using ax.vlines. The >> former adds Line2D objects while the latter adds a LineCollection which >> is holding path objects. I'm really not sure what's going on there. I'm >> not done checking it out yet, but I'm curious if anyone has any ideas >> off the top of their head. >> >> The second issue, which is more pressing, is when you resize vertically, >> the axes limits of the plot don't change (good), but unfortunately the >> lines don't stay connected to their lower y-coordinate in data space >> (bad). I'm really needing to draw things in a coordinate system that's >> independant of the data scale but also doesn't depend on the aspect >> ratio of the axes, so that I can get lines (and data plots) where the x >> gridlines are always at a 45 degree angle and the lower Y-value point >> stays fixed. By problem right now is that while I can find the lower >> left corner in pixel space and use that to do the proper adjustments, >> this changes when you resize. This changing is especially important in >> the y-direction. What I need is either of: >> >> 1) Axes space adjusted for aspect ratio (and updated with resizes) >> 2) Pixel space relative to some corner of the axes >> >> Or something similar that I don't know about. Any thoughts, or do I >> just need to come up with some magical combination of transforms that >> works? You can see what I have so far in my attached file. >> > > Ryan, based only on your description of the problems, and of what you > need, I think the answer, or at least part of it, may be in good old > quiver. Look at the way the transform is being generated depending on > the units chosen, and note that preserving a specified angle on the page > is part of it. Also note that the transform has to be regenerated on > resize events, so a custom draw method is required. > > (Mike D. translated my original quiver code to use his transforms > framework.) > > It seems like there should be an easier-to-use and more general way to > do these sorts of things, and maybe there is--or maybe it can be ginned up. > > This reminds me of a thread a long time ago regarding adding hooks so > that classes could register methods to be executed before their artists > are rendered but after things like window and axes sizes have been > determined. Since I'm 1. A meteorologist and 2. responsible for the draw-hook thread, I see I'm implicated here :) The utility of the before/after draw hook comes in when you want to do something system wide on all draw events. If the SkewT needs to do some setup before the Axes draw, a simple override of draw() seems the better route, since the need here would be class specific. That said, I was inspired by this to add on a bit to my previous hook solution, but that belongs in a separate thread. -Eric B - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
How do you guys manage committing only parts of your working copy, especially when you want to commit part of a file? I figure there's got to be a better way than multiple SVN checkouts and manually editing diffs. >>> svn should do this automagically; it only commits the diff from your >>> current working version and the svn HEAD. >>> svn up >>> # do some work svn diff # these are the changes that will be committed, just preview them svn commit -m 'my log message' # the diff will be committed >> >> I'm more interested how you guys handle having multiple lines of >> development going on in a single working copy, like working on >> multiple separate additions to axes.py. Trying to commit only a >> subset of those changes is difficult as far as I can tell. Or is the >> advice "don't do that" and use separate working copies? What if I'm >> working on something big and then have a small bug fix to do on the >> same file? Additional working copies wouldn't be a big deal, but it >> seems to take forever to do a fresh checkout from sourceforge. >> >> Ryan >> > > I think you could have a master checkout, and then use a local rsync to > make copies of it for hacking around on different parts. (This is the > sort of thing that is made very fast and easy with mercurial, but the > mercurial-svn interface mechanisms seem to be a bit clumsy, > unfortunately. Mike recently mentioned doing this sort of thing with > git. I haven't looked into git much; it has the reputation of being > rather hard to understand, and I have been happily using mercurial for > my local work for quite a long time, so I am not eager to start getting > confused by an alternative.) > This (and another comment I got in private) was pretty much what I expected. I just wanted to make sure I wasn't missing anything. I've already got two separate checkouts at the moment, so I think I'll try to just keep them up to date and keep one pristine for small stuff and testing. I'll keep rsync in mind however when I need a fresh one, thanks, 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=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Before/after callback registry decorator
I've expanded a bit on my previous solution for pre/post draw method
callbacks to add a registry which can be used to connect up arbitrary
callback functions.
The solution above is easy to adapt to other functions that might need
a callback, such as (to pick a random example) set_xlim.
See the attached example, which shows the functionality in action.
I've also shown how to handle the calls to start/stop raster in the
renderer that were my previous use case.
-Eric B
from matplotlib.cbook import CallbackRegistry
from matplotlib.axes import Axes
class Hooks(object):
def __init__(self):
signals = ('before_draw', 'after_draw')
self.callbacks = CallbackRegistry(signals)
def before_after_draw(self, draw):
"""
Decorator for Artist.draw method. Provides routines
that run before and after the draw call. The before and after functions
are useful for changing artist-dependant renderer attributes or making
other setup function calls, such as starting and flushing a mixed-mode
renderer.
"""
def before(artist, renderer):
self.callbacks.process('before_draw', artist, renderer)
def after(artist, renderer):
self.callbacks.process('after_draw', artist, renderer)
def draw_wrapper(artist, renderer):
before(artist, renderer)
draw(artist, renderer)
after(artist, renderer)
# "safe wrapping" to exactly replicate anything we haven't overridden above
draw_wrapper.__name__ = draw.__name__
draw_wrapper.__dict__ = draw.__dict__
draw_wrapper.__doc__ = draw.__doc__
return draw_wrapper
def greeter(artist, renderer):
print 'Hello, ', artist, '. You will be rendered tonight by', renderer
def benediction(artist, renderer):
print 'Good night, ', artist, '. You were rendered tonight by', renderer
def start_raster_mode(artist, renderer):
if artist.get_rasterized():
renderer.start_rasterizing()
def stop_raster_mode(artist, renderer):
if artist.get_rasterized():
renderer.stop_rasterizing()
hooks = Hooks()
hooks.callbacks.connect('before_draw', greeter)
hooks.callbacks.connect('after_draw', benediction)
hooks.callbacks.connect('before_draw', start_raster_mode)
hooks.callbacks.connect('after_draw', stop_raster_mode)
class WrappedAxes(Axes):
""" In real life, the Axes.draw() method would be decorated directly,
but this serves for the purposes of this demo. """
@hooks.before_after_draw
def draw(self, renderer):
super(WrappedAxes, self).draw(renderer)
import matplotlib.pyplot as plt
fig = plt.figure()
fig.clf()
ax = fig.add_axes(WrappedAxes(fig, (0.1,0.1,0.8,0.8)))
ax.plot(range(10))
plt.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=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Wind Barbs
Ok, I've committed my wind barbs stuff in SVN. Anyone interested, go ahead an hammer on it. Should I post this over on matplotlib-users, or does experience show that the SVN crowd all read here? (This is what you get for having a n00b developer :) ) Jeff, does a method need to be added to Basemap? If so, will you handle it or should it? 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=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs
Ryan May wrote: > Ok, > > I've committed my wind barbs stuff in SVN. Anyone interested, go ahead > an hammer on it. > > Should I post this over on matplotlib-users, or does experience show > that the SVN crowd all read here? (This is what you get for having a > n00b developer :) ) We routinely encourage anyone who uses svn to follow this list, but who knows? I don't think it would hurt to advertise it and see if there are any other meteorologists lurking out there who want to help check it out. Eric > > Jeff, does a method need to be added to Basemap? If so, will you handle > it or should it? > > Ryan > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
