Re: [matplotlib-devel] Release schedule for version 1.0.1?

[Benjamin Root]

On Thu, Oct 28, 2010 at 12:44 AM, Andrew Straw  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
>
>
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
--
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?

[John Hunter]

On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root  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

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

[Benjamin Root]

On Thu, Oct 28, 2010 at 9:55 AM, John Hunter  wrote:

> On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root  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
>

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
--
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] Thoughts about callbacks

[Eric Bruning]

On Mon, Oct 25, 2010 at 9:40 AM, Michael Droettboom  wrote:
>  On 10/23/2010 06:05 PM, David Carmean wrote:
>> 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.
> It's great to see someone working on this.  Similar ideas have been
> thrown around since at least as long as I "joined the party" in 2007
> (search the e-mail archives for "Traits").  I like your approach because
> it should allow for a tighter integration of Traits, while at the same
> time not adding Traits as a dependency.  It just might be the elusive
> middle ground that prevented us from really going forward way back when.
>
> Mike

+1 on Mike's middle-ground idea.

In case you haven't seen it, decorators are presently used to allow
Aritist.draw to make a raster mode switch for a MixedModeRenderer.
It's really a generic per-artist before/after draw signal implemented
for that single purpose. This could potentially be refactored if
there's a new signaling system in place.

-Eric

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

[Christopher Barker]

On 10/25/10 1:41 PM, Daniel Hyams wrote:
> It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> MPLCONFIGDIR environment variables.

> You can set these env variables within your code, before import of
> matplotlib via os.environment.

I'm glad I've learned about this, and will start doing it with my 
bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it 
be possible to set this sort of thing without resorting to that little 
round trip through environment variables?

Not a big deal, but it feels kludgy.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

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

[John Hunter]

On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
 wrote:
> On 10/25/10 1:41 PM, Daniel Hyams wrote:
>> It doesn't really insist on it right?  There are MATPLOTLIBDIR and
>> MPLCONFIGDIR environment variables.
>
>> You can set these env variables within your code, before import of
>> matplotlib via os.environment.
>
> I'm glad I've learned about this, and will start doing it with my
> bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it
> be possible to set this sort of thing without resorting to that little
> round trip through environment variables?
>
> Not a big deal, but it feels kludgy.

The MPLCONFIGDIR tells mpl where to find the config file.  It's hard
to read the config, no matter how pythonic it is,  if you don't know
where it is.  Once the config file (matplotlibrc) is located  you can
set the datapath with the  'datapath' parameter so you don't need
MATPLOTLIBDATA (which is only used if datapath is not set).  From the
rc file:


  # Where your matplotlib data lives if you installed to a non-default
  # location.  This is where the matplotlib fonts, bitmaps, etc reside
  #datapath : /home/jdhunter/mpldata


We could use command line args, but mpl is a library and shouldn't
really be using them...  Arguably we are already doing too much in the
way of command line args.

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

Re: [matplotlib-devel] Release schedule for version 1.0.1?

[Benjamin Root]

On Thu, Oct 28, 2010 at 1:50 PM, John Hunter  wrote:

> On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
>  wrote:
> > On 10/25/10 1:41 PM, Daniel Hyams wrote:
> >> It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> >> MPLCONFIGDIR environment variables.
> >
> >> You can set these env variables within your code, before import of
> >> matplotlib via os.environment.
> >
> > I'm glad I've learned about this, and will start doing it with my
> > bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it
> > be possible to set this sort of thing without resorting to that little
> > round trip through environment variables?
> >
> > Not a big deal, but it feels kludgy.
>
> The MPLCONFIGDIR tells mpl where to find the config file.  It's hard
> to read the config, no matter how pythonic it is,  if you don't know
> where it is.  Once the config file (matplotlibrc) is located  you can
> set the datapath with the  'datapath' parameter so you don't need
> MATPLOTLIBDATA (which is only used if datapath is not set).  From the
> rc file:
>
>
>  # Where your matplotlib data lives if you installed to a non-default
>  # location.  This is where the matplotlib fonts, bitmaps, etc reside
>  #datapath : /home/jdhunter/mpldata
>
>
> We could use command line args, but mpl is a library and shouldn't
> really be using them...  Arguably we are already doing too much in the
> way of command line args.
>
> JDH
>
>
Isn't this a problem with any program/library?  Could we go a route where
(for *nix) we check the current working directory for the file, then check
the user account's .local directory, then check the /etc directory for the
any remaining settings?  Maybe for Windows use (dare I say it!) the
registry?

(Please excuse the registry idea if this completely flies in the face of
modern Windows development practices, I haven't programmed in Windows since
my days of taking AP Computer Science ten years ago).

Ben Root
--
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?

[Russell E. Owen]

In article <4cc9bcd8.60...@noaa.gov>,
 Christopher Barker  wrote:

> On 10/25/10 1:41 PM, Daniel Hyams wrote:
> > It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> > MPLCONFIGDIR environment variables.
> 
> > You can set these env variables within your code, before import of
> > matplotlib via os.environment.
> 
> I'm glad I've learned about this, and will start doing it with my 
> bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it 
> be possible to set this sort of thing without resorting to that little 
> round trip through environment variables?
> 
> Not a big deal, but it feels kludgy.
> 
> -Chris

It's an interesting question. You can't call a matplotlib function to do 
it because it has to happen before matplotlib is loaded. I suppose there 
could be a configuration package to perform the operation.

Having looked into it some, I confess I am not that sold on using 
MPLCONFIGDIR in my bundled applications. Issues include:

* The font cache uses absolute paths.

Thus the cache will break if the application is moved or renamed. So 
there is no point to using MPLCONFIGDIR to avoid the problem of 
matplotlib crashing when the font cache is out of date. It cannot help!

* Where to put it?

I had hoped to put it in the bundled application itself, so that it 
would be thrown out when the application was thrown out. But matplotlib 
crashes if the directory cannot be written (pity that; it'd be nice if 
it could run without a font cache). Thus the application could not be 
run from the disk image or from an Applications directory that an admin 
had protected by making it read-only.

I'd like to avoid generating a new MPLCONFIGDIR directory for every 
version of my application (or every version of matplotlib). So it seems 
to me the only sensible choice is to have one MPLCONFIGDIR shared by all 
versions of the application. The only point I can see to doing this is 
to avoid user-written matplotlibrc files: the danger that they would 
mess up the appearance of the application or be incompatible with the 
version of matplotlib in the application.

An alternative is to just keep using the default MPLCONFIGDIR 
(~/.matplotlib) and put up with the risk of a matplotlibrc file doing 
bad things. That's my plan for now since I know few users who bother to 
set exotic things in their matplotlibrc files, and my application 
already explicitly set the important settings.

-- Russell


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

[John Hunter]

On Thu, Oct 28, 2010 at 2:46 PM, Russell E. Owen  wrote:

> It's an interesting question. You can't call a matplotlib function to do
> it because it has to happen before matplotlib is loaded. I suppose there
> could be a configuration package to perform the operation.

This is basically what we already do, minus the /etc part.  So we
could check some default global locations for a matplotlibrc if we
want to.  Currently we

  1. check for the ENV var

  2. check the current dir for a file called matplotlibrc and use it if there

  3. check $HOME/.matplotlib/matplotlibrc



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

Re: [matplotlib-devel] Release schedule for version 1.0.1?

[Christopher Barker]

On 10/28/10 11:50 AM, John Hunter wrote:
> On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
>>> You can set these env variables within your code, before import of
>>> matplotlib via os.environment.

> The MPLCONFIGDIR tells mpl where to find the config file.  It's hard
> to read the config, no matter how pythonic it is,  if you don't know
> where it is.

OK -- so that does need to be set as the first part of the process.

>  Once the config file (matplotlibrc) is located  you can
> set the datapath with the  'datapath' parameter so you don't need
> MATPLOTLIBDATA (which is only used if datapath is not set).

So the fontcache will be put/found there? That would solve part of 
Russell's (and my) issue.

> We could use command line args, but mpl is a library and shouldn't
> really be using them...  Arguably we are already doing too much in the
> way of command line args.

I agree -- command line args are not the way to go.

On 10/28/10 12:46 PM, Russell E. Owen wrote:

> It's an interesting question. You can't call a matplotlib function to do
> it because it has to happen before matplotlib is loaded. I suppose there
> could be a configuration package to perform the operation.

I actually like that idea. It could even do a bit more, like have the 
matplotlib.use() function, and who knows how many others.

I've never liked the .matplotlibrc approach -- it makes great sense for 
an interactive environment, but not so much for embedding MPL in other 
apps, for all the reason's Russell has laid out.

If there was a mplconfig module that you could import first, and have 
functions in there where you could set all the defaults the way tyou 
like them, it would be easier to make self-contained MPL apps that 
didn't step on each-others toes.

> * The font cache uses absolute paths.

perhaps that could be fixed -- how are parameters like that stored now? 
If it was an attribute of some object, it could be made a property that 
resolved the path is some nifty way. Or, if there were a mplconfig 
module, it could figure out the absolute path for the font cache at run 
time.

> * Where to put it?
>
> I had hoped to put it in the bundled application itself, so that it
> would be thrown out when the application was thrown out.

I think the official way to do it on OS-X is to put it in 
~/Library/Application Support. However, I don't now how that gets 
cleaned up -- if ever!

> I'd like to avoid generating a new MPLCONFIGDIR directory for every
> version of my application (or every version of matplotlib).

I suppose, like for any application configuration, you'd want a new 
version to check the config, and clean it out if it is for an old 
version (or, even better, update for the new version, but that's a lot 
of work)

> An alternative is to just keep using the default MPLCONFIGDIR
> (~/.matplotlib) and put up with the risk of a matplotlibrc file doing
> bad things. That's my plan for now since I know few users who bother to
> set exotic things in their matplotlibrc files, and my application
> already explicitly set the important settings.

I've gotten away with that as well, but I still don't like it!

Is is possible for MPL to read from one place, but write to another? 
Doesn't that happen already for when MPL first starts up and doesn't 
have anything?

And it sounds like the fontcache and rc file don't NEED to be in teh 
same place -- they probably shouldn't be for this type of use.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov

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

[James Evans]

In reference to the configuration package idea...

I (and the users that I support) use matplotlib both as a standalone plotter
for generating lots of plots, as an interactive plotter, and as an embedded
plot in an application environment.  In all of these instances we have found
the '.matplotlibrc' mechanism to be severely lacking in control of plot
formats.  Users will be generating series of plots that are going to be
embedded into documents and therefore want a uniform look and feel to those
plots.  Later they want to generate some plots for use on an overhead
projector (which has a much different DPI).  Another time they are
interactively plotting on their workstation and still again doing all this
in an embedded form as well.

The solution we have come up with, although a little bit of a hack, is a
configuration/formatter class, where instances are used to manage the
formatting of the plots.  Each instance can represent a specific set of
configurations controlling everything from font properties to background
color.

The difference here is that having global defaults is all fine and dandy,
but sometimes just setting a global default is not enough and controlling
the setting as an encapsulated entity that can be passed around and selected
at will can be quite useful.

Just my $0.02

--James Evans


> On 10/28/10 12:46 PM, Russell E. Owen wrote:
> 
> > It's an interesting question. You can't call a matplotlib function to
> do
> > it because it has to happen before matplotlib is loaded. I suppose
> there
> > could be a configuration package to perform the operation.
> 
> I actually like that idea. It could even do a bit more, like have the
> matplotlib.use() function, and who knows how many others.
> 
> I've never liked the .matplotlibrc approach -- it makes great sense for
> an interactive environment, but not so much for embedding MPL in other
> apps, for all the reason's Russell has laid out.
> 
> If there was a mplconfig module that you could import first, and have
> functions in there where you could set all the defaults the way tyou
> like them, it would be easier to make self-contained MPL apps that
> didn't step on each-others toes.


--
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] Typo in make.osx

[Uri Laserson]

This line:

ARCH_FLAGS="-arch i386-arch x86_64"

should actually be

ARCH_FLAGS="-arch i386 -arch x86_64"

(notice the extra space after i386.  it wouldn't build for me without this
fix.)

Uri

...
Uri Laserson
Graduate Student, Biomedical Engineering
Harvard-MIT Division of Health Sciences and Technology
M +1 917 742 8019
laser...@mit.edu
--
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] Qt4 backend

[Jelmer Cnossen]

Hello,

recently I upgraded to matplotlib 1.0.0 which I mainly use for plotting in my 
(python 2.6 based) application with Qt4 GUI. Overall it works fine, but there 
are a few issues I experienced also with the previous version, especially with 
the toolbar.

When building a standalone version using py2exe, images of the toolbar are 
missing. I had to manually modify the .svg extensions
to .png in the _init_toolbar() function in backend_qt4.py. And for the new 
'qt4_editor_options' option, no png existed yet.

Since I wanted to get rid of some toolbar functions in my standalone app, I 
wanted to create my own backend. But following the instructions in the 
backend_template.py didn't help me much. In the comments at the beginning of 
this file it says:

"...add 'xxx' to the switchyard in matplotlib/backends/__init__.py and 'xxx' to 
the backends list in the validate_backend methon in
matplotlib/__init__.py and you're off."

Unfortunately it doesn't work this way (anymore).

Is it possible to update the instructions on doing your own backend? Updating 
the Qt4 backend would help as well.
I know this is not the right place for feature requests, but anyway: it would 
be nice to have some flexibility in modifying the toolbar (which functions to 
add or not,etc). Now I do it the quick and dirty way: I comment out the toolbar 
items in the _init_toolbar() function in backend_qt4.py. However, depending on 
the app I'm working on, I have to comment/uncomment it...

Kind regards,

Jelmer

--Disclaimer-- 

This email and any files transmitted with it are confidential and may be 
privileged or otherwise protected from disclosure and are intended solely for 
the use of the entity / individual to whom they are addressed. If you have 
received this email in error or If you are not the intended recipient, please 
notify the sender immediately by way of telephone or email and delete this 
message and any files transmitted from your system. Please note that any views 
presented in the email are solely those of the author and do not necessarily 
represent those of the organization. While all care has been taken to avoid 
viruses the recipient is advised to check this email and attachments for 
presence of viruses. The organization accepts no liability on this account.
--
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] matplotlib: two issues with MPLCONFIGDIR

[John Palmieri]

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
 for an
example of the sort of error which arises, and see
 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
 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

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