Menu
▾
▴
matplotlib-devel
|
From: Michael D. <md...@st...> - 2008-07-07 16:19:58
|
I noticed today that the examples in the docs have the ticks on the outside of the axes. You can see it here: http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html I'm having a terrible time tracking down the cause -- maybe I'm just not thinking clearly today. By version bisection, I determined that it broke with revision 5690: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690 I've verified this twice (cleaning all build and installation remnants out in between), and I'm pretty sure that's the revision where things break. But there's nothing in that revision that leaps out as a cause (particularly since the effect is global and affects plots that weren't even updated in that revision). One other tidbit of information -- the example plots work fine when called directly. This only seems to affect plots generated for the docs. Any ideas? Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Fernando P. <fpe...@gm...> - 2008-07-07 17:07:04
|
On Mon, Jul 7, 2008 at 9:19 AM, Michael Droettboom <md...@st...> wrote: > One other tidbit of information -- the example plots work fine when > called directly. This only seems to affect plots generated for the docs. Are the docs built with a custom .matplotlibrc? Maybe there's a different setting there that's triggering a bug... Cheers, f |
|
From: Michael D. <md...@st...> - 2008-07-07 17:14:50
|
Yes, but curiously, it doesn't change between those revisions... Mike Fernando Perez wrote: > On Mon, Jul 7, 2008 at 9:19 AM, Michael Droettboom <md...@st...> wrote: > > >> One other tidbit of information -- the example plots work fine when >> called directly. This only seems to affect plots generated for the docs. >> > > Are the docs built with a custom .matplotlibrc? Maybe there's a > different setting there that's triggering a bug... > > Cheers, > > f > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Fernando P. <fpe...@gm...> - 2008-07-07 17:18:10
|
On Mon, Jul 7, 2008 at 10:14 AM, Michael Droettboom <md...@st...> wrote: > Yes, but curiously, it doesn't change between those revisions... But it's different from *your* user rc file. That might point to the setting that causes the problem... f |
|
From: Michael D. <md...@st...> - 2008-07-07 17:26:14
|
Removing all contents of the doc/matplotlibrc and doc/pyplots/matplotlibrc files (reverting to the defaults), or removing the files completely, does not fix the tick outside the axes issue... Removing my ~/.matplotlib/matplotlibrc does not resolve the issue. However, other rcparam values do change and have the expected impact, so it isn't just that the doc/matplotlibrc and doc/pyplot/matplotlibrc aren't being read. Cheers, Mike Fernando Perez wrote: > On Mon, Jul 7, 2008 at 10:14 AM, Michael Droettboom <md...@st...> wrote: > >> Yes, but curiously, it doesn't change between those revisions... >> > > But it's different from *your* user rc file. That might point to the > setting that causes the problem... > > f > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Tony Yu <ts...@gm...> - 2008-07-07 17:24:58
|
On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote: > I noticed today that the examples in the docs have the ticks on the > outside of the axes. You can see it here: > > http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html > > I'm having a terrible time tracking down the cause -- maybe I'm just > not > thinking clearly today. By version bisection, I determined that it > broke with revision 5690: > > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690 > > I've verified this twice (cleaning all build and installation remnants > out in between), and I'm pretty sure that's the revision where > things break. > > But there's nothing in that revision that leaps out as a cause > (particularly since the effect is global and affects plots that > weren't > even updated in that revision). I think this problem is actually caused by contour_demo.py which sets >>> matplotlib.rcParams['xtick.direction'] = 'out' >>> matplotlib.rcParams['ytick.direction'] = 'out' Every plot called after contour_demo.py will probably have ticks outside of the axes. I think this problem has to do with how Python does imports (I'm on shaky ground here, so my explanation may be wrong). If matplotlib is already imported then a new call to `import matplotlib` doesn't actually do anything. So the above change rcParams never gets reinitialized to the default values. Try adding >>> matplotlib.rcParams['xtick.direction'] = 'in' >>> matplotlib.rcParams['ytick.direction'] = 'in' to the end of contour_demo.py. -Tony > > One other tidbit of information -- the example plots work fine when > called directly. This only seems to affect plots generated for the > docs. > > Any ideas? > > Mike > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Michael D. <md...@st...> - 2008-07-07 17:28:08
|
Thank you for finding this! That is indeed the case. I think we need to rework the plot generation code to avoid side effects by forcibly resetting state between plots. Maybe we should just fork another Python process for each plot. Darren, since (I believe) you wrote the initial documentation plotting code, do you have any thoughts? Cheers, Mike Tony Yu wrote: > > On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote: > >> I noticed today that the examples in the docs have the ticks on the >> outside of the axes. You can see it here: >> >> http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html >> >> I'm having a terrible time tracking down the cause -- maybe I'm just not >> thinking clearly today. By version bisection, I determined that it >> broke with revision 5690: >> >> >> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690 >> >> >> I've verified this twice (cleaning all build and installation remnants >> out in between), and I'm pretty sure that's the revision where things >> break. >> >> But there's nothing in that revision that leaps out as a cause >> (particularly since the effect is global and affects plots that weren't >> even updated in that revision). > > I think this problem is actually caused by contour_demo.py which sets > > >>> matplotlib.rcParams['xtick.direction'] = 'out' > >>> matplotlib.rcParams['ytick.direction'] = 'out' > > Every plot called after contour_demo.py will probably have ticks > outside of the axes. I think this problem has to do with how Python > does imports (I'm on shaky ground here, so my explanation may be > wrong). If matplotlib is already imported then a new call to `import > matplotlib` doesn't actually do anything. So the above change rcParams > never gets reinitialized to the default values. > > Try adding > > >>> matplotlib.rcParams['xtick.direction'] = 'in' > >>> matplotlib.rcParams['ytick.direction'] = 'in' > > to the end of contour_demo.py. > > > -Tony > >> >> One other tidbit of information -- the example plots work fine when >> called directly. This only seems to affect plots generated for the >> docs. >> >> Any ideas? >> >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Operations and Engineering Division >> Space Telescope Science Institute >> Operated by AURA for NASA >> >> >> ------------------------------------------------------------------------- >> >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Fernando P. <fpe...@gm...> - 2008-07-07 18:14:43
|
On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> wrote: > Thank you for finding this! That is indeed the case. > > I think we need to rework the plot generation code to avoid side effects > by forcibly resetting state between plots. Maybe we should just fork > another Python process for each plot. Darren, since (I believe) you > wrote the initial documentation plotting code, do you have any thoughts? Isn't that unnecessarily slow? Why not have each plot simply make a call to load a clean state? rc_defaults() or somesuch? This little call could even be auto-run by the doc generation code, without requiring a full process restart. Basically I think MPL should be stateless enough to tolerate working in a long-lived process with repeatable results. Anything else should be considered a bug IMHO ;) (I know rcParams is precisely a stateful system, but it should be trivial to obtain a known clean state always, with a single call). Cheers, f |
|
From: Michael D. <md...@st...> - 2008-07-07 18:33:49
|
Fernando Perez wrote: > On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> wrote: > >> Thank you for finding this! That is indeed the case. >> >> I think we need to rework the plot generation code to avoid side effects >> by forcibly resetting state between plots. Maybe we should just fork >> another Python process for each plot. Darren, since (I believe) you >> wrote the initial documentation plotting code, do you have any thoughts? >> > > Isn't that unnecessarily slow? Why not have each plot simply make a > call to load a clean state? rc_defaults() or somesuch? This little > call could even be auto-run by the doc generation code, without > requiring a full process restart. > Agreed, and that does seem to fix this particular issue. > Basically I think MPL should be stateless enough to tolerate working > in a long-lived process with repeatable results. Anything else should > be considered a bug IMHO ;) (I know rcParams is precisely a stateful > system, but it should be trivial to obtain a known clean state always, > with a single call). > For the most part, I think that's correct. There are still some lingering uses where certain objects and values are cached at startup time based on rcParams. (For example, in backend_pdf, and some things mathtext used to do). But that's sort of a different issue, because there the problem is with some values being immutable after startup, not being unable to reset back to the startup state. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Darren D. <dsd...@gm...> - 2008-07-08 13:31:57
|
On Monday 07 July 2008 02:33:40 pm Michael Droettboom wrote: > Fernando Perez wrote: > > On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> wrote: > >> Thank you for finding this! That is indeed the case. > >> > >> I think we need to rework the plot generation code to avoid side effects > >> by forcibly resetting state between plots. Maybe we should just fork > >> another Python process for each plot. Darren, since (I believe) you > >> wrote the initial documentation plotting code, do you have any thoughts? > > > > Isn't that unnecessarily slow? Why not have each plot simply make a > > call to load a clean state? rc_defaults() or somesuch? This little > > call could even be auto-run by the doc generation code, without > > requiring a full process restart. > > Agreed, and that does seem to fix this particular issue. Sorry I didn't respond before now, I got back into town last night. Tony, thank you for tracking this down, that was a really good find. I don't think I would have ever thought to look in the right place. Mike, is the issue settled? Darren |
|
From: Michael D. <md...@st...> - 2008-07-08 13:55:09
|
Yes, I believe so, barring any other side effects we inadvertently create in the future... ;) Mike Darren Dale wrote: > On Monday 07 July 2008 02:33:40 pm Michael Droettboom wrote: > >> Fernando Perez wrote: >> >>> On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> >>> > wrote: > >>>> Thank you for finding this! That is indeed the case. >>>> >>>> I think we need to rework the plot generation code to avoid side effects >>>> by forcibly resetting state between plots. Maybe we should just fork >>>> another Python process for each plot. Darren, since (I believe) you >>>> wrote the initial documentation plotting code, do you have any thoughts? >>>> >>> Isn't that unnecessarily slow? Why not have each plot simply make a >>> call to load a clean state? rc_defaults() or somesuch? This little >>> call could even be auto-run by the doc generation code, without >>> requiring a full process restart. >>> >> Agreed, and that does seem to fix this particular issue. >> > > Sorry I didn't respond before now, I got back into town last night. Tony, > thank you for tracking this down, that was a really good find. I don't think > I would have ever thought to look in the right place. > > Mike, is the issue settled? > > Darren > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
