matplotlib-devel Mailing List for matplotlib (Page 4)

On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> <fri...@gm...> wrote:
> > Hi,
> >
> > I want to set up a git mirror for matplotlib, but I 1) have some minor
> > problems and 2) want to know what others think about this.
>
> Late last year, I did some work to convert the svn repository to git.
> The code to d the conversion is available at
> https://github.com/darrendale/mpl2git . The resulting git repo is
> available at https://github.com/darrendale/matplotlib . I have not
> pursued the project further because there did not seem to be enough
> interest in migrating from svn/sourceforge to git/github to justify
> investing more of my time in the project.
>
> > I'm a native git user and I don't know how to use svn properly.
>
> I read that as "uninterested in learning how to use svn", and such
> sentiment is probably a fact of life as many (most?) open source
> projects move to DVC. In my opinion, matplotlib is likely to draw more
> contributors if it lowers barriers to entry and uses a DVCS that is
> growing in popularity, like git/github.
>
> Darren
>
>
In discussions with Ryan May on the prospect of switching over to git, it
sounds like we have a "Bike Shed" problem where we (the main developers)
agree that we agree that a bike shed should be built, but we can't agree on
the color to paint it...
I think the main source of the huge download size is the data that is coming
from the basemap toolkit. I do not think that it would be a good thing to
have everyone and their mother needing to do a 'git clone' on their computer
and find they have to pull down 500+ MB of stuff to get matplotlib. It is
because of this that a straight-forward migration from svn to matplotlib
won't be possible.
What have been the proposed solutions to dealing with basemap's data?
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.
>
> 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
>
Finally got around to committing this. I committed it to the maintenance
branch in r8933 and merged into the development branch in r8934.
Ben Root

On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
<fri...@gm...> wrote:
> Hi,
>
> I want to set up a git mirror for matplotlib, but I 1) have some minor
> problems and 2) want to know what others think about this.
Late last year, I did some work to convert the svn repository to git.
The code to d the conversion is available at
https://github.com/darrendale/mpl2git . The resulting git repo is
available at https://github.com/darrendale/matplotlib . I have not
pursued the project further because there did not seem to be enough
interest in migrating from svn/sourceforge to git/github to justify
investing more of my time in the project.
> I'm a native git user and I don't know how to use svn properly.
I read that as "uninterested in learning how to use svn", and such
sentiment is probably a fact of life as many (most?) open source
projects move to DVC. In my opinion, matplotlib is likely to draw more
contributors if it lowers barriers to entry and uses a DVCS that is
growing in popularity, like git/github.
Darren

On Tue, Jan 18, 2011 at 12:27 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Dear Matplotlib developers,
>
> Attached is a patch to improve the functionality of legend.
> The two biggest changes are as follows,
>
> * Drawing of legend is delegated to "legend handlers".
> * Introduces a new "Container" class. This is primarily to support
> legend of complex plots (e.g., bar, errorbar, etc).
>
> The first change is to ease the creation of customized legends. See
> "legend_demo_custom_handler.py" for example.
> The second change is to support legend of complex plots. Axes
> instances now have a "containers" attribute. And this is only intended
> to be used for generating a legend. For example, "bar" plots create a
> series of Rectangle patches. Previously, it returned a list of these
> patches. With the current change, it creates a container object of
> these rectangle patches and return it instead. As the container class
> is derived from a tuple, it should be backward-compatible.
> Furthermore, the container object is added to the Axes.containers
> attributes. And legend command use this "container" attribute to
> properly create a legend for the bar.
>
> A two example figures are attached.
>
> As this patch introduces relatively significant changes. I wanted to
> get some comments from others before I commit.
> The change will be divided into four commits.
>
> Regards,
>
> -JJ
>
>
Nice. I will look through it this week and see if I can break it.
Ben Root

Hi,
I want to set up a git mirror for matplotlib, but I 1) have some minor
problems and 2) want to know what others think about this.
I'm a native git user and I don't know how to use svn properly. So I
try everything to avoid svn. Furthermore, I like git so much that I
don't want to give it up when developing for matplotlib.
As is well-known, there *is* already a git mirror for mpl, using
svnmerge.py, i.e., http://github.com/astraw/matplotlib. Anyway, this
repo seems to be not actively maintained for monthes. The last comit
on branch trunk is from Nov 12, 2010.
Yesterday I tried git-svn on the matplotlib sf repo, and it took quite
a long time (already ~500 MB), but it stopped with some error message:
RA layer request failed: REPORT of
'/svnroot/matplotlib/!svn/vcc/default': SSL negotiation failed:
Connection reset by peer (https://matplotlib.svn.sourceforge.net) at
/usr/local/libexec/git-core/git-svn line 5061
I could imagine the sf server treated me as some DoS user.
I attach a part of the log of how I initialised the git repo (without
the middle part), and also some tees of $git branch -a and $git log
trunk | head -n 150.
I realised that I used different options to git svn init (i.e., I used
--std-layout) than stated on
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git,
but I cannot see why I should use --trunk=trunk/matplotlib
--prefix=svn/. From the logs of $git svn fetch, it looks good.
If there is no feedback until today eve here in Germany (in ~6 hrs),
I'll try again today evening to $git svn fetch some more of the repo.
If there is positive feedback, I'll consider writing to the github
guys to give me ~2 Gigs of storage for the mirror. If there is
negative feedback, I'll consider giving the project up. Note, that it
is inevitable for me to publish the mirror when Ben and I want to use
it (for some project we have since a few monthes on mpl).
I would suggest to always put git changes *on top* of svn changes, so
no use of $git merge trunk, but always $git rebase. This is the only
way to make usable diffs which can go in into svn on sf as far as I
can see.
There is a general problem which will pertain all git users: Once the
changes went via svn into the sf repo, they reappear on the github
mirror, causing conflicts in the branches on github where they
originally came from. The solution to this would be clear, but I
think there will be no way to get a consensus to switch from svn to
git on mpl completely.
Friedrich

etc for producing images at various scales)
Reply-To: 
In-Reply-To: <20110121232036.GA26739@ykcyc>
X-PGP-Key: http://pirsquared.org/PaulIvanov0F3E28F7.asc
Paul Ivanov, on 2011年01月21日 15:20, wrote:
> I'm almost certain that one *can* write a function to do this
> pro grammatically (without having to hand tweak anything), by
> looking at say, the .get_window_extent() but I haven't found the
> time to scratch that itch, yet.
> 
> If someone wants to beat me to it, here's the sort of thing that
> you can do:
> 
> def show_labels_by_shrinking(ax):
> " adjust subplot parameters to fit the yaxis label"
> f = ax.figure
> textwidth = ax.yaxis.get_label().get_window_extent().width
> labelwidth = max([lab.get_window_extent().width for lab in ax.get_yticklabels()])
> plt.subplots_adjust(left=(textwidth+labelwidth+3*ax.yaxis.labelpad)/f.get_window_extent().width)
> # the 3 *ax.yaxis.labelpad is just a fudge factor for now, need
> # to look into the sourcecode to figure out what the
> # appropriate placement is normally, to know how to adjust
> # properly
> 
> 
> ax.set_ylabel('foo')
> show_labels_by_shrinking(ax)
> ax.set_ylabel("a\nmulti\nline\nexample")
> show_labels_by_shrinking(ax)
I should add that along with doing a similar thing for the xaxis,
this would need to be extended for the multiple subplot case, to
also adjust the wspace and hspace parameters accordingly. 
this is important functionality currently missing from matplotlib
out-of-the-box at the moment, so I'll try my crack at it this out
this weekend. 
CCing the devel list in case someone has more opinions.
best, 
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

2011年1月17日 Eoghan Harrington <eo...@gm...>
> Hi,
>
> I noticed some erroneous behaviour when using a
> LinearSegmentedColormap with an "under" color and different numbers of
> color levels. The attached script replicates the behaviour, whereby
> lowering the number of colors causes less of the values to be
> considered "under" the vmin. I tracked the problem back to the
> Colormap class where the results of Normalize are multiplied by the
> number of color levels (N) and casted as an int to be used as indices
> in the color array. The expected behaviour would be that all negative
> values should be considered "under", however the results of the cast
> means that anything between 0 and -0.5 will be set to 0 and therefore
> will be in the normal color range for the colormap. The attached patch
> overcomes this by setting all negative values to -1 before applying
> the cast.
>
> Thanks for your help,
> Eoghan
>
>
Thanks for catching this one. Blindly casting to int is wrong (which has a
problem for values between -1 and 0, not just -0.5 and 0). This has been
committed in v1_0_maint as r8931 and in the development trunk as r8932.
Ben Root

On Sat, Jan 8, 2011 at 6:36 PM, Benjamin Root <ben...@ou...> wrote:
> 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
>
Re-pinging this question....
Ben Root

-- In the process of clearing out patch backlog --
This patch has been committed to the trunk in r8930. I am not going to
commit this to 1.0.x unless I am absolutely certain that this patch doesn't
break any other use-cases.
Ben Root
On Fri, Jan 7, 2011 at 9:28 PM, Benjamin Root <ben...@ou...> wrote:
> 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
>
>
>

Binaries:
Build with static libs from most recent source distribution. Since we
want a click-and-working installer, it's not effordable to request
installing X11 (10.4) or similar.
Home Builds:
Libraries:
1) From X11. Seems to be the most simple way.
2) From most recent source distribution. Where to install? Maybe:
Static linkage against libraries built and installed in the mpl build
dir. This would avoid overwriting the user's system-wide libraries.
It would also have the advantage to support non-root builds.
3) From binary distribution package including just those libraries.
This seems not a bright idea.
4) From separately user-compiled and system wide installed source
distributions of the libraries.
X11:
10.3.9: ??
10.4: Looks like that X11 has to be opted in. (John)
10.5: Unknown
10.6: X11 very much probably included (opt-out at OS install point).
Installed in /usr/X11/lib/. (Friedrich)
=> A build system should detect the native OS X libraries (way (1)).
If they are not present, it's up to the user to decide what to do, if
to go route (2), (3), or (4). Build system could use Paver (as numpy
does).
Friedrich

Hi,
I feel your pain on the issue of eggs...
> - Is there some way to name the eggs to disambiguate between 32-bit
> Python 2.7 (which works on all versions of Mac OS X) and 64-bit Python
> 2.7 (which only works on 10.6) that is compatible with easy_install?
> In the past if the eggs had strange names easy_install misbehaved.
When I built the readline package on the Mac, I ran into similar
issues. To keep things simple (or so I thought), I built one universal
egg. On Leopard with Apple Python 2.5 (see
http://pypi.python.org/pypi/readline/2.5.1) and the setuptools at the
time (May 2008), the egg was named *-fat.egg. Since there is no
architecture called "fat", easy_install refused to select it for
installation. So I renamed it to the explicit architectures
(*-i386.egg, *-ppc.egg, *-ppc64.egg, *-x86_64.egg), but this was
another saga, since PyPI refused to upload identical files with
different names. I then tweaked each egg slightly to bypass this...
Very silly, as you can see.
The latest version of the readline package
(http://pypi.python.org/pypi/readline) has an egg for Leopard and Snow
Leopard built against the default Apple Python on each system. On Snow
Leopard and Python 2.6, the egg is now called *-universal.egg and
seems to work with the latest easy_install. To avoid repeating the
silly tweaking of eggs, I renamed the Leopard *-fat.egg to *-i386.egg
only, as that is pretty much the dominant architecture which will keep
most easy_install users happy (70% of the downloads of the 2.5.1
Leopard version with four eggs picked the i386 egg).
To get back to your question, I would venture something like
matplotlib-1.0.1-py2.7-macosx-10.3-i386.egg and
matplotlib-1.0.1-py2.7-macosx-10.6-x86_64.egg (ditto for the ppc
architectures).
Regards,
Ludwig
P.S.
> So my recommendation is not to Python 2.5 on a Mac.
I have been running matplotlib on Apple Python 2.5 on Leopard mostly
with the TkAgg backend (on Apple Tk) for a few years now - maybe it's
time to upgrade ;-)

Hi all,
I'm fighting against this weirdness since some days: if I build mpl
debian package on my system, it builds normally, but if I build the
package in a clean chroot it fails, and I only noticed because I want
to create a link in doc/build/html/_static dir, that's missing. and
I'm wondering why! I can't seem to find a clear answer to that, so I'm
asking for any advice yo might have.
The full log of the package build in the chroot is at [1] (it's quite
large expanded); at the end of the file there are some ls -lR to try
to identify what's going wrong.
[1] http://people.debian.org/~morph/matplotlib_1.0.1-1_amd64.build.bz2
Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

=========================
Announcing EuroScipy 2011
=========================
---------------------------------------------
The 4th European meeting on Python in Science
---------------------------------------------
**Paris, Ecole Normale Supérieure, August 25-28 2011**
We are happy to announce the 4th EuroScipy meeting, in Paris, August
2011.
The EuroSciPy meeting is a cross-disciplinary gathering focused on
the use and development of the Python language in scientific
research. This event strives to bring together both users and
developers of scientific tools, as well as academic research and
state of the art industry.
Main topics
===========
- Presentations of scientific tools and libraries using the
 Python language, including but not limited to:
 - vector and array manipulation
 - parallel computing
 - scientific visualization
 - scientific data flow and persistence
 - algorithms implemented or exposed in Python
 - web applications and portals for science and engineering.
- Reports on the use of Python in scientific achievements or ongoing
 projects.
- General-purpose Python tools that can be of special interest to the
 scientific community.
Tutorials
=========
There will be two tutorial tracks at the conference, an introductory one,
to bring up to speed with the Python language as a scientific tool, and
an advanced track, during which experts of the field will lecture on
specific advanced topics such as advanced use of numpy, scientific
visualization, software engineering...
Keynote Speaker: Fernando Perez
===============================
We are excited to welcome Fernando Perez (UC Berkeley, Helen Wills
Neuroscience Institute, USA) as our keynote speaker. Fernando Perez
is the original author of the enhanced interactive python shell
IPython and a very active contributor to the Python for Science
ecosystem.
Important dates
===============
Talk submission deadline: Sunday May 8
Program announced: Sunday May 29
Tutorials tracks: Thursday August 25 - Friday August 26
Conference track: Saturday August 27 - Sunday August 28
Call for papers
===============
We are soliciting talks that discuss topics related to scientific
computing using Python. These include applications, teaching, future
development directions, and research. We welcome contributions from
the industry as well as the academic world. Indeed, industrial
research and development as well academic research face the
challenge of mastering IT tools for exploration, modeling and
analysis. We look forward to hearing your recent breakthroughs
using Python!
Submission guidelines
=====================
- We solicit talk proposals in the form of a one-page long abstract.
- Submissions whose main purpose is to promote a commercial product or
 service will be refused.
- All accepted proposals must be presented at the EuroSciPy conference
 by at least one author.
The one-page long abstracts are for conference planing and selection
purposes only. We will later select papers for publication of
post-proceedings in a peer-reviewed journal.
How to submit an abstract
=========================
To submit a talk to the EuroScipy conference follow the instructions
here:
http://www.euroscipy.org/card/euroscipy2011_call_for_papers
Organizers
==========
Chairs:
 - Gaël Varoquaux (INSERM, Unicog team, and INRIA, Parietal team)
 - Nicolas Chauvat (Logilab)
Local organization committee:
 - Emmanuelle Gouillart (Saint-Gobain Recherche)
 - Jean-Philippe Chauvat (Logilab)
Tutorial chair:
 - Valentin Haenel (MKP, Technische Universität Berlin)
Program committee:
 - Chair: Tiziano Zito (MKP, Technische Universität Berlin)
 - Romain Brette (ENS Paris, DEC)
 - Emmanuelle Gouillart (Saint-Gobain Recherche)
 - Eric Lebigot (Laboratoire Kastler Brossel, Université Pierre et
 Marie Curie)
 - Konrad Hinsen (Soleil Synchrotron, CNRS)
 - Hans Petter Langtangen (Simula laboratories)
 - Jarrod Millman (UC Berkeley, Helen Wills NeuroScience institute)
 - Mike Müller (Python Academy)
 - Didrik Pinte (Enthought Inc)
 - Marc Poinot (ONERA)
 - Christophe Pradal (CIRAD/INRIA, Virtual Plantes team)
 - Andreas Schreiber (DLR)
 - Stéfan van der Walt (University of Stellenbosch)
Website
=======
http://www.euroscipy.org/conference/euroscipy_2011

I have not built modern versions of matplotlib for python.org's Python 
2.5 because its Tcl/Tk support is badly broken such that any attempt 
to use a "reasonable" version of Tcl/Tk (e.g. ActiveState 8.4.19) will 
cause segfaults. Perhaps I am being unreasonable but:
- I use Tcl/Tk extensively so I care about it a lot
- Segfaults are frustrating for everybody and reflect badly on 
matplotlib (however unfairly)
The Tcl/Tk 8.4 included by Apple in all versions of its OS to date has 
is old and buggy. (Even the last version of 8.4 -- 8.4.19 -- has bugs, 
but it's a lot better than Apple's version). Hence it is important for 
users to be able to upgrade without getting segfaults.
So my recommendation is not to Python 2.5 on a Mac.
Regarding binary eggs for matplotlib, I suspect there are issues that 
will make easy_install not work well:
- The builder script setupegg.py does not seem to include dependency 
information. I found setupegg.py a bit confusing so I may have missed 
something. But if the dependencies are missing, surely this is a bug?
- Is there some way to name the eggs to disambiguate between 32-bit 
Python 2.7 (which works on all versions of Mac OS X) and 64-bit Python 
2.7 (which only works on 10.6) that is compatible with easy_install? 
In the past if the eggs had strange names easy_install misbehaved.
Also setup.cfg is a bit of a pain when making distributions because:
- The default back end is Agg instead of TkAgg. Surely it should be 
TkAgg if Tkinter is present in the Python?
- For binary installers your desire is to include pytz and dateutil in 
the distribution. But for eggs your desire is to exclude them and list 
them as dependencies instead. I think these are reasonable rules, but 
they're not the default. Instead one has to edit setup.cfg one way for 
binary distributions and another way for eggs. That makes building 
releases more error-prone.
I do realize that in the long term you'd be better off with only one 
kind of binary: eggs or binary installers (presumably eggs). But 
unless easy_install has improved a lot I don't think we're there yet.
Regards,
-- Russell
On Jan 20, 2011, at 9:07 AM, John Hunter wrote:
> On Thu, Jan 20, 2011 at 10:23 AM, Jeffrey Wong <jef...@gm...> 
> wrote:
>> On Jan 20, 2011, at 6:14 AM, John Hunter wrote:
>>
>>> On Thu, Jan 20, 2011 at 2:50 AM, Jeffrey Wong <jef...@gm...> 
>>> wrote:
>>>> Hi,
>>>>
>>>> I tried to install matplotlib on python 2.7 and use the graph 
>>>> drawing functionality with NetworkX (nodes and edges).
>>>>
>>>> easy_install and pip both think that the latest version is 
>>>> 0.91.1, which is wrong because it will import numpy.core.ma 
>>>> instead of numpy.ma.
>>>>
>>>>
>>>> I'm not sure how to fix this but PyPI lists you as the maintainer 
>>>> so I thought you might know.
>>>>
>>>> Thanks for putting it in PyPI anyhow!
>>>
>>> CC-ing the devel list.
>>>
>>> It's not clear to me why this is -- I have 1.0.1 as the active 
>>> version
>>> on pypi, which is reflected on http://pypi.python.org/pypi/matplotlib
>>> and the download URL is listed as
>>>
>>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>>>
>>> 0.91.1 is flagged as hidden. I am not a pypi expert, but don't see
>>> anything wrong here,
>>
>>
>> I can't use my python 2.7 to reproduce the problem since I 
>> installed matplotlib manually using the MacOS X Python 2.7 dmg/ 
>> installer.
>> It now sees matplotlib 1.0.1-r0 as current.
>>
>> However with the system python 2.5, it makes the following search:
>>
>> emcs-imac:Facethingy jeffwong$ /usr/bin/easy_install -n matplotlib
>> Searching for matplotlib
>> Reading http://pypi.python.org/simple/matplotlib/
>> Reading http://matplotlib.sourceforge.net
>> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0
>> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3/
>> Reading http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
>> Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
>> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
>> Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
>> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
>> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>> Best match: matplotlib 0.91.1
>> Downloading http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.1.tar.gz#md5 
>> =56a9344b077b5accbc4823be19f69dd6
>> ^Cinterrupted
>> emcs-imac:Facethingy jeffwong$
>>
>>
>> Perhaps someone sees something obviously wrong with this...
>
> I see -- we have seen problems with this before. It is very difficult
> to get eggs names properly for OSX that are recognized. We have
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1_r0-py2.7-macosx-10.3-fat.egg/download
>
> My guess is that the "_r0" or "10.3" in the name is breaking the 
> matching rule
>
> JDH

On Thu, Jan 20, 2011 at 1:25 AM, Eric Firing <ef...@ha...> wrote:
> On 01/19/2011 07:25 PM, Jae-Joon Lee wrote:
> > Big thank you for correcting those typos where virtually all of them are
> mine.
> >
> > I'm +1 for backporting these changes as they will not break anything.
> > But others may have different ideas.
>
> I'm roughly neutral; I would only caution that when backporting, one
> needs to tell svnmerge about it. Something like:
>
> svnmerge merge -S v1 -r NUM --record-only
> svn commit -F svnmerge-commit-message.txt
>
> where you are in your trunk checkout, and NUM is the revision in which
> you did the backporting.
>
> Eric
>
>
My vote is to backport those fixes. This way, distro maintainers can
release a patch for the docs if they wish, and anyone else checking out the
maintenance releases would get those fixes for their docs. I personally
have a few fellow students who I set them up with matplotlib built from the
maintenance branch.
Also, if -- and this is a *big* if -- we decide to release another bugfix
release, the docs will be ready to go.
Ben Root
P.S. - Good to know that is how to do a backport using svnmerge. Maybe we
should add that to the coding guide? (Obviously, we would want major notes
pointing out that the preferred procedure is to commit to the maintenance
branch and then svnmerge to the maintenance branch.)

On Thu, Jan 20, 2011 at 10:23 AM, Jeffrey Wong <jef...@gm...> wrote:
> On Jan 20, 2011, at 6:14 AM, John Hunter wrote:
>
>> On Thu, Jan 20, 2011 at 2:50 AM, Jeffrey Wong <jef...@gm...> wrote:
>>> Hi,
>>>
>>> I tried to install matplotlib on python 2.7 and use the graph drawing functionality with NetworkX (nodes and edges).
>>>
>>> easy_install and pip both think that the latest version is 0.91.1, which is wrong because it will import numpy.core.ma instead of numpy.ma.
>>>
>>>
>>> I'm not sure how to fix this but PyPI lists you as the maintainer so I thought you might know.
>>>
>>> Thanks for putting it in PyPI anyhow!
>>
>> CC-ing the devel list.
>>
>> It's not clear to me why this is -- I have 1.0.1 as the active version
>> on pypi, which is reflected on http://pypi.python.org/pypi/matplotlib
>> and the download URL is listed as
>>
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>>
>> 0.91.1 is flagged as hidden. I am not a pypi expert, but don't see
>> anything wrong here,
>
>
> I can't use my python 2.7 to reproduce the problem since I installed matplotlib manually using the MacOS X Python 2.7 dmg/installer.
> It now sees matplotlib 1.0.1-r0 as current.
>
> However with the system python 2.5, it makes the following search:
>
> emcs-imac:Facethingy jeffwong$ /usr/bin/easy_install -n matplotlib
> Searching for matplotlib
> Reading http://pypi.python.org/simple/matplotlib/
> Reading http://matplotlib.sourceforge.net
> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0
> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3/
> Reading http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
> Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
> Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
> Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
> Best match: matplotlib 0.91.1
> Downloading http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.1.tar.gz#md5=56a9344b077b5accbc4823be19f69dd6
> ^Cinterrupted
> emcs-imac:Facethingy jeffwong$
>
>
> Perhaps someone sees something obviously wrong with this...
I see -- we have seen problems with this before. It is very difficult
to get eggs names properly for OSX that are recognized. We have
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1_r0-py2.7-macosx-10.3-fat.egg/download
My guess is that the "_r0" or "10.3" in the name is breaking the matching rule
JDH

On Jan 20, 2011, at 6:14 AM, John Hunter wrote:
> On Thu, Jan 20, 2011 at 2:50 AM, Jeffrey Wong <jef...@gm...> wrote:
>> Hi,
>> 
>> I tried to install matplotlib on python 2.7 and use the graph drawing functionality with NetworkX (nodes and edges).
>> 
>> easy_install and pip both think that the latest version is 0.91.1, which is wrong because it will import numpy.core.ma instead of numpy.ma.
>> 
>> 
>> I'm not sure how to fix this but PyPI lists you as the maintainer so I thought you might know.
>> 
>> Thanks for putting it in PyPI anyhow!
> 
> CC-ing the devel list.
> 
> It's not clear to me why this is -- I have 1.0.1 as the active version
> on pypi, which is reflected on http://pypi.python.org/pypi/matplotlib
> and the download URL is listed as
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
> 
> 0.91.1 is flagged as hidden. I am not a pypi expert, but don't see
> anything wrong here,
I can't use my python 2.7 to reproduce the problem since I installed matplotlib manually using the MacOS X Python 2.7 dmg/installer.
It now sees matplotlib 1.0.1-r0 as current.
However with the system python 2.5, it makes the following search:
emcs-imac:Facethingy jeffwong$ /usr/bin/easy_install -n matplotlib
Searching for matplotlib
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0
Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3/
Reading http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
Best match: matplotlib 0.91.1
Downloading http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.1.tar.gz#md5=56a9344b077b5accbc4823be19f69dd6
^Cinterrupted
emcs-imac:Facethingy jeffwong$ 
Perhaps someone sees something obviously wrong with this...

On Thu, Jan 20, 2011 at 2:50 AM, Jeffrey Wong <jef...@gm...> wrote:
> Hi,
>
> I tried to install matplotlib on python 2.7 and use the graph drawing functionality with NetworkX (nodes and edges).
>
> easy_install and pip both think that the latest version is 0.91.1, which is wrong because it will import numpy.core.ma instead of numpy.ma.
>
>
> I'm not sure how to fix this but PyPI lists you as the maintainer so I thought you might know.
>
> Thanks for putting it in PyPI anyhow!
CC-ing the devel list.
It's not clear to me why this is -- I have 1.0.1 as the active version
on pypi, which is reflected on http://pypi.python.org/pypi/matplotlib
and the download URL is listed as
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
0.91.1 is flagged as hidden. I am not a pypi expert, but don't see
anything wrong here,

On 01/19/2011 07:25 PM, Jae-Joon Lee wrote:
> Big thank you for correcting those typos where virtually all of them are mine.
>
> I'm +1 for backporting these changes as they will not break anything.
> But others may have different ideas.
I'm roughly neutral; I would only caution that when backporting, one 
needs to tell svnmerge about it. Something like:
svnmerge merge -S v1 -r NUM --record-only
svn commit -F svnmerge-commit-message.txt
where you are in your trunk checkout, and NUM is the revision in which 
you did the backporting.
Eric
>
> Regards,
>
> -JJ
>
>
>
> On Tue, Jan 18, 2011 at 4:35 AM, Paul Ivanov<piv...@gm...> wrote:
>> Hi everyone,
>>
>> I just committed a big typos fix to trunk (r8925), should changes
>> like this be backported to the maintenance branch?
>>
>> best,
>> --
>> Paul Ivanov

Big thank you for correcting those typos where virtually all of them are mine.
I'm +1 for backporting these changes as they will not break anything.
But others may have different ideas.
Regards,
-JJ
On Tue, Jan 18, 2011 at 4:35 AM, Paul Ivanov <piv...@gm...> wrote:
> Hi everyone,
>
> I just committed a big typos fix to trunk (r8925), should changes
> like this be backported to the maintenance branch?
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists, off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk00mfQACgkQe+cmRQ8+KPe3GgCeJfWOFkR3eVcxFmk6LoBLfwBX
> QfoAn00POewPxxsyz+x3pMV2QKlcxRuh
> =cNxK
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On 01/18/2011 08:13 PM, Jed Ludlow wrote:
> Please forgive me if I'm raising a heretical question with this since I
> understand the topic of competing Qt bindings for Python gets a little
> touchy in and of itself. Nonetheless, the elephant is in the room. I
> searched the archives and found only a few comments on the subject:
> http://www.mail-archive.com/mat...@li.../msg18652.html
> Has there been any additional discussion among the developers about
> creating a formal backend for Pyside?
Not that I know of.
Considerations:
1) Each additional backend adds a maintenance and development burden.
2) Interactive backends, to be fully useful, need to be be supported by 
ipython.
Eric

On Tue, Jan 18, 2011 at 11:13:47PM -0700, Jed Ludlow wrote:
> Please forgive me if I'm raising a heretical question with this since I
> understand thetopic of competing Qt bindings for Python gets a little
> touchy in and of itself.
> [...]
> Has there been any additional discussion among the developers about
> creating a formal backend for Pyside?
Actually, I think that your question is not heretical at all, since the
GPL license (viral) on PyQt is somewhat in contradiction with the BSD
license (non viral) of matplotlib.
That said, somebody needs to do the work, and I can only offer cheers,
but not help.
Ga

Please forgive me if I'm raising a heretical question with this since I
understand the topic of competing Qt bindings for Python gets a little
touchy in and of itself. Nonetheless, the elephant is in the room. I
searched the archives and found only a few comments on the subject:
http://www.mail-archive.com/mat...@li.../msg18652.html
Has there been any additional discussion among the developers about creating
a formal backend for Pyside?

Hello all,
I am trying (unsuccessfully at present) to build the sampledoc tutorial on
windows with the freshest sampledoc tutorial and svn-build matplotlib on
windows xp, and I was wondering if I was missing a step along the way. I
would really like to be able to use Sphinx to document my project. A
collection of errors is generated when I try to do
make html
in the root sampledoc_tut folder that I pulled from svn. When I open the
generated html files, rather than seeing the plots on the extensions page, I
see no-image icons and the links to the code, png, and pdf files are output
as :
[`source code <.\plot_directive\pyplots/ellipses.py>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
, `hires.png <.\plot_directive\pyplots/ellipses.hires.png>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
,`pdf <.\plot_directive\pyplots/ellipses.pdf>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
]
Something seems to be messed up somewhere along the way. It should build
straight away out of the box, no??
The build errors that I get are:
C:\Documents and
Settings\ibell\Desktop\sampledoc_tut\sphinxext\inheritance_diagram.py:312:
DeprecationWarning: xfileref_role is deprecated, use XRefRole
 'class', ':class:`%s`' % name, name, 0, state)
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
(ERROR/3) Anonymous hyperlink mismatch: 5 references but 0 targets.
See "backrefs" attribute for IDs.
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\pyplots\ellipses.png
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\pyplots\ellipses.pdf
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\inline\aa2bc10136.png
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\inline\aa2bc10136.pdf
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 50%] extensions
###writing output... [100%] index
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst:220:
(WARNING/2) 'dot' called with invalid arguments
writing additional files... genindex search
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 6 warnings.
process_begin: CreateProcess(NULL, echo, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [html] Error 2
Any help would be greatly appreciated.
Ian
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

Sandro Tosi, on 2011年01月18日 19:29, wrote:
> Hi,
> 
> On Tue, Jan 18, 2011 at 15:00, Michael Droettboom <md...@st...> wrote:
> > I'm not sure PIL enters into it -- there shouldn't be any code path
> > involving PIL in that case.
> >
> > I think this a case where the image comparison tolerance needs to be
> > increased. You would do this be passing a "tol" parameter to the
> > image_comparison decorator on the pcolormesh test. The default is 1e-3,
> > but it should be conservatively increased until the test passes. You
> > can perform this experiment yourself, or attach the result image for the
> > test to this list and I can experiment to find a correct value.
> 
> I'm attaching the images, just for reference; as you can see, the
> difference is very tiny and with a tolerance of 0.02 I was able to
> pass the test (RMS Value: 0.0116511801977).
I just wanted to chime in that there *is* structure in the
differences between the images - which don't show up on screens
which don't have linearized gamma (the difference between 0 and 1
are much smaller in brightness than the difference between 127
and 128, for example).
A quick way to get around this is to just invert the colors.
in X11, I do this with 'xcalib -a -i' which toggles back to
normal if you run the command twice (Compiz also has it's own
version of this via some keyboard shortcut, IIRC, but I don't use
it). ImageMagick's convert can do this with the -negate flag. On
OS X, there's something like command-F8 to do this. 
For completeness, if you're interested in doing this in
matplotlib, ;) just subtract your (floating point 0.0-1.0) color
from (1.,1.,1.) to get the new color.
I'm attaching the difference image, with its colors inverted.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7