matplotlib-devel Mailing List for matplotlib (Page 6)

A fellow student approached me today wanting to know if matplotlib was able
to produce a certain kind of 3d plot where a filled contour was placed on
one of the axes panels. I knew it was possible with regular contours, but
was surprised when I realized that the same feature wasn't available for
contourf. So I wrote a patch to add that feature (and clean up a few
documentation-related things). I also added an example script with
examples/mplot3d/contourf3d_demo2.py.
This is the image produced by the example:
http://dl.dropbox.com/u/7325604/newcontourf3d.png
This was committed in r8915.
Enjoy!
Ben Root

Hi!
There is an example using ct.raw but it's not included in the
'sourcedata' tarball:
/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py:322:
PlotWarning: Exception running plot
/home/morph/deb/build-area/matplotlib-1.0.1/doc/mpl_examples/pylab_examples/image_demo2.py
Traceback (most recent call last):
 File "/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 319, in render_figures
 run_code(plot_path, function_name, plot_code, context=context)
 File "/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 230, in run_code
 "__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
 File "image_demo2.py", line 9, in <module>
IOError: [Errno 2] No such file or directory:
'/home/morph/deb/build-area/matplotlib-1.0.1/sampledata/ct.raw'
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing <ef...@ha...> wrote:
> On 01/12/2011 07:20 AM, Benjamin Root wrote:
> > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...
> > <mailto:jd...@gm...>> wrote:
> >
> > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> > > John,
> > >
> > > Just to clarify, have we officially released 1.0.1, or are we
> > still in the
> > > RC phase? If we haven't released yet, what is the deadline for
> final
> > > patches for 1.0.1?
> > >
> >
> > 1.0.1 is final but I held off on the announcement until Russel got
> the
> > OSX builds uploaded (which he did yesterday, but I still haven't
> > gotten to the announcement). If there are significant problems (eg
> > the 3D stuff you reported or other issues) I have no problem pushing
> > out 1.0.2 quickly.
> >
> > JDH
> >
> >
> > John,
> >
> > I am fine with letting 1.0.1 go out as is (unless we can't live with the
> > documentation typos that has shown up). I am also hesistant about
> > putting out yet another bug-fix release because there will be distros
> > that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which
> > would turn into a maintenance nightmare. Instead, let's just let those
> > package maintainers keep up with the patches to 1.0.1.
> >
> > This also raises a question. When putting out maintenance patches, are
> > we going to have to patch 1.0.0 and 1.0.1?
> >
> > I think what happened with 1.0.1 is that while there were some clear
> > goals (solidification of the backend codes and getting the no-download
> > doc feature working), it also became a bit of a free-for-all for
> > receiving other patches (I am guilty of this). Personally, I lost sight
> > of the point of the RCs and that is to seek out and squash only the
> > show-stopper bugs. Any other patches should not go in.
> >
> > Looking forward, I think there are a couple of things that we can do for
> > the next release (1.1.0?) that would be greatly beneficial. First, I
> > think having a clear and firm (but not set-in-stone) release date is
> > important. Second, release candidates should probably be made available
> > for a couple of weeks. Third, I think when it comes time for a release,
> > there should be at least one or two other developers agreeing on the
> > release (the purpose of this is to give a last-chance for any
> > objections, and to share the responsibility of the release). Last,
> > there should probably be clearer goals/milestones for the releases.
> >
> > I would appreciate any thoughts/comments on this. We can start up a new
> > thread if it is more appropriate.
> >
> > Ben Root
> >
>
> Ben,
>
> It sounds like what you are talking about is more like the way numpy has
> been working, complete with a release manager. Would you be willing and
> able to take on that role, along with all the other excellent work you
> have been doing? It would be a big step forward for mpl, I think.
>
> Eric
>
>
I agree, I think that is the direction MPL needs to go. We are
feature-packed, but still have a lot of rough edges. The prospect of being
a release manager is great, but it will depend on when we plan to release if
I will have enough time to devote to that.
Ben Root

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote:
> On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote:
> > I am fine with letting 1.0.1 go out as is (unless we can't live with the
>
> is already out: look at SF download page to see how many have downloaded
> it.
>
> > documentation typos that has shown up). I am also hesistant about
> putting
> > out yet another bug-fix release because there will be distros that will
> have
> > 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into
> a
> > maintenance nightmare. Instead, let's just let those package maintainers
> > keep up with the patches to 1.0.1.
> >
> > This also raises a question. When putting out maintenance patches, are
> we
> > going to have to patch 1.0.0 and 1.0.1?
>
> If you're saying you want to publish another tarball with version
> 1.0.1 that has different contents of the current one, than with my
> distro package maintainer and programmer hats on I say "you should
> not". If you have published (and not advertised, ok) something, you
> cannot re-publish the same version but with something "different" in
> it. Just go with 1.0.2, distros have (usually) the latest version and
> you are free to release patches in the HEAD of your development tree:
> it's a distro package maintainer evaluate if this patches are to be
> backported to the distro version, if the version cannot be bring
> up-to-date with the latest release.
>
> Cheers,
>
I believe we are actually in agreement, but perhaps I wasn't clear enough.
The maintenance patches that I speak of are committed in the v1_0_maint
branch of the svn repo. The tarball still has the original code from the
release point regardless of what patches have been committed since then.
Package maintainers can choose to cherry-pick those patches or even track
that maintenance branch for their own packaging purposes. The point is that
new features should not be added (unless absolutely necessary) and that old
features are not removed on that branch.
Please see our coding guide under "Committing Changes" (particularly the
last bullet):
> Keep the maintenance branch (0.91) the latest release branch (eg 0.98.4)
> and trunk in sync where it makes sense. If there is a bug on both that needs
> fixing, use svnmerge.py <http://www.orcaware.com/svn/wiki/Svnmerge.py> to
> keep them in sync.
>
So, back to the issue regarding whether to put out a 1.0.2 or not. We will
always be wanting to patch things (lord knows there are enough bugs...) and
at some point we have to say "it is good enough". Right now, my only major
qualm with the current 1.0.1 release has been the documentation (by the way,
the Coding Guide page looks terrible on my small screen). Code-wise, I am
willing to accept it as is and start focusing on 1.1.0.
Ben Root

On Wed, Jan 12, 2011 at 23:59, Sandro Tosi <mo...@de...> wrote:
> Hello MPL Devs,
>
> On Tue, Jan 4, 2011 at 20:13, Jakub Wilk <jw...@de...> wrote:
>> Package: python-matplotlib-doc
>> Version: 0.99.3-1
>> Severity: glitch
>> User: pyt...@li...
>> Usertags: sphinx1.0
>> Tags: patch
>>
>> See the attached patch.
>
> Jakub wrote a patch that fix the link from draw_markers() in
> api_change to its documentation. It's exploited when using sphinx1.x,
> I'm forwarding the patch to let it be applied upstream.
Now with attachment :)
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

forwarded 608939 mat...@li...
thanks
Hello MPL Devs,
On Tue, Jan 4, 2011 at 20:13, Jakub Wilk <jw...@de...> wrote:
> Package: python-matplotlib-doc
> Version: 0.99.3-1
> Severity: glitch
> User: pyt...@li...
> Usertags: sphinx1.0
> Tags: patch
>
> See the attached patch.
Jakub wrote a patch that fix the link from draw_markers() in
api_change to its documentation. It's exploited when using sphinx1.x,
I'm forwarding the patch to let it be applied upstream.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote:
> If you're saying you want to publish another tarball with version
> 1.0.1 that has different contents of the current one, than with my
> distro package maintainer and programmer hats on I say "you should
> not". If you have published (and not advertised, ok) something, you
> cannot re-publish the same version but with something "different" in
> it. Just go with 1.0.2, distros have (usually) the latest version and
> you are free to release patches in the HEAD of your development tree:
> it's a distro package maintainer evaluate if this patches are to be
> backported to the distro version, if the version cannot be bring
> up-to-date with the latest release.
Exactly, once we upload a version with a number, it is fixed. It
becomes really difficult to debug when two people think they are using
the same code and looking at different bases.

On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote:
> I am fine with letting 1.0.1 go out as is (unless we can't live with the
is already out: look at SF download page to see how many have downloaded it.
> documentation typos that has shown up). I am also hesistant about putting
> out yet another bug-fix release because there will be distros that will have
> 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a
> maintenance nightmare. Instead, let's just let those package maintainers
> keep up with the patches to 1.0.1.
>
> This also raises a question. When putting out maintenance patches, are we
> going to have to patch 1.0.0 and 1.0.1?
If you're saying you want to publish another tarball with version
1.0.1 that has different contents of the current one, than with my
distro package maintainer and programmer hats on I say "you should
not". If you have published (and not advertised, ok) something, you
cannot re-publish the same version but with something "different" in
it. Just go with 1.0.2, distros have (usually) the latest version and
you are free to release patches in the HEAD of your development tree:
it's a distro package maintainer evaluate if this patches are to be
backported to the distro version, if the version cannot be bring
up-to-date with the latest release.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 01/12/2011 07:20 AM, Benjamin Root wrote:
> On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
> On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
> > John,
> >
> > Just to clarify, have we officially released 1.0.1, or are we
> still in the
> > RC phase? If we haven't released yet, what is the deadline for final
> > patches for 1.0.1?
> >
>
> 1.0.1 is final but I held off on the announcement until Russel got the
> OSX builds uploaded (which he did yesterday, but I still haven't
> gotten to the announcement). If there are significant problems (eg
> the 3D stuff you reported or other issues) I have no problem pushing
> out 1.0.2 quickly.
>
> JDH
>
>
> John,
>
> I am fine with letting 1.0.1 go out as is (unless we can't live with the
> documentation typos that has shown up). I am also hesistant about
> putting out yet another bug-fix release because there will be distros
> that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which
> would turn into a maintenance nightmare. Instead, let's just let those
> package maintainers keep up with the patches to 1.0.1.
>
> This also raises a question. When putting out maintenance patches, are
> we going to have to patch 1.0.0 and 1.0.1?
>
> I think what happened with 1.0.1 is that while there were some clear
> goals (solidification of the backend codes and getting the no-download
> doc feature working), it also became a bit of a free-for-all for
> receiving other patches (I am guilty of this). Personally, I lost sight
> of the point of the RCs and that is to seek out and squash only the
> show-stopper bugs. Any other patches should not go in.
>
> Looking forward, I think there are a couple of things that we can do for
> the next release (1.1.0?) that would be greatly beneficial. First, I
> think having a clear and firm (but not set-in-stone) release date is
> important. Second, release candidates should probably be made available
> for a couple of weeks. Third, I think when it comes time for a release,
> there should be at least one or two other developers agreeing on the
> release (the purpose of this is to give a last-chance for any
> objections, and to share the responsibility of the release). Last,
> there should probably be clearer goals/milestones for the releases.
>
> I would appreciate any thoughts/comments on this. We can start up a new
> thread if it is more appropriate.
>
> Ben Root
>
Ben,
It sounds like what you are talking about is more like the way numpy has 
been working, complete with a release manager. Would you be willing and 
able to take on that role, along with all the other excellent work you 
have been doing? It would be a big step forward for mpl, I think.
Eric

On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...> wrote:
> > John,
> >
> > Just to clarify, have we officially released 1.0.1, or are we still in
> the
> > RC phase? If we haven't released yet, what is the deadline for final
> > patches for 1.0.1?
> >
>
> 1.0.1 is final but I held off on the announcement until Russel got the
> OSX builds uploaded (which he did yesterday, but I still haven't
> gotten to the announcement). If there are significant problems (eg
> the 3D stuff you reported or other issues) I have no problem pushing
> out 1.0.2 quickly.
>
> JDH
>
John,
I am fine with letting 1.0.1 go out as is (unless we can't live with the
documentation typos that has shown up). I am also hesistant about putting
out yet another bug-fix release because there will be distros that will have
1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a
maintenance nightmare. Instead, let's just let those package maintainers
keep up with the patches to 1.0.1.
This also raises a question. When putting out maintenance patches, are we
going to have to patch 1.0.0 and 1.0.1?
I think what happened with 1.0.1 is that while there were some clear goals
(solidification of the backend codes and getting the no-download doc feature
working), it also became a bit of a free-for-all for receiving other patches
(I am guilty of this). Personally, I lost sight of the point of the RCs and
that is to seek out and squash only the show-stopper bugs. Any other
patches should not go in.
Looking forward, I think there are a couple of things that we can do for the
next release (1.1.0?) that would be greatly beneficial. First, I think
having a clear and firm (but not set-in-stone) release date is important.
Second, release candidates should probably be made available for a couple of
weeks. Third, I think when it comes time for a release, there should be at
least one or two other developers agreeing on the release (the purpose of
this is to give a last-chance for any objections, and to share the
responsibility of the release). Last, there should probably be clearer
goals/milestones for the releases.
I would appreciate any thoughts/comments on this. We can start up a new
thread if it is more appropriate.
Ben Root

Benjamin Root, on 2011年01月11日 14:55, wrote:
> I am on the online version of the matplotlib documentation, and I am finding
> some artifacts of the Sphinx build.
> 
> For example there is ".. _gridspec-guide:" at the top of the page on
> http://matplotlib.sourceforge.net/users/gridspec.html
Hi Ben,
I sent a fix for the gridspec-guide anchor in a patch that
included a new gridspec example before I got commit rights, but
Jae-Joon wanted to examine it further before committing. I just
checked in the trivial fix for this in r8903.
> There is also a " `AxesGrid`_" in the last paragraph of this section:
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#what-is-axesgrid-toolkit
using 
 svn log doc/mpl_toolkits/axes_grid/users/overview.rst
to track down when this file changed, I saw that r8010 
 svn diff -r 8010 doc/mpl_toolkits/axes_grid/users/overview.rst
made a few changes of the instance AxesGrid to ImageGrid,
including a section title that went from being "Axes Grid" to
"Image Grid", so that's probably how the broken link happened.
I took care of it in r8094 just now.
Also, to preempt potential race condition on improving the docs -
I have a substantial fix-up of a bunch of typos in the docstrings
of mpl_toolkits/axes_grid1/ files that I'll check in later on
tonight or tomorrow.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...> wrote:
> John,
>
> Just to clarify, have we officially released 1.0.1, or are we still in the
> RC phase? If we haven't released yet, what is the deadline for final
> patches for 1.0.1?
>
1.0.1 is final but I held off on the announcement until Russel got the
OSX builds uploaded (which he did yesterday, but I still haven't
gotten to the announcement). If there are significant problems (eg
the 3D stuff you reported or other issues) I have no problem pushing
out 1.0.2 quickly.
JDH

I am on the online version of the matplotlib documentation, and I am finding
some artifacts of the Sphinx build.
For example there is ".. _gridspec-guide:" at the top of the page on
http://matplotlib.sourceforge.net/users/gridspec.html
There is also a " `AxesGrid`_" in the last paragraph of this section:
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#what-is-axesgrid-toolkit
I can probably fix these if these are the only ones, but I mention it here
in case anyone has a clue what happened (and where there might be others)
and knows how to fix it.
Ben Root

John,
Just to clarify, have we officially released 1.0.1, or are we still in the
RC phase? If we haven't released yet, what is the deadline for final
patches for 1.0.1?
Ben Root

Hi John,
On Thu, Jan 6, 2011 at 20:57, John Hunter <jd...@gm...> wrote:
> On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben...@ou...> wrote:
>> Ah, all the more reason to apply abspath() or realpath(). To decide which
>> to use, let's consider the case of someone (like a developer) having
>> multiple builds of matplotlib in separate directories, and uses a symlink to
>> point to whichever he wants to use at the moment.
>>
>> The question is, in this use-case, would we want the symbolic link pathname,
>> or the absolute pathname? I don't mess around with docs enough to know
>> which I would want.
>>
>> I have attached a modified patch (which uses realpath(), but could easily be
>> changed to abspath()). I also included some comments to more fully document
>> what is going on and the rational for the logic being taken.
>
> OK, I incorporated your changes and committed. Thanks.
Just to be sure: this patch is *not* in the released 1.0.1 tarball
(and it will be included in the next released version), is that
correct?
Anyhow, with a bit of hackery in our building process, I'm able to
prepare Debian packages without download anything from the net: thanks
a lot for your support throughout all the process!!
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 01/10/2011 08:02 AM, Benjamin Root wrote:
[...]
>
> My feeling is that for the purposes of 1.0.1, what you put together is
> good (although with those new functions underscored). I will then merge
> that over to the development branch. In the development branch, we can
> then make any additional design changes. As far as the 1.0.1 release
> goes, there really shouldn't be any new functionalities, only bug fixes
> for existing code.
Do you mean 1.0.2? John tagged 1.0.1 4 days ago, it is listed as 
available for download, and I see that a couple of Mac dmg versions were 
added within the last hour.
Eric
>
> Ben Root

On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt <
fri...@gm...> wrote:
> 2011年1月8日 Benjamin Root <ben...@ou...>:
> > The changes look ok to me so far. It looks to be mostly a
> re-organization
> > of existing logic and some consolidation of code. My only concerns are
> the
> > creation of two new functions. Besides the obvious issues with potential
> > namespace collisions in other parts of the code that might do an 'from cm
> > import *', my main issue is that these functions are probably really only
> > meant for internal use and should probably start with an underscore. We
> can
> > always un-underscore them in a later release...
>
> I agree on that the functions are kind of internal. Atm they do not
> reach their aim of generating cmaps from arbitrary specifications
> (generate_cmap can only handle known cmaps by name). It seems to me I
> was too fast and did not think it thoroughly through :-/.
>
> I'm not really satisfied with the current state of the patch with the
> informations you gave at hand. I wrote this patch as it is because I
> assumed functions like ``revcmap`` are supposed to stay
> backward-compatible.
>
>
Any existing function should remain backwards compatible, and so I have no
intention of putting an underscore on that one. Only on the new ones.
> If backward compatibility isn't an issue for this functions, so why
> not going ahead and rewriting the functions so that they deliver some
> useful functionality instead of only helping functionality. And if
> there are non-public stuff functions remaining, we could place an
> __all__ at the top of the file, to prevent them being imported by
> ``from cm import *``.
>
>
That might be a style issue that would be up to other maintainers.
Personally, at the very least, any function that is meant to be internal
should start with an underscore just to act as a flag to others. But then
using the __all__ approach gives the added benefit of making the
documentation cleaner.
> > I will do a bit more testing to see if I can break it, but barring that,
> I
> > will commit a slightly modified version of the patch later today.
>
> :-/ You are too fast for me.
>
>
Actually, I haven't committed anything yet. I have a bit of a backlog
here...
> In fact I think this functions belong to
> colors.LinearSegmentedColormap. Reversing should be a method of that
> one, and they should accept directly all kind of specifications at
> initialisation time.
>
>
Actually, I think it belongs down in Colormap. I don't see why this should
be limited to just LinearSegmentedColormap.
> So what parts should stay backwards compatible and which are we able to
> change?
>
> * Do we have to keep LinearSegmentedColormap.from_list() or should it
> be simply an alias for its __init__()?
> * What is the callable-functionality in cm.revcmap for? It can
> handle callable value items, but where's this used in mpl?
> * And, as said, do we have to keep this list-and-dicitionary mangling
> functions outside of LinearSegmentedColormap? I.e., can we replace it
> by reversing fully-fledged Colormaps, instead of reversing their
> tuple-or-dict specs?
>
>
My feeling is that for the purposes of 1.0.1, what you put together is good
(although with those new functions underscored). I will then merge that
over to the development branch. In the development branch, we can then make
any additional design changes. As far as the 1.0.1 release goes, there
really shouldn't be any new functionalities, only bug fixes for existing
code.
Ben Root

2011年1月8日 Benjamin Root <ben...@ou...>:
> The changes look ok to me so far. It looks to be mostly a re-organization
> of existing logic and some consolidation of code. My only concerns are the
> creation of two new functions. Besides the obvious issues with potential
> namespace collisions in other parts of the code that might do an 'from cm
> import *', my main issue is that these functions are probably really only
> meant for internal use and should probably start with an underscore. We can
> always un-underscore them in a later release...
I agree on that the functions are kind of internal. Atm they do not
reach their aim of generating cmaps from arbitrary specifications
(generate_cmap can only handle known cmaps by name). It seems to me I
was too fast and did not think it thoroughly through :-/.
I'm not really satisfied with the current state of the patch with the
informations you gave at hand. I wrote this patch as it is because I
assumed functions like ``revcmap`` are supposed to stay
backward-compatible.
If backward compatibility isn't an issue for this functions, so why
not going ahead and rewriting the functions so that they deliver some
useful functionality instead of only helping functionality. And if
there are non-public stuff functions remaining, we could place an
__all__ at the top of the file, to prevent them being imported by
``from cm import *``.
> I will do a bit more testing to see if I can break it, but barring that, I
> will commit a slightly modified version of the patch later today.
:-/ You are too fast for me.
In fact I think this functions belong to
colors.LinearSegmentedColormap. Reversing should be a method of that
one, and they should accept directly all kind of specifications at
initialisation time.
So what parts should stay backwards compatible and which are we able to change?
* Do we have to keep LinearSegmentedColormap.from_list() or should it
be simply an alias for its __init__()?
* What is the callable-functionality in cm.revcmap for? It can
handle callable value items, but where's this used in mpl?
* And, as said, do we have to keep this list-and-dicitionary mangling
functions outside of LinearSegmentedColormap? I.e., can we replace it
by reversing fully-fledged Colormaps, instead of reversing their
tuple-or-dict specs?
Friedrich

I just tried running a test in matplotlib and I got the following error:
======================================================================
ERROR: Failure: IOError ([Errno 2] No such file or directory:
'/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/lib/pymodules/python2.6/nose/loader.py", line 224, in generate
 for test in g():
 File
"/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/testing/decorators.py",
line 91, in compare_images_generator
 shutil.copyfile(src,dst)
 File "/usr/lib/python2.6/shutil.py", line 50, in copyfile
 with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory:
'/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png'
Anybody know anything about this particular test?
Ben Root

On Thu, Jan 6, 2011 at 10:20 AM, Friedrich Romstedt <
fri...@gm...> wrote:
> Hi Ben,
>
> nice to get a response. It's not an urgent patch, but should go in
> somwhen (imo). If you could take it and verify that it breaks nothing
> I would owe you a donut ;)
>
> Why OL?
>
> Here's the reference:
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/25103
> Notice that in the email from 18 Oct 14:55, I gave the wrong branch on
> GitHub, it's
> https://github.com/friedrichromstedt/matplotlib/tree/friedrichromstedt-get_cmap
> apparently (not "trunk" branch).
>
> Shall I add it to the bug tracker so that you can assign it maybe to
> yourself?
>
> I long for a matplotlib GitHub repo ... You might use the GitHub
> system to review the patch (it's more readable than a diff file I
> guess). Here's the link:
>
> https://github.com/friedrichromstedt/matplotlib/commit/1ac794b362d143ac6a634b70993d950d8fe4adeb
> .
>
> Feel free to go on-list, I did not snip away at your response so that
> the on-list history will be complete.
>
> Friedrich
>
> 2011年1月6日 Benjamin Root <ben...@ou...>:
> > On Mon, Jan 3, 2011 at 2:36 PM, Friedrich Romstedt
> > <fri...@gm...> wrote:
> >>
> >> 2010年10月19日 Friedrich Romstedt <fri...@gm...>:
> >> > The test suite passes except for some failures on my 10.6 Mac OS X
> >> > with yesterday checked-out astraw github repo. I'll send them in
> >> > another thread. Let's keep tidy :-) There's more than the symlog
> >> > error mentioned by LittleBigBrain on my sys.
> >> >
> >> > The failures are identical with and without the patch.
> >> >
> >> > Opinions?
> >>
> >> There has been no response, so I'm resending together with the patch
> >> file. The patch is created by $ git format-patch -1 on my old git
> >> branch from that time, and can be reapplied by:
> >>
> >> $ patch -p1 <0001-Fixing-bug-in-mpl.cm.get_cmap.patch
> >>
> >> I cannot test it against recent svn because my gcc on Mac OS X went
> >> havoc after restoring the system from Time Machine (the HDD crashed).
> >> Does anybody know what to do when it cannot find even stdarg.h ????
> >>
> >> That time the failures of the test suite did not increase by
> >> introducing the change. And it fixes LittleBigBrain's bug.
> >>
> >> Annotations from the git commit are in the patch file. I think it
> >> needs some thinking-through, although I did it carefully, to approve
> >> it.
> >>
> >> Btw what happened to the astraw github mirror? The latest commit on
> >> branch "trunk" is from November.
> >>
> >> Friedrich
> >>
> >
> > Friedrich,
> >
> > I don't know why you haven't gotten a response on this. I have not
> looked
> > into it at all though. Is it a patch that needs to go into 1.0.1? If
> so, I
> > can make sure it gets there.
> >
> > Ben Root
>
The changes look ok to me so far. It looks to be mostly a re-organization
of existing logic and some consolidation of code. My only concerns are the
creation of two new functions. Besides the obvious issues with potential
namespace collisions in other parts of the code that might do an 'from cm
import *', my main issue is that these functions are probably really only
meant for internal use and should probably start with an underscore. We can
always un-underscore them in a later release...
I will do a bit more testing to see if I can break it, but barring that, I
will commit a slightly modified version of the patch later today.
Ben Root
P.S. - As for going off-list in my last email, that was an 'oops'.

Hello,
I have been noticing odd behaviors when plotting polygons and surfaces using
mplot3d. Some polygon faces were being slightly transparent, for example
when you rotate the sphere in the 'surface3d_demo2.py' example. Some faces
were completely missing, for example in the 'hist3d_demo.py' example. In
the surface3d_demo3.py example, I wasn't fully happy with the appearance of
the plot and I was fairly sure it wasn't 100% correct.
I believe I have the problem tracked down to the "_shade_colors()" method in
axes3d.py. I have a patch and it needs to be applied to both the
development branch and one for the release candidate. However, I am almost
certain that it could break some others 3d display code and I would like
people to check it out first before it gets applied.
The 'mplot3d_vectshade.patch' can be used against the current development
branch, while 'mplot3d_vectshade_rc2.patch' can be used against the latest
in the maintenance branch.
Thanks, and I would greatly appreciate your input!
Ben Root

2010年12月18日 TRINATH ATMAKURI <tod...@gm...>:
> As part of Scipy India sprint I wrote a code for Sierpinski's gasket. I
> uploaded the file at the website http://gist.github.com. The URL of the
> code is:
>
>  https://gist.github.com/746409
>
> Please let me know if i need to made any changes before this is accepted.
Hi Trinath,
worksforme - and I like it. Was there some fractal stuff at SciPy India?
Friedrich
P.S.: (Make sure to "reply to all" if necessary.)

On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben...@ou...> wrote:
> Ah, all the more reason to apply abspath() or realpath(). To decide which
> to use, let's consider the case of someone (like a developer) having
> multiple builds of matplotlib in separate directories, and uses a symlink to
> point to whichever he wants to use at the moment.
>
> The question is, in this use-case, would we want the symbolic link pathname,
> or the absolute pathname? I don't mess around with docs enough to know
> which I would want.
>
> I have attached a modified patch (which uses realpath(), but could easily be
> changed to abspath()). I also included some comments to more fully document
> what is going on and the rational for the logic being taken.
OK, I incorporated your changes and committed. Thanks.
> P.S. - Just to make sure, I noticed that rcParamsOrig is only in the
> maintenance branch. It was intended to leave the development branch
> "broken" for now until we get this working properly?
That's correct, but I just did a big merge of all the branch changes
so the trunk is fixed as well now.
JDH

On Thu, Jan 6, 2011 at 12:32 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Jan 6, 2011 at 12:22 PM, John Hunter <jd...@gm...> wrote:
>
> > matplotlib_fname() always returns absolute path. I have not used
> > realpath, but if you think there is a use for it here, feel free to
> > post an amended patch.
>
> There is an exception to this -- if MATPLOTLIBRC or MPLCONFIGDIR are
> relative paths, then matplotlib_fname will return a relative path too.
>
Ah, all the more reason to apply abspath() or realpath(). To decide which
to use, let's consider the case of someone (like a developer) having
multiple builds of matplotlib in separate directories, and uses a symlink to
point to whichever he wants to use at the moment.
The question is, in this use-case, would we want the symbolic link pathname,
or the absolute pathname? I don't mess around with docs enough to know
which I would want.
I have attached a modified patch (which uses realpath(), but could easily be
changed to abspath()). I also included some comments to more fully document
what is going on and the rational for the logic being taken.
Ben Root
P.S. - Just to make sure, I noticed that rcParamsOrig is only in the
maintenance branch. It was intended to leave the development branch
"broken" for now until we get this working properly?

On Thu, Jan 6, 2011 at 12:22 PM, John Hunter <jd...@gm...> wrote:
> matplotlib_fname() always returns absolute path. I have not used
> realpath, but if you think there is a use for it here, feel free to
> post an amended patch.
There is an exception to this -- if MATPLOTLIBRC or MPLCONFIGDIR are
relative paths, then matplotlib_fname will return a relative path too.