matplotlib-devel Mailing List for matplotlib (Page 9)

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


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Mon, Jul 21, 2008 at 1:06 PM, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
>>
>> On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <Dav...@ir...> wrote:
>>
>>> 2) Can someone explain to me why is_string_like in the cbook doesn't
>>> just do isinstance(obj,str)?  Is there anything "string like" that won't
>>> be caught be this isinstance call?
>>
>>  In [65]: s = u'jdh'
>>
>>  In [66]: isinstance(s, str)
>>  Out[66]: False
>>
>>  In [67]: isinstance(s, unicode)
>>  Out[67]: True
>>
>> So we could check for str or unicode, but a user may be using a custom
>> string like class from some c++ extension code that is part of a large
>> in house API.  The point is that we don't care if it *is* a string, we
>> just want it to act like a string
>>
>>  http://en.wikipedia.org/wiki/Duck_typing
>
> Sometimes we have
>
> if is_string_like(s) and s == 'some string': do_something()
>
> I think that as long as we know s is not None (which often is something that
> is being checked first) then it would be simpler, faster, and more readable
> to use
>
> if str(s) == 'some string': do_something()
>
> John, do you see any problems with this?  I think str(s) is guaranteed to
> return a string--that is, not to fail--for any python object, correct?

My guess is that your code will work, but I am disinclined to remove a
check that is working and was probably added to satisfy some corner
case we are forgetting about.  str can fail, BTW:


In [35]: class Evil:
   ....:     def __str__(self):
   ....:         raise NotImplementedError
   ....:

In [36]: evil = Evil()

In [37]: print str(evil)
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
  File "<ipython console>", line 3, in __str__
NotImplementedError

Jeff Whitaker wrote:
>>     Basically, Fortune's sweepline algorithm for Delaunay triangulation
>>     simply needs to be replaced with an algorithm that can be formulated
>>     using Jonathan Shewchuck's robust predicates:
>>
>>      http://www.cs.cmu.edu/~quake/robust.html

great idea.

> I checked 
> Shewchuk's web page and unfortunately his code comes with this license:

...

How I wish people would just pick a known Open Source License -- it's 
not like there are a shortage of them! Might it be worth a note to 
Shewchuk asking him if we can put it in MPL? -- though it doesn't look 
promising. Fortunately, his Robust Predicate code is, I think, in the 
public domain, or a more flexible license anyway.

We've got some robust code in-house that does it all in integers, though 
that does limit your options. It's based on Knuth's work in:

Axioms and Hulls
by Donald E. Knuth (Heidelberg: Springer-Verlag, 1992), ix+109pp.
(Lecture Notes in Computer Science, no. 606.)
ISBN 3-540-55611-7

http://www-cs-faculty.stanford.edu/~knuth/aah.html

Anyone know of any other code based on that work?

Nice to see this moving forward, though -- thanks, everyone!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Ryan May wrote:
> 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.
> 
> I don't think an IdentityTransform() implies drawing in pixels.  My 
> length 9 barb is a lot longer than 9 pixels.  It looks more like ~50. I 
> really was looking for (and thought I found) a way to draw in a 
> resolution independant fashion.  Axes coordinates are close, but 
> unfortunately, as you stretch a figure, this can distort things.
> 
>>> It should apply fine to SVN, but there are commented lines that should be
>>> switched with the ones there when set/get_offsets() are added to
>>> Collections.
>>>
>>> Comments and Suggestions?
>>>
>>> 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.)

Eric

John Hunter wrote:
> On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <Dav...@ir...> wrote:
> 
>> 2) Can someone explain to me why is_string_like in the cbook doesn't
>> just do isinstance(obj,str)?  Is there anything "string like" that won't
>> be caught be this isinstance call?
> 
>   In [65]: s = u'jdh'
> 
>   In [66]: isinstance(s, str)
>   Out[66]: False
> 
>   In [67]: isinstance(s, unicode)
>   Out[67]: True
> 
> So we could check for str or unicode, but a user may be using a custom
> string like class from some c++ extension code that is part of a large
> in house API.  The point is that we don't care if it *is* a string, we
> just want it to act like a string
> 
>   http://en.wikipedia.org/wiki/Duck_typing

Sometimes we have

if is_string_like(s) and s == 'some string': do_something()

I think that as long as we know s is not None (which often is something 
that is being checked first) then it would be simpler, faster, and more 
readable to use

if str(s) == 'some string': do_something()

John, do you see any problems with this?  I think str(s) is guaranteed 
to return a string--that is, not to fail--for any python object, correct?

Eric

Ryan May wrote:
> Hi,
> 
> I noticed that offset_copy() went away in the transforms rewrite and was 
> replaced with a trans + transfroms.Affine2D().translate(x,y).  This 
> works fine for x,y in pixels.  However, offset_copy would also let you 
> specify x,y in points.  How can I get that to work with the new 
> transforms? More importantly, can I do it without knowing the dpi?

Also, it looks like examples/pylab_examples/transoffset.py is broken...

(I think more and more we need to automatically run the examples and
compare against "known good" images in svn as a form of automated testing.)

-Andrew

I've been to trying add more flexible control over the axis lines,  
ticks, tick labels, etc., but I think I'm in over my head on this  
project. Again and again, I've settled on one approach only to  
completely rewrite it the next time I look at the code. I'm looking  
for some major design advice/ideas that will make the code simpler  
(AND maintain compatibility with the current implementation of Axis  
and Tick objects).

For simplicity, I've only made changes to the x-axis. Since this  
involves some major changes, I wrote this as a module that subclasses  
XTicks and XAxis as opposed to a patch on axis.py (which would be the  
ultimate, but at this point unlikely, goal). The attached module is  
quite long at the moment, but most of it is comments and methods  
copied (but slightly modified) from `axis.py`. I tried to document how/ 
why the method has changed if I copied the method.

Sorry for the code dump.
-Tony

On Mon, Jul 21, 2008 at 05:30:00AM -0500, John Hunter wrote:
> On Mon, Jul 21, 2008 at 4:07 AM, Gael Varoquaux
> <gae...@no...> wrote:

> > Could somebody review this patch and possibly check it in? It is not
> > perfect but is, IMHO, a good start that works on everything I have thrown

> OK, looks good; I've committed it to svn r5798.  I have commented out
> the tkinter import until we figure out what if anything we need to do
> in that case.

Thanks John. Sorry for leaving the tk part behind. It should indeed be
commented out.

Gaël

On Mon, Jul 21, 2008 at 10:17 AM, David Kaplan <Dav...@ir...> wrote:

> Similar level of question: What is the policy on using scipy in
> matplotlib?  I want to use linear interpolation, and
> simple_linear_interpolation in the cbook doesn't do what I want.  I
> imagine that we are trying to avoid dependence on scipy.

Yes, to date we've avoided a scipy dependence, which is a nuisance for
developers, but makes installation a bit easier.

JDH

Hi,

Similar level of question: What is the policy on using scipy in
matplotlib?  I want to use linear interpolation, and
simple_linear_interpolation in the cbook doesn't do what I want.  I
imagine that we are trying to avoid dependence on scipy.

Thanks,
David


On Mon, 2008-07-21 at 08:42 -0500, John Hunter wrote:
> On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <Dav...@ir...> wrote:
> 
> > 2) Can someone explain to me why is_string_like in the cbook doesn't
> > just do isinstance(obj,str)?  Is there anything "string like" that won't
> > be caught be this isinstance call?
> 
>   In [65]: s = u'jdh'
> 
>   In [66]: isinstance(s, str)
>   Out[66]: False
> 
>   In [67]: isinstance(s, unicode)
>   Out[67]: True
> 
> So we could check for str or unicode, but a user may be using a custom
> string like class from some c++ extension code that is part of a large
> in house API.  The point is that we don't care if it *is* a string, we
> just want it to act like a string
> 
>   http://en.wikipedia.org/wiki/Duck_typing
-- 
**********************************
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 Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <Dav...@ir...> wrote:

> 2) Can someone explain to me why is_string_like in the cbook doesn't
> just do isinstance(obj,str)?  Is there anything "string like" that won't
> be caught be this isinstance call?

  In [65]: s = u'jdh'

  In [66]: isinstance(s, str)
  Out[66]: False

  In [67]: isinstance(s, unicode)
  Out[67]: True

So we could check for str or unicode, but a user may be using a custom
string like class from some c++ extension code that is part of a large
in house API.  The point is that we don't care if it *is* a string, we
just want it to act like a string

  http://en.wikipedia.org/wiki/Duck_typing

Hi,

On Sun, 2008-07-20 at 08:09 -1000, Eric Firing wrote:
> It sounds like there is time to do it before the release without messing 
> up the release.  Just make sure the backend_drivers.py test suite still 
> runs OK.  If you can add tests (i.e., examples run by backend_drivers) 
> that exercise the new functionality, that is even better.  The 
> interactive part of the functionality can't be tested in an automated 
> way, but the rest can, and adding an example is a good way to help users 
> see how to use it.  In any case, go ahead and commit when ready.
> 

I have recommitted my changes to contour.py plus modifications to fix
the problems you identified (r5799).  I also included a couple of new
pylab_examples that test the new interactive (ginput, etc.) and
non-interactive (e.g., using a dictionary to specify label format)
elements.  The non-interactive pylab_example (contour_label_demo) has
been integrated into backend_driver.py.  This should hopefully help save
me from myself.

> Yes, the labeling code is difficult, and I have not looked at it in a 
> long time.  If you are interested, please do look at it from the 
> standpoint of a possible major revision that might make it easier to 
> understand and easier to enhance.
> 

For the moment, I have tried to add a few comments here and there that
explain my understanding of things and identify some problems.  One
thing that should probably be fixed immediately is that the attribute
names in ContourLabeler don't meet the standards in the coding guide
(e.g., label_levels instead of clabelLevels) and are hard to understand
(e.g., cl could be contourLevels instead of clabelLevels).  I would like
to fix these, but this may break user's code that depends, e.g., on
CS.cl having that name.  How much should I worry about this?  There are
likely few users that directly modify ContourSet properties, but you
never know.  I think changing these names and adding a few comments
would at least pave the way for future improvements.

I also have a couple of general questions for the group:

1) ginput currently returns a list of tuples instead of a two-column
array of x,y coordinates.  I think a numpy array is more intuitive and
saves the user having to cast to array.  Is there any reason why ginput
should not return a numpy array instead of a list of tuples?

2) Can someone explain to me why is_string_like in the cbook doesn't
just do isinstance(obj,str)?  Is there anything "string like" that won't
be caught be this isinstance call?

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

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

On Mon, Jul 21, 2008 at 4:07 AM, Gael Varoquaux
<gae...@no...> wrote:

> Could somebody review this patch and possibly check it in? It is not
> perfect but is, IMHO, a good start that works on everything I have thrown

OK, looks good; I've committed it to svn r5798.  I have commented out
the tkinter import until we figure out what if anything we need to do
in that case.

Thanks for the patch.

JDH

On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann
<kla...@fm...> wrote:
> Hello *,
>
> right now the NonUniformImage class in image.py uses numpy's asarray
> method. All similar classes instead use numpy.ma.asarray, thus allowing
> for masked images.
> I think this should be changed as in the attached patch.
>
> Otherwise thanks for matplotlib :)

Eric, could you take a look at this?  Although the patch is trivial, I
just want to make sure that the image extension code will do the right
thing if a masked array gets passed into it.  I d not see any special
handling in _image.pcolor so am not sure what happens when a masked
array gets passed in.

JDH

On Sat, Jul 19, 2008 at 08:05:52AM +0200, Gael Varoquaux wrote:
> On Sat, Jul 19, 2008 at 07:31:19AM +0200, Gael Varoquaux wrote:
> >   - show starts a mainloop and is blocking even if there are not windows
> >     open. This basically leads to a deadlock where the user cannot
> >     interrupt the mainloop. This can probably be easily fixed, and I'll
> >     look into it.

> It turns out it was only in the GTK backend, and quite trivial to
> correct. Attached is a new patch, including this correction.

Could somebody review this patch and possibly check it in? It is not
perfect but is, IMHO, a good start that works on everything I have thrown
at it. I have not been able to abstract in more by pushing the relevant
code in the backends, as in introduces coupling that induces the
selection of the wrong backend.

Debian freeze is close, and I would really like this to go in before. We
do need to work on a vendor registry for the long run, to allow
application builders to override this mechanism on a per-application
basis. However to be able to have a roper view of what this registry, I
need to wip up an app to use it. I am busy doing that, but it won't be
ready before Debian freeze, whereas the attached patch fixes all my
problems.

Cheers,

Gaël

Hello *,

right now the NonUniformImage class in image.py uses numpy's asarray
method. All similar classes instead use numpy.ma.asarray, thus allowing
for masked images.
I think this should be changed as in the attached patch.

Otherwise thanks for matplotlib :)
Klaus

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.

I don't think an IdentityTransform() implies drawing in pixels.  My 
length 9 barb is a lot longer than 9 pixels.  It looks more like ~50. I 
really was looking for (and thought I found) a way to draw in a 
resolution independant fashion.  Axes coordinates are close, but 
unfortunately, as you stretch a figure, this can distort things.

>> It should apply fine to SVN, but there are commented lines that should be
>> switched with the ones there when set/get_offsets() are added to
>> Collections.
>>
>> Comments and Suggestions?
>>
>> 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

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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.

> It should apply fine to SVN, but there are commented lines that should be
> switched with the ones there when set/get_offsets() are added to
> Collections.
>
> Comments and Suggestions?
>
> 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

On Sun, Jul 20, 2008 at 3:44 PM, Ryan May <rm...@gm...> wrote:

> I noticed that offset_copy() went away in the transforms rewrite and was
> replaced with a trans + transfroms.Affine2D().translate(x,y).  This
> works fine for x,y in pixels.  However, offset_copy would also let you
> specify x,y in points.  How can I get that to work with the new
> transforms? More importantly, can I do it without knowing the dpi?

You should be able to get the dpi -- at least if you are working with
an Artist instance, you can access the dpi as a.figure.dpi.  With
this, you can scale the x and y of the translation to do offsets in
dpi.

JDH

Hi,

I noticed that offset_copy() went away in the transforms rewrite and was 
replaced with a trans + transfroms.Affine2D().translate(x,y).  This 
works fine for x,y in pixels.  However, offset_copy would also let you 
specify x,y in points.  How can I get that to work with the new 
transforms? More importantly, can I do it without knowing the dpi?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

David M. Kaplan wrote:
> Hi,
> 
> Sorry about the problems.  The labeling code is somewhat difficult to
> understand and I was using label indices when I should have used level
> indices (or vice-versa).  I have a fix, but want to test it more before
> committing.  Let me know when is a good time to do it so that I don't
> mess up a release.

It sounds like there is time to do it before the release without messing 
up the release.  Just make sure the backend_drivers.py test suite still 
runs OK.  If you can add tests (i.e., examples run by backend_drivers) 
that exercise the new functionality, that is even better.  The 
interactive part of the functionality can't be tested in an automated 
way, but the rest can, and adding an example is a good way to help users 
see how to use it.  In any case, go ahead and commit when ready.

Yes, the labeling code is difficult, and I have not looked at it in a 
long time.  If you are interested, please do look at it from the 
standpoint of a possible major revision that might make it easier to 
understand and easier to enhance.

Eric

> 
> Cheers,
> David
> 
> On Sat, 2008-07-19 at 19:30 -0700,
> mat...@li... wrote:
>> David,
>>
>> I am reverting your changes to contour.py; that is, I am taking it
>> back 
>> to 5689.  The problem is that running contour_demo.py, below, fails. 
>> Some index accounting somewhere is getting fouled up.  I don't have
>> time 
>> to investigate.
>>
>> When you have it straightened out you can put the changes back, so
>> this 
>> is just a brief setback.
>>
>> We might want to consider, however, whether such extensive changes 
>> should be made immediately *before* a "bugfix" release.  I think John
>> is 
>> trying to get one out.  I am already a little nervous about other
>> recent 
>> and impending changes in this context.  (Your idea of a branch was a 
>> good one in concept, but maybe a pain and more trouble than it is
>> worth 
>> with svn.  Too bad we aren't using something nice like Mercurial.
>> Now, 
>> that comment should push a few buttons.)
>>
>> Eric
>>

On Sat, Jul 19, 2008 at 03:42:27PM -0500, John Hunter wrote:
> On Sat, Jul 19, 2008 at 1:05 AM, Gael Varoquaux
> <gae...@no...> wrote:

> > It turns out it was only in the GTK backend, and quite trivial to
> > correct. Attached is a new patch, including this correction.

> Hey Gael, this is starting to look reasonable.  I know implementing
> these checks, such as detecting whether the mainloop is active, can be
> a hassle, so thanks for taking the time to write against so many
> environments.  We may want to make take the logic you've provided and
> encapsulate them in the backend methods to make them more easily
> recognizable, fixable and reusable.  Eg, each unser interface backend
> would provide a "mainloop_running" method.  You could then access this
> in pyplot to support your fallback logic, and also we could use it in
> "show" to make sure we don't try and start mainloops that are already
> running.

In theory this could work, but the problem is that the logics for
selecting the backend gets executed when matplotlib.backends is imported,
ie before importing any backend. I tried implementing your suggestion,
but it failed because I had to imports from backends. Am I missing
something obvious?

> One thing notice in your patch is that when it comes time to check for
> tk, you import tkinter and then do nothing with it.  I assume this is
> a placeholder until you figure out what you want to do?

I have actually given up on that, so you should probably remove these two
lines. If somebody knows how to check accurately for tk, I am interested.

Cheers,

Gaël

Hi John & All

> The only short term pressure for a point release is coming from
> debian, because they are having some trouble with our last point
> release.  Because debian is an important platform, I want to get a
> point release out that satisfies their problems ASAP, but not before
> we are ready.  Whether this is next week or next month or next year
> will depend on whether the code is ready (I hear echos of Orson Welles
> in the old Paul Masson commercial, "We will sell no wine, before it's
> time").
>
> In the case of the contouring enhancements, they're not ready, so
> we'll wait.  In the situation where debian or some other important
> vendor has a freeze deadline with a critical problem that needs
> fixing, we can always do a branch off the last point release that
> fixes just the required bugs.  Sandro can keep us appraised if such a
> deadline is approaching for 0.98.2.

First of all, I'd like to thank you all for the huge support you're
giving back to Debian.

About deadlines, just yesterday it was announced[1] that general
freeze will happen the next weekend, so it's rather soon :)

We are using the policy "We release when we are ready" and I think
it's a good one, so once you're confident with a new point version,
release :) ; then it will be my responsibility to praise release
managers to include the new version in Debian ;)

Cheers,
Sandro

[1] http://lists.debian.org/debian-devel-announce/2008/07/msg00005.html

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi,

Sorry about the problems.  The labeling code is somewhat difficult to
understand and I was using label indices when I should have used level
indices (or vice-versa).  I have a fix, but want to test it more before
committing.  Let me know when is a good time to do it so that I don't
mess up a release.

Cheers,
David

On Sat, 2008-07-19 at 19:30 -0700,
mat...@li... wrote:
> David,
> 
> I am reverting your changes to contour.py; that is, I am taking it
> back 
> to 5689.  The problem is that running contour_demo.py, below, fails. 
> Some index accounting somewhere is getting fouled up.  I don't have
> time 
> to investigate.
> 
> When you have it straightened out you can put the changes back, so
> this 
> is just a brief setback.
> 
> We might want to consider, however, whether such extensive changes 
> should be made immediately *before* a "bugfix" release.  I think John
> is 
> trying to get one out.  I am already a little nervous about other
> recent 
> and impending changes in this context.  (Your idea of a branch was a 
> good one in concept, but maybe a pain and more trouble than it is
> worth 
> with svn.  Too bad we aren't using something nice like Mercurial.
> Now, 
> that comment should push a few buttons.)
> 
> Eric
> 
-- 
**********************************
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,

As promised, here's a patch to add wind barbs to matplotlib.  This 
should addresses all of the comments I've received as well as all of the 
issues I previously mentioned.  A synopsis of some of the updates:

1) Based on a conversation with Eric Firing, I've gone ahead and added 
the Barbs collection to quiver.py, which seems like a logical place.

2) Method added to set the data components.

3) Masked arrays are handled by saving all of the original arrays and 
using copies fed through delete_masked_points whenever the U/V are updated.

4) Setting the color of the edges/line portion of the barbs was easy, 
thanks to the setting of edgecolor='face' that Eric Firing pointed out. 
    I guess this is a post 0.98.1 addition, since I don't have it in my 
system copy, only SVN.  I also, for some reason, don't remember seeing 
the patch either.  Anyhow, colormapping of the *whole* barb works now.

5) I added an empty circle marker for low wind speeds (vector 
magnitudes).  Accomplishing having the unfilled circle while having the 
barbs filled involved a bit of a "elegant hack".  Using the set of 
vertices that draws the CirclePolygon, I add an additional copy of these 
vertices, basically drawing the circle back the other way.  This is 
basically tricking the drawing algorithm into drawing a really thin 
annulus with a very small gap, but it works perfectly as far as I can 
tell.  It's also somewhat consistent with the way the lines on the barb 
are drawn.  It is *far* simpler than any other solution, which would 
have required somehow mapping a color to each polygon *before* calling
draw_path_collection().  None of the backends I test had a problem, 
including PS, PDF, and SVG (tested with Evince, Firefox, and Acroread).

6) The relative sizes of components of the barb can be controlled by
passing a dictionary in through the sizes keyword parameter.  The 
dictionary has keys 'spacing', 'height', 'width', 'emptybarb', which
map to values which are the size of these components relative to the 
length of the barb. I've also adjust some of the defaults a little so 
that tweaking shouldn't be needed (such as the issue Jeff raised).  This 
seemed a lot better than passing around all of these parameters separately.

7)Driver demo code was moved to barb_demo.py under the pylab_examples. I 
loved Jeff's demo, but obviously that can only go in basemap.

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.

It should apply fine to SVN, but there are commented lines that should 
be switched with the ones there when set/get_offsets() are added to 
Collections.

Comments and Suggestions?

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.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma