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.
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
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/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
On 10/23/10 10:35 PM, jas...@cr... 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. > John Palmieri asked me to forward his response (below) about the problems Sage has been having with matplotlib and backward incompatibility: Thanks, Jason ========================================================== 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 jhp...@gm...
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 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...
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 Chr...@no...
On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker <Chr...@no...> 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
On Thu, Oct 28, 2010 at 1:50 PM, John Hunter <jd...@gm...> wrote: > On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker > <Chr...@no...> 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
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 Chr...@no...
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.
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 (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 ... 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
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
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 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
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
On Thu, Oct 28, 2010 at 12:44 AM, Andrew Straw <str...@as...> 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
On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben...@ou...> 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
On Thu, Oct 28, 2010 at 9:55 AM, John Hunter <jd...@gm...> wrote: > On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben...@ou...> 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
In article <4CC...@no...>, Christopher Barker <Chr...@no...> 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
On Thu, Oct 28, 2010 at 2:46 PM, Russell E. Owen <ro...@uw...> 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