release: stalled again?

What will it take to get a release out, so that debian, ubuntu, etc. can have something better than 1.0.1? And so that the python 3 merge can take place?

Eric

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

In particular, for the RC, I want to make sure that installation and documents for the installation is solid. I will have on hand an older, stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow Leopard (one is 32 bits while the other is 64, I think).

As a side note, the macbook can be used for automated build/test machine as it really isn’t useful for anything else for me.

Ben Root

That sounds to me as if the master branch is at release quality, or very close to. I could test it on Windows this weekend if that's true.

Christoph

···

On 9/17/2011 2:08 PM, Benjamin Root wrote:

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

In particular, for the RC, I want to make sure that installation and
documents for the installation is solid. I will have on hand an older,
stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
Leopard (one is 32 bits while the other is 64, I think).

As a side note, the macbook can be used for automated build/test machine
as it really isn't useful for anything else for me.

Ben Root

Works for me; should we branch on the rc cut or before? I suggest we
branch on the cut, but don't merge anything in before the 23rd that is
not release ready (eg Ben when you advised holding off on the
projection merge because it touched hairy parts of the code).

···

On Sat, Sep 17, 2011 at 4:08 PM, Benjamin Root <ben.root@...553...> wrote:

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

Works for me; should we branch on the rc cut or before? I suggest we
branch on the cut,

Agreed. We still have some pull requests that point to master. If we branch before the cut, re-pulling just delays things.

but don’t merge anything in before the 23rd that is
not release ready (eg Ben when you advised holding off on the
projection merge because it touched hairy parts of the code).

Agreed. Let’s declare a feature freeze at this point. Unless you already have a pull, no new features, and even those with existing pulls need to be carefully considered. I already have to make some updates to the “what’s new” section…

Ben Root

···

On Saturday, September 17, 2011, John Hunter <jdh2358@…149…> wrote:

On Sat, Sep 17, 2011 at 4:08 PM, Benjamin Root <ben.root@…553…> wrote:

While you are working on 'what's new" could you consider adding a
section on the new sankey module and maybe inline one example from the
api/sankey_demo.py? I think they are pretty snazzy.

JDH

···

On Sat, Sep 17, 2011 at 7:01 PM, Benjamin Root <ben.root@...553...> wrote:

Agreed. Let's declare a feature freeze at this point. Unless you already
have a pull, no new features, and even those with existing pulls need to be
carefully considered. I already have to make some updates to the "what's
new" section...

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

In particular, for the RC, I want to make sure that installation and
documents for the installation is solid. I will have on hand an older,
stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
Leopard (one is 32 bits while the other is 64, I think).

As a side note, the macbook can be used for automated build/test machine
as it really isn't useful for anything else for me.

Ben Root

That sounds to me as if the master branch is at release quality, or very
close to. I could test it on Windows this weekend if that's true.

Christoph,

It should be close. There are still three test failures, which I noted in a separate message to matplotlib-devel.

Eric

···

On 09/17/2011 12:17 PM, Christoph Gohlke wrote:

On 9/17/2011 2:08 PM, Benjamin Root wrote:

Christoph

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

The master branch builds OK on Windows and so far almost everything worked well.

I have trouble receiving the sample_data from github via cbook.py. There are frequent HTTP 304 (Not Modified) and 500 (Internal Server Error) exceptions and redirection to <https://raw.github.com/matplotlib/sample_data/master&gt;\.

Christoph

···

On 9/17/2011 7:16 PM, Eric Firing wrote:

On 09/17/2011 12:17 PM, Christoph Gohlke wrote:

On 9/17/2011 2:08 PM, Benjamin Root wrote:

I think it will take a declaration of a firm deadline. How about this?

Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)

In particular, for the RC, I want to make sure that installation and
documents for the installation is solid. I will have on hand an older,
stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
Leopard (one is 32 bits while the other is 64, I think).

As a side note, the macbook can be used for automated build/test machine
as it really isn't useful for anything else for me.

Ben Root

That sounds to me as if the master branch is at release quality, or very
close to. I could test it on Windows this weekend if that's true.

Christoph,

It should be close. There are still three test failures, which I noted
in a separate message to matplotlib-devel.

Eric

Christoph

I'm not sure why, but as of a few weeks ago, with recent builds of
numpy/mpl I always get these warnings:

In [1]: imshow(rand(10,10))
Out[1]: <matplotlib.image.AxesImage at 0x278f390>

In [2]: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:519:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
  np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:531:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
  np.putmask(xa, xa<0.0, -1)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:535:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
  np.putmask(xa, xa>self.N-1, self._i_over)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:536:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
  np.putmask(xa, xa<0, self._i_under)

It would be nice to have these gone from master before release.

Cheers,

f

I can fix these putmask calls, but strangely I am not seeing the
deprecation warning on numpy and mpl HEAD

  In [1]: print np.__version__
  2.0.0.dev-aded70c

  In [2]: print matplotlib.__version__
  1.1.0

  In [3]: imshow(rand(10,10))
  Out[3]: <matplotlib.image.AxesImage at 0x48ff8d0>

If I do a simple putmask test I also don't get the warning

  In [4]: x = np.random.rand(10)

  In [5]: np.putmask(x, x<0.5, 0)

Do you have some custom warning or error settings turned on/ What
commit of np are you on?

I like how they have the commit hash in the version number; we need that.

···

On Sun, Sep 18, 2011 at 1:44 PM, Fernando Perez <fperez.net@...149...> wrote:

I'm not sure why, but as of a few weeks ago, with recent builds of
numpy/mpl I always get these warnings:

In [1]: imshow(rand(10,10))
Out[1]: <matplotlib.image.AxesImage at 0x278f390>

In [2]: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:519:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:531:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
np.putmask(xa, xa<0.0, -1)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:535:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
np.putmask(xa, xa>self.N-1, self._i_over)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:536:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
np.putmask(xa, xa<0, self._i_under)

It would be nice to have these gone from master before release.

I confirmed this on linux and added an issue on github:
cbook.get_sample_data broken · Issue #478 · matplotlib/matplotlib · GitHub. I also assigned
a new tag "release_critical" which we should use as we close in on the
release to mark show-stopper issues. I assigned this to Jouni since
he wrote most of the original implementation. Jouni, if you can't get
to this let me know and I'll take a look.

JDH

···

On Sun, Sep 18, 2011 at 1:17 AM, Christoph Gohlke <cgohlke@...244...> wrote:

The master branch builds OK on Windows and so far almost everything
worked well.

I have trouble receiving the sample_data from github via cbook.py. There
are frequent HTTP 304 (Not Modified) and 500 (Internal Server Error)
exceptions and redirection to
<https://raw.github.com/matplotlib/sample_data/master&gt;\.

Weird, I'm on the same; I just did a clean git pull right before building:

In [1]: np.__version__
Out[1]: '2.0.0.dev-aded70c'

In [2]: matplotlib.__version__
Out[2]: '1.1.0'

(master)dreamweaver[matplotlib]> git log --oneline | head -1
fcc8039 axisartist: implement LocatorDM, LocatorD, LocatorHM, LocatorH
and update FormatterHMS and FormaterDMS

This is on a linux 10.10 box, 64-bit just in case it matters. I
haven't tested it on 32-bits. The problem also appears (at least for
me) on my office box that you have access to.

Happy to test further...

f

···

On Sun, Sep 18, 2011 at 12:05 PM, John Hunter <jdh2358@...149...> wrote:

I can fix these putmask calls, but strangely I am not seeing the
deprecation warning on numpy and mpl HEAD

In [1]: print np.__version__
2.0.0.dev-aded70c

In [2]: print matplotlib.__version__
1.1.0

In [3]: imshow(rand(10,10))
Out[3]: <matplotlib.image.AxesImage at 0x48ff8d0>

I can fix these putmask calls, but strangely I am not seeing the
deprecation warning on numpy and mpl HEAD

putmask was deprecated in favor of copyto only 2 months ago; copyto didn't even exist before that. So we certainly can't replace putmask with copyto in mpl.

http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b

Eric

···

On 09/18/2011 09:24 AM, Fernando Perez wrote:

On Sun, Sep 18, 2011 at 12:05 PM, John Hunter<jdh2358@...149...> wrote:

  In [1]: print np.__version__
  2.0.0.dev-aded70c

  In [2]: print matplotlib.__version__
  1.1.0

  In [3]: imshow(rand(10,10))
  Out[3]:<matplotlib.image.AxesImage at 0x48ff8d0>

Weird, I'm on the same; I just did a clean git pull right before building:

In [1]: np.__version__
Out[1]: '2.0.0.dev-aded70c'

In [2]: matplotlib.__version__
Out[2]: '1.1.0'

(master)dreamweaver[matplotlib]> git log --oneline | head -1
fcc8039 axisartist: implement LocatorDM, LocatorD, LocatorHM, LocatorH
and update FormatterHMS and FormaterDMS

This is on a linux 10.10 box, 64-bit just in case it matters. I
haven't tested it on 32-bits. The problem also appears (at least for
me) on my office box that you have access to.

Happy to test further...

f

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

putmask was deprecated in favor of copyto only 2 months ago; copyto
didn't even exist before that. So we certainly can't replace putmask
with copyto in mpl.

http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b

The putmasks in colors.py are simple and could be replaced by a simple
boolean, mask eg replace

  np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.

with

  xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.

In quiver.py, there appear to be some broadcasting shape issues that
make this trickier, eg in

        short = np.repeat(length < minsh, 8, axis=1)
        # Now select X0, Y0 if short, otherwise X, Y
        np.putmask(X, short, X0)

Since much of quiver.py is your code I believe Eric, maybe you can
come up with something that doesn't rely on putmasking and just uses
plain vanilla boolean arrays of the right shape?

JDH

putmask was deprecated in favor of copyto only 2 months ago; copyto
didn't even exist before that. So we certainly can't replace putmask
with copyto in mpl.

http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b

The putmasks in colors.py are simple and could be replaced by a simple
boolean, mask eg replace

   np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.

with

   xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.

In quiver.py, there appear to be some broadcasting shape issues that
make this trickier, eg in

         short = np.repeat(length< minsh, 8, axis=1)
         # Now select X0, Y0 if short, otherwise X, Y
         np.putmask(X, short, X0)

Since much of quiver.py is your code I believe Eric, maybe you can
come up with something that doesn't rely on putmasking and just uses
plain vanilla boolean arrays of the right shape?

I really don't want to mess with this now; putmask was used because it is *much* faster than boolean indexing (after I supplied the fast_putmask code to numpy back in 2007). And I did that because it removed a genuine, significant bottleneck in mpl. Now, with Mark Wiebe's modifications to numpy, putmask is obsolete. His copyto is as fast, and boolean indexing might even be good enough now. But the next mpl release is not targeted at numpy 2.0. It will be used with older versions as well, and probably most often.

We will need to deal with the deprecation of putmask, but this is not the time to do it, unless there is a way to do it that does *not* change the present actual *use* of putmask, but merely tells numpy to shut up about it. I don't know why it is complaining; I don't think that it is normal procedure to start issuing warnings the minute a replacement (copyto) appears.

We are trying to get a release out without introducing major breakage. It is a bad time to muck around with internals like the use of putmask.

Eric

···

On 09/18/2011 09:54 AM, John Hunter wrote:

JDH

John,

There is a way to deal with this now: define our own copyto which uses np.copyto if it exists, and falls back on putnav otherwise. I think this can be done with reasonable safety and no loss of performance. The only question is where to put our copyto. I think a new compat.py would make sense as a home for this sort of version compatibility interface code. We may need a lot more in the future as numpy evolves.

Eric

···

On 09/18/2011 09:54 AM, John Hunter wrote:

putmask was deprecated in favor of copyto only 2 months ago; copyto
didn't even exist before that. So we certainly can't replace putmask
with copyto in mpl.

http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b

The putmasks in colors.py are simple and could be replaced by a simple
boolean, mask eg replace

   np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.

with

   xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.

In quiver.py, there appear to be some broadcasting shape issues that
make this trickier, eg in

         short = np.repeat(length< minsh, 8, axis=1)
         # Now select X0, Y0 if short, otherwise X, Y
         np.putmask(X, short, X0)

Since much of quiver.py is your code I believe Eric, maybe you can
come up with something that doesn't rely on putmasking and just uses
plain vanilla boolean arrays of the right shape?

JDH

We used to put these in cbook I believe; eg functions that existed in
python2.3 that we wanted to use but weren't defined in python2.2 which
we supported. We could prefix them with a leading underscore to steer
users away from them

def _copyto(...):
   # temporary function to use numpy's copyto if it is defined, else
putmask; this function will be deprecated when we support only numpy
2.0 and later
   ...

I'd be in favor of doing this, because deprecations warnings are a nuisance.

JDH

···

On Sun, Sep 18, 2011 at 4:02 PM, Eric Firing <efiring@...229...> wrote:

There is a way to deal with this now: define our own copyto which uses
np.copyto if it exists, and falls back on putnav otherwise. I think this
can be done with reasonable safety and no loss of performance. The only
question is where to put our copyto. I think a new compat.py would make
sense as a home for this sort of version compatibility interface code. We
may need a lot more in the future as numpy evolves.

If you want to just silence this particular warning, it can be done
with this code:

import warnings
warnings.filterwarnings('ignore', 'putmask has been deprecated',
                        DeprecationWarning)

That would be enough to keep numpy quiet about this for now...

Cheers,

f

···

On Sun, Sep 18, 2011 at 2:02 PM, Eric Firing <efiring@...229...> wrote:

There is a way to deal with this now: define our own copyto which uses
np.copyto if it exists, and falls back on putnav otherwise. I think
this can be done with reasonable safety and no loss of performance. The
only question is where to put our copyto. I think a new compat.py would
make sense as a home for this sort of version compatibility interface
code. We may need a lot more in the future as numpy evolves.

See

Eric

···

On 09/18/2011 11:15 AM, John Hunter wrote:

On Sun, Sep 18, 2011 at 4:02 PM, Eric Firing<efiring@...229...> wrote:

There is a way to deal with this now: define our own copyto which uses
np.copyto if it exists, and falls back on putnav otherwise. I think this
can be done with reasonable safety and no loss of performance. The only
question is where to put our copyto. I think a new compat.py would make
sense as a home for this sort of version compatibility interface code. We
may need a lot more in the future as numpy evolves.

We used to put these in cbook I believe; eg functions that existed in
python2.3 that we wanted to use but weren't defined in python2.2 which
we supported. We could prefix them with a leading underscore to steer
users away from them

def _copyto(...):
    # temporary function to use numpy's copyto if it is defined, else
putmask; this function will be deprecated when we support only numpy
2.0 and later
    ...

I'd be in favor of doing this, because deprecations warnings are a nuisance.

JDH