matplotlib-devel Mailing List for matplotlib

I noticed a couple of really minor typos as shown below:

Index: matplotlib/lib/matplotlib/axis.py
===================================================================
--- matplotlib/lib/matplotlib/axis.py	(revision 5860)
+++ matplotlib/lib/matplotlib/axis.py	(working copy)
@@ -147,7 +147,7 @@
          """
          self._pad = val

-    def get_pad(self, val):
+    def get_pad(self):
          'Get the value of the tick label pad in points'
          return self._pad

Index: matplotlib/examples/event_handling/lasso_demo.py
===================================================================
--- matplotlib/examples/event_handling/lasso_demo.py	(revision 5860)
+++ matplotlib/examples/event_handling/lasso_demo.py	(working copy)
@@ -69,7 +69,7 @@
          # acquire a lock on the widget drawing
          self.canvas.widgetlock(self.lasso)

-if 0:
+if __name__ == '__main__':

      data = [Datum(*xy) for xy in rand(100, 2)]

On Thu, Jul 24, 2008 at 5:45 PM, Paul Kienzle <pki...@ni...> wrote:
> Hi,
>
> I added support for scroll wheel events in wx.  This includes
> a new attribute event.step since the wx mouse wheel event
> reports larger steps when scrolling faster.  I don't see
> how to check step in gtk, so I set step to +1 and -1 for up
> and down.
>
> Can someone with gtk please run the following to make sure
> I didn't break anything:
>
>    examples/pylab_examples/image_slices_viewer.py

Works fine for me here...

JDH

Hi,

I added support for scroll wheel events in wx.  This includes
a new attribute event.step since the wx mouse wheel event
reports larger steps when scrolling faster.  I don't see
how to check step in gtk, so I set step to +1 and -1 for up 
and down.

Can someone with gtk please run the following to make sure
I didn't break anything:

    examples/pylab_examples/image_slices_viewer.py


Thanks,

	- Paul

Eric Firing wrote:
> John Hunter wrote:
>> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <pki...@ni...> wrote:

>>
>>> Running, I get a leak of about 5.6 KiB per loop.
>>> I'm using matplotlib svn, macos 10.4, numpy 1.1.0
>> I'm not seeing this w/ PDF or Agg in linux...  what backend are you
>> using (the file had set use('PDF') so I assume you are using that.
> 
> Ubuntu hardy, numpy svn, mpl svn, memleak_hawaii3.py with default pdf 
> output:
> 399 12710
> 400 12710
> Average memory consumed per loop: 0.8706k bytes

And with agg backend:
399 12285
400 12285
Average memory consumed per loop: 0.1244k bytes

With ps backend:
399 12206
400 12206
Average memory consumed per loop: 0.1343k bytes


Eric

On Thu, Jul 24, 2008 at 5:16 PM, Paul Kienzle <pki...@ni...> wrote:

> PDF.

OK, correction, I am seeing this too.  I cheated and didn't let the
test run to the end.  It looked like the memory was flat-lining so I
moved on the Agg test (which is not leaking on my completed tests).

> The examples are a great learning resource.  They should not
> include deprecated patterns.  I suggest removing it.

Will do -- I'll just rewrite it into the suggested pattern and rename
it accordingly (eg simple_anim_tk.py, etc...)


JDH

On Thu, Jul 24, 2008 at 04:28:00PM -0500, John Hunter wrote:
> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <pki...@ni...> wrote:
> > Running, I get a leak of about 5.6 KiB per loop.
> > I'm using matplotlib svn, macos 10.4, numpy 1.1.0
> 
> I'm not seeing this w/ PDF or Agg in linux...  what backend are you
> using (the file had set use('PDF') so I assume you are using that.

PDF.

> Thanks for the fixes.  This mode of animation works on tk, but not
> really for the GUI backends, and is discouraged on the cookbook page.
> We probably should update the example to use Tkagg and discourage this
> usage on other GUIs.

The examples are a great learning resource.  They should not
include deprecated patterns.  I suggest removing it.

	- Paul

On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <pki...@ni...> wrote:

> I also fixed some of the lesser used examples.  I'm not going to try to
> fix examples/units.  examples/animation/anim.py doesn't update on my
> wxagg backend (wx 2.8.3).

I fixed a few of the units examples that were trivial.  The others
were already broken on the trunk so it is not a regression, and I will
hold off on anything more significant pending the units api/design doc
we were discussing earlier.  I also added the working examples to the
backend_driver so at least we will not regress further in the
meantime...

JDH

John Hunter wrote:
> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <pki...@ni...> wrote:
> 
>> Testing hawaii on my machine, I saw the following error:
>>
>>  Traceback (most recent call last):
>>    File "memleak_hawaii3.py", line 13, in <module>
>>      rand = np.mlab.rand
>>  AttributeError: 'module' object has no attribute 'mlab'
>>
>> I replaced mlab with random and it now works.
> 
> Sorry, I had fixed that locally and forgotten to commit.  Committed now.
> 
>> Running, I get a leak of about 5.6 KiB per loop.
>> I'm using matplotlib svn, macos 10.4, numpy 1.1.0
> 
> I'm not seeing this w/ PDF or Agg in linux...  what backend are you
> using (the file had set use('PDF') so I assume you are using that.

Ubuntu hardy, numpy svn, mpl svn, memleak_hawaii3.py with default pdf 
output:
399 12710
400 12710
Average memory consumed per loop: 0.8706k bytes

Eric

On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <pki...@ni...> wrote:

> Testing hawaii on my machine, I saw the following error:
>
>  Traceback (most recent call last):
>    File "memleak_hawaii3.py", line 13, in <module>
>      rand = np.mlab.rand
>  AttributeError: 'module' object has no attribute 'mlab'
>
> I replaced mlab with random and it now works.

Sorry, I had fixed that locally and forgotten to commit.  Committed now.

> Running, I get a leak of about 5.6 KiB per loop.
> I'm using matplotlib svn, macos 10.4, numpy 1.1.0

I'm not seeing this w/ PDF or Agg in linux...  what backend are you
using (the file had set use('PDF') so I assume you are using that.


> I also fixed some of the lesser used examples.  I'm not going to try to
> fix examples/units.  examples/animation/anim.py doesn't update on my
> wxagg backend (wx 2.8.3).

Thanks for the fixes.  This mode of animation works on tk, but not
really for the GUI backends, and is discouraged on the cookbook page.
We probably should update the example to use Tkagg and discourage this
usage on other GUIs.

JDH

On Thu, Jul 24, 2008 at 02:17:19PM -0500, John Hunter wrote:
> I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if
> the weekday doesn't work for you Charlie we might do a source release
> on Friday or Saturday (for Sandro/debian) and you can get the build
> out over the weekend (if you have time).  Obviously a lot of work has
> gone into these releases, and a lot recently, so it is important to
> test on what platforms you can.  Currently backend driver and memleak
> hawaii are passing on my platform, and I have managed to at least
> lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and
> QT4) on at least one platform and for some backends a couple.

Testing hawaii on my machine, I saw the following error:

  Traceback (most recent call last):
    File "memleak_hawaii3.py", line 13, in <module>
      rand = np.mlab.rand
  AttributeError: 'module' object has no attribute 'mlab'

I replaced mlab with random and it now works.

Running, I get a leak of about 5.6 KiB per loop.
I'm using matplotlib svn, macos 10.4, numpy 1.1.0

I also fixed some of the lesser used examples.  I'm not going to try to
fix examples/units.  examples/animation/anim.py doesn't update on my
wxagg backend (wx 2.8.3).

	- Paul

I am out on town for a meeting until Sunday evening.  I unfortunately won't
be able to act until Monday at the earliest.  Cutting the source release
sounds like a good plan.

- Charlie

On Thu, Jul 24, 2008 at 3:17 PM, John Hunter <jd...@gm...> wrote:

> I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if
> the weekday doesn't work for you Charlie we might do a source release
> on Friday or Saturday (for Sandro/debian) and you can get the build
> out over the weekend (if you have time).  Obviously a lot of work has
> gone into these releases, and a lot recently, so it is important to
> test on what platforms you can.  Currently backend driver and memleak
> hawaii are passing on my platform, and I have managed to at least
> lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and
> QT4) on at least one platform and for some backends a couple.
>
> The contouring code has had the most recent significant changes, so if
> you have limited time hit that the hardest.
>
> Charlie, let me know what your time frame is....
>
> Sandro, here is a release candidate tarball for you to test with:
> http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz
>
> Thanks,
> JDH
>

John Hunter wrote:
> On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <rm...@gm...> wrote:
> 
>> <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
> 
> That is because "savefig" has its own dpi, which overrides the figure
> dpi.  Tee ideas is that you typically want a different dpi for the UI
> window and for the harcopy
> 
>> 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).
> 
> I'm not familiar enough with the windbarb code to know where the "9
> pixel" thing that is bothering you is creeping in, I'm just saying
> that using an identity transform means you are drawing in canvas
> (pixel) space and not accounting for dpi.  The Figure instance has a
> "dpi_scale_transform" that is designed to handle dpi scaling, and
> updates itself when the figure dpi is changed so you don't have to
> handle the callbacks.  Take a look at this and see if you can
> incorporate it.  If you have troubles, Michael or I can advise
> further.
> 
> If you clarify the "9 pixel" problem that is bothering you, I may be
> able to help more sooner...

Part of the problem is the horrible and misleading sizes arg in 
PolyCollections, probably a hangover (yes, a headache) from supporting a 
Matlab-compatible argument in scatter.  I can try to straighten this out 
and clarify the situation after the release, not before.  I will add an 
alternative kwarg to scatter at the same time, and hope the old usage 
gradually dies out.

Eric


> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,

Anyone planning to attend post-SciPy2008 code sprints?

Some projects I'm interested in:

  support for units (px, pt/in/cm/mm, em/ex/<font height>, %axis/%figure)
  style sheet editor (needs backend support for forms and menus)
  canvas interface for interactive plotting applications

- Paul

I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if
the weekday doesn't work for you Charlie we might do a source release
on Friday or Saturday (for Sandro/debian) and you can get the build
out over the weekend (if you have time).  Obviously a lot of work has
gone into these releases, and a lot recently, so it is important to
test on what platforms you can.  Currently backend driver and memleak
hawaii are passing on my platform, and I have managed to at least
lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and
QT4) on at least one platform and for some backends a couple.

The contouring code has had the most recent significant changes, so if
you have limited time hit that the hardest.

Charlie, let me know what your time frame is....

Sandro, here is a release candidate tarball for you to test with:
http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz

Thanks,
JDH

There are a number of documentation warnings -- at lease some of these
are because doc strings in the api docs are non-compliant.  If you've
been working on any of these functions, please take a moment to try
and bring them up to snuff (I suspect one or more of these is mine,
but I'm pasting them all here).

WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring
of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation.
WARNING: <autodoc>:0: (ERROR/3) Unexpected indentation.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring
of matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15:
(WARNING/2) Literal block expected; none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring
of matplotlib.backend_bases.FigureCanvasBase.stop_event_loop_default:8:
(WARNING/2) Literal block expected; none found.
WARNING: /home/jdhunter/mpl/doc/api/cbook_api.rst:9: (WARNING/2) error
while formatting signature for matplotlib.cbook.Xlator: arg is not a
Python function
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring
of matplotlib.cbook.distances_along_curve:6: (WARNING/2) Literal block
expected; none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring
of matplotlib.cbook.is_closed_polygon:8: (WARNING/2) Literal block
expected; none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring
of matplotlib.cbook.less_simple_linear_interpolation:14: (WARNING/2)
Literal block expected; none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring
of matplotlib.cbook.path_length:6: (WARNING/2) Literal block expected;
none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring
of matplotlib.cbook.vector_lengths:8: (WARNING/2) Literal block
expected; none found.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py:docstring
of matplotlib.figure.Figure.text:37: (WARNING/2) Inline strong
start-string without end-string.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring
of matplotlib.pyplot.acorr:55: (ERROR/3) Unexpected indentation.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring
of matplotlib.pyplot.annotate:15: (ERROR/3) Unexpected indentation.
WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring
of matplotlib.pyplot.gca:2: (WARNING/2) Inline strong start-string
without end-string.

On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote:
> Hi,
> 
> No, it doesn't appear to work with or without my changes.  Also, it
> looks to me like the following code is now misplaced in backend_wx.py:
> 
> # 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)
> 
> It now appears after some functions not in the class.  Is this OK?

This code is not part of any class.  Anyway, I moved it to the top
of the file.

> Also, I noticed that this defines bind, while elsewhere in the class
> self.Bind is used.  Is this correct?  If so, should these other
> references perhaps take advantage of your abstraction?

I've committed a change so that all functions now use 

    bind(self, wx.EVT, callback, id=id)

rather than

    if wx.VERSION_STRING >= '2.5':
        self.Bind(wx.EVT,callback,id=id)
    else:
        wx.EVT(self, id, callback)

I'm not set up to test against wx < 2.5, though given its age
and the small user base of matplotlib wx, I'm not sure that
it is relevant anymore.


- Paul

Hi,

No, it doesn't appear to work with or without my changes.  Also, it
looks to me like the following code is now misplaced in backend_wx.py:

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

It now appears after some functions not in the class.  Is this OK?

Also, I noticed that this defines bind, while elsewhere in the class
self.Bind is used.  Is this correct?  If so, should these other
references perhaps take advantage of your abstraction?

Cheers,
David


On Thu, 2008-07-24 at 11:02 -0400, Paul Kienzle wrote:
> On Thu, Jul 24, 2008 at 12:12:21PM +0200, David Kaplan wrote:
> > 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.
> 
> Does wx work for you without the change? I suspect not...
> 
> I posted a fix to make the wx backend work for me with 
> examples/pylab_examples/ginput_demo.py and wx 2.8.3.
> 
> One issue I didn't address properly is what happens when the user 
> exits by closing the window.  Currently it raises an error when
> ginput requests draw.
> 
> 	- Paul
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thu, Jul 24, 2008 at 12:12:21PM +0200, David Kaplan wrote:
> 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.

Does wx work for you without the change? I suspect not...

I posted a fix to make the wx backend work for me with 
examples/pylab_examples/ginput_demo.py and wx 2.8.3.

One issue I didn't address properly is what happens when the user 
exits by closing the window.  Currently it raises an error when
ginput requests draw.

	- Paul

On Thu, Jul 24, 2008 at 9:32 AM, David Kaplan <Dav...@ir...> wrote:

>> * avoid the ternary operator, as in
>>
>>             # Figure out label rotation.
>>             rotation,nlc = cs.calc_label_rot_and_inline(
>>                 slc, imin, lw, lc if self.inline else [],
>>                 self.inline_spacing )
>>
>> since this requires python2.5.  I replaced this, and a similar
>> construct in contour.py, so please make sure I did the right thing
>>
>
> The reason I used this was that I saw the following line in contour.py
> (line 325):
>
> lc = [tuple(l) for l in linecontour]
>
> Doesn't this also require 2.5 or is the if different than the for?
> Should this also be changed?

No, this (a list comprehension) is fine.  The problem is the ternary
operator " lc if self.inline else []"
which is not supported in python 2.4.  I believe all the python
2.5isms have been removed.

>>     def func(x=None):
>>         if x is None: x = []
>>
>> I have fixed this in contour.py
>>
>
> I don't really understand how this can be a problem, but it probably
> isn't that important unless you feel like enlightening me.

See for example
http://www.velocityreviews.com/forums/t350126-default-argument-to-init.html

Hi,

I made the suggested fixes.  Comments below:

On Thu, 2008-07-24 at 08:38 -0500, John Hunter wrote:
> On Thu, Jul 24, 2008 at 7:31 AM, David Kaplan <Dav...@ir...> wrote:
> 
> > I committed the changes to clabel (r5830).
> 
> Hey David -- thanks for these fixes.  I noticed a couple of things I
> want to comment on
> 
> * avoid the ternary operator, as in
> 
>             # Figure out label rotation.
>             rotation,nlc = cs.calc_label_rot_and_inline(
>                 slc, imin, lw, lc if self.inline else [],
>                 self.inline_spacing )
> 
> since this requires python2.5.  I replaced this, and a similar
> construct in contour.py, so please make sure I did the right thing
> 

The reason I used this was that I saw the following line in contour.py
(line 325):

lc = [tuple(l) for l in linecontour]

Doesn't this also require 2.5 or is the if different than the for?
Should this also be changed?

> * avoid needless *args, **kwargs usage.  We do this all the time in
> pylab and to a lesser extent in axes.py because we are passing the
> function call on to another layer.  In that case, at least document
> the proper signature as the first line in the docstring.  But unless
> we need it, avoid it, eg in

I removed all this arbitrary argument stuff.  I was thinking that if we
ever invented a better mouse trap, this would let us automatically pass
that on to GUI's we haven't written specific functions for yet.  But we
are unlikely to invent a better mouse trap.

> 
> * Using an empty list in a python kwarg as the default is a gotcha, as in
> 
>     def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ):
> 
> The reason is that if the function mutates the list, this often leads
> to unintended consequences as the list is module level and thus shared
> between instances and method calls.  The standard idiom for mutable
> (lists and dicts) keyword args s
> 
>     def func(x=None):
>         if x is None: x = []
> 
> I have fixed this in contour.py
> 

I don't really understand how this can be a problem, but it probably
isn't that important unless you feel like enlightening me.

Cheers,
David

> 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 10:05 PM, Ryan May <rm...@gm...> wrote:

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

That is because "savefig" has its own dpi, which overrides the figure
dpi.  Tee ideas is that you typically want a different dpi for the UI
window and for the harcopy

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

I'm not familiar enough with the windbarb code to know where the "9
pixel" thing that is bothering you is creeping in, I'm just saying
that using an identity transform means you are drawing in canvas
(pixel) space and not accounting for dpi.  The Figure instance has a
"dpi_scale_transform" that is designed to handle dpi scaling, and
updates itself when the figure dpi is changed so you don't have to
handle the callbacks.  Take a look at this and see if you can
incorporate it.  If you have troubles, Michael or I can advise
further.

If you clarify the "9 pixel" problem that is bothering you, I may be
able to help more sooner...

JDH

On Thu, Jul 24, 2008 at 7:31 AM, David Kaplan <Dav...@ir...> wrote:

> I committed the changes to clabel (r5830).

Hey David -- thanks for these fixes.  I noticed a couple of things I
want to comment on

* avoid the ternary operator, as in

            # Figure out label rotation.
            rotation,nlc = cs.calc_label_rot_and_inline(
                slc, imin, lw, lc if self.inline else [],
                self.inline_spacing )

since this requires python2.5.  I replaced this, and a similar
construct in contour.py, so please make sure I did the right thing

* avoid needless *args, **kwargs usage.  We do this all the time in
pylab and to a lesser extent in axes.py because we are passing the
function call on to another layer.  In that case, at least document
the proper signature as the first line in the docstring.  But unless
we need it, avoid it, eg in

    def start_event_loop(self,*args,**kwargs):
        """
        Start an event loop.  This is used to start a blocking event
        loop so that interactive f

If you want to give the user who is using a known UI that supports
extra args, do it like

     def func(self, timeout, **kwargs):

and pass the kwargs through, but at lease require the known args and
kwargs in the main signature.


* Using an empty list in a python kwarg as the default is a gotcha, as in

    def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ):

The reason is that if the function mutates the list, this often leads
to unintended consequences as the list is module level and thus shared
between instances and method calls.  The standard idiom for mutable
(lists and dicts) keyword args s

    def func(x=None):
        if x is None: x = []

I have fixed this in contour.py

JDH

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