matplotlib-devel Mailing List for matplotlib

On Wed, Jan 5, 2011 at 23:22, John Hunter <jd...@gm...> wrote:
> OK, I found the problem. Somehow my edit to sphinxext.plot_directive
> to actually call the new function was not saved and committed. I just
> fixed this, so the branch *should* work. The branch
> matlpotlib/sphinxext/plot_directive.py should call rc_file_defaults
> rather than rcdefaults. After an svn up, confirm that this is so
> before testing.
$ grep -c rc_file_defaults lib/matplotlib/sphinxext/plot_directive.py
0
so it's not there :(
and the only file containing rc_file_defaults is lib/matplotlib/__init__.py
of course, examples are stil stuck if no network to SF is available
Oh i think I got it, lib/matplotlib/sphinxext/plot_directive.py was
updated on trunk instead of the v1.0 branch.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 3:49 PM, Sandro Tosi <mo...@de...> wrote:
> On Wed, Jan 5, 2011 at 20:31, John Hunter <jd...@gm...> wrote:
>> On Wed, Jan 5, 2011 at 1:23 PM, Sandro Tosi <mo...@de...> wrote:
>>>
>>> On Wed, Jan 5, 2011 at 19:48, Sandro Tosi <mo...@de...> wrote:
>>> > ehm... no, I'm testing it the rc + your patch, sorry :) I'm updating
>>> > my local svn copy and try again
>>>
>>> Ok, I'm trying with trunk now (or those changes are on another
>>> branch?), and it stops at
>>
>>
>> We're working in the release branch. Changes have not been made to trunk.
>>
>> svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint
>> mpl1
>
> I tried with that branch, but I had no luck :( it still tries to
> download stuff from the net, whatever I set as examples.directory in
> matplotlibrc (yes, I'm trying to compile inside doc/ and I have
> 'examples.download : False' set) and/or MATPLOTLIB_SAMPLE_DATA . JFTR
> the cmdline I'm using is:
>
> morph@zion:~/deb/upstream_checkout/mpl1/doc$
> MATPLOTLIB_SAMPLE_DATA=/home/morph/deb/upstream_checkout/mpl1/sampledata/
> MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
> PYTHONPATH=../build/lib.linux-x86_64-2.6/ ./make.py --small all
>
> $ tail -2 matplotlibrc
> examples.download : False # False to bypass downloading mechanism
> examples.directory : /home/morph/deb/upstream_checkout/mpl1/sampledata/
OK, I found the problem. Somehow my edit to sphinxext.plot_directive
to actually call the new function was not saved and committed. I just
fixed this, so the branch *should* work. The branch
matlpotlib/sphinxext/plot_directive.py should call rc_file_defaults
rather than rcdefaults. After an svn up, confirm that this is so
before testing.
JDH

On Wed, Jan 5, 2011 at 23:07, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 4:04 PM, Sandro Tosi <mo...@de...> wrote:
>
>> it's not exactly monitory, but I disable all the requests to
>> matplotlib.svn.sourceforge.net via iptables:
>>
>> sudo iptables -A OUTPUT -d matplotlib.svn.sourceforge.net -j DROP
>>
>> and you're sure nothing passes towards that address :) and in fact,
>> the moment you reach an example with get_sample_data() it stops.
>
> That's helpful. I used to be an iptables guru, but it has been a long
> time. How do you reverse the command when you are done testing?
if you have only those rule, then just issue a
sudo iptables -F
to flus the whole iptables chains list rules; else, you have to:
sudo iptables -nL OUTPUT --line-numbers
take notes of the line number of those for MPL SF (the ip addresses are those in
$ host matplotlib.svn.sourceforge.net
matplotlib.svn.sourceforge.net has address 216.34.181.177
matplotlib.svn.sourceforge.net has address 216.34.181.65
)
and then remove them:
sudo iptables -D OUTPUT <line number above>
(note that if you delete a rules, the following ones have linenumber changed...)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 4:04 PM, Sandro Tosi <mo...@de...> wrote:
> it's not exactly monitory, but I disable all the requests to
> matplotlib.svn.sourceforge.net via iptables:
>
> sudo iptables -A OUTPUT -d matplotlib.svn.sourceforge.net -j DROP
>
> and you're sure nothing passes towards that address :) and in fact,
> the moment you reach an example with get_sample_data() it stops.
That's helpful. I used to be an iptables guru, but it has been a long
time. How do you reverse the command when you are done testing?
JDH

On Wed, Jan 5, 2011 at 23:00, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 3:49 PM, Sandro Tosi <mo...@de...> wrote:
>
>> I tried with that branch, but I had no luck :( it still tries to
>> download stuff from the net, whatever I set as examples.directory in
>> matplotlibrc (yes, I'm trying to compile inside doc/ and I have
>> 'examples.download : False' set) and/or MATPLOTLIB_SAMPLE_DATA . JFTR
>> the cmdline I'm using is:
>>
>> morph@zion:~/deb/upstream_checkout/mpl1/doc$
>> MATPLOTLIB_SAMPLE_DATA=/home/morph/deb/upstream_checkout/mpl1/sampledata/
>> MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
>> PYTHONPATH=../build/lib.linux-x86_64-2.6/ ./make.py --small all
>>
>> $ tail -2 matplotlibrc
>> examples.download : False # False to bypass downloading mechanism
>> examples.directory : /home/morph/deb/upstream_checkout/mpl1/sampledata/
>
>
> Strange -- I'll try and test tonight with a machine disconnected from
> the internet. Out of curiosity, what command/tool are you using to
> monitor the internet requests? Ben, are you seeing the same problems?
it's not exactly monitory, but I disable all the requests to
matplotlib.svn.sourceforge.net via iptables:
sudo iptables -A OUTPUT -d matplotlib.svn.sourceforge.net -j DROP
and you're sure nothing passes towards that address :) and in fact,
the moment you reach an example with get_sample_data() it stops.
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 3:49 PM, Sandro Tosi <mo...@de...> wrote:
> I tried with that branch, but I had no luck :( it still tries to
> download stuff from the net, whatever I set as examples.directory in
> matplotlibrc (yes, I'm trying to compile inside doc/ and I have
> 'examples.download : False' set) and/or MATPLOTLIB_SAMPLE_DATA . JFTR
> the cmdline I'm using is:
>
> morph@zion:~/deb/upstream_checkout/mpl1/doc$
> MATPLOTLIB_SAMPLE_DATA=/home/morph/deb/upstream_checkout/mpl1/sampledata/
> MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
> PYTHONPATH=../build/lib.linux-x86_64-2.6/ ./make.py --small all
>
> $ tail -2 matplotlibrc
> examples.download : False # False to bypass downloading mechanism
> examples.directory : /home/morph/deb/upstream_checkout/mpl1/sampledata/
Strange -- I'll try and test tonight with a machine disconnected from
the internet. Out of curiosity, what command/tool are you using to
monitor the internet requests? Ben, are you seeing the same problems?
JDH

On Wed, Jan 5, 2011 at 20:31, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 1:23 PM, Sandro Tosi <mo...@de...> wrote:
>>
>> On Wed, Jan 5, 2011 at 19:48, Sandro Tosi <mo...@de...> wrote:
>> > ehm... no, I'm testing it the rc + your patch, sorry :) I'm updating
>> > my local svn copy and try again
>>
>> Ok, I'm trying with trunk now (or those changes are on another
>> branch?), and it stops at
>
>
> We're working in the release branch. Changes have not been made to trunk.
>
> svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint
> mpl1
I tried with that branch, but I had no luck :( it still tries to
download stuff from the net, whatever I set as examples.directory in
matplotlibrc (yes, I'm trying to compile inside doc/ and I have
'examples.download : False' set) and/or MATPLOTLIB_SAMPLE_DATA . JFTR
the cmdline I'm using is:
morph@zion:~/deb/upstream_checkout/mpl1/doc$
MATPLOTLIB_SAMPLE_DATA=/home/morph/deb/upstream_checkout/mpl1/sampledata/
MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
PYTHONPATH=../build/lib.linux-x86_64-2.6/ ./make.py --small all
$ tail -2 matplotlibrc
examples.download : False # False to bypass downloading mechanism
examples.directory : /home/morph/deb/upstream_checkout/mpl1/sampledata/
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 1:31 PM, John Hunter <jd...@gm...> wrote:
> We're working in the release branch. Changes have not been made to trunk.
>
> svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint
> mpl1
>
rc2 tarball is here:
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1rc2.tar.gz/download

On Wed, Jan 5, 2011 at 1:23 PM, Sandro Tosi <mo...@de...> wrote:
>
> On Wed, Jan 5, 2011 at 19:48, Sandro Tosi <mo...@de...> wrote:
> > ehm... no, I'm testing it the rc + your patch, sorry :) I'm updating
> > my local svn copy and try again
>
> Ok, I'm trying with trunk now (or those changes are on another
> branch?), and it stops at
We're working in the release branch. Changes have not been made to trunk.
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint
mpl1
JDH

On Wed, Jan 5, 2011 at 19:48, Sandro Tosi <mo...@de...> wrote:
> ehm... no, I'm testing it the rc + your patch, sorry :) I'm updating
> my local svn copy and try again
Ok, I'm trying with trunk now (or those changes are on another
branch?), and it stops at
reading sources... [ 20%] examples/axes_grid/demo_axes_divider
while with RC it stops at
reading sources... [ 14%] examples/api/date_demo
6% improvements :D anyhow, the demo_axes_divider needs file
axes_grid/bivariate_normal.npy that's present in
../sampledata/axes_grid/bivariate_normal.npy so I don't know. John, is
trunk working for your? I'm blocking network access to MPL SF with
sudo iptables -A OUTPUT -d matplotlib.svn.sourceforge.net -j DROP
and when you need it back
sudo iptables -F
(I flush all the rules since I have only the one above).
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 19:45, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 12:10 PM, John Hunter <jd...@gm...> wrote:
>>
>> The code in matplotlib.cbook.get_sample_data reads:
>>
>>   if not matplotlib.rcParams['examples.download']:
>>     directory = matplotlib.rcParams['examples.directory']
>>     f = os.path.join(directory, fname)
>>     if asfileobj:
>>       return open(f, 'rb')
>>     else:
>>       return f
>>
>> So if the rc file is getting picked up and examples.download is set to
>> False, the code cannot reach the network as far as I can see.
>
> Just to ask an obvious question -- are you testing from svn branch. Because
> the bug is fixed there, not in the rc... I could cut an rc2, just want to
> make sure we are looking at the same code.
ehm... no, I'm testing it the rc + your patch, sorry :) I'm updating
my local svn copy and try again
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 12:10 PM, John Hunter <jd...@gm...> wrote:
>
> The code in matplotlib.cbook.get_sample_data reads:
>
> if not matplotlib.rcParams['examples.download']:
> directory = matplotlib.rcParams['examples.directory']
> f = os.path.join(directory, fname)
> if asfileobj:
> return open(f, 'rb')
> else:
> return f
>
> So if the rc file is getting picked up and examples.download is set to
> False, the code cannot reach the network as far as I can see.
>
Just to ask an obvious question -- are you testing from svn branch. Because
the bug is fixed there, not in the rc... I could cut an rc2, just want to
make sure we are looking at the same code.
JDH

On Wed, Jan 5, 2011 at 12:05 PM, Sandro Tosi <mo...@de...> wrote:
>
> yes, it's the version I'm going to use for the RC, that's because
> version 1.0.1~rc1-1 is lower than 1.0.1-1 (debian versions) and so
> uploading an RC package will not prevent for the final release to be
> uploaded (1.0.1rc1-1 is bigger than 1.0.1-1). Do you think that might
> be the problem?
>
>
I'm not sure -- tilde has special meanings in paths, eg ~jdhunter is my home
directory. But even if you had the wrong path, it should cause an error,
not an internet download. Are you running the doc build from the doc
directory. It is important that the cwd is doc when you start the doc
build.
The code in matplotlib.cbook.get_sample_data reads:
 if not matplotlib.rcParams['examples.download']:
 directory = matplotlib.rcParams['examples.directory']
 f = os.path.join(directory, fname)
 if asfileobj:
 return open(f, 'rb')
 else:
 return f
So if the rc file is getting picked up and examples.download is set to
False, the code cannot reach the network as far as I can see.

On Wed, Jan 5, 2011 at 18:57, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 11:48 AM, Sandro Tosi <mo...@de...> wrote:
>>
>> So you'll want to patch doc/matplotlibrc to set this param.
>>
>> ehm that's what I meant with "configuring doc/matplotlibrc" - I did that
>> :)
>>
>> $ tail -n2 doc/matplotlibrc
>> examples.download : False # False to bypass downloading mechanism
>> examples.directory :
>> /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
>>
>> and sampledata is .. from doc
>> /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
>
> Is that tilde in you path matplotlib-1.0.1~rc1 correct?
yes, it's the version I'm going to use for the RC, that's because
version 1.0.1~rc1-1 is lower than 1.0.1-1 (debian versions) and so
uploading an RC package will not prevent for the final release to be
uploaded (1.0.1rc1-1 is bigger than 1.0.1-1). Do you think that might
be the problem?
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 11:48 AM, Sandro Tosi <mo...@de...> wrote:
> So you'll want to patch doc/matplotlibrc to set this param.
>
> ehm that's what I meant with "configuring doc/matplotlibrc" - I did that :)
>
> $ tail -n2 doc/matplotlibrc
> examples.download : False # False to bypass downloading mechanism
> examples.directory :
> /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
>
> and sampledata is .. from doc
> /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
Is that tilde in you path matplotlib-1.0.1~rc1 correct?

On Wed, Jan 5, 2011 at 18:45, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <mo...@de...> wrote:
>>
>> > +def rc_file_defaults():
>> > +  """
>> > +  Restore the default rc params from the original matplotlib rc that
>> > +  was loaded
>> > +  """
>> > +  rcParams.update(rcParamsOrig)
>> > +
>> > _use_error_msg = """ This call to matplotlib.use() has no effect
>> > because the the backend has already been chosen;
>> > matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
>>
>>
>> I take the patch is not complete, right? because naively applying it
>> in a just-untarred source code + configuring doc/matplotlibrc don't
>> work (ie keeps trying accessing the net)
>>
>
>
> Well, that is the default behavior. You still have to untar, and set the
> examples.directory rc parameter as Ben discussed to do a no download doc
> build. So you'll want to patch doc/matplotlibrc to set this param.
ehm that's what I meant with "configuring doc/matplotlibrc" - I did that :)
$ tail -n2 doc/matplotlibrc
examples.download : False # False to bypass downloading mechanism
examples.directory : /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
and sampledata is .. from doc
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <mo...@de...> wrote:
> > +def rc_file_defaults():
> > + """
> > + Restore the default rc params from the original matplotlib rc that
> > + was loaded
> > + """
> > + rcParams.update(rcParamsOrig)
> > +
> > _use_error_msg = """ This call to matplotlib.use() has no effect
> > because the the backend has already been chosen;
> > matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
>
>
> I take the patch is not complete, right? because naively applying it
> in a just-untarred source code + configuring doc/matplotlibrc don't
> work (ie keeps trying accessing the net)
>
>
Well, that is the default behavior. You still have to untar, and set the
examples.directory rc parameter as Ben discussed to do a no download doc
build. So you'll want to patch doc/matplotlibrc to set this param.
JDH

On Wed, Jan 5, 2011 at 11:11 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben...@ou...> wrote:
>
>> On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...>wrote:
>>
>>> Not sure if this should hold the release but 1.0.1rc fails to run two
>>> examples (contourf_log.py and pcolor_log.py) as described in bug
>>> #3143748 "Math domain error in ticker.py is_decade()"
>>> <
>>> http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720
>>> >
>>>
>>> Christoph
>>>
>>> On 1/5/2011 5:36 AM, John Hunter wrote:
>>> > OK, I'm not aware of any outstanding issues that should hold this
>>> > release. If there are any, please let me know, else I'll upload the
>>> > final later today.
>>> >
>>> > On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
>>> > <mailto:mjl...@ya...>> wrote:
>>> >
>>> > Done.
>>> >
>>> > Thanks,
>>> > --Michiel.
>>> >
>>> >
>>>
>>>
>> The fix that was applied to the development branch should have also been
>> applied to the maintenance branch as well, but it appears that it wasn't.
>> The fix given in r8873 is correct, though. Adding the np.abs() fixes the
>> domain error. Taking the lx calculation out would mess things up for those
>> who are using various offsets for their plots.
>>
>> Although, looking at the code closer, I have to wonder if it is still
>> correct because of the "nearest_long()" function. Doesn't python already
>> have established rounding functions that should be used for these things?
>>
>> Anyway, I don't know why the tickers for the colorbars are wrong... the
>> contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py
>> code uses norm=LogNorm(). These are two different approaches, and the tick
>> labels are still wrong. Does anybody else have any insight on this?
>>
>> Ben Root
>>
>>
> Interesting... if I use format=ticker.LogFormatter(labelOnlyBase=False) in
> the call to colorbar, it works as expected. Even more interesting, if I use
> format=ticker.LogFormatterMathtext() or
> format=ticker.LogFormatterExponent(), it also works as expected (even though
> labelOnlyBase=True for those two...).
>
> btw, I would be nice if LogFormatterMathtext() was used instead of
> LogFormatter() for the default for colorbar. It appears that this is the
> case for regular plots, so I don't know why the same doesn't happen for
> colorbars (but that's for another day...).
>
> Ben Root
>
>
It appears that in the call for LogFormatter(), it calls is_decade(), while
LogFormatterExponent() and LogFormatterMathtext() are using
is_close_to_int() instead of is_decade(). Should LogFormatter() be changed
to use is_close_to_int() or was the use of is_close_to_int() a temporary
workaround with some issue in is_decade()?
Ben Root

Hi John,
On Wed, Jan 5, 2011 at 15:04, John Hunter <jd...@gm...> wrote:
> I agree the current behavior needs to be improved. I'm testing a change now
> which utilizes two functions, now properly documented, and removing the hack
> in the plot_directive since the file defaults will be preserved. This keeps
> the current behavior, since rcdefaults is unchanged, but fixes the doc
> string, and introduces a new function with the desired behavior.
thanks for working on it!
> Index: doc/matplotlibrc
> ===================================================================
> --- doc/matplotlibrc  (revision 8886)
> +++ doc/matplotlibrc  (working copy)
> @@ -232,7 +232,7 @@
>
> ### FIGURE
> # See http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure
> -figure.figsize  : 6, 4  # figure size in inches
> +figure.figsize  : 5.5, 4.5  # figure size in inches
> #figure.dpi    : 80   # figure dots per inch
> #figure.facecolor : 0.75  # figure facecolor; 0.75 is scalar gray
> #figure.edgecolor : white  # figure edgecolor
> Index: lib/matplotlib/__init__.py
> ===================================================================
> --- lib/matplotlib/__init__.py (revision 8886)
> +++ lib/matplotlib/__init__.py (working copy)
> @@ -762,6 +762,7 @@
>
> # this is the instance used by the matplotlib classes
> rcParams = rc_params()
> +rcParamsOrig = rcParams.copy()
>
> rcParamsDefault = RcParams([ (key, default) for key, (default, converter)
> in \
>           defaultParams.iteritems() ])
> @@ -843,11 +844,19 @@
>
> def rcdefaults():
>   """
> -  Restore the default rc params - the ones that were created at
> -  matplotlib load time.
> +  Restore the default rc params - these are not the params loaded by
> +  the rc file, but mpl's internal params. See rc_file_defaults for
> +  reloading the default params from the rc file
>   """
>   rcParams.update(rcParamsDefault)
>
> +def rc_file_defaults():
> +  """
> +  Restore the default rc params from the original matplotlib rc that
> +  was loaded
> +  """
> +  rcParams.update(rcParamsOrig)
> +
> _use_error_msg = """ This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
I take the patch is not complete, right? because naively applying it
in a just-untarred source code + configuring doc/matplotlibrc don't
work (ie keeps trying accessing the net)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 11:21 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jan 5, 2011 at 11:17 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> Very strange -- this is what I am doing for a clean build and install.
>> Can't see where I am going wrong...
>> I'm also having the same problem on two platofrms (python2.4 solaris,
>> python2.6 linux)
>>
>>
>> jdhunter@uqbar:mpl1> rm -rf build
>> ~/dev/lib/python2.6/site-packages/matplotlib* ~/.matplotlib/*cache*
>>
>
>
> I found the problem -- failed to flush mpl_toolkits for the clean install.
> Line should read:
>
>
> > rm -rf build ~/dev/lib/python2.6/site-packages/matplotlib*
> ~/.matplotlib/*cache* ~/dev/lib/python2.6/site-packages/mpl_toolkits/
>
> Sorry for the noise! Note to self -- start using virtualevn...
>
> JDH
>
>
No worries!
As a side note, I have been using:
python setupegg.py develop --user
for the past year with very few headaches. It makes an egg.lnk file (in the
~/.local directory) that points back to the current code directory. Some
things might get wonky with respect to things that have to be recompiled,
but for pure python changes, it works very nicely. I can't remember if it
works in RHEL5, though...
Ben Root

On Wed, Jan 5, 2011 at 11:17 AM, John Hunter <jd...@gm...> wrote:
>
>
> Very strange -- this is what I am doing for a clean build and install.
> Can't see where I am going wrong...
> I'm also having the same problem on two platofrms (python2.4 solaris,
> python2.6 linux)
>
>
> jdhunter@uqbar:mpl1> rm -rf build
> ~/dev/lib/python2.6/site-packages/matplotlib* ~/.matplotlib/*cache*
>
I found the problem -- failed to flush mpl_toolkits for the clean install.
Line should read:
> rm -rf build ~/dev/lib/python2.6/site-packages/matplotlib*
~/.matplotlib/*cache* ~/dev/lib/python2.6/site-packages/mpl_toolkits/
Sorry for the noise! Note to self -- start using virtualevn...
JDH

On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...> wrote:
>
>> Not sure if this should hold the release but 1.0.1rc fails to run two
>> examples (contourf_log.py and pcolor_log.py) as described in bug
>> #3143748 "Math domain error in ticker.py is_decade()"
>> <
>> http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720
>> >
>>
>> Christoph
>>
>> On 1/5/2011 5:36 AM, John Hunter wrote:
>> > OK, I'm not aware of any outstanding issues that should hold this
>> > release. If there are any, please let me know, else I'll upload the
>> > final later today.
>> >
>> > On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
>> > <mailto:mjl...@ya...>> wrote:
>> >
>> > Done.
>> >
>> > Thanks,
>> > --Michiel.
>> >
>> >
>>
>>
> The fix that was applied to the development branch should have also been
> applied to the maintenance branch as well, but it appears that it wasn't.
> The fix given in r8873 is correct, though. Adding the np.abs() fixes the
> domain error. Taking the lx calculation out would mess things up for those
> who are using various offsets for their plots.
>
> Although, looking at the code closer, I have to wonder if it is still
> correct because of the "nearest_long()" function. Doesn't python already
> have established rounding functions that should be used for these things?
>
> Anyway, I don't know why the tickers for the colorbars are wrong... the
> contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py
> code uses norm=LogNorm(). These are two different approaches, and the tick
> labels are still wrong. Does anybody else have any insight on this?
>
> Ben Root
>
>
Interesting... if I use format=ticker.LogFormatter(labelOnlyBase=False) in
the call to colorbar, it works as expected. Even more interesting, if I use
format=ticker.LogFormatterMathtext() or
format=ticker.LogFormatterExponent(), it also works as expected (even though
labelOnlyBase=True for those two...).
btw, I would be nice if LogFormatterMathtext() was used instead of
LogFormatter() for the default for colorbar. It appears that this is the
case for regular plots, so I don't know why the same doesn't happen for
colorbars (but that's for another day...).
Ben Root

On Wed, Jan 5, 2011 at 10:44 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>>
>>>
>>> I tried the naive fix in lines.py
>>>
>>> def set_axes(self, ax):
>>> Artist.set_axes(self, ax)
>>> if getattr(ax, 'xaxis', None):
>>> self._xcid = ax.xaxis.callbacks.connect('units',
>>> self.recache_always)
>>> if getattr(ax, 'yaxis', None) is not None:
>>> self._ycid = ax.yaxis.callbacks.connect('units',
>>> self.recache_always)
>>> set_axes.__doc__ = Artist.set_axes.__doc__
>>>
>>>
>>
>> Oops, type in my naieve fix. Should read
>>
>>
>> def set_axes(self, ax):
>> Artist.set_axes(self, ax)
>> if getattr(ax, 'xaxis', None) is not None:
>>
>> self._xcid = ax.xaxis.callbacks.connect('units',
>> self.recache_always)
>> if getattr(ax, 'yaxis', None) is not None:
>> self._ycid = ax.yaxis.callbacks.connect('units',
>> self.recache_always)
>> set_axes.__doc__ = Artist.set_axes.__doc__
>>
>> but the problem remains.
>>
>>
> Hmmm, let me check it out... I hope it wasn't one of my patches that did
> it....
>
> Ben Root
>
>
I initially had problems (although with the gtkagg backend...), but then I
moved my development branch build to another directory to effectively hide
it and then rebuilt the 1.0.1 branch, and everything worked fine. Maybe
there was something in the build process that got messed up?
Ben Root

On Wed, Jan 5, 2011 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>
>>
>> I tried the naive fix in lines.py
>>
>> def set_axes(self, ax):
>> Artist.set_axes(self, ax)
>> if getattr(ax, 'xaxis', None):
>> self._xcid = ax.xaxis.callbacks.connect('units',
>> self.recache_always)
>> if getattr(ax, 'yaxis', None) is not None:
>> self._ycid = ax.yaxis.callbacks.connect('units',
>> self.recache_always)
>> set_axes.__doc__ = Artist.set_axes.__doc__
>>
>>
>
> Oops, type in my naieve fix. Should read
>
>
> def set_axes(self, ax):
> Artist.set_axes(self, ax)
> if getattr(ax, 'xaxis', None) is not None:
>
> self._xcid = ax.xaxis.callbacks.connect('units',
> self.recache_always)
> if getattr(ax, 'yaxis', None) is not None:
> self._ycid = ax.yaxis.callbacks.connect('units',
> self.recache_always)
> set_axes.__doc__ = Artist.set_axes.__doc__
>
> but the problem remains.
>
>
Hmmm, let me check it out... I hope it wasn't one of my patches that did
it....
Ben Root

On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>
> I tried the naive fix in lines.py
>
> def set_axes(self, ax):
> Artist.set_axes(self, ax)
> if getattr(ax, 'xaxis', None):
> self._xcid = ax.xaxis.callbacks.connect('units',
> self.recache_always)
> if getattr(ax, 'yaxis', None) is not None:
> self._ycid = ax.yaxis.callbacks.connect('units',
> self.recache_always)
> set_axes.__doc__ = Artist.set_axes.__doc__
>
>
Oops, type in my naieve fix. Should read
 def set_axes(self, ax):
 Artist.set_axes(self, ax)
 if getattr(ax, 'xaxis', None) is not None:
 self._xcid = ax.xaxis.callbacks.connect('units',
self.recache_always)
 if getattr(ax, 'yaxis', None) is not None:
 self._ycid = ax.yaxis.callbacks.connect('units',
self.recache_always)
 set_axes.__doc__ = Artist.set_axes.__doc__
but the problem remains.