matplotlib-devel Mailing List for matplotlib (Page 7)

Hi,
I committed the changes to clabel (r5830). For the attribute renaming,
I think we can safely rename most of them. In my opinion, the only ones
that users might use are .cl, .cl_xy and .cl_cvalues. The clabel
function creates these just before finishing from their more
appropriately named versions. This should provide enough backward
compatibility for a release or two.
And yes, isvector is different from iterable. For example:
In [81]: cbook.isvector( array([3,4,5,6]).reshape(1,1,1,4) )
Out[81]: True
In [82]: cbook.isvector( array([3,4,5,6]).reshape(1,1,2,2) )
Out[82]: False
This function is probably more useful in matlab since it has no shape
way to distinguish vectors from 2D matrices, but still it doesn't hurt
to have it around.
Cheers,
David
On Wed, 2008年07月23日 at 08:08 -1000, Eric Firing wrote:
> John Hunter wrote:
> > On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <Dav...@ir...> wrote:
> >> Hi,
> >>
> >> Well, I now know more than I ever wanted to about clabel. I decided to
> >> improve a bit on the inlining and ended up rewriting it. For automatic
> >> label placement, I basically use the existing algorithm for determining
> >> label location, but have replaced existing code for determining the
> >> angle of rotation and the amount of the contour to take off for inlining
> >> with new code. This new code is based on using pixel-space distances
> >> along the contour. This allows one to (1) get nice balanced inlining
> >> with the same amount of space on either side of the label, and (2) to
> >> vary the amount of space you want around the label. It also should deal
> >> better with labels located near contour edges and labels covering the
> >> entire contour.
> 
> It all sounds like much-needed improvement.
> 
> >>
> >> Along the way, I renamed all ContourLabeler specific attributes to
> >> something like .labelAttribute. This makes the namespace cleaner in my
> >> mind, but might break existing user code that does things directly with
> >> ContourLabeler attributes.
> > 
> > Eric, do you have any sense of whether people would use this directly?
> 
> I think the probability that anyone is doing this is low, but it would 
> be nice to ask on the users mailing list.
> 
> > Since this is a point release, I want to minimize API breakage, so at
> > least keep the old attrs around for this cycle. Eg, in Axes I
> > recently renamed axesPatch to simply patch as follows:
> > 
> > # the patch draws the background of the axes. we want this to
> > # be below the other artists; the axesPatch name is deprecated
> > self.patch = self.axesPatch = self._gen_axes_patch()
> > 
> > we don't have an easy way to catch deprecated usage w/o some property
> > or getattr magic. If you want to add getter properties for the
> > deprecated attrs which warn and point to the new, that would be ideal.
> 
> In general, yes, but in this case I think it would be better to go with 
> your simpler method above, of making duplicate names. It reduces the 
> code clutter and the chance of introducing last-minute errors. The 
> mailing list and API_CHANGES can be used to notify users of the upcoming 
> deprecation. If there is an outcry, indicating wide use of the 
> attributes, then properties can be introduced later to smooth the 
> deprecation process. But I predict there will be hardly a peep.
> 
> > 
> > 
> >> I also added a few new functions to cbook. One does simple linear
> >> interpolation (in addition to an existing cbook function that is similar
> >> but a bit different). Others do things with vector lengths. I also
> Maybe explain in the docstring or a comment why this version is needed?
> >> added a function called isvector that is identical to a Matlab function
> Maybe use try/except to return False if the test fails? If the input is 
> a string, or None, for example? Whether to do this depends on what the 
> use case is.
> >> of the same name. If desired, I can move this to mlab.py, but for the
> >> moment it is in cbook.py because most of the is? functions are there.
> > 
> > That's fine. Is this different from "iterable"
> > 
> >> On an aside, I noted that mlab.norm uses cut-and-paste documentation
> >> from Matlab. Is this wise?
> > 
> > No, please rewrite the docstring. Some of mlab was borrowed form
> > other people's codes, and I was unaware of this.
> 
> norm is one of the things we should not have at all; ours should be 
> deprecated in favor of numpy.linalg.norm. It would be good to have a 
> linear algebra guru look at this to see whether a straight substitution 
> with deprecation warning would work, or whether there are significant 
> differences. If something close to a substitution will work, then the 
> docstring in mlab can be replaced with a reference to the numpy 
> function. And then in some future release, it will all be deleted.
> 
> > 
> >> I have tested all the changes against the existing pylab_examples and
> >> things work fine. Nonetheless, since lots of things have been changed,
> >> I haven't committed them for fear of interfering with the release.
> >> Instead, I am attaching the patch set. If I get the green light, I will
> >> commit these changes.
> > 
> Given the stated "release early, release often" strategy, go ahead and 
> commit.
> 
> Eric
> 
> > I'll leve the final call on this to Eric, but after this I suggest we
> > implement a feature freeze until after we get the current code tested
> > and out. Friday is a reasonable target if others agree and we have a
> > chance to test this for a couple of days.
> > 
> >> Related: while I am digging around in there, now is probably the moment
> >> for me to integrate Paul Kienzle's comments on start/stop_event_loop in
> >> FigureCanvasBase, etc. I am not sure there is a consensus on this. I
> >> am currently thinking that the best way to integrate this, while
> >> minimizing repeated code, is a mixin plus a couple of new classes,
> >> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
> >> inherit the mixin and the base classes without "GUI". Interactive
> >> backends would then inherit these. Non-interactive backends would
> >> inherit versions that throw errors from FigureBaseCanvas. Complex, but
> >> this assures clean inheritance. Thoughts welcome.
> > 
> > See my response in the original thread. I'm not sure we ever reached
> > a consensus on this one, and I'm still uncomfortable with a more
> > complex hierarchy. I'm willing to be convince if you and Paul and
> > Gael disagree, but I have yet to see why a flat implementation will
> > not work here.
> > 
> > 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
**********************************

Hi,
I have finally committed a changeset for moving the "event loop" stuff
into the backends. I have hopefully found a compromise that will please
most. Since this is close to release date, I suggest that everyone who
can give it a look (r5831) and if there is any problem, just role the
changes back and release with the old code.
My compromise was the following:
1) In FigureCanvasBase, create start/stop_event_loop that raise errors.
I kept these names instead of wait_start wait_stop because I think
things like start_event_loop is used in other programming contexts to
denote the same things. In the documentation string, I tried to make it
clear that this is not the overall GUI event loop. If people aren't
happy, changing is a fairly simple find and replace.
2) In FigureCanvasBase, I also created start/stop_event_loop_default.
These do the standard time.sleep thing. start_event_loop_default throws
a deprecated warning saying it should be replaced by a gui specific
version. Once we have the gui specific versions, I still think we
should keep this function around as this code is very simple and
straightforward and is likely to work on almost anything. For example,
if we ever had a problem with a backend, we could always use this till a
fix was found.
3) In cocoagg, fltkagg, gtk, qt, qt4, and tkagg, I implemented
fall-through functions for start/stop_event_loop that simply call the
default versions.
4) In WX, I used the code submitted by Paul, but was unable to check it
because when I tried to use the WX backend, I got an error about no
GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2.
Again, any problem with this, just role the changes back until after the
release.
Cheers,
David
Traceback (most recent call last):
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 1035, in _onPaint
 self.draw(repaint=False)
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 903, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
724, in draw
 if self.frameon: self.patch.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
257, in draw
 gc = renderer.new_gc()
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 360, in new_gc
 self.gc = GraphicsContextWx(self.bitmap, self)
 File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 457, in __init__
 gfx_ctx = wx.GraphicsContext.Create(dc)
<type 'exceptions.AttributeError'>: 'module' object has no attribute
'GraphicsContext'
-- 
**********************************
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
**********************************

John Hunter wrote:
> On Sat, Jul 19, 2008 at 11:09 PM, Ryan May <rm...@gm...> wrote:
> 
>> The only issue I've seen is that scaling with PS is way too big. I've
>> attached ps and pdf files from the same run to show the problem.
> 
> The only thing I can think of is since you are using a identity
> transform and drawing in pixels, you are seeing the effect of the
> savefig dpi in pdf and png but not in ps, which hardcodes the dpi to
> 72. If this is correct, you should not see the effect if you pass
> dpi=72 to savefig when saving the PS and PDF. You will probably want
> to modify the patch to make sure your barbs scales are dpi
> independent. I have only looked briefly at the barbs code so I could
> be missing something obvious, but this is the first thing that comes
> to mind.
<grumble> Ok, it fixes the problem if I pass dpi=72 to savefig(). 
Curiously, passing dpi=72 to Figure() does not have the same effect. So 
now how do I fix it? I'm really not sure what's going wrong here. If I 
had to guess, it's a problem between figure size being in inches while 
I'm drawing in pixels (still don't know how that works, because there's 
no way those barbs are 9 pixels long).
Ideas?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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.
> 
Ok, I've attached code that works for my purpose. It includes text data 
so that you can see what the plot is supposed to look like. It turned 
out to be rather simple once I figured out exactly what needed to happen 
and how the matplotlib API stacked up. As noted in the file, I still 
have much to do, like add proper gridlines and somehow fix the nastiness 
when you try to pan or zoom. I now at least have a plot that gives me 
what I want and resizes correctly (the fact that it looks weird to my 
meteorologist eyes when resized is a consequence of the transform's 
dependence on data ranges and physical size of the plot).
I ended up going with an approach that just overrides draw to call a 
function to update the Axes.transData attribute. I also set transData 
to be a transformWrapper() so that any objects that grab the transform 
will have access the the updated transform when a resize occurs. BIG 
THANKS to Mike for creating such an awesome transform framework. Once 
you get the hang of the coordinate systems and know what's actually 
possible, it's *extremely* powerful.
Now my bigger question is where the heck to put what I have when I'm 
finished...
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Jul 23, 2008 at 09:14:46AM -0500, John Hunter wrote:
> > Related: while I am digging around in there, now is probably the moment
> > for me to integrate Paul Kienzle's comments on start/stop_event_loop in
> > FigureCanvasBase, etc. I am not sure there is a consensus on this. I
> > am currently thinking that the best way to integrate this, while
> > minimizing repeated code, is a mixin plus a couple of new classes,
> > FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
> > inherit the mixin and the base classes without "GUI". Interactive
> > backends would then inherit these. Non-interactive backends would
> > inherit versions that throw errors from FigureBaseCanvas. Complex, but
> > this assures clean inheritance. Thoughts welcome.
> See my response in the original thread. I'm not sure we ever reached
> a consensus on this one, and I'm still uncomfortable with a more
> complex hierarchy. I'm willing to be convince if you and Paul and
> Gael disagree, but I have yet to see why a flat implementation will
> not work here.
I actually lean on the simple side for now. If we find as we improve the
event-loop related stuff that we need this, we can easily add an
abstraction, but right now I don't see a big benefit. Anyhow, whoever
does the work gets to decide, as usual.
Gaël

Eric Firing wrote:
> Ryan May wrote:
>> Ok,
>>
>> I've committed my wind barbs stuff in SVN. Anyone interested, go 
>> ahead an hammer on it.
> 
> Very nice!
> 
> Comments on the example, barb_demo.py:
> 
> 1) In your third panel, you put the args after the kwargs. I had no 
> idea this was even legal--it's the first time I have seen it. It's 
> probably better to stick with conventional usage so as not to distract 
> the reader from the point, which is how to use the barb function.
> 
> 2) In a similar vein, I would suggest sticking with explicit X, Y, U, V 
> arguments. Your (*zip(*data)) is an obfuscation.
> 
> 3) It would be better to use non-square asymmetric arrays so as to make 
> it clear which point in the data array corresponds to which point on the 
> plot. An example with NxN arrays doesn't help illustrate the relation 
> between the array and the plot locations.
> 
Ok, I checked in some changes that should address all of those, plus 
provide a more comprehensive demonstration of capabilities. Thanks for 
the feedback.
I also got rid of the windows line endings (sorry). Usually not a 
problem, but I've had a (temporary) "opportunity" to be using windows 
for some development.
Let me know if you see anything else.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John Hunter wrote:
>> I have tested all the changes against the existing pylab_examples and
>> things work fine. Nonetheless, since lots of things have been changed,
>> I haven't committed them for fear of interfering with the release.
>> Instead, I am attaching the patch set. If I get the green light, I will
>> commit these changes.
> 
> I'll leve the final call on this to Eric, but after this I suggest we
> implement a feature freeze until after we get the current code tested
> and out. Friday is a reasonable target if others agree and we have a
> chance to test this for a couple of days.
> 
+1
Are we going to try to get anything out after that for scipy, or is this 
it? I realize with Friday we're targeting Debian.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On solaris with gcc-4.3.1, the macro __cplusplus is not defined to
199711L. This is a long-standing issue with solaris. This doesn't much
matter on some platforms, but for matplotlib, what is happening to me
is that through a series of defines and conditionals, the method
putchar, as used here:
./ttconv/ttutil.cpp:void TTStreamWriter::putchar(int val)
gets tokenized by the preprocessor into putc by
/usr/include/iso/stdio_iso.h, here on line 350:
#define putchar(x) putc((x), stdout)
This only happens if __cplusplus is < 199711L. I'm avoiding this by
building using the studio C compiler, but I thought I'd mention this
in case it's possible to detect this during the configuration stage,
and perhaps wrap with something like:
#ifdef
#if __cplusplus <= 199711L
#undef putchar
#endif
#endif
However, I haven't tested this yet. Has anyone else thought about
this?
Thanks,
-Peter
-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

John Hunter wrote:
> On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <Dav...@ir...> wrote:
>> Hi,
>>
>> Well, I now know more than I ever wanted to about clabel. I decided to
>> improve a bit on the inlining and ended up rewriting it. For automatic
>> label placement, I basically use the existing algorithm for determining
>> label location, but have replaced existing code for determining the
>> angle of rotation and the amount of the contour to take off for inlining
>> with new code. This new code is based on using pixel-space distances
>> along the contour. This allows one to (1) get nice balanced inlining
>> with the same amount of space on either side of the label, and (2) to
>> vary the amount of space you want around the label. It also should deal
>> better with labels located near contour edges and labels covering the
>> entire contour.
It all sounds like much-needed improvement.
>>
>> Along the way, I renamed all ContourLabeler specific attributes to
>> something like .labelAttribute. This makes the namespace cleaner in my
>> mind, but might break existing user code that does things directly with
>> ContourLabeler attributes.
> 
> Eric, do you have any sense of whether people would use this directly?
I think the probability that anyone is doing this is low, but it would 
be nice to ask on the users mailing list.
> Since this is a point release, I want to minimize API breakage, so at
> least keep the old attrs around for this cycle. Eg, in Axes I
> recently renamed axesPatch to simply patch as follows:
> 
> # the patch draws the background of the axes. we want this to
> # be below the other artists; the axesPatch name is deprecated
> self.patch = self.axesPatch = self._gen_axes_patch()
> 
> we don't have an easy way to catch deprecated usage w/o some property
> or getattr magic. If you want to add getter properties for the
> deprecated attrs which warn and point to the new, that would be ideal.
In general, yes, but in this case I think it would be better to go with 
your simpler method above, of making duplicate names. It reduces the 
code clutter and the chance of introducing last-minute errors. The 
mailing list and API_CHANGES can be used to notify users of the upcoming 
deprecation. If there is an outcry, indicating wide use of the 
attributes, then properties can be introduced later to smooth the 
deprecation process. But I predict there will be hardly a peep.
> 
> 
>> I also added a few new functions to cbook. One does simple linear
>> interpolation (in addition to an existing cbook function that is similar
>> but a bit different). Others do things with vector lengths. I also
Maybe explain in the docstring or a comment why this version is needed?
>> added a function called isvector that is identical to a Matlab function
Maybe use try/except to return False if the test fails? If the input is 
a string, or None, for example? Whether to do this depends on what the 
use case is.
>> of the same name. If desired, I can move this to mlab.py, but for the
>> moment it is in cbook.py because most of the is? functions are there.
> 
> That's fine. Is this different from "iterable"
> 
>> On an aside, I noted that mlab.norm uses cut-and-paste documentation
>> from Matlab. Is this wise?
> 
> No, please rewrite the docstring. Some of mlab was borrowed form
> other people's codes, and I was unaware of this.
norm is one of the things we should not have at all; ours should be 
deprecated in favor of numpy.linalg.norm. It would be good to have a 
linear algebra guru look at this to see whether a straight substitution 
with deprecation warning would work, or whether there are significant 
differences. If something close to a substitution will work, then the 
docstring in mlab can be replaced with a reference to the numpy 
function. And then in some future release, it will all be deleted.
> 
>> I have tested all the changes against the existing pylab_examples and
>> things work fine. Nonetheless, since lots of things have been changed,
>> I haven't committed them for fear of interfering with the release.
>> Instead, I am attaching the patch set. If I get the green light, I will
>> commit these changes.
> 
Given the stated "release early, release often" strategy, go ahead and 
commit.
Eric
> I'll leve the final call on this to Eric, but after this I suggest we
> implement a feature freeze until after we get the current code tested
> and out. Friday is a reasonable target if others agree and we have a
> chance to test this for a couple of days.
> 
>> Related: while I am digging around in there, now is probably the moment
>> for me to integrate Paul Kienzle's comments on start/stop_event_loop in
>> FigureCanvasBase, etc. I am not sure there is a consensus on this. I
>> am currently thinking that the best way to integrate this, while
>> minimizing repeated code, is a mixin plus a couple of new classes,
>> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
>> inherit the mixin and the base classes without "GUI". Interactive
>> backends would then inherit these. Non-interactive backends would
>> inherit versions that throw errors from FigureBaseCanvas. Complex, but
>> this assures clean inheritance. Thoughts welcome.
> 
> See my response in the original thread. I'm not sure we ever reached
> a consensus on this one, and I'm still uncomfortable with a more
> complex hierarchy. I'm willing to be convince if you and Paul and
> Gael disagree, but I have yet to see why a flat implementation will
> not work here.
> 
> 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

On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <Dav...@ir...> wrote:
> Hi,
>
> Well, I now know more than I ever wanted to about clabel. I decided to
> improve a bit on the inlining and ended up rewriting it. For automatic
> label placement, I basically use the existing algorithm for determining
> label location, but have replaced existing code for determining the
> angle of rotation and the amount of the contour to take off for inlining
> with new code. This new code is based on using pixel-space distances
> along the contour. This allows one to (1) get nice balanced inlining
> with the same amount of space on either side of the label, and (2) to
> vary the amount of space you want around the label. It also should deal
> better with labels located near contour edges and labels covering the
> entire contour.
>
> Along the way, I renamed all ContourLabeler specific attributes to
> something like .labelAttribute. This makes the namespace cleaner in my
> mind, but might break existing user code that does things directly with
> ContourLabeler attributes.
Eric, do you have any sense of whether people would use this directly?
Since this is a point release, I want to minimize API breakage, so at
least keep the old attrs around for this cycle. Eg, in Axes I
recently renamed axesPatch to simply patch as follows:
 # the patch draws the background of the axes. we want this to
 # be below the other artists; the axesPatch name is deprecated
 self.patch = self.axesPatch = self._gen_axes_patch()
we don't have an easy way to catch deprecated usage w/o some property
or getattr magic. If you want to add getter properties for the
deprecated attrs which warn and point to the new, that would be ideal.
> I also added a few new functions to cbook. One does simple linear
> interpolation (in addition to an existing cbook function that is similar
> but a bit different). Others do things with vector lengths. I also
> added a function called isvector that is identical to a Matlab function
> of the same name. If desired, I can move this to mlab.py, but for the
> moment it is in cbook.py because most of the is? functions are there.
That's fine. Is this different from "iterable"
> On an aside, I noted that mlab.norm uses cut-and-paste documentation
> from Matlab. Is this wise?
No, please rewrite the docstring. Some of mlab was borrowed form
other people's codes, and I was unaware of this.
> I have tested all the changes against the existing pylab_examples and
> things work fine. Nonetheless, since lots of things have been changed,
> I haven't committed them for fear of interfering with the release.
> Instead, I am attaching the patch set. If I get the green light, I will
> commit these changes.
I'll leve the final call on this to Eric, but after this I suggest we
implement a feature freeze until after we get the current code tested
and out. Friday is a reasonable target if others agree and we have a
chance to test this for a couple of days.
> Related: while I am digging around in there, now is probably the moment
> for me to integrate Paul Kienzle's comments on start/stop_event_loop in
> FigureCanvasBase, etc. I am not sure there is a consensus on this. I
> am currently thinking that the best way to integrate this, while
> minimizing repeated code, is a mixin plus a couple of new classes,
> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
> inherit the mixin and the base classes without "GUI". Interactive
> backends would then inherit these. Non-interactive backends would
> inherit versions that throw errors from FigureBaseCanvas. Complex, but
> this assures clean inheritance. Thoughts welcome.
See my response in the original thread. I'm not sure we ever reached
a consensus on this one, and I'm still uncomfortable with a more
complex hierarchy. I'm willing to be convince if you and Paul and
Gael disagree, but I have yet to see why a flat implementation will
not work here.
JDH

On Wed, Jul 23, 2008 at 8:53 AM, David Kaplan <Dav...@ir...> wrote:
> That should be an "and" not an "or"
OK, I'll leave the final fix to you.....
JDH

On Fri, Jul 18, 2008 at 2:32 PM, David M. Kaplan <Dav...@ir...> wrote:
> Well, yeah. I think this would mean a lot of the same code in many
> backends. I also like the idea of a deeper hierarchy with a
> FigureCanvasUserInterface class that inherits FigureCanvasBase but adds
> functional start/stop_loop_events because it would allow for a simple
> cbook test for a working user interface:
> isinstance(mycanvas,FigureCanvasUserInterface)
I'm not sure I see where the redundant code is coming in. In envision
the base class doing nothing in start_event_loop and stop_event_loop
which solves the problem for the non-UI backends, and all the UI
backends will have to be specialized to deal with their own event
loops. Basically, we would need to provide implementations for gtk,
tk, wx and qt (and maybe qt4?) since these are the four backends that
are actually maintained. Perhaps I am overly squeamish, but I am
uncomfortable with a default UI implementation here anyhow.
This is the paradigm we have used for the canvas draw_idle method and
it has worked fine. If we get consensus on this, I think we can bang
out the four methods quickly. tk requires nothing special and can be
based on the current sleep implementation. I can help with gtk if
need be. Paul has already done wx. qt anyone?
Also, are the names stop_event_loop and stop_event_loop good choices?
I find them confusing because I associate them with the UI event loop
which will always be running. Something like
wait_start and wait_stop is more intuitive to me.
> A deeper hierarchy won't help the inheritance problem for GTKAgg though.
I believe this will solve the problem, because FigureCanvasGTK is
inherited first, so GTKAgg will get the specialized method. According
to Guido at
http://www.network-theory.co.uk/docs/pytut/MultipleInheritance.html
 The only rule necessary to explain the semantics is the resolution
rule used for class attribute
 references. This is depth-first, left-to-right. Thus, if an
attribute is not found in DerivedClassName,
 it is searched in Base1, then (recursively) in the base classes of
Base1, and only if it is not
 found there, it is searched in Base2, and so on.

Hi,
Almost:
In [3]: cbook.is_scalar((0,1))
Out[3]: True
That should be an "and" not an "or".
Cheers,
David
On Wed, 2008年07月23日 at 08:16 -0500, John Hunter wrote:
> On Wed, Jul 23, 2008 at 4:04 AM, David Kaplan <Dav...@ir...> wrote:
> > Hi,
> >
> > I believe that the cbook.is_scalar function has a bug:
> >
> > In [19]: cbook.is_scalar('abc')
> > Out[19]: 1
> >
> > I believe it should be:
> >
> > def is_scalar(obj):
> > 'return true if *obj* is not string like and is not iterable'
> > return not is_string_like(obj) and not iterable(obj)
> 
> Yep, good catch. I committed this fix to 5822
> 
> JDH
-- 
**********************************
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 Wed, Jul 23, 2008 at 4:04 AM, David Kaplan <Dav...@ir...> wrote:
> Hi,
>
> I believe that the cbook.is_scalar function has a bug:
>
> In [19]: cbook.is_scalar('abc')
> Out[19]: 1
>
> I believe it should be:
>
> def is_scalar(obj):
> 'return true if *obj* is not string like and is not iterable'
> return not is_string_like(obj) and not iterable(obj)
Yep, good catch. I committed this fix to 5822
JDH

Hi,
Well, I now know more than I ever wanted to about clabel. I decided to
improve a bit on the inlining and ended up rewriting it. For automatic
label placement, I basically use the existing algorithm for determining
label location, but have replaced existing code for determining the
angle of rotation and the amount of the contour to take off for inlining
with new code. This new code is based on using pixel-space distances
along the contour. This allows one to (1) get nice balanced inlining
with the same amount of space on either side of the label, and (2) to
vary the amount of space you want around the label. It also should deal
better with labels located near contour edges and labels covering the
entire contour.
Along the way, I renamed all ContourLabeler specific attributes to
something like .labelAttribute. This makes the namespace cleaner in my
mind, but might break existing user code that does things directly with
ContourLabeler attributes.
I also added a few new functions to cbook. One does simple linear
interpolation (in addition to an existing cbook function that is similar
but a bit different). Others do things with vector lengths. I also
added a function called isvector that is identical to a Matlab function
of the same name. If desired, I can move this to mlab.py, but for the
moment it is in cbook.py because most of the is? functions are there.
On an aside, I noted that mlab.norm uses cut-and-paste documentation
from Matlab. Is this wise?
I have tested all the changes against the existing pylab_examples and
things work fine. Nonetheless, since lots of things have been changed,
I haven't committed them for fear of interfering with the release.
Instead, I am attaching the patch set. If I get the green light, I will
commit these changes.
Related: while I am digging around in there, now is probably the moment
for me to integrate Paul Kienzle's comments on start/stop_event_loop in
FigureCanvasBase, etc. I am not sure there is a consensus on this. I
am currently thinking that the best way to integrate this, while
minimizing repeated code, is a mixin plus a couple of new classes,
FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
inherit the mixin and the base classes without "GUI". Interactive
backends would then inherit these. Non-interactive backends would
inherit versions that throw errors from FigureBaseCanvas. Complex, but
this assures clean inheritance. Thoughts welcome.
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
**********************************

Eric Firing wrote:
> Ryan May wrote:
>> Ok,
>>
>> I've committed my wind barbs stuff in SVN. Anyone interested, go 
>> ahead an hammer on it.
> 
> Very nice!
> 
> Comments on the example, barb_demo.py:
> 
> 1) In your third panel, you put the args after the kwargs. I had no 
> idea this was even legal--it's the first time I have seen it. It's 
> probably better to stick with conventional usage so as not to distract 
> the reader from the point, which is how to use the barb function.
Magic! I don't know either. It's one of those things you stick in 
during development for expediency.
> 2) In a similar vein, I would suggest sticking with explicit X, Y, U, V 
> arguments. Your (*zip(*data)) is an obfuscation.
Agreed.
> 3) It would be better to use non-square asymmetric arrays so as to make 
> it clear which point in the data array corresponds to which point on the 
> plot. An example with NxN arrays doesn't help illustrate the relation 
> between the array and the plot locations.
Sure.
I was going to tweak the demo anyways to show off more of the available 
parameters, so all of this will fit in well with that. I'll try to 
squeeze that in tonight.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I believe that the cbook.is_scalar function has a bug:
In [19]: cbook.is_scalar('abc')
Out[19]: 1
I believe it should be:
def is_scalar(obj):
 'return true if *obj* is not string like and is not iterable'
 return not is_string_like(obj) and not iterable(obj)
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
**********************************

Ryan May wrote:
> Ok,
> 
> I've committed my wind barbs stuff in SVN. Anyone interested, go ahead 
> an hammer on it.
Very nice!
Comments on the example, barb_demo.py:
1) In your third panel, you put the args after the kwargs. I had no 
idea this was even legal--it's the first time I have seen it. It's 
probably better to stick with conventional usage so as not to distract 
the reader from the point, which is how to use the barb function.
2) In a similar vein, I would suggest sticking with explicit X, Y, U, V 
arguments. Your (*zip(*data)) is an obfuscation.
3) It would be better to use non-square asymmetric arrays so as to make 
it clear which point in the data array corresponds to which point on the 
plot. An example with NxN arrays doesn't help illustrate the relation 
between the array and the plot locations.
Eric

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
> 

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

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

>>>> 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

On Tue, Jul 22, 2008 at 6:55 PM, Eric Firing <ef...@ha...> 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

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

On Jul 22, 2008, at 6:26 PM, Ryan May <rm...@gm...> wrote:
> John Hunter wrote:
>> On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <rm...@gm...> 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