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
Are the docs built with a custom .matplotlibrc? Maybe there's a
different setting there that's triggering a bug...
Cheers,
f
···
On Mon, Jul 7, 2008 at 9:19 AM, Michael Droettboom <mdroe@...31...> wrote:
One other tidbit of information -- the example plots work fine when
called directly. This only seems to affect plots generated for the docs.
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 <mdroe@...31...> 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
But it's different from *your* user rc file. That might point to the
setting that causes the problem...
f
···
On Mon, Jul 7, 2008 at 10:14 AM, Michael Droettboom <mdroe@...31...> wrote:
Yes, but curiously, it doesn't change between those revisions...
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:
matplotlib download | SourceForge.net
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
···
On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote:
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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 <mdroe@...31...> 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
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:
matplotlib download | SourceForge.net
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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
···
On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <mdroe@...31...> 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?
Fernando Perez 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
···
On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <mdroe@...31...> wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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
···
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 <mdroe@...31...> 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.
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 <mdroe@...31...> >>> > 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