Re: [matplotlib-devel] Constrained zoom to x axis broken ?

On 04/16/2011 08:44 PM, [email protected] wrote: > > > http://matplotlib.sourceforge.net/users/navigation_toolbar.html > Constrained zoom to x axis (hold x key + left click zoom icon) is broken > for me with master. > > Tested with TkAgg, Qt4Agg backend > features was working on mpl 1.0.0 It work

Re: [matplotlib-devel] Constrained zoom to x axis broken ?

On 04/17/2011 07:59 AM, Eric Firing wrote: > On 04/16/2011 08:44 PM, [email protected] wrote: >> > > http://matplotlib.sourceforge.net/users/navigation_toolbar.html >> Constrained zoom to x axis (hold x key + left click zoom icon) is broken >> for me with mast

[matplotlib-devel] What is rcParams['units'] for?

While investigating the imshow problem reported today by Emanuale Passera (a problem that seems to have been fixed, though I don't know when or how), I stumbled across the verbose-helpful report of the "units" rcParams entry. Sure enough, it is in rcsetup.py and in matplotlibrc.template, but a

Re: [matplotlib-devel] What is rcParams['units'] for?

al units support on or off. > As far as I know, there is no need for it. I will try removing it. Eric > > --James > > >> -Original Message- >> From: Darren Dale [mailto:[email protected]] >> Sent: Tuesday, April 19, 2011 4:42 AM >> To: Eric Firing;

[matplotlib-devel] other test side effect

Mike, I see you fixed a test side effect that I was not aware of. While you are working on the decorator, you might consider how to fix another: every test that imports testing/jpl_units is changing the way units are handled. This breaks test_axes.test_units_strings. In addition to closing

Re: [matplotlib-devel] Website needs love

On 05/16/2011 06:56 AM, Benjamin Root wrote: > > > On Tue, May 10, 2011 at 12:53 PM, John Hunter > wrote: > > > > On Tue, May 10, 2011 at 12:48 PM, Benjamin Root > wrote: > > > > > The one thing I am confused about is what file to

Re: [matplotlib-devel] Website needs love

On 05/16/2011 09:08 AM, Benjamin Root wrote: > > > On Mon, May 16, 2011 at 1:35 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 05/16/2011 06:56 AM, Benjamin Root wrote: > > > > > > On Tue, May 10, 2011 at 12:53 PM,

Re: [matplotlib-devel] Website needs love

On 05/16/2011 09:32 AM, Benjamin Root wrote: > > > On Mon, May 16, 2011 at 2:08 PM, Benjamin Root <mailto:[email protected]>> wrote: > > > > On Mon, May 16, 2011 at 1:35 PM, Eric Firing <mailto:[email protected]>> wrote: > >

[matplotlib-devel] github pull requests: odd listings of hundreds of commits

I suspect that the series of May 6 commits ending with a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such a way that some (but not all) older pull requests on github like this one https://github.com/matplotlib/matplotlib/pull/1 are showing hundreds of commits and diffs. E

Re: [matplotlib-devel] github pull requests: odd listings of hundreds of commits

your 14406a commit: if I understand correctly, a better recovery method would have been to use git reset --hard HEAD^ to simply back up the branch pointer by one. The bad commit would still be in your local tree, but it would be un-named (that is, it would have no branch name) and would not

Re: [matplotlib-devel] github pull requests: odd listings of hundreds of commits

On 05/18/2011 08:47 AM, Benjamin Root wrote: > > > On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <mailto:[email protected]>> wrote: > > On 18/05/2011 5:14 AM, Eric Firing wrote: > > 3) We don't have to always push sets of changes from an origina

Re: [matplotlib-devel] github pull requests: odd listings of hundreds of commits

On 05/18/2011 11:45 AM, Darren Dale wrote: >> >> I suspect the anomalies have not resulted from forced pushes, but from >> local pulls and merges followed by innocuous pushes. So the key is >> understanding how to ensure one's local branches have the desired >> history before pushing to github.

Re: [matplotlib-devel] Website needs love

On 05/20/2011 11:48 AM, Benjamin Root wrote: > > > I have made a few more small changes, and I have an additional change > that I have not committed yet. The table of contents for the examples > page has every single example titled as something like "animation > example code:". This is repeatiti

Re: [matplotlib-devel] Website needs love

On 05/20/2011 11:48 AM, Benjamin Root wrote: > Some other ideas I have had is to include a link to the glossary page in > the page header next to "docs", and maybe the FAQ, as well? I also want > to expand the glossary page, and comb through the docstrings to > incorporate more ":term:" usage. H

[matplotlib-devel] Fwd: Re: [SciPy-Dev] Used "Automatic Merge" on my github pull request...

FYI, here is a github nugget from the scipy people: Original Message Subject:Re: [SciPy-Dev] Used "Automatic Merge" on my github pull request... Date: Sun, 22 May 2011 11:49:44 +0200 From: Ralf Gommers Reply-To: SciPy Developers List To: SciPy Developers

Re: [matplotlib-devel] behavior of drawing in interactive mode

On 05/22/2011 07:04 AM, Mike Kaufman wrote: > Hi, > > After switching over from the MacOSX backend to the GTKAgg backend, I > started notice a big change in drawing behavior. > > Now I know that MacOSX is interactive all the time by [mis]design, so I > wasn't surprised that I would have to add draw

Re: [matplotlib-devel] Website needs love

On 05/22/2011 10:07 AM, Benjamin Root wrote: > I went ahead with the merge conflict procedure, and everything appear to > be ok. I had also noticed a few additional mistakes in the INSTALL file > currently in v1.0.x that I fixed as well. I will double-check the > commit/merge before pushing it u

Re: [matplotlib-devel] Website needs love

On 05/22/2011 11:33 AM, Benjamin Root wrote: > > > On Sun, May 22, 2011 at 4:11 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 05/22/2011 10:07 AM, Benjamin Root wrote: > > > I went ahead with the merge conflict procedure, and everything >

Re: [matplotlib-devel] build matplotlib1.0.1 with libpng.1.5.2

On 05/25/2011 10:53 AM, Dieter Schön wrote: > hi list, > > first, thanks for providing matplotlib, i am using it in several projects. > > i had problems with several png files and decided to upgrade libpng. > this broke matplotlib. > as you can see in the documentation of libpng15, it is no longer

Re: [matplotlib-devel] build matplotlib1.0.1 with libpng.1.5.2

On 05/26/2011 04:40 AM, Michael Droettboom wrote: > On 05/25/2011 05:36 PM, Eric Firing wrote: >> On 05/25/2011 10:53 AM, Dieter Schön wrote: >> >>> hi list, >>> >>> first, thanks for providing matplotlib, i am using it in several projects. >>> &g

Re: [matplotlib-devel] build matplotlib1.0.1 with libpng.1.5.2

On 05/27/2011 05:02 AM, Michael Droettboom wrote: > On 05/26/2011 03:19 PM, Eric Firing wrote: >> >> Mike, >> >> I think you did--unintentionally! If you look at the graph with qgit >> (or presumably any other such tool) in the vicinity of your commits on >

Re: [matplotlib-devel] build matplotlib1.0.1 with libpng.1.5.2

On 05/27/2011 08:31 AM, Pauli Virtanen wrote: > On Fri, 27 May 2011 07:29:15 -1000, Eric Firing wrote: > [clip] >> I wouldn't worry about it. It seems likely that other things from >> master did leak into v1.0.x, but at this point I don't think it matters. >> v1

Re: [matplotlib-devel] v1.0.x branch seems confused

On 06/01/2011 08:26 AM, Michael Droettboom wrote: > Yes, it seems that the v1.0.x got hosed somehow back in early May. Eric > Firing did some spelunking and traced it to a push I made, but I'm not > sure what I did wrong, and I'm even less sure how to fix it. If someone > wit

Re: [matplotlib-devel] v1.0.x branch seems confused

On 06/01/2011 09:07 AM, Benjamin Root wrote: > > > On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 06/01/2011 08:26 AM, Michael Droettboom wrote: > > Yes, it seems that the v1.0.x got hosed somehow back in early >

Re: [matplotlib-devel] v1.0.x branch seems confused

On 06/01/2011 12:38 PM, Matthew Brett wrote: > Hi, > > On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote: >>> The current practice worked very nicely with SVN (IMHO), and I think it >> >> (I recall that Mike had to rescue us more than once from svnmerge >> con

Re: [matplotlib-devel] v1.0.x branch seems confused

On 06/02/2011 11:48 AM, Darren Dale wrote: [...] > > I had another look at the history after rereading Pauli's email. I'm > going to try the following on a temporary v1.0.x-cleanup branch: > > * "git reset --hard 0e6dad5230" > * redo pull request 103 > * cherry-pick the following commits off of the

Re: [matplotlib-devel] v1.0.x branch seems confused

On 06/02/2011 12:35 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing wrote: >> On 06/02/2011 11:48 AM, Darren Dale wrote: >> [...] >>> >>> I had another look at the history after rereading Pauli's email. I'm >>> going to tr

Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint

On 06/03/2011 07:21 AM, Benjamin Root wrote: > P.S. : As an interesting aside to what caused me to find this mistake... > My docs were still not building correctly, although now that the v1.0.x > branch is fixed, it didn't have the multiprocessing trick that is in > master. Therefore, when the er

Re: [matplotlib-devel] plt.plot projection kwarg

On 06/04/2011 06:05 AM, Benjamin Root wrote: > On Sat, Jun 4, 2011 at 9:09 AM, Phil Elson > wrote: > > > The first line of code on the page > http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests > that it is possible to give the proje

Re: [matplotlib-devel] plt.plot projection kwarg

On 06/04/2011 09:08 AM, Eric Firing wrote: > Independently, I want to redo the FAQ discussion of draw(), show(), and > interactive versus non-interactive mode. It is possible that this topic > needs more attention elsewhere as well, but I want to start with the FAQ. I think I will

Re: [matplotlib-devel] plt.plot projection kwarg

On 06/04/2011 09:45 AM, Phil Elson wrote: > > I think the only case where this would work correctly is if the plot > command would also trigger the creation of a new axes object. > Can't see how this can ever happen given the pyplot.plot code, which > creates a standard axes without passing throug

Re: [matplotlib-devel] Bug in scatter() in current git head?

On 06/05/2011 06:00 PM, Fernando Perez wrote: > Hi all, > > I think there's a problem with scatter() that didn't use to be there, > as in current HEAD it seems to not be computing xlim/ylim correctly: > > scatter(range(100),rand(100)) > > sets a plot with a (0,1) window on x/y, which is obviously t

Re: [matplotlib-devel] Bug in scatter() in current git head?

On 06/05/2011 06:00 PM, Fernando Perez wrote: > Hi all, > > I think there's a problem with scatter() that didn't use to be there, > as in current HEAD it seems to not be computing xlim/ylim correctly: > > scatter(range(100),rand(100)) > > sets a plot with a (0,1) window on x/y, which is obviously t

Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?

On 06/15/2011 10:35 AM, Darren Dale wrote: > > I figured out how to migrate soureforges tracker to github issues with > the new github api. There are 232 open issues on the sourceforge > tracker, 79 of which are feature requests. Most sf issues are from > 2009 and on, many in the last few months.

Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?

On 06/20/2011 08:47 AM, Darren Dale wrote: > On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing wrote: >> On 06/15/2011 10:35 AM, Darren Dale wrote: >> >>> >>> I figured out how to migrate soureforges tracker to github issues with >>> the new github api. Th

Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?

On 06/20/2011 11:29 AM, Darren Dale wrote: > Ok, I've migrated the issues over to github. > > Darren Darren, Thank you. Now I see another possible problem with the issue tracker: it doesn't seem to have a way to select issues that do *not* have a particular label. Well, at least that gives u

[matplotlib-devel] github issue labels

Suggestion: let's try to keep the labels short. I think that will make it easier to see what we have as the number of labels increases, and will make the labels a bit less visually overwhelming. (It looks like existing labels can be edited in the Manage Labels function, but I was afraid to tr

Re: [matplotlib-devel] adding valid signals to a CallbackRegistry?

On 06/23/2011 10:53 AM, John Hunter wrote: > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom wrote: >> On 06/23/2011 03:49 PM, Benjamin Root wrote: >> >> Hello all, >> >> I am working to make mplot3d feature-parity with regular axes objects. I >> have come across a possible design flaw with t

Re: [matplotlib-devel] compile failure with git tree

On 07/02/2011 02:37 AM, Xavier Gnata wrote: > Hi, > > I'm use to compile the mpl git tree but I get an error with the current one: > > > running build_ext > building 'matplotlib.backends._tkagg' extension > C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 > -Wall -fPIC > > comp

Re: [matplotlib-devel] compile failure with git tree

On 07/02/2011 02:37 AM, Xavier Gnata wrote: > Hi, > > I'm use to compile the mpl git tree but I get an error with the current one: > > > running build_ext > building 'matplotlib.backends._tkagg' extension > C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 > -Wall -fPIC > > comp

Re: [matplotlib-devel] Update Qt import logic for event loop handling?

On 07/02/2011 12:21 PM, Fernando Perez wrote: > Hi folks, > > as indicated here: > > https://github.com/ipython/ipython/pull/550#issuecomment-1490217 > > our Qt-handling logic has recently changed a little bit, so it would > be great if on the mpl side things could be updated to match the > current

Re: [matplotlib-devel] [IPython-dev] Qt api selection re. ipython and matplotlib

On 07/04/2011 06:51 PM, MinRK wrote: > On Mon, Jul 4, 2011 at 20:57, Eric Firing wrote: >> On 07/04/2011 04:26 PM, Darren Dale wrote: >>> On Mon, Jul 4, 2011 at 9:17 PM, Fernando Perez >>> wrote: >>>> Hi folks, >>>> >>>> Eric Fi

Re: [matplotlib-devel] [IPython-dev] Qt api selection re. ipython and matplotlib

On 07/04/2011 09:42 PM, Eric Firing wrote: > > I updated mpl pull request #390 and added ipython pull request #550 with That should have been ipython pull request #556. Eric -- All of the data generated in y

Re: [matplotlib-devel] Plan for cutting v1.1.0?

On 07/13/2011 08:58 AM, Benjamin Root wrote: > Just wondering if there is any sort of agreement/target for cutting a > v1.1.0 release? I think we are very close. Most of what I see that > needs to be done are documentation-related (and I want to add a > can_pan() function to mirror the can_zoom()

Re: [matplotlib-devel] Plan for cutting v1.1.0?

On 07/13/2011 10:20 AM, Paul Ivanov wrote: > Eric Firing, on 2011-07-13 09:54, wrote: >> ipython has moved to github for their homepage and documentation, but as >> far as I can see, github has no facility for hosting downloads; the >> ipython tarballs are on scipy.org.

[matplotlib-devel] Fwd: Re: [matplotlib] Provide ipython 0.11 compatibility (#411)

Can we please just release something now, so Debian doesn't have to come up with their own modification of 1.0.1? Eric Original Message Subject: Re: [matplotlib] Provide ipython 0.11 compatibility (#411) Date: Wed, 03 Aug 2011 11:28:03 -0700 From: sandrotosi To: efir...@hawai

[matplotlib-devel] demo_parasite_axes triggers bug?

I ran into some failures while trying to build the docs from master. Here is one, illustrated via running an example directly. efiring@manini:~/programs/py/mpl/matplotlib/doc$ python /home/efiring/programs/py/mpl/matplotlib/doc/mpl_toolkits/axes_grid/figures/demo_parasite_axes.py Traceback (most

[matplotlib-devel] make_room_for_ylabel_using_axesgrid.py example: no output

JJ, Thanks for your fast fix of the last problem I reported. Now that the doc build is trying to run scripts with the __main__ conditional, one of the examples it is tripping over is make_room_for_ylabel_using_axesgrid.py. When I try to run it on the command line or in ipython, it displays no

Re: [matplotlib-devel] make_room_for_ylabel_using_axesgrid.py example: no output

On 08/15/2011 12:07 PM, Eric Firing wrote: > JJ, > > Thanks for your fast fix of the last problem I reported. > > Now that the doc build is trying to run scripts with the __main__ > conditional, one of the examples it is tripping over is > make_room_for_ylabel_using_axesgrid.

Re: [matplotlib-devel] Hardcoded 'extent' in Axes.matshow unnecessary?

On 08/13/2011 08:05 AM, Eike von Seggern wrote: > Dear developers, > > I find the hard-coded "extent" in Axes.matshow limits the usability of > this method and hence of pyplot.matshow, because passing "origin" does > switch the order or the rows but does not switch the order of the y-axis > labels,

Re: [matplotlib-devel] Calling all Mac OSX users!

On 08/16/2011 10:10 AM, John Hunter wrote: > On Mon, Aug 15, 2011 at 9:34 PM, Benjamin Root wrote: >> The mpl developers are getting very close to the long-awaited v1.1.0 release >> of matplotlib. Before we do so, we are doing some final checking of the >> documentation to make sure that all crit

[matplotlib-devel] 3 svg failures in master

Running backend_driver: Backend svg took 4.94 minutes to complete Failures: ['../pylab_examples/quadmesh_demo.py', '../api/logo2.py', '../api/watermark_text.py'] All the other backends passed. It looks like there is a single svg problem being triggered by all three of these examples. Eric

Re: [matplotlib-devel] Calling all Mac OSX users!

vailable for 3.x, so there will still be limitations. Eric > > On Aug 17, 2011, at 2:45 PM, Russell E. Owen wrote: > >> In article<[email protected]>, >> Eric Firing wrote: >> >>> On 08/16/2011 10:10 AM, John Hunter wrote: >>>> On Mon,

Re: [matplotlib-devel] make_room_for_ylabel_using_axesgrid.py example: no output

ent, thank you. Eric > > Regards, > > -JJ > > > On Tue, Aug 16, 2011 at 8:52 AM, Eric Firing wrote: >> On 08/15/2011 12:07 PM, Eric Firing wrote: >>> JJ, >>> >>> Thanks for your fast fix of the last problem I reported. >>> >>>

[matplotlib-devel] merged v1.0.x-maint into master

There were a couple of bug fixes in maint that had not yet been merged into master, so I just did that. I'm pretty sure it is OK, but in view of the impending release, checking and testing is particularly welcome. Eric ---

[matplotlib-devel] trailing whitespace again

Trailing whitespace has been creeping back into the sources; if you are committing to git, please check that you are not introducing it into the files you modify. Eric -- Get a FREE DOWNLOAD! and learn more about uberSV

Re: [matplotlib-devel] Calling all Mac OSX users!

On 08/21/2011 10:06 AM, Benjamin Root wrote: > Ok, there has been a lot of useful discussion (for both MacOSX and > Windows), but in the end, I want to know this: Is it possible for > matplotlib to provide a single, recommended, fully-supported-by-us > method for installing our package (possibly fo

Re: [matplotlib-devel] Plot line style cycle?

On 08/25/2011 04:09 AM, Benjamin Root wrote: > I am currently in the process of a paper submission, and the page charge > estimation took us for a bit of a surprise. Luckily, most of my plots > don't need color, and I would like to regenerate them in b&w mode. > > Is there some default line style

Re: [matplotlib-devel] graphics context: use alpha value from foreground color if present

On 08/26/2011 06:23 AM, Michiel de Hoon wrote: > Dear all, > > I am currently modifying the MacOSX backend to make its > interactive/non-interactive behavior consistent with the other backends in > matplotlib. > When I was testing the backend, I found a new bug that seems to be related to > a re

Re: [matplotlib-devel] graphics context: use alpha value from foreground color if present

On 08/26/2011 06:23 AM, Michiel de Hoon wrote: > Dear all, > > I am currently modifying the MacOSX backend to make its > interactive/non-interactive behavior consistent with the other backends in > matplotlib. > When I was testing the backend, I found a new bug that seems to be related to > a re

Re: [matplotlib-devel] graphics context: use alpha value from foreground color if present

On 08/26/2011 08:21 PM, Michiel de Hoon wrote: > Thanks! That solves the problem for me. > Once these changes have made it into trunk, I can commit my changes to the > MacOSX backend. Done--I hit the merge button. Eric > > Thanks, > --Michiel > > --- On Fri, 8/2

[matplotlib-devel] another missing example?

doc/mpl_examples/mplot3d/offset_demo.py Ben, Building the docs is choking on the absence of the above file. Eric -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at a

Re: [matplotlib-devel] another missing example?

om master but forgot to update my local doc branch accordingly. Eric > > Another possibility is that you have to do a "python make.py clean" > first to clear out any pickled info that might prevent detection of new > scripts. > > Ben > > On Mon, Aug 29,

Re: [matplotlib-devel] [Matplotlib-users] Matplotlib 1.0.1 Tk backend

I can see how this could cause some confusion. Maybe we can get it fixed before the next release, maybe not. Part of the problem here is that auto-generation of docs saves a huge amount of work, but can also lead to problems, of which this is just one example. Eric > > > ----- Original

Re: [matplotlib-devel] [Matplotlib-users] Matplotlib 1.0.1 Tk backend

On 09/02/2011 04:48 AM, Benjamin Root wrote: > On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 08/31/2011 05:00 PM, Trevor J Christensen wrote: > > I went here: > > > > http://matplotlib.source

Re: [matplotlib-devel] [Matplotlib-users] Matplotlib 1.0.1 Tk backend

On 09/02/2011 04:48 AM, Benjamin Root wrote: > On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <mailto:[email protected]>> wrote: > > On 08/31/2011 05:00 PM, Trevor J Christensen wrote: > > I went here: > > > > http://matplotlib.source

Re: [matplotlib-devel] [Matplotlib-users] Matplotlib 1.0.1 Tk backend

On 09/02/2011 08:54 AM, Eric Firing wrote: > Now I see it: all the other backends are simply setting constants in > their cursord, so they are not calling the functions that create the > cursors until runtime; backend_gtk is calling the functions at import > time. This is a desig

Re: [matplotlib-devel] PySide Backend

On 09/08/2011 03:53 PM, Tiago Bonetti wrote: > I'm new to github, so forgive me if I'm a litlle lost. > I have the most recent master branch from github matplotlib > / matplotlib > public repository... > I would like to help

Re: [matplotlib-devel] Implementation of cubehelix color scheme

On 09/09/2011 04:51 AM, Pim Schellart wrote: > Dear Developers, > > In the field of Astronomy (and in science in general) we often make > images that represent the intensity of some source. > However the color schemes used to display images are not perceived as > increasing monotonically in brightn

Re: [matplotlib-devel] Another colormap

On 07/18/2011 07:07 AM, Sameer Grover wrote: > I came across this website where different colormaps have been compared > and the author has come up with an optimal colormap for data > visualization called the "cool-warm colormap". > > http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html > >

Re: [matplotlib-devel] Implementation of cubehelix color scheme

On 09/13/2011 02:19 AM, Pim Schellart wrote: > Dear Eric (and other developers), > > I have implemented the requested changes and the resulting diff can be > seen at https://github.com/pschella/matplotlib/compare/master...cubehelix > I tried to do a better job at documentation and hope this is > su

[matplotlib-devel] release: stalled again?

What will it take to get a release out, so that debian, ubuntu, etc. can have something better than 1.0.1? And so that the python 3 merge can take place? Eric -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, C

[matplotlib-devel] 3 test failures

I tried running the nosetests, and got failures. I put in a pull request to take care of one source, but three remain: symlog2 svg image_interp pdf tight_layout5 svg I have only looked into the last of these, which has nothing to do directly with tight_layout; on my system, the svg file is bei

Re: [matplotlib-devel] release: stalled again?

On 09/17/2011 12:17 PM, Christoph Gohlke wrote: > > > On 9/17/2011 2:08 PM, Benjamin Root wrote: >> I think it will take a declaration of a firm deadline. How about this? >> >> Cut RC release Friday, Sept 23rd >> Release v1.1.0 Friday, Sept. 30th. >> (Barring any major significant changes) >> >> I

Re: [matplotlib-devel] release: stalled again?

On 09/18/2011 09:24 AM, Fernando Perez wrote: > On Sun, Sep 18, 2011 at 12:05 PM, John Hunter wrote: >> I can fix these putmask calls, but strangely I am not seeing the >> deprecation warning on numpy and mpl HEAD putmask was deprecated in favor of copyto only 2 months ago; copyto didn't even ex

Re: [matplotlib-devel] release: stalled again?

On 09/18/2011 09:54 AM, John Hunter wrote: >> putmask was deprecated in favor of copyto only 2 months ago; copyto >> didn't even exist before that. So we certainly can't replace putmask >> with copyto in mpl. >> >> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b > > > The p

Re: [matplotlib-devel] release: stalled again?

On 09/18/2011 09:54 AM, John Hunter wrote: >> putmask was deprecated in favor of copyto only 2 months ago; copyto >> didn't even exist before that. So we certainly can't replace putmask >> with copyto in mpl. >> >> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b > > > The p

Re: [matplotlib-devel] release: stalled again?

On 09/18/2011 09:46 AM, Fernando Perez wrote: > On Sun, Sep 18, 2011 at 12:41 PM, John Hunter wrote: >> >> I'm on 11.04, 64 bit also. >> >> What does this give you? >> >> > ython -c 'import numpy as np; print np.__version__; x = >> np.random.rand(10); np.putmask(x, x<0.5, 0.)' >> >> I only get

Re: [matplotlib-devel] Quantization of normalized float to uint8

On 09/18/2011 09:30 AM, Christoph Gohlke wrote: > Hello, > > matplotlib uses int(x*255) or np.array(x*255, np.uint8) to quantize > normalized floating point numbers x in the range [0.0 to 1.0] to > integers in the range [0 to 255]. This way only 1.0 is mapped to 255, > not for example 0.999. Is thi

Re: [matplotlib-devel] release: stalled again?

On 09/18/2011 11:15 AM, John Hunter wrote: > On Sun, Sep 18, 2011 at 4:02 PM, Eric Firing wrote: >> There is a way to deal with this now: define our own copyto which uses >> np.copyto if it exists, and falls back on putnav otherwise. I think this >> can be done with reasonab

Re: [matplotlib-devel] Quiver

> > You can create a line collection that is color mappable by deriving > from LineCollection and ScalarMappable. It will take a little more > work to fully integrate it into the colormappable framework, eg so > colorbars and interactive changing of colormaps works as expected, but > this may b

Re: [matplotlib-devel] Quiver

Jordan, Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..." My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interf

Re: [matplotlib-devel] Quiver Patch

Jordan, Sorry for the duplication, but I made and committed a similar LineCollection change before seeing your message. It is almost identical to yours. I will check your Quiver change and commit it if it looks OK. Thanks. Eric - Original Message - From: Jordan Dawe <[EMAIL PROTECTED

Re: [matplotlib-devel] Quiver Patch

Jordan, I committed the quiver patch with a slight modification, no functional change. Eric - Original Message - From: Jordan Dawe <[EMAIL PROTECTED]> Date: Tuesday, May 30, 2006 12:39 pm Subject: [matplotlib-devel] Quiver Patch To: matplotlib development list > Ok, here's something of

Re: [matplotlib-devel] RGBA in imshow

Jeff, Thanks for the report. I have committed a bugfix combined with a speedup: the check for gray will not occur if the image is cached. Eric - Original Message - From: Jeff Whitaker <[EMAIL PROTECTED]> Date: Friday, June 2, 2006 1:07 pm Subject: [matplotlib-devel] RGBA in imshow To:

[matplotlib-devel] new Quiver progress

Jordan, Gary, I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be pres

Re: [matplotlib-devel] [Matplotlib-users] can't get started

John Hunter wrote: >>"Charlie" == Charlie Moad <[EMAIL PROTECTED]> writes: > > > Charlie> On 6/2/06, David S. <[EMAIL PROTECTED]> wrote: > >> I have just installed numpy-0.9.8, scipy-0.4.9, and > >> matplotlib-0.87.2 on a Windows machine with Python 2.4.2. > > Charlie> matplo

Re: [matplotlib-devel] contour demo

John Hunter wrote: > In the last figure 4 of contour_demo.py, the positioning of the > vertical colorbar looks too low. I would expect it to align roughly > with the vertical extent of the image axes. Is this intentional, > configurable, or a bug? > I committed a change to the demo that reposit

Re: [matplotlib-devel] new Quiver progress

Robert Hetland wrote: Let me know if you would like to do a quick alpha test before you commit. I'll help to put it through the paces.. -Rob. Rob, Thanks. Attached are a diff against svn and a test script to get you started. If you apply the diff as a patch, you should be able to call

Re: [matplotlib-devel] contour demo

John Hunter wrote: > In the last figure 4 of contour_demo.py, the positioning of the > vertical colorbar looks too low. I would expect it to align roughly > with the vertical extent of the image axes. Is this intentional, > configurable, or a bug? I would call it a design deficiency. In mpl as

Re: [matplotlib-devel] new Quiver progress

Gary, Thanks for the prompt test and report. I agree that the ability to put a dot at locations where arrows are below a threshold would be good. I will add it. I think it should be similar to a circle marker that scales with the arrow width, and has a diameter that is a fraction of that wid

Re: [matplotlib-devel] new Quiver progress

> Hey someone said something nice about transforms! About time, isn't it! One thing I still don't understand: when is it necessary to bracket code with freeze/thaw? > > Eric, I haven't had a chance to try this code out but I did read > through it and it looks very nice. A small comment: fig.

[matplotlib-devel] quiver2 in svn

A reimplementation of the quiver command has been committed to svn. It is temporarily accessible as "quiver2" so as not to interfere with the original quiver, and in examples there is a quiver2_demo.py. The API differs from that of the original quiver. See the docstring for details. Since t

[matplotlib-devel] quiverkey

I added the ability to easily generate a key for quiver plots. The function is called quiverkey(). It is illustrated in the revised examples/quiver_demo.py. I also changed Axes.quiver and pylab.quiver to use quiver2 if possible--that is, if it seems consistent with the arguments that are supp

Re: [matplotlib-devel] quiver2 in svn

Helge, Helge Avlesen wrote: > On 6/9/06, Eric Firing <[EMAIL PROTECTED]> wrote: > >>Suggestions for improvements in the API or other aspects are welcome. > > > Hi, > an option for quiver to quickly draw thousands of simple monocolor > arrows each constructed f

[matplotlib-devel] basemap support for new quiver

Jeff, I made minimal changes to my copy of basemap to support the new quiver and quiverkey, and to illustrate them in quiver_demo.py. The older quiver is still accessible as quiver_classic. A diff against svn is attached. (It includes do-nothing diffs caused by my editor's deletion of end-o

Re: [matplotlib-devel] new Quiver progress

John Hunter wrote: >>>>>>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes: > > > >> Hey someone said something nice about transforms! > > Eric> About time, isn't it! > > Eric> One thing I still don't

Re: [matplotlib-devel] Thoughts on quiver2

Robert, Thanks for the feedback. Comments are below. I think I addressed some items over the weekend, so the version in svn should work better than the one you tested, assuming you tested the original one I sent out as a diff. Robert Hetland wrote: > > Eric- > > I had a chance to play arou

[matplotlib-devel] collection efficiency improvement

Based on a quick look, I think it would be easy to make LineCollection and PolyCollection accept a numerix array in place of [(x,y), (x,y), ...] for each line segment or polygon; specifically, this could replaced by an N x 2 array, where the first column would be x and the second would be y. B

Re: [matplotlib-devel] collection efficiency improvement

John Hunter wrote: >>>>>>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes: > > > Eric> Based on a quick look, I think it would be easy to make > Eric> LineCollection and PolyCollection accept a numerix array in > Eric> place

<    1   2   3   4   5   6   7   8   9   10   >