matplotlib-devel

[matplotlib-devel] reverting changes to contour.py

[Eric F. <ef...@ha...>]

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


In [1]:run contour_demo.py
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)

/home/efiring/programs/py/mpl/mpl_trunk/examples/pylab_examples/contour_demo.py 
in <module>()
      82            inline=1,
      83            fmt='%1.1f',
---> 84            fontsize=14)
      85
      86 # make a colorbar for the contour lines

/usr/local/lib/python2.5/site-packages/matplotlib/pyplot.pyc in 
clabel(*args, **kwargs)
    1698         hold(h)
    1699     try:
-> 1700         ret =  gca().clabel(*args, **kwargs)
    1701         draw_if_interactive()
    1702     except:

/usr/local/lib/python2.5/site-packages/matplotlib/axes.pyc in 
clabel(self, CS, *args, **kwargs)
    5996
    5997     def clabel(self, CS, *args, **kwargs):
-> 5998         return CS.clabel(*args, **kwargs)
    5999     clabel.__doc__ = mcontour.ContourSet.clabel.__doc__
    6000

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
clabel(self, *args, **kwargs)
     150             blocking_contour_labeler(inline)
     151         else:
--> 152             self.labels(inline)
     153
     154         self.label_list =  cbook.silent_list('text.Text', self.cl)

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
labels(self, inline)
     451                 if self.print_label(slc,lw):
     452                     x,y, rotation, ind  = 
self.locate_label(slc, lw)
--> 453                     self.add_label(x,y,rotation,icon)
     454
     455                     if inline:

/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in 
add_label(self, x, y, rotation, icon)
     364                       verticalalignment='center')
     365
--> 366         color = 
self.label_mappable.to_rgba(self.label_cvalues[icon],
     367                                             alpha=self.alpha)
     368

IndexError: index out of bounds
 > 
/usr/local/lib/python2.5/site-packages/matplotlib/contour.py(366)add_label()
     365
--> 366         color = 
self.label_mappable.to_rgba(self.label_cvalues[icon],
     367                                             alpha=self.alpha)

ipdb> icon
7
ipdb> self.label_cvalues
array([-1. , -0.6, -0.2,  0.2,  0.6,  1. ,  1.4])

Re: [matplotlib-devel] reverting changes to contour.py

[John H. <jd...@gm...>]

On Sat, Jul 19, 2008 at 8:02 PM, Eric Firing <ef...@ha...> wrote:

> 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

Although I may have used the phrase "bugfix release" many times in the
past, I want to clarify my thinking on this.  I distinguish between
point releases and major releases.  With the exception of the
maintenance branch, on which the *only* changes should be bugfixes, I
expect every point release to have new features and bugfixes.  When we
decide to bump the major version is of course subjective, but it
normally comes when a number of significant features have been
introduced, and it should be comparatively rare, 2 to 4 times a year
or so.  But I expect and want new features in every point release.

We are fortunate that we have a lot of developers, and Charlie is a
very responsive release manager.  I would rather err on the side of
getting new features out, tested to the best of our abilities, with
the understanding that if we break something important we will roll
out a point release that fixes a critical bug within 12 to 24 hours,
and hide the broken release in the mean time.  Release early, release
often.
My aversion to branches stems not from the weaknesses in svn merge,
which may be better in hg or other version control systems.  The
reason I wnat people contributing to the trunk is that I want as many
people testing and using the code as possible so we can find and fix
the bugs before they are released.  While Michael's transforms
refactoring was so significant that it absolutely required a branch,
we did not start finding the bugs until we made his branch the trunk,
and even then did not find the bulk of them.  We found them when we
released the code.  More tests will help, and we should have as many
tests as we can muster, but until we have bullet-proof tests we have
to leverage our developers and users as testers.

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.

JDH

Re: [matplotlib-devel] reverting changes to contour.py

[Sandro T. <mat...@gm...>]

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