matplotlib-devel Mailing List for matplotlib

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...

On Sat, Oct 23, 2010 at 1:37 PM, Kynn Jones <ky...@gm...> 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

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(texcache):
 os.mkdir(texcache)
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(texcache)
 except OSError, e:
 assert e.errno==errno.EEXIST, 'Cannot create %s.' % texcache
(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

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

On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom <md...@st...> 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 (2010年9月21日) | 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 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.
Mike
> 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 - 4ドルM cash, 500 devices, nearly 6ドルM 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel