[matplotlib-devel] matplotlib-grayscale

moved from matplotlib-users: http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users On 10/22/2011 09:31 AM, Friedrich Romstedt wrote: > 2011/10/21 Friedrich Romstedt: >> I will try to dig out t

Re: [matplotlib-devel] Merging Python 3 branch?

On 10/28/2011 07:50 AM, Michael Droettboom wrote: > Now that we have 1.1.0 out, I was thinking maybe now is the time to > merge the matplotlib-py3 branch into master. As a reminder, the main > downside is losing compatibility with Python 2.5 and earlier. We would > continue to have a 1.1.x mainte

Re: [matplotlib-devel] Merging Python 3 branch?

On 10/28/2011 09:00 AM, Michael Droettboom wrote: >> 4) I hope the 1.1.x branch doesn't have to be maintained too long; or if >> it does, it would be good to have a single designated maintainer to take >> care of it, backporting from master or applying custom fixes as needed. >> > I feel like merg

Re: [matplotlib-devel] nxutils

On 11/17/2011 10:19 AM, Michael Droettboom wrote: > Most of what was in nxutils has been superseded by things in Numpy, and > it makes more sense for it to be over there. > > In the case of points_inside_poly, you can use the Path object in > path.py and the "contains_point" method. > > Mike Mike,

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

On 12/16/2011 10:20 AM, Fernando Perez wrote: > Hi all, > > I just added the stinkbug.png file to the sample_data repo so the > Image tutorial and other examples using this image could be run by > users making cbook.get_sample_data calls. But while it works fine > with a reasonably recent MPL, I t

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

On 12/16/2011 02:12 PM, Fernando Perez wrote: > wgethttp://fperez.org/tmp/sample_data_svn.tgz > tar xzf sample_data_svn.tgz > cd sample_data_svn > svn commit -m"Sync SVN repo with contents in current git repo" > Nope: efiring@manini:~/temp/sample_data_svn$ svn commit -m"Sync SVN repo with conten

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

On 12/30/2011 01:57 PM, Paul Ivanov wrote: Eric Firing, on 2011-12-27 15:31, wrote: It looks like this is something I can fix by modifying ListedColormap. It is discarding the alpha values, and I don't think there is any reason it needs to do so. One of my first attempts at a contributi

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

On 01/02/2012 05:51 PM, Tony Yu wrote: > > > On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 12/30/2011 01:57 PM, Paul Ivanov wrote: > > Eric Firing, on 2011-12-27 15:31, wrote: > > It looks

Re: [matplotlib-devel] imread() in master branch doesn't work

On 01/14/2012 09:02 AM, Benjamin Root wrote: > Tried using plt.imread() today on a PNG file, and I am getting this > PyCXX error: > > Traceback (most recent call last): >File "", line 1, in >File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line > 1746, in imread > return

Re: [matplotlib-devel] imread() in master branch doesn't work

b/src/_png.cpp > @@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object& py_fileobj, > const b > >if (PyErr_Occurred()) { >Py_DECREF((PyObject *)A); > -return NULL; > +throw Py::Exception(); >} else { > return (Py

Re: [matplotlib-devel] All information about SF-filed bugs is inaccessible at SF

On 01/29/2012 10:53 AM, Fernando Perez wrote: > Hi all, > > I don't know if you guys were aware of this, and if there's anything > that can be done, but I just realized that all the bugs tagged SF: Fernando, Yes, this became evident right away after the transition; in addition, there was a coord

Re: [matplotlib-devel] re lease schedule for next version

On 02/25/2012 08:34 AM, Benjamin Root wrote: > > > On Saturday, February 25, 2012, John Hunter wrote: > > > > On Sat, Feb 25, 2012 at 8:34 AM, Benjamin Root > wrote: > > > > On Thursday, February 23, 2012, RuiDC wrote: > > > Hi, > There's a number of bugs fi

Re: [matplotlib-devel] Pyplot Documentation

On 02/29/2012 12:47 PM, S Krieger wrote: > Hi, > > My name is Sammy, I'm a university student currently pursing a bachelors > in computer science. I have been working with the pyplot API for some > time. It has been a very useful tool for me, especially in some of my > courses (so thank you for mak

Re: [matplotlib-devel] matplotlib and Google Summer of Code

On 03/01/2012 07:18 AM, John Hunter wrote: > > > > > On Mar 1, 2012, at 9:01 AM, Nick Barnes wrote: > >> May I ask whether matplotlib is taking part in this year's GSoC? >> I'm canvassing ideas for the Climate Code Foundation's >> participation, and some scientists have suggested >> matplotlib-rel

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

On 03/09/2012 11:42 AM, Tony Yu wrote: > > > On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen > wrote: > > I was just analyzing why 145 colours were listed in > matplotlib.colors.cnames instead of the 140 that are apparently "HTML > standard" and, although there's

Re: [matplotlib-devel] quiver warnings

On 03/11/2012 12:27 PM, D. S. McNeil wrote: > Hi! Bumping this upstream from Sage, where we use quiver to draw > slope fields. The following code > > ### > import matplotlib.pyplot as plt > import numpy as np > > fig = plt.figure() > r = np.arange(10) > X,Y = np.meshgrid(r,r) > U, V = np.cos(X),

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

On 04/09/2012 04:13 AM, Jouni K. Seppänen wrote: > Benjamin Root writes: > >>> It seems that savig a pcolor plot to a pdf format always includes >>> gridlines, which isn't true for other output formats like png. The >>> attached example demonstrates this problem. I've only tested this on >>> ver

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

On 04/09/2012 09:25 AM, Michael Gilbert wrote: > On Mon, Apr 9, 2012 at 1:43 PM, Eric Firing wrote: >>> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to >>> make the lines go away at least in Preview. Making them overlap by 0.1 >>> units doe

Re: [matplotlib-devel] plot() with a nearly-constant sequence doesn't always work

On 05/25/2012 12:46 PM, Dan Drake wrote: > Hello matplotlib developers, > > In Sage, we've run into a problem with plotting a sequence whose > y-values change by very small amounts. Here's an example that doesn't > use anything from Sage: > > import pylab > pylab.plot([0, 1], [0, 1e-14]) > pylab.sa

Re: [matplotlib-devel] plot() with a nearly-constant sequence doesn't always work

On 05/25/2012 12:46 PM, Dan Drake wrote: > Hello matplotlib developers, > > In Sage, we've run into a problem with plotting a sequence whose > y-values change by very small amounts. Here's an example that doesn't > use anything from Sage: > > import pylab > pylab.plot([0, 1], [0, 1e-14]) > pylab.sa

Re: [matplotlib-devel] plot() with a nearly-constant sequence doesn't always work

On 05/25/2012 12:46 PM, Dan Drake wrote: > Hello matplotlib developers, > > In Sage, we've run into a problem with plotting a sequence whose > y-values change by very small amounts. Here's an example that doesn't > use anything from Sage: > > import pylab > pylab.plot([0, 1], [0, 1e-14]) > pylab.sa

Re: [matplotlib-devel] PR backlog -- ping us!

On 06/01/2012 06:21 AM, Michael Droettboom wrote: > Ideally, the example would be both: > > 1) standalone under the examples tree so that it creates a gallery > entry in the docs It doesn't have to be a new example, it can be a modification of an existing example. Examples are good, but too

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

On 06/02/2012 10:38 AM, Sandro Tosi wrote: > Hello, > > On Sat, May 12, 2012 at 11:56 AM, Sandro Tosi wrote: >> Hello, >> as you may be aware of, in 1 month (more or less) Debian will freeze, >> that means that no new upstream releases will be allowed in the >> upcoming release, only fixex for imp

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

On 06/07/2012 09:04 AM, John Hunter wrote: > On Thu, Jun 7, 2012 at 1:55 PM, Eric Firing wrote: > >> I did not see any replies to Sandro's reasonable question. >> >> Wasn't there at least a plan for a 1.1.x release soon? >> >> There are quite a f

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

On 06/09/2012 11:14 AM, John Hunter wrote: > I just uploaded the v1.1.1rc2 tarballs to the sourceforge site John, Is it intentional that the tarballs include doc/build? Eric > > https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/ > > As soon as we get binaries, I'll s

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

On 06/09/2012 12:21 PM, John Hunter wrote: > On Sat, Jun 9, 2012 at 5:11 PM, Eric Firing wrote: >> On 06/09/2012 11:14 AM, John Hunter wrote: >>> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site >> >> John, >> >> Is it intentional that th

[matplotlib-devel] needed: OS X maintainer

If you have expertise in python package building on OS X, including more than one method and more than one OS X version, please see https://github.com/matplotlib/matplotlib/issues/168. Eric -- Live Security Virtual Conf

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

On 07/05/2012 01:41 PM, Russell Owen wrote: > By the way: I installed ghostscript from source and Inkscape application > from binary. More tests pass, but many still show K. My guess is that > matplotlib can see ghostscript but not the Inkscape application (no > surprise). Inkscape has too many dep

[matplotlib-devel] Time to delete backend_qt (QT3)?

Is there any good reason *not* to delete support for Qt3 from master? Is anyone who is using it likely to be able to upgrade to the next mpl release, and yet *not* be able to install Qt4 and its bindings? Note that ipython no longer supports Qt3. Eric -

Re: [matplotlib-devel] MacOSX backend throws exception when plotting a quadmesh

On 2012/07/10 6:44 PM, Patrick Marsh wrote: > Hi, All, > > When trying to call plt.show() to display a generate QuadMesh using the > MacOSX backend, an error complaining about "TypeError: only length-1 > arrays can be converted to Python scalars" is generated. The following > gist contains two file

Re: [matplotlib-devel] import collections problem

On 07/19/2012 09:24 AM, Benjamin Root wrote: > Working on my refactor of axes.py, I needed to use defaultdict and > possibly OrderedDict from the collections standard module. Problem is > that matplotlib already has a collections.py module in lib/matplotlib. > This file takes precedence in the imp

Re: [matplotlib-devel] import collections problem

On 07/19/2012 09:37 AM, Benjamin Root wrote: > > > On Thu, Jul 19, 2012 at 2:32 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 07/19/2012 09:24 AM, Benjamin Root wrote: > > Working on my refactor of axes.py, I needed to use defaultdict and >

Re: [matplotlib-devel] matplotlib.use()

On 2012/07/20 9:34 AM, Ryan May wrote: > Hi, > > I'm here at the SciPy sprints trying to fix switching inline/gui for > the ipython notebook. I've noticed something weird about > matplotlib.use() : > > if 'matplotlib.backends' in sys.modules: > if warn: warnings.warn(_use_error_msg) >

Re: [matplotlib-devel] Adding Matlab's fplot to Axes

On 2012/07/23 11:43 AM, Damon McDougall wrote: > Hello all, > > So, as per Philip's suggestion > (https://github.com/matplotlib/matplotlib/pull/737) I've started > encapsulating fplot functionality into a class. The point of this is so > that the user can call either of the following: > > FPlot_ins

Re: [matplotlib-devel] How to properly use git to implement a feature

On 2012/08/12 3:34 PM, Daniel Hyams wrote: > > I was wanting to add a feature to matplotlib...one that I would use in > my application. I also want to contribute the feature back. I'm > personally using version 1.1.1 of matplotlib. Disclaimer...I only know > enough about git to be dangerous. > >

Re: [matplotlib-devel] MEP9: interactivity

On 2012/08/17 8:45 AM, Daniel Hyams wrote: > I was planning to just create my own branch to start putting code in, > but would it be better for an admin to create a branch off of master in > the main matplotlib repo (say MEP9)? Then whoever wants to help out > with MEP9 can branch from that and is

[matplotlib-devel] gca() returns Axes

I have run into a problem related to tight_layout when building the docs, and the root of it seems to be that plt.gca() returns an Axes, not an AxesSubplot. This seems odd, since it appears that it should be equivalent to plt.subplot(1,1,1) when there is no pre-existing axes. Does anyone see a

Re: [matplotlib-devel] gca() returns Axes

On 2012/08/21 10:21 AM, Eric Firing wrote: > I have run into a problem related to tight_layout when building the > docs, and the root of it seems to be that plt.gca() returns an Axes, not > an AxesSubplot. This seems odd, since it appears that it should be > equivalent to plt.subplot

Re: [matplotlib-devel] Stacked plotting in matplotlib

On 2012/08/23 11:55 AM, Damon McDougall wrote: > Hey Nic, > > Thanks for bringing this up. I was the author for #819, so I'd like to > get some dicussion going on this, too. Sorry for the delay, I was in the > midst of writing a thesis, which I am now free of. > > On Sun, Aug 12, 2012 at 11:51:24PM

Re: [matplotlib-devel] Stacked plotting in matplotlib

On 2012/08/23 2:54 PM, Fernando Perez wrote: > On Thu, Aug 23, 2012 at 4:21 PM, Eric Firing wrote: >> OK, here are mine: I oppose overloading plot with a "stacked" kwarg and >> functionality. It is complicated enough as it is. I don't see any >> prob

Re: [matplotlib-devel] Stacked plotting in matplotlib

On 2012/08/23 6:41 PM, Fernando Perez wrote: > Hi Eric, > > On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing wrote: >> I'm not sure I understand what you are getting at, but I don't think there >> should be any interface changes for plot or for their log variants. >

Re: [matplotlib-devel] svg rasterization dpi patch

On 2012/08/26 5:50 AM, Michael Welter wrote: > Hello, > > i made a patch which would allow the svg backend to make > rasterized plots according to the dpi given in savefig. > I wanted this in order to have high-res scatter plots. > As you probably know it is hardcoded to 72 dpi right now. > The ide

Re: [matplotlib-devel] bug in vector plotting

On 2012/08/29 10:07 AM, David Raymond wrote: > > I think that I have found a serious bug in vector plotting (quiver) I think you are correct, but a quick look at the code has not yet revealed what is going wrong. I will look into it. Eric > when the "angle=xy" option is used on a plot with a l

Re: [matplotlib-devel] bug in vector plotting

On 2012/08/29 10:07 AM, David Raymond wrote: > > I think that I have found a serious bug in vector plotting (quiver) > when the "angle=xy" option is used on a plot with a large aspect > ratio. It is my understanding that with this option, the vector with > tail at (x,y) would have its head at (x +

Re: [matplotlib-devel] Fwd: Patch: set capsize of errorbar via matplotlibrc

On 2012/08/29 11:57 PM, Hans Dembinski wrote: > Dear developers, > > I submitted a patch a few weeks ago that I think would be useful to have > in the matplotlib, but I didn't get any response. I use the library > extensively for science work and would like to be able to contribute to > this great

[matplotlib-devel] backend_macosx linewidth bug

Michiel, In the 4th comment on https://github.com/matplotlib/matplotlib/issues/786 I give a little example illustrating a macosx bug: it seems that when drawing a path, the linewidth, which is specified in points, is not interpreted correctly unless the figure.dpi has exactly the right value.

Re: [matplotlib-devel] Is anyone using make.osx?

On 2012/09/07 6:56 AM, Daniel Hyams wrote: > I do, but I'm not wedded to it; I'll use whatever is there. The > convenience of it is that it downloaded dependencies and built them for > you. Will setup.py do the same? No, it won't. The problem with make.osx in that regard is that the dependenci

Re: [matplotlib-devel] Time to delete backend_qt (QT3)?

1:44 AM, Darren Dale <mailto:[email protected]>> wrote: > > On Tue, Jul 10, 2012 at 8:54 AM, Benjamin Root <mailto:[email protected]>> wrote: > > > > > > On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <mailto:[email protected]

Re: [matplotlib-devel] 1.2.0rc1 is cut

On 2012/09/13 11:56 AM, Russell E. Owen wrote: > building 'matplotlib.backends._macosx' extension > gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g > -O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=

Re: [matplotlib-devel] quick bug fix

On 2012/09/27 7:13 PM, Alexander Heger wrote: > I am not sure what I need to do to get any bug fixes included into mpl. The most efficient way is with a pull request. And perhaps a little patience combined with persistence. > All previous attempts failed. > Is it a community effort? Yes, but t

[matplotlib-devel] branch merge strategy

Mike, I'm getting confused about branch merge strategy. Usually, it seems that it has been to periodically merge the maintenance branch into master. Something like this: git fetch upstream git checkout master git merge --ff-only upstream/master git merge upstream/v1.2.x # test, commit changes

Re: [matplotlib-devel] branch merge strategy

On 2012/09/30 7:14 AM, Michael Droettboom wrote: > On 09/29/2012 08:07 PM, Eric Firing wrote: >> Mike, >> >> I'm getting confused about branch merge strategy. Usually, it seems >> that it has been to periodically merge the maintenance branch into >> master.

[matplotlib-devel] deprecate and remove original Navigation toolbar?

Is there any good reason to retain the original NavigationToolbar code in the backends, and the corresponding "classic" option in rcParams['toolbar']? Eric -- Don't let slow site performance ruin your business. Deploy N

Re: [matplotlib-devel] log scale plots ignore tick_params

On 2012/10/09 3:03 PM, Mike Kaufman wrote: > > The example code should explain the problem. > tick_params(), at least for the ticks themselves, is ignored by log plots. > > clf() > x = arange(10) > subplot(211) > plot(x, x) > tick_params(right='off') # works. > > subplot(212) > semilogy(x, x) > tic

Re: [matplotlib-devel] log scale plots ignore tick_params

On 2012/10/09 4:38 PM, Benjamin Root wrote: > > > On Tuesday, October 9, 2012, Mike Kaufman wrote: > > On 10/9/12 9:42 PM, Eric Firing wrote: > > On 2012/10/09 3:03 PM, Mike Kaufman wrote: > > >> clf() > >> x = arange(10)

Re: [matplotlib-devel] PEP8 github label

On 2012/10/13 1:16 PM, Damon McDougall wrote: > I probably should have tested the waters first, but I added a PEP8 > github label. It's neon orange so you can't miss it. The reason I did > this is so that the list of v1.2.x milestoned issues can be easily > filtered by eye. That way it looks less d

Re: [matplotlib-devel] PEP8 github label

On 2012/10/13 1:52 PM, Damon McDougall wrote: > On Sun, Oct 14, 2012 at 1:29 AM, Eric Firing wrote: >> On 2012/10/13 1:16 PM, Damon McDougall wrote: >>> I probably should have tested the waters first, but I added a PEP8 >>> github label. It's neon orange so you

Re: [matplotlib-devel] PEP8 github label

On 2012/10/14 12:17 AM, Damon McDougall wrote: > On Sun, Oct 14, 2012 at 2:23 AM, Eric Firing wrote: >> That would be my preference; but has Mike written anything about where PEP8 >> changes should go? > > All I can find is this: https://github.com/matplotlib/matplotlib/pull/

[matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

All, I think we are in a messy situation, and we need to reach some agreement as to how to proceed. This has been discussed a bit in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel The name of that thread did not r

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

On 2012/10/14 12:44 PM, Damon McDougall wrote: > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing wrote: >> All, >> >> I think we are in a messy situation, and we need to reach some agreement >> as to how to proceed. This has been discussed a bit in this thread: &

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

On 2012/10/14 4:49 PM, Jae-Joon Lee wrote: > I'd agree with Eric on most of his points. > > On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing wrote: >> If some of the PEP8 commits include genuine bug-fixes that need to be in >> v1.2.x, then these fixes should be made via P

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

On 2012/10/14 12:44 PM, Damon McDougall wrote: > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing wrote: >> All, >> >> I think we are in a messy situation, and we need to reach some agreement >> as to how to proceed. This has been discussed a bit in this thread: &

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

tag an rc3, and then target a release date, somewhere in in the 2-4 weeks hence range. In the meantime, PEP8 PRs can be completed on master, after which feature enhancements can proceed on master. Eric > > Mike > > On 10/15/2012 12:10 AM, Eric Firing wrote: >> On 2012/10/14 12:4

Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?

On 2012/10/31 2:04 AM, Maximilian Albert wrote: > [I sent this email a few weeks ago already, but I wasn't subscribed to > matplotlib-devel at the time and it seems that the message was never > approved by the moderator. So here comes my second attempt. :)] > > Hi all, > > this is my first post to

Re: [matplotlib-devel] Use of meta on Artist

On 2012/11/26 7:12 AM, Michael Droettboom wrote: > The problem is that I don't think we can do this for all artists. Some > may need to create groupings, or push and pop state even if they are > "invisible". For instance, this is used in the SVG backend to create > named groupings (possibly empty

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 2012/12/03 4:54 AM, Michael Droettboom wrote: > I think Cython is well suited to writing new algorithmic code to speed > up hot spots in Python code. I don't think it's as well suited as glue > between C and Python -- that was not a main goal of the original Pyrex > project, IIRC. It feels kin

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 2012/12/04 12:07 PM, Damon McDougall wrote: > On Mon, Dec 3, 2012 at 12:12 PM, Chris Barker - NOAA Federal > wrote: >> generated code is ugly and hard to maintain, it is not designed to be >> human-readable, and we wouldn't get the advantages of bug-fixes >> further development in Cython. > > A

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 2012/12/06 7:16 AM, Michael Droettboom wrote: > I think this has been a very helpful and useful discussion. > > I'm going to attempt to summarize this discussion and propose some ways > forward here. > > The impetus for this discussion is that PyCXX seems to be not adequately > maintained. It i

Re: [matplotlib-devel] Github Downloads going away...

On 2012/12/14 6:58 AM, Michael Droettboom wrote: > Github has removed the ability to host binaries. They've removed this > feature without any apparent notification except on their blog saying > "it's gone today". And the suggested alternative is to use paid services. > > https://github.com/blog/

Re: [matplotlib-devel] Github Downloads going away...

On 2012/12/16 9:21 AM, Damon McDougall wrote: > On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout > wrote: >> On 12/14/12 10:55 AM, Nathaniel Smith wrote: >>> sourceforge's horror of an interface. >> >> I'll second that. Every time I go to Sourceforge, I have to figure out >> how in the world to downl

Re: [matplotlib-devel] Problem in backporting Matplotlib for Py3 on Kubuntu Precise

On 2012/12/29 6:25 AM, Shriramana Sharma wrote: > On Sat, Dec 29, 2012 at 9:24 PM, Thomas Kluyver wrote: >> >> If it helps, I have a PPA with builds of the development version of >> matplotlib, including Python 3 builds on precise. I use those packages >> myself, and it's been pretty stable. >> >>

Re: [matplotlib-devel] autoconf+python

On 2013/01/07 7:24 AM, Benjamin Root wrote: > > > On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver > wrote: > > On 7 January 2013 16:57, Benjamin Root > wrote: > > I was just reading some comments from Richard Stallman on ./ >

Re: [matplotlib-devel] autoconf+python

On 2013/01/07 7:29 AM, Michael Droettboom wrote: > I, also, am not too much up on the details --- but I think if it's > possible for "make install" to just call "python setup.py install" under > the hood, I'd have no objections. I think I would even object to that. What would be the point of it?

[matplotlib-devel] PR #1599

We have too many pull requests stacking up. As an easy way to deal with two of them, does anyone strenuously object to merging #1599 and closing #1581? There are no comments on #1599. Eric -- Master Visual Studio, Sha

Re: [matplotlib-devel] Requiring numpy requirement to 1.5 on master?

On 2013/01/11 5:38 AM, Michael Droettboom wrote: > As pointed out in #1650, we have a bug on Python 3.x handling file-like > objects that are UNIX FILEs, but not actual filesystem files, such as > the sockets used for a urllib HTTP request. > > https://github.com/matplotlib/matplotlib/pull/1650 > >

Re: [matplotlib-devel] Usefulness of Travis-CI

On 2013/01/15 2:20 PM, Damon McDougall wrote: > Hi all, > > Recently, it has become more and more common that the travis builds > fail. They fail not because the test suite fails but because of some > inherent issues with travis itself. Usually, either the git clone > fails or some other simple s

Re: [matplotlib-devel] "Flash" rendering in the Agg backend

On 2013/03/06 7:06 AM, Phil Elson wrote: > Smart rendering of adjacent, anti-aliased patches is a question which > has come up a couple of times in various guises in the past. > It is my understanding that the lack of this functionality led us to > disable anti-aliasing for contouring and is the re

Re: [matplotlib-devel] label= kwarg for imshow() and other scalarmappable plots

On 2013/03/24 12:14 PM, Benjamin Root wrote: > So, for plot(), scatter() and other plotting functions, we can provide a > label= kwarg so that a legend() can automatically populate the legend, > making it extremely easy and convenient for making legends. But for > image-based (scalar mappable) typ

[matplotlib-devel] Fwd: Re: [matplotlib] Make wx and wxagg work with wx 2.9.x on Mac. (#2004)

/matplotlib CC: Eric Firing As a data point, this works fine with wx 2.8.12 on my Linux box. Any testers with wx 2.8 on their Mac? It seems harmless enough... — Reply to this email directly or view it on GitHub <https://github.com/matplotlib/matplotlib/pull/2004#issuecomment-18168

[matplotlib-devel] basemap installation problem with mpl master

If I do a clean install of mpl master, and then of basemap, basemap lands in dist-packages/mpl_toolkits, as it always has. But now it is not found--I can't import it. It seems that now the *real* mpl_toolkits is cleverly hidden inside an egg directory with a monstrous name, leaving basemap or

Re: [matplotlib-devel] basemap installation problem with mpl master

On 2013/07/06 5:32 AM, Damon McDougall wrote: > > > > On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <mailto:[email protected]>> wrote: > > If I do a clean install of mpl master, and then of basemap, basemap > lands in dist-packages/mpl_toolkits, as it always

Re: [matplotlib-devel] Completely wrong tick formatting

On 2013/07/04 11:43 PM, Pål Gunnar Ellingsen wrote: > Hi > > I'm having some problems with the formatter of ticks in a polar plot. > Below is a minimum example > The first figure is correct, the second has wrong ticks. > > This has be tested both on 1.2.0 and the latest from git (1.4.x, commit > 64

Re: [matplotlib-devel] Reorganizing axes plot methods

On 2013/07/08 7:19 PM, Tony Yu wrote: > This is an idea that's been kicking around in my head for awhile. > Basically, the Axes class is way too expansive. Nelle made a major step > in the right direction with a PR that split it up into plotting and > non-plotting methods: > > https://github.com/ma

Re: [matplotlib-devel] Reorganizing axes plot methods

On 2013/07/10 1:11 AM, Anton Akhmerov wrote: > Eric Firing writes: > >> This would require pyplot to be imported by everything, wouldn't it? >> That would completely defeat the strategy of having an OO level that >> doesn't know about pyplot at all, and then havi

Re: [matplotlib-devel] Reorganizing axes plot methods

On 2013/07/17 3:14 AM, Michael Droettboom wrote: > Yes. This is great work! > > Just to chime in (after having been away for most of this conversation) --> > > I think we can do this reorganization now without introducing any > implicit (or otherwise) use of gca()/pyplot stuff in the Axes class >

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

On 2013/07/20 4:18 AM, David P. Sanders wrote: > Hi, > > Probably many of you know about "Plot or Not", a site where we vote on > the same plot presented in different ways, to get feedback about better > matplotlibrc params: > > http://warm-escarpment-9042.herokuapp.com/ > > It seems to me an absol

Re: [matplotlib-devel] How to use STIX fonts in matplotlib plots?

On 2013/07/20 4:41 AM, David P. Sanders wrote: > I find the default font used in matplotlib horrible. We should be able > to do much better these days. Which font is being used as default on your installation? And what are the characteristics that earn the rating of "horrible"? Eric --

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

? On second thought, it sounds like it would be better if I remain ignorant; and I suspect you are not being overly cautious in having some reservations. Eric > > Cheers! > Ben Root > > On Jul 20, 2013 2:20 PM, "Eric Firing" <mailto:[email protected]>> wrote: >

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

On 2013/07/20 11:47 AM, Chris Beaumont wrote: > Hi, > > I thought I'd chime in on this discussion -- Adrian Price-Whelan and I > put together plotornot during the SciPy sprints. > > I wouldn't advocate for linking to plotornot from matplotlib -- the idea > is semi tongue-in-cheek, and meant to gaug

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

On 2013/07/20 2:38 PM, David P. Sanders wrote: > And this is my problem with 'rc': it brings to mind an arcane config > file hidden away somewhere that has a terrible syntax and must not be > touched. > > As Chris and Adrian have emphasized, the point is that we *should* be > tweaking away at the

Re: [matplotlib-devel] No plot output when running a script from another script

On 2013/07/20 10:16 PM, David P. Sanders wrote: I am trying to execute (with execfile) a script A.py containing matplotlib plotting commands from within a script B.py. Within B.py, I do execfile("A.py") The A.py script runs correctly, except that no plot is shown. I have checked that the A.p

Re: [matplotlib-devel] How to use STIX fonts in matplotlib plots?

On 2013/07/20 10:08 PM, David P. Sanders wrote: > The fuzziness I referred to was indeed a retina issue, stemming from the > fact *that the default output format is still PNG*. It seems to me that > these days the default output should be SVG, which immediately resolves > all retina issues!! (And a

[matplotlib-devel] idle_event is invoked only once · Issue #959 · matplotlib/matplotlib

https://github.com/matplotlib/matplotlib/issues/959 Does anyone know of a reason not to simply delete the bits of idle_event support that are present? It looks like there isn't much, and it doesn't do anything. Unless someone knows why we have it at all, and has a plan to make it work, I thin

[matplotlib-devel] aspect ratio handling: poor default of "adjustable" parameter?

https://github.com/matplotlib/matplotlib/issues/2243 The above issue raises the question of whether the default for aspect ratio handling should be "datalim" instead of "box". The big advantage is that this completely avoids the problem described in the issue, where setting aspect='equal' can

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

On 2013/07/31 11:12 AM, Russell E. Owen wrote: > All the interesting information about a build is printed at the > beginning and soon scrolls out of sight, so it's usually not obvious if > a build is missing something expected. I think we could collect that information and re-print it to the scree

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

On 2013/07/31 8:02 AM, Michael Droettboom wrote: > The layout has changed, but sidebar has not. Can you provide a > screenshot? Note, you can always visit the older version of the website > athttp://matplotlib.org/1.2.1 for direct comparison. The problem is that the new layout only works with a

Re: [matplotlib-devel] How to spell control

On 2013/08/01 10:40 AM, Matt Terry wrote: > Hi, > I'm working on cleaning up the key-event callback code. What is the > correct spelling of the control key? Is it "control" or "ctrl"? > Different backends spell it differently. May I homogenize things at the > expense of breaking code? Fwiw, the qt4

Re: [matplotlib-devel] Calling to those "embedding" matplotlib in applications

On 2013/08/14 12:18 PM, Erik Bray wrote: > Apparently IDLE doesn't set sys.ps1 either: Maybe this is a good thing; interactive mode doesn't work in IDLE. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! I

Re: [matplotlib-devel] Error in import matplotlib.pyplot using Python/C API

On 2013/09/10 5:43 AM, Michael Droettboom wrote: > Do any of those use ctypes? Try creating a minimal ctypes example and > see if that works. Mike, I was a bit horrified to see that ctypes import and usage in mpl; fortunately it is a workaround for a PySide bug, and should only be temporary, i

Re: [matplotlib-devel] Error in import matplotlib.pyplot using Python/C API

On 2013/09/11 8:49 AM, Filipe Saraiva wrote: > Em Ter 10 Set 2013 19:21:01 BRT, Christoph Gohlke escreveu: >> On 9/10/2013 1:54 PM, Eric Firing wrote: >>> On 2013/09/10 5:43 AM, Michael Droettboom wrote: >>>> Do any of those use ctypes? Try creating a minimal ctype

<    5   6   7   8   9   10   11   >