Re: [matplotlib-devel] Release schedule for version 1.0.1?
On Fri, Oct 22, 2010 at 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. 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 -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] how to submit a patch?
I came across this Python syntax bug in matplotlib.figure.add_subplot: raise ValueError( "polar=True, yet projection='%s'. " + "Only one of these arguments should be supplied." % projection) If that code ever executes it will fail with "TypeError: not all arguments converted during string formatting". It's trivial to fix, of course, (just delete the '+') but I don't know how to submit a patch. Could someone please show me? TIA! ~kj -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] how to submit a patch?
On Sat, Oct 23, 2010 at 1:37 PM, Kynn Jones wrote: > I came across this Python syntax bug in matplotlib.figure.add_subplot: > raise ValueError( > "polar=True, yet projection='%s'. " + > "Only one of these arguments should be supplied." % > projection) > If that code ever executes it will fail with "TypeError: not all arguments > converted during string formatting". > It's trivial to fix, of course, (just delete the '+') but I don't know how > to submit a patch. Could someone please show me? Good catch. I can make the change if you want. However, if you want to use as a learning experience, first make a copy of the original file, say figure.py.orig. Then make the changes to your figure.py. Then you need to run diff: diff -u figure.py.orig figure.py > patchname.diff Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Thoughts about callbacks
As I blurted on -users, I'm thinking lately about callbacks in the non-GUI portions of the libraries--mostly Artist and subclasses. I'm curious if anybody else has been thinking about them? Ideally, I'd like to see the following: All of the Artist subclasses, and anything else that might belong to a Figure, would be updated to use/add cbook.CallbackRegistry callbacks (weakref = good thing). In addition to emulating/replacing the simplistic 'pchanged' callback with a signal of that same name, there would be a signal named after each setter method, and said methods fire off their eponymous signal after they modify the property. There should be some way to rate-limit or temporarily block individual signals or callback connections. The various constructors, etc, would be modified to "subscribe" to the 'pchanged' signal of all children, such that even if a particular object in the "middle" of a figure heirarchy does nothing with the signal, a sort of a global 'pchanged' signal propagates up to the top object (FigureManager, Canvas, Figure, something). My current Use Case for these features is in experimenting with different Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired of calling canvas.draw() all the time :) But also, I'm working on a GUI to do the same (traits UI), and want to tie both layers of the model together with callbacks to speed up the experimenting. I've spent a few hours this weekend doing some meta-monkey-patching-- using __getattribute__ to decorate the setters on-the-fly to invoke callbacks.process(*args) after the changes. I have a few more quick hacks to try before I'm ready to decide on a production-ready strategy. So my question today is: is anyone interested in discussing these ideas and how to implement them? Thanks... -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
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. Thanks, Jason -- Jason Grout -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
