Release schedule for version 1.0.1?

_Russell_E_Owen4 · October 22, 2010, 9:45pm

I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font
cache will cause matplotlib to fail (the application mysteriously exits
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide
how best to deal with it. Depending on the timing of 1.0.1 I can decide
whether it's worth putting in my own workaround, bundling a prerelease
version of matplotlib or just waiting for the official release.

Regards,

-- Russell

P.S. does anyone know a way to get maplotlib to either not use its font
cache or to use a version in mpl-data instead of ~/.matplotlib? When
matplotlib is bundled into an application it seems dangerous for it to
be sharing cached files with potentially older or newer versions that
are installed or are bundled with other applications.

Michael_Droettboom · October 23, 2010, 12:16am

I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font
cache will cause matplotlib to fail (the application mysteriously exits
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide
how best to deal with it. Depending on the timing of 1.0.1 I can decide
whether it's worth putting in my own workaround, bundling a prerelease
version of matplotlib or just waiting for the official release.

I'm not sure what the timeframe is on 1.0.1.

What problem with the cache are you referring to? I'm aware of a problem where if some fonts are moved or removed after the cache is created matplotlib will crash (and this problem is fixed in the trunk), but is that really a problem in everyday practice? I'm just curious -- if there's another issue with the cache that I'm not aware of, I'd like to fix it.

Mike

···

On 10/22/2010 05:45 PM, Russell E. Owen wrote:

Regards,

-- Russell

P.S. does anyone know a way to get maplotlib to either not use its font
cache or to use a version in mpl-data instead of ~/.matplotlib? When
matplotlib is bundled into an application it seems dangerous for it to
be sharing cached files with potentially older or newer versions that
are installed or are bundled with other applications.

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps& games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

_John_Hunter · October 23, 2010, 11:59am

I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font
cache will cause matplotlib to fail (the application mysteriously exits
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide
how best to deal with it. Depending on the timing of 1.0.1 I can decide
whether it's worth putting in my own workaround, bundling a prerelease
version of matplotlib or just waiting for the official release.

I'm not sure what the timeframe is on 1.0.1.

I would be happy to do a release early next week. Is anyone aware of
any show stopper bugs that need to be fixed first? I had hoped to do
it last week ahead of the ETS release, but simply did not get to it.

What problem with the cache are you referring to? I'm aware of a
problem where if some fonts are moved or removed after the cache is
created matplotlib will crash (and this problem is fixed in the trunk),
but is that really a problem in everyday practice? I'm just curious --
if there's another issue with the cache that I'm not aware of, I'd like
to fix it.

I used to see font cache problems when testing and/or doc building for
a 0.99 branch release on a machine which had been running 1.0svn
trunk. I can't replicate it now, so perhaps it is fixed (though I
have only tried reverting the install and making plots, not doing full
doc builds). The only commit related to the cache since the 1.0
release that I see is

r8712 | mdboom | 2010-09-21 16:13:25 -0400 (Tue, 21 Sep 2010) | 2 lines

If a font file is looked up in the cache, but that font file no longer exists
on disk, rebuild the cache.

Not sure why this would caused a failure in the case of going from 1.0
to 0.99 ...

Russell, a good solution for you, not just for this particular
problem, but in general, is to use MPLCONFIGDIR in your application.
This will give you a custom location for your rc file, font cache,
etc.... We use it on the buildbots which are running multiple
installations of mpl to avoid clashes.

Hope this helps,
JDH

···

On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom <mdroe@...31...> wrote:

On 10/22/2010 05:45 PM, Russell E. Owen wrote:

system · October 24, 2010, 3:35am

We've been running into problems in Sage that seem to occur because font caches from 1.0.0 make old versions of matplotlib die. I haven't seen the problem myself, but several Sage developers have put in quite a bit of time in diagnosing the problem. In the end, I think they wrote a patch to do custom MPLCONFIGDIR for different versions of matplotlib in different versions of Sage.

I'm CCing sage-devel, in case one of the sage devs that ran into problems wants to comment.

Thanks,

Jason

···

On 10/22/10 7:16 PM, Michael Droettboom wrote:

On 10/22/2010 05:45 PM, Russell E. Owen wrote:

I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font
cache will cause matplotlib to fail (the application mysteriously exits
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide
how best to deal with it. Depending on the timing of 1.0.1 I can decide
whether it's worth putting in my own workaround, bundling a prerelease
version of matplotlib or just waiting for the official release.

I'm not sure what the timeframe is on 1.0.1.

What problem with the cache are you referring to? I'm aware of a
problem where if some fonts are moved or removed after the cache is
created matplotlib will crash (and this problem is fixed in the trunk),
but is that really a problem in everyday practice? I'm just curious --
if there's another issue with the cache that I'm not aware of, I'd like
to fix it.
'

--
Jason Grout

Jason_Grout2 · October 26, 2010, 5:52pm

John Palmieri asked me to forward his response (below) about the problems Sage has been having with matplotlib and backward incompatibility:

Thanks,

Jason

···

On 10/23/10 10:35 PM, jason-sage@...691... wrote:

On 10/22/10 7:16 PM, Michael Droettboom wrote:

On 10/22/2010 05:45 PM, Russell E. Owen wrote:

I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font
cache will cause matplotlib to fail (the application mysteriously exits
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide
how best to deal with it. Depending on the timing of 1.0.1 I can decide
whether it's worth putting in my own workaround, bundling a prerelease
version of matplotlib or just waiting for the official release.

I'm not sure what the timeframe is on 1.0.1.

What problem with the cache are you referring to? I'm aware of a
problem where if some fonts are moved or removed after the cache is
created matplotlib will crash (and this problem is fixed in the trunk),
but is that really a problem in everyday practice? I'm just curious --
if there's another issue with the cache that I'm not aware of, I'd like
to fix it.
'

We've been running into problems in Sage that seem to occur because font
caches from 1.0.0 make old versions of matplotlib die. I haven't seen
the problem myself, but several Sage developers have put in quite a bit
of time in diagnosing the problem. In the end, I think they wrote a
patch to do custom MPLCONFIGDIR for different versions of matplotlib in
different versions of Sage.

I'm CCing sage-devel, in case one of the sage devs that ran into
problems wants to comment.

==========================================================

The Sage developers have found two issues with MPLCONFIGDIR:

- First, when upgrading from version 0.99.3 to 1.0.0, the contents of
that directory seem to cause compatibility problems. That is, once
you upgrade to a version of Sage using 1.0.0, it overwrites whatever
was in that directory, and then you get errors when using an older
version of Sage which still uses 0.99.3. See
<http://trac.sagemath.org/sage_trac/ticket/9221#comment:82> for an
example of the sort of error which arises, and see
<http://trac.sagemath.org/sage_trac/ticket/6235> for our fix: in Sage,
we set MPLCONFIGDIR to different directories based on the version of
matplotlib.

- Second, the following code in matplotlib/texmanager.py can cause a
race condition when creating MPLCONFIGDIR:

if not os.path.exists(DIR):
os.mkdir(DIR)

In particular, when running doctests for Sage, if MPLCONFIGDIR doesn't
exist, two different doctests can try to create it at the same time,
causing a problem. (I've also heard people suggest that these sort of
race conditions can be security issues, but I don't know about the
validity of this.) See
<http://trac.sagemath.org/sage_trac/ticket/10159> for our fix: we
replace those lines by

   try:
       os.mkdir(DIR)
   except OSError, e:
       if e.errno == errno.EEXIST:
            pass
       else:
            raise

(and also add "import errno" at the beginning of the file).

I'd be happy to hear any comments you might have about these.

--
John Palmieri
jhpalmieri64@...149...

Andrew_Straw5 · October 28, 2010, 5:44am

I think we should really get the build bot to all green again before doing a release. Currently, the last that happened was October 4: http://mpl-buildbot.code.astraw.com/waterfall

···

On 10/23/2010 04:59, John Hunter wrote:

I would be happy to do a release early next week. Is anyone aware of
any show stopper bugs that need to be fixed first?

Benjamin_Root1 · October 28, 2010, 2:05pm

Just as a quick question that I would like to throw out. It isn’t a bug, but rather an aesthetics issue that I caused for the version 1.0 release.

With allowing 3d plots to be made subplottable, the margins for the plot area became a lot smaller than for the original method of producing 3d plots. This is because of the default region for subaxes, which usually matches the plotting region for a normal plot. However, 3d plots have been explicitly setting the viewing area to take up the entire axes rather than obeying the rcParams. With subplotting (or even creating a single plot using fig.gca() ), the rcParams override the explicit setting of the plot area. Therefore, 3d plots appear “squished” if created using the projection=‘3d’ approach.

My question is this: Would it at all be feasible (or even desirable) to have some sort of ability to specify defaults that are specific to a particular axes type? Currently, the code for setting the parameters will grab the rcparams if the figure is being newly created, or will copy the parameters from an existing figure in the case of creating subplots in an existing figure. This assumes a one-size-fits-all which 3d plots might need to be an exception.

Thoughts? Comments?

Ben Root

···

On Thu, Oct 28, 2010 at 12:44 AM, Andrew Straw <strawman@…36…> wrote:

On 10/23/2010 04:59, John Hunter wrote:

I would be happy to do a release early next week. Is anyone aware of

any show stopper bugs that need to be fixed first?

I think we should really get the build bot to all green again before

doing a release. Currently, the last that happened was October 4:

http://mpl-buildbot.code.astraw.com/waterfall

_John_Hunter · October 28, 2010, 2:55pm

Punting on the larger question.... others may have an opinion.

If it is a feature not a bug, can you commit new baseline images for
the buildbot and see if we can get it to go green?

JDH

···

On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben.root@...553...> wrote:

Just as a quick question that I would like to throw out. It isn't a bug,
but rather an aesthetics issue that I caused for the version 1.0 release.

With allowing 3d plots to be made subplottable, the margins for the plot
area became a lot smaller than for the original method of producing 3d
plots. This is because of the default region for subaxes, which usually
matches the plotting region for a normal plot. However, 3d plots have been
explicitly setting the viewing area to take up the entire axes rather than
obeying the rcParams. With subplotting (or even creating a single plot
using fig.gca() ), the rcParams override the explicit setting of the plot
area. Therefore, 3d plots appear "squished" if created using the
projection='3d' approach.

My question is this: Would it at all be feasible (or even desirable) to have
some sort of ability to specify defaults that are specific to a particular
axes type? Currently, the code for setting the parameters will grab the
rcparams if the figure is being newly created, or will copy the parameters
from an existing figure in the case of creating subplots in an existing
figure. This assumes a one-size-fits-all which 3d plots might need to be an
exception.

Benjamin_Root1 · October 28, 2010, 4:14pm

The current test failures appear to be related to changes made to pcolormesh, and nothing to do with mplot3d. As for the mplot3d images, the documentation images were updated, and I think I updated all of the code and documentation. I don’t think the test suite checks those, does it? Oddly enough, I can’t seem to find any test code for mplot3d (looks like another item to add onto my todo list…).

Ben Root

···

On Thu, Oct 28, 2010 at 9:55 AM, John Hunter <jdh2358@…149…> wrote:

On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben.root@…553…> wrote:

Just as a quick question that I would like to throw out. It isn’t a bug,

but rather an aesthetics issue that I caused for the version 1.0 release.

With allowing 3d plots to be made subplottable, the margins for the plot

area became a lot smaller than for the original method of producing 3d

plots. This is because of the default region for subaxes, which usually

matches the plotting region for a normal plot. However, 3d plots have been

explicitly setting the viewing area to take up the entire axes rather than

obeying the rcParams. With subplotting (or even creating a single plot

using fig.gca() ), the rcParams override the explicit setting of the plot

area. Therefore, 3d plots appear “squished” if created using the

projection=‘3d’ approach.

My question is this: Would it at all be feasible (or even desirable) to have

some sort of ability to specify defaults that are specific to a particular

axes type? Currently, the code for setting the parameters will grab the

rcparams if the figure is being newly created, or will copy the parameters

from an existing figure in the case of creating subplots in an existing

figure. This assumes a one-size-fits-all which 3d plots might need to be an

exception.

Punting on the larger question… others may have an opinion.

If it is a feature not a bug, can you commit new baseline images for

the buildbot and see if we can get it to go green?

JDH