matplotlib-devel Mailing List for matplotlib

On Mon, Oct 25, 2010 at 4:09 PM, Daniel Hyams <dh...@gm...> wrote:
> Right, I was referring specifically to MATPLOTLIBDIR ;)
>
> I was just pleased as punch to find it in the source code, documented or no
> :)


I'm guessing you mean MATPLOTLIBDATA ?  And you're right, it isn't
documented (yet)...

JDH

Right, I was referring specifically to MATPLOTLIBDIR ;)

I was just pleased as punch to find it in the source code, documented or no
:)


On Mon, Oct 25, 2010 at 5:06 PM, John Hunter <jd...@gm...> wrote:

> On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams <dh...@gm...> wrote:
>
> > It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> > MPLCONFIGDIR environment variables.  The former is for the location of
> > mpl-data, and is not really documented well (that I could find, anyway,
> but
> > I found it in the source code), and MPLCONFIGDIR specifies where your
> > configuration files for matplotlib are.  This is where your font cache
> will
> > be, as well as your matplotlibrc.
> >
> > You can set these env variables within your code, before import of
> > matplotlib via os.environment.
>
> They should be better documented, but the MPLCONFIGDIR is in the FAQ
>
>
>
> http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location
>



-- 
Daniel Hyams
dh...@gm...

On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams <dh...@gm...> wrote:

> It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> MPLCONFIGDIR environment variables.  The former is for the location of
> mpl-data, and is not really documented well (that I could find, anyway, but
> I found it in the source code), and MPLCONFIGDIR specifies where your
> configuration files for matplotlib are.  This is where your font cache will
> be, as well as your matplotlibrc.
>
> You can set these env variables within your code, before import of
> matplotlib via os.environment.

They should be better documented, but the MPLCONFIGDIR is in the FAQ


http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location

On Mon, Oct 25, 2010 at 4:15 PM, Russell E. Owen <ro...@uw...> wrote:

> In article <4CC...@st...>,
>  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.
> >
> > 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.
>
> The known problem what I am referring to. Fortunately.
>
> It has proven to be a very serious problem in practice. I bundle
> matplotlib into a Mac application and for a significant number of my
> users it crashes at startup due to problems with the matplotlib cache
> files. The fix is always the same: delete the cache.
>
> Some reasons this has happened
> - The user first runs the application from the distribution dmg file
> before copying to /Applications
> - The user installs it and runs it, but then moves or renames it for
> some reason...boom
> - The user had an older version of matplotlib installed but then deleted
> it for some reason.
>
> Fortunately the fix from the trunk will do the job.
>
> That said, it still seems risky to me that matplotlib insists on using a
> shared directory for its cache and matplotlibrc file: that there's no
> way to tell matplotlib to put that data somewhere else (e.g. inside the
> application bundle). With bundled applications it is quite likely the
> user may run multiple versions of matplotlib without even knowing it. If
> any of that data is version-dependent then this is a recipe for
> mysterious problems.
>
>
It doesn't really insist on it right?  There are MATPLOTLIBDIR and
MPLCONFIGDIR environment variables.  The former is for the location of
mpl-data, and is not really documented well (that I could find, anyway, but
I found it in the source code), and MPLCONFIGDIR specifies where your
configuration files for matplotlib are.  This is where your font cache will
be, as well as your matplotlibrc.

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



-- 
Daniel Hyams
dh...@gm...

In article 
<AAN...@ma...>,
 John Hunter <jd...@gm...> wrote:

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

That's the fix I wanted.

Oddly enough, I never noticed the problem until I started bundling 1.0.0 
with my application. Then I had many reports of it. However, I also 
started bundling a strip chart widget and it's conceivable that my 
earlier simpler plots never needed the font cache.

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

Thank you. That sounds like precisely what I wanted! I can keep my 
application self-contained. Wonderful!

-- Russell

In article <4CC...@st...>,
 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.
> 
> 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.

The known problem what I am referring to. Fortunately.

It has proven to be a very serious problem in practice. I bundle 
matplotlib into a Mac application and for a significant number of my 
users it crashes at startup due to problems with the matplotlib cache 
files. The fix is always the same: delete the cache.

Some reasons this has happened
- The user first runs the application from the distribution dmg file 
before copying to /Applications
- The user installs it and runs it, but then moves or renames it for 
some reason...boom
- The user had an older version of matplotlib installed but then deleted 
it for some reason.

Fortunately the fix from the trunk will do the job.

That said, it still seems risky to me that matplotlib insists on using a 
shared directory for its cache and matplotlibrc file: that there's no 
way to tell matplotlib to put that data somewhere else (e.g. inside the 
application bundle). With bundled applications it is quite likely the 
user may run multiple versions of matplotlib without even knowing it. If 
any of that data is version-dependent then this is a recipe for 
mysterious problems.

-- Russell

  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

On Mon, Oct 25, 2010 at 6:53 AM, Kynn Jones <ky...@gm...> wrote:

>> diff -u figure.py.orig figure.py > patchname.diff
>
> OK, got that part.  Thanks.  But where do I send the patch?

Actually, we recommend submitting an svn diff.  Details at:

  http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch

JDH

Ben, JJ, thanks for your suggestions.  I'll look into what you proposed.

~kj

On Sat, Oct 23, 2010 at 3:13 PM, Ryan May <rm...@gm...> wrote:

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

OK, got that part.  Thanks.  But where do I send the patch?

~kj

On Sat, Oct 23, 2010 at 7:09 AM, Kynn Jones <ky...@gm...> wrote:
> Without knowing much about the internals of matplotlib, it seems to me that
> the best way to do this would be to define a container class that can have
> itself as one of the contained elements.  In this way, a containment
> hierarchy of arbitrary depth could be defined.  But it is my understanding
> that there is no immediate way to do this in matplotlib now, so I'd have to
> implement it myself.

Matplotlib has a simple hierachy of Figure-Axes-Artists (this is not
100% correct description as a matter of fact, see
http://matplotlib.sourceforge.net/users/artists.html for more
details).

All Axes instances have associated positions within a figure instance.
If you want to have a hierarchy of multiple axes, what you can do
basically is to make those positions in hierarchical manner.

This can be very trivial depending on what exactly you want (e.g., how
you want the axes sizes (and the gaps inbetween) specified). However,
there are a few ways to ease this process.

http://github.com/astraw/mplsizer

mpl v1.0 has gridspec.

http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-using-subplotspec

For example, you may do something like

import matplotlib.gridspec as gridspec
fig = gcf()
gs0 = gridspec.GridSpec(2, 2)
ax = fig.add_subplot(gs0[0, 0])

gs00 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs0[1])
ax2 = fig.add_subplot(gs00[0])

gs000 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs00[1])
ax3 = fig.add_subplot(gs000[0])

Or, you can use axes_grid toolkit as mentioned above.

Regards,

-JJ

--- On Sun, 10/24/10, Ryan May <rm...@gm...> wrote:
> > One solution is to add an .animation attribute to the
> > Figure class, which is None by default (for non-animated
> > drawing).
> I'm not completely wild about it, because it just feels
> wrong to put something specific to animation inside figure.

OK I see your point.

> The problem we're trying to solve here is biltting, so is 
> there some way we can improve how blitting is handled?

For a general API for blitting (something that is not restricted to animations), we need two functions: one that tells matplotlib that we want to blit something, and one that does the actual blitting. Right now we only have the latter. Let me point out also that there is nothing peculiar about blitting in Quartz. It's just that in Quartz all drawing operations should be performed from inside the event loop.

For comparison, this is roughly what happens if you draw a line:

plot(x,y)
# tells matplotlib that we want to draw a line
# this triggers a call to
draw_if_interactive()
# this marks the canvas as invalid
# the event loop then calls a callback function to redraw the canvas
# the callback function calls
figure.draw(renderer)
# which calls
renderer.draw_path
# which does the actual drawing

For a general blitting API, we need the equivalent of the plot function; something that informs matplotlib that we want to blit but doesn't do the actual blitting. The actual blitting should then be done from inside figure.draw.

If you just want to implement blitting for animations, one option is to add a draw() method to TimedAnimation, and to set fig.draw = self.draw in the __init__.py of TimedAnimation. Then when a figure needs to be redrawn, TimedAnimation.draw will be called from inside the event loop. Such a TimedAnimation.draw function should then be roughly the same as the current _draw_next_frame function.

Best,
--Michiel.



      

On Fri, Oct 22, 2010 at 5:09 PM, Kynn Jones <ky...@gm...> wrote:

> I need to generate a fairly complex chart, for which I need the ability to
> specify not only subplots, but also sub-subplots, and even
> sub-sub-sub-plots.  (Our group has found such charts useful in the past, but
> they were generated using horrific MATLAB code.)
>
> I'll try to describe what I want to do in a bit more detail (it's messy).
>
> First imagine a simple plot (just a simple X-Y line graph connecting 3-4
> datapoints).  I'll call this a level-0 plot.  Now, join ~10 of these level-0
> plots side-by-side (with no space between the plots).  This new aggregate is
> a level-1 plot.  Next stack ~10 level-1 plots vertically, again, with no
> space between them.  The resulting aggregate is a level-2 plot.  Finally
> arrange ~10 of these level-2 plots side-by-side, with some spacing between
> them.  The desired final product is this level-3 plot.
>
> Without knowing much about the internals of matplotlib, it seems to me that
> the best way to do this would be to define a container class that can have
> itself as one of the contained elements.  In this way, a containment
> hierarchy of arbitrary depth could be defined.  But it is my understanding
> that there is no immediate way to do this in matplotlib now, so I'd have to
> implement it myself.
>
> I could use some guidance to the source code.
>
> What I need to clarify is the following.  First consider some simple plot
> A: it has axes, data points, tick marks, labels, etc., and for all these
> elements there are associated absolute x-y coordinates on the canvas.  If
> now we make this plot A one of the subplots in a collection of, say, 12
> subplots, arranged as 3 rows of 4 subplots each, all the x-y coordinates
> associated with the original plot A will have to be translated and scaled,
> so that the subplot lands in the right place on the canvas, and has the
> appropriate size.  This process of translation and scaling is what I want to
> pinpoint: What exactly is the connection between running the add_subplot
> method and the translation+scaling that it entails?
>
> What would be a good entry point for me to answer the questions above by
> reading the source code?
>
> TIA!
>
> ~kj
>
>
Looks like you are talking about an arbitrarily deep hierarchical
subplotting feature.  I am not exactly sure how feasible/unfeasible this is,
but a good place to start might be to take a look at the axes_grid toolkit
that does a lot of very advanced axes organizational tricks.

http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html

I hope this proves useful, or at least inspires you for ideas on how to
accomplish what you are looking for cleanly.  And, as always, patches are
always welcome!

Ben Root