Re: [matplotlib-devel] [PATCH 0/2] remove unused code

Kelvin, Thank you for your work. Would it be possible for you to open a pull request on git hub with these changes (that is where we so almost all of our code review recently and is hooked in to a continuous integration service). I have not looked at the diff yet (still on my phone), but from loo

[matplotlib-devel] [PATCH 0/2] remove unused code

First ever patch submission. Here I propose cleaning up some unused variables and imports. Kelvin Li (2): remove unused variable "cmd_split" backends: remove unnecessary import statements lib/matplotlib/backends/backend_agg.py | 2 -- lib/matplotlib/backends/backend_cairo.py |

[matplotlib-devel] [PATCH 1/2] remove unused variable "cmd_split"

--- lib/matplotlib/backends/backend_ps.py | 3 --- lib/matplotlib/texmanager.py | 6 -- 2 files changed, 9 deletions(-) diff --git a/lib/matplotlib/backends/backend_ps.py b/lib/matplotlib/backends/backend_ps.py index cea707d..699d1ba 100644 --- a/lib/matplotlib/backends/backend_ps.p

[matplotlib-devel] [PATCH 2/2] backends: remove unnecessary import statements

--- lib/matplotlib/backends/backend_agg.py | 2 -- lib/matplotlib/backends/backend_cairo.py | 5 ++-- lib/matplotlib/backends/backend_gdk.py | 9 --- lib/matplotlib/backends/backend_gtk.py | 7 +++-- lib/matplotlib/backends/backend_gtk3agg.py | 1 - lib/m

Re: [matplotlib-devel] Patch review: Autoscaling on add_patch()

Amit, Thanks for your bug report and your PR for fixing the bug. I haven't had time to look over it yet, and I won't have the ability to review it for the upcoming week (in fact, I will be without internet connection). If no one gets around to reviewing it in the next week due to the holiday seaso

[matplotlib-devel] Patch review: Autoscaling on add_patch()

Hi all, I submitted a PR yesterday: https://github.com/matplotlib/matplotlib/pull/3936 to add autoscale_view() in the add_patch() method. This aims to fix: https://github.com/amitsaha/matplotlib/tree/issue3934 I am very much a matplotlib user, so if the PR doesn't look right, I am willing to wor

Re: [matplotlib-devel] [PATCH] gtkagg backend leaks gc's.

On Sun, Nov 11, 2012 at 4:23 PM, Benjamin Root wrote: > > > On Thursday, November 8, 2012, Carl Michal wrote: >> >> Hello, >> >> I noticed that a program I had that uses canvas.blit() to do animated >> graphs >> with the gtkagg backend was leaking memory. >> >> I tracked this down to gtk gc's bein

Re: [matplotlib-devel] [PATCH] gtkagg backend leaks gc's.

On Thursday, November 8, 2012, Carl Michal wrote: > Hello, > > I noticed that a program I had that uses canvas.blit() to do animated > graphs > with the gtkagg backend was leaking memory. > > I tracked this down to gtk gc's being allocated in agg_to_gtk_drawable with > gdk_gc_new(), but never bein

Re: [matplotlib-devel] [PATCH] gtkagg backend leaks gc's.

Hello, I noticed that a program I had that uses canvas.blit() to do animated graphs with the gtkagg backend was leaking memory. I tracked this down to gtk gc's being allocated in agg_to_gtk_drawable with gdk_gc_new(), but never being destroyed. The leak can be seen using the 'Animating selecte

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

On Sun, Sep 9, 2012 at 3:24 PM, Benjamin Root wrote: > > > On Tue, Apr 17, 2012 at 10:02 AM, Jostein Bø Fløystad < > jostein.floys...@gmail.com> wrote: > >> Ben, >> >> That sounds great, especially regarding the test images. I don't know >> how the image comparison tests work, that's why I kept i

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

On Tue, Apr 17, 2012 at 10:02 AM, Jostein Bø Fløystad < jostein.floys...@gmail.com> wrote: > Ben, > > That sounds great, especially regarding the test images. I don't know > how the image comparison tests work, that's why I kept it very > fundamental. > > Thanks! > > Jostein. > > Just rediscovered

[matplotlib-devel] Patch: fixed conversion from pt to inch in tight_layout

Hi, I noticed that when using tight_layout, the figure padding changes for different figure.dpi settings. This is caused by an error in when converting from points to inches. A point is always 1/72 inch and does not depend on the dots per inches. This is the patch for fixing the conversion: Diff

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

Hi fellow developers, I am using matplotlib in particle physics where we generally do not plot the little end caps of error bars. They add no information, but they make the plot harder to read, especially if it is a busy plot. In physics, we follow the general aesthetic rule to maximise the "

Re: [matplotlib-devel] Patch: more Pythonic rc handling

Dnia wtorek, 10 lipca 2012 21:32:40 Maciek Dems pisze: > In the attachment I include a path to the current git main repo, which > enables this way of handling RC properties. I would appreciate very much if > they were reviewed and included in the next release of Matplotlib (the > patch is not parti

[matplotlib-devel] Patch: more Pythonic rc handling

The standard RC parameters handling in Matplotlib has always troubled me. The syntax rc('figure.subplot', top=0.9) is not very conveniet if one wants to change a singe property. Direct rcParams['figure.subplot.top'] seems better suited in this case. However, as the dots are already used to indi

[matplotlib-devel] Patch for errorbar, alpha kw did not apply to lines and cap markers

Hi matplotlib developers, this is my first commit to matplotlib. I am using it heavily in a scientific context. I followed the How-to and send you an according patch for what I consider a bug. If it doesn't make sense, please be lenient with me for now, since it my first time. : ) As describ

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

Ben, That sounds great, especially regarding the test images. I don't know how the image comparison tests work, that's why I kept it very fundamental. Thanks! Jostein. Den 14:59 17. april 2012 skrev Benjamin Root følgende: > > > On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad > wrote: >>

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad < jostein.floys...@gmail.com> wrote: > Hi Benjamin, > > and thanks for looking into this. The traceback you showed in your > post is the original one that I see before applying the second patch. > After applying the second patch, I do not see th

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

Hi Benjamin, and thanks for looking into this. The traceback you showed in your post is the original one that I see before applying the second patch. After applying the second patch, I do not see this traceback any more, and I get the results I expect. In other words, I'm unable to reproduce the b

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

On Sat, Apr 7, 2012 at 11:25 AM, Jostein Bø Fløystad < jostein.floys...@gmail.com> wrote: > I've had problems saving MxNx3 (RGB) numpy arrays as images using > imsave. It fails with an exception, and the problem seems to be line > 1243 in image.py: > > figsize = [x / float(dpi) for x in arr.shape[

[matplotlib-devel] PATCH: Accept color/alpha in imsave

I've had problems saving MxNx3 (RGB) numpy arrays as images using imsave. It fails with an exception, and the problem seems to be line 1243 in image.py: figsize = [x / float(dpi) for x in arr.shape[::-1]] The purpose of arr.shape[::-1] seems to be to reorder the height and width dimensions. It wo

Re: [matplotlib-devel] Patch: Reorder #includes in ttconv/pprdrv_tt2.cpp

On Fri, Oct 14, 2011 at 6:30 AM, Wesley Emeneker wrote: > Attached is patch that moves > #include > to before > #include > > The Portland group compiler (v 11.8) won't build ttconv/pprdrv_tt2.cpp with > the original ordering. > This is most likely a compiler bug, but changing the include order s

[matplotlib-devel] Patch: Reorder #includes in ttconv/pprdrv_tt2.cpp

Attached is patch that moves #include to before #include The Portland group compiler (v 11.8) won't build ttconv/pprdrv_tt2.cpp with the original ordering. This is most likely a compiler bug, but changing the include order seems pretty harmless. Thanks for the great tool. I love matplotlib. W

Re: [matplotlib-devel] Patch to fix PNG with newer libpng

Thanks for the report. This issue was fixed some time ago on the maintenance branch, but we have not been very good at getting maintenance releases out lately. Hopefully one will drop shortly. Mike On 07/22/2011 03:57 PM, Andy Somogyi wrote: Hi All, Apparently, some time ago, libpng made t

[matplotlib-devel] Patch to fix PNG with newer libpng

Hi All, Apparently, some time ago, libpng made the png_info structure opaque. OSX has a newer version on libpng, so matplotlib would not compile. Attached is the _png.cpp that fixes this issue, I changed it to use the new libpng access routines. This issue will certainly come up on any platfo

[matplotlib-devel] Patch for uninitialized vertices in Path.arc

Hi, Using matplotlib.path.Path.arc to create a wedge (e.g. via matplotlib.path.Path.wedge) creates a Path with three uninitialized vertex positions. (The first one and the last two.) As you would expect - sometimes this leads to nasty drawing artifacts! I've tried zeroing the entire array a

Re: [matplotlib-devel] Patch for matplotlib-py3

b development list Subject: Re: [matplotlib-devel] Patch for matplotlib-py3 I thought the workflow/process of contributing to matplotlib did not change: <http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg07849.html> <http://matplotlib.sourceforge.net/faq/howto_faq.html#contribu

Re: [matplotlib-devel] Patch for matplotlib-py3

pment_workflow.html > > Cheers, > Mike > > > From: Christoph Gohlke [cgoh...@uci.edu] > Sent: Wednesday, March 16, 2011 3:01 PM > To: matplotlib development list > Subject: [matplotlib-devel] Patch for matplotlib-py3 > > Hello, >

Re: [matplotlib-devel] Patch for matplotlib-py3

From: Christoph Gohlke [cgoh...@uci.edu] Sent: Wednesday, March 16, 2011 3:01 PM To: matplotlib development list Subject: [matplotlib-devel] Patch for matplotlib-py3 Hello, please consider the attached patch for the matplotlib-py3 fork on github. It corrects some

[matplotlib-devel] Patch for matplotlib-py3

Hello, please consider the attached patch for the matplotlib-py3 fork on github. It corrects some build and test failures and removes unnecessary 'extern "C"' statements from PyMODINIT_FUNC functions. From : Note that PyMODINIT_FU

[matplotlib-devel] patch to add legend.frameon to rcParams

I noticed that this didn't exist and I never seem to want a frame anyway so here's a patch. I wasn't sure if anything in doc/ needed to be changed... I don't really like the name "legend.frameon". I'd rather have "legend.frame" or "legend.useframe". If people would accept changing the name of

Re: [matplotlib-devel] Patch for Bug ID: 3176823 plot_date does not respect timezone

On Wed, Feb 16, 2011 at 1:21 PM, Maximilian Trescher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi there, > > I just created my first patch for matplotlib, it's addressing bug 3176823. > > I send the patch with an example (as suggested in the faq). A pull request has been filed

[matplotlib-devel] Patch for Bug ID: 3176823 plot_date does not respect timezone

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I just created my first patch for matplotlib, it's addressing bug 3176823. I send the patch with an example (as suggested in the faq). You can see the effect in the example: before patching it ignores the tz argument, and marks are set at

Re: [matplotlib-devel] patch to close plots with 'q'

On 02/09/2011 09:23 PM, Marshall Ward wrote: > Hello, first time poster, Marshall, Welcome! I'm sorry my first reply was a bit curt, especially considering that you are offering a patch. We do appreciate contributions. A little discussion may be required as to the future strategy for keyboar

Re: [matplotlib-devel] patch to close plots with 'q'

On 02/09/2011 09:23 PM, Marshall Ward wrote: > Hello, first time poster, > > I've made a patch to add a keyboard shortcut to close plot windows with > the 'q' key (patchfile attached, in case it is of interest to the > matplotlib team). But as I was finishing it up, I noticed that there was > alrea

[matplotlib-devel] patch to close plots with 'q'

Hello, first time poster, I've made a patch to add a keyboard shortcut to close plot windows with the 'q' key (patchfile attached, in case it is of interest to the matplotlib team). But as I was finishing it up, I noticed that there was already something similar in the code, commented out (even us

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

2011/1/22 Benjamin Root : > Finally got around to committing this.  I committed it to the maintenance > branch in r8933 and merged into the development branch in r8934. Okay, I agree on this, but I will work on it again once the git transition is complete, or similar. Thanks, Friedrich -

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2011/1/8 Benjamin Root : > > The changes look ok to me so far. It looks to be mostly a > re-organization > > of existing logic and some consolidation of code. My only concerns are > the > > creation of tw

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

On 01/10/2011 08:02 AM, Benjamin Root wrote: [...] > > My feeling is that for the purposes of 1.0.1, what you put together is > good (although with those new functions underscored). I will then merge > that over to the development branch. In the development branch, we can > then make any addition

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2011/1/8 Benjamin Root : > > The changes look ok to me so far. It looks to be mostly a > re-organization > > of existing logic and some consolidation of code. My only concerns are > the > > creation of tw

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

2011/1/8 Benjamin Root : > The changes look ok to me so far.  It looks to be mostly a re-organization > of existing logic and some consolidation of code.  My only concerns are the > creation of two new functions.  Besides the obvious issues with potential > namespace collisions in other parts of th

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

On Thu, Jan 6, 2011 at 10:20 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > Hi Ben, > > nice to get a response. It's not an urgent patch, but should go in > somwhen (imo). If you could take it and verify that it breaks nothing > I would owe you a donut ;) > > Why OL? > > Here's t

Re: [matplotlib-devel] patch: bug with twinx and scientific style

On 01/02/2011 05:03 PM, Paul Ivanov wrote: > I sent this to the -users list a little over a week ago - now > resending to -devel list against the latest svn. Paul, Thanks, I applied your fix to the maintenance branch, so it should appear in the 1.0.1 release that is in the works. I ran into an

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

In article <4d02914a.6050...@noaa.gov>, Christopher Barker wrote: > On 12/9/10 11:57 PM, Ludwig Schwardt wrote: > > This patch reminded me to ask why the builtin libpng, zlib and > > libfreetype on Mac OS 10.5 and later are not used to build Matplotlib, > > It may be because we still want to su

Re: [matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

2010/10/19 Friedrich Romstedt : > The test suite passes except for some failures on my 10.6 Mac OS X > with yesterday checked-out astraw github repo.  I'll send them in > another thread.  Let's keep tidy :-)  There's more than the symlog > error mentioned by LittleBigBrain on my sys. > > The failur

[matplotlib-devel] patch: bug with twinx and scientific style

I sent this to the -users list a little over a week ago - now resending to -devel list against the latest svn. best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 Paul Ivanov, on 2010-12-23 09:47, wrote: > Václav

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

2010/12/31 John Hunter : > I don't know what the situation is now, but the last version of OS X I > installed was 10.4 and X11 was a separate installation from xcode, if I > recall correctly.  Are you sure it is on by default? I'm not completely sure, but really quite sure. I don't think it's com

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

On Fri, Dec 31, 2010 at 10:00 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > > I've been meaning to publish my installation instructions for > > numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a > > while, but that will have to wait for another day... I've tried

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

On Fri, Dec 31, 2010 at 9:54 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > > Also, not everyone has X11 installed (or does everyone now?) > > > One can opt X11 out at installation time IIRC. But it's a rare case I > believe. > > I don't know what the situation is now, but the l

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

2010/12/10 Ludwig Schwardt : > For the record, I set the following environment variables in > ~/.profile on Snow Leopard: > >    # These compiler flags ensure 32-bit + 64-bit code generation, as > Snow Leopard produces 64-bit code by default >    export MACOSX_DEPLOYMENT_TARGET=10.6 >    export CFL

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

2010/12/10 Christopher Barker : > On 12/9/10 11:57 PM, Ludwig Schwardt wrote: >> This patch reminded me to ask why the builtin libpng, zlib and >> libfreetype on Mac OS 10.5 and later are not used to build Matplotlib, > > It may be because we still want to support OS-X 10.4 . I was not aware of th

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

On 12/9/10 11:57 PM, Ludwig Schwardt wrote: > This patch reminded me to ask why the builtin libpng, zlib and > libfreetype on Mac OS 10.5 and later are not used to build Matplotlib, It may be because we still want to support OS-X 10.4 . Also, not everyone has X11 installed (or does everyone now?)

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

Hi, This patch reminded me to ask why the builtin libpng, zlib and libfreetype on Mac OS 10.5 and later are not used to build Matplotlib, removing the need to download these extra libraries. I was pleased to discover that Snow Leopard shipped with libpng and libfreetype as part of X11, only to fin

[matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

This patch is for make.osx. Note it also changes the python version to 2.7. https://gist.github.com/735337 Uri ... Uri Laserson Graduate Student, Biomedical Engineering Harvard-MIT Division of Health Sciences and Te

[matplotlib-devel] PATCH

I came across this Python syntax bug in matplotlib.figure.add_subplot: raise ValueError( "polar=True, yet projection='%s'. " + "Only one of these arguments should be supplied." % projection) (That code wil

[matplotlib-devel] [PATCH] dysfunction in mpl.cm.get_cmap() (Reporter: LittleBigBrain)

Hi As discussed recently I have a patch, see http://github.com/friedrichromstedt/matplotlib/commit/1ac794b362d143ac6a634b70993d950d8fe4adeb . I'd like to provide a patch in .patch format for this. But I don't know how to do this. Is it simply $git format-patch -1? The test suite passes except

Re: [matplotlib-devel] [PATCH] Discontinuous colormaps are reversed incorrectly

On 10/01/2010 03:59 PM, Stan West wrote: > Hi, developers. I stumbled upon this when I noticed that gist_stern_r > isn't the reverse of gist_stern. As the attached script shows, the > discontinuity in red is wrong, and green stays zero instead of ramping. > The problem seems to be that when cm.revc

Re: [matplotlib-devel] [PATCH] Discontinuous colormaps are reversed incorrectly

On Fri, Oct 1, 2010 at 8:59 PM, Stan West wrote: > Hi, developers. I stumbled upon this when I noticed that gist_stern_r > isn't the reverse of gist_stern. As the attached script shows, the > discontinuity in red is wrong, and green stays zero instead of ramping. The > problem seems to be that w

[matplotlib-devel] [PATCH] Discontinuous colormaps are reversed incorrectly

Hi, developers. I stumbled upon this when I noticed that gist_stern_r isn't the reverse of gist_stern. As the attached script shows, the discontinuity in red is wrong, and green stays zero instead of ramping. The problem seems to be that when cm.revcmap() reverses a linear segment map spec (such as

Re: [matplotlib-devel] Patch for matplotlib.__init__ for speedup

(CC'ing list this time) On Tue, Sep 21, 2010 at 4:30 AM, Dieter Weber wrote: > Hi Ryan, > well, I was rethinking the patch again after sending it, and I got it > wrong. :-/ Accessing a deprecated property would give a KeyError with my > previous patch, as this property is never set. To support de

Re: [matplotlib-devel] Patch for matplotlib.__init__ for speedup

On Mon, Sep 20, 2010 at 6:04 PM, Dieter Weber wrote: > Hi, > I'm currently working on speeding up the legend rendering of matplotlib > as this turns out to be a bottleneck for my application. With some > tracing and profiling, I found that > matplotlib.__init__.RcParams.__getitem__() makes up arou

[matplotlib-devel] Patch for matplotlib.__init__ for speedup

Hi, I'm currently working on speeding up the legend rendering of matplotlib as this turns out to be a bottleneck for my application. With some tracing and profiling, I found that matplotlib.__init__.RcParams.__getitem__() makes up around 10% of the total function calls (by number) in my little test

[matplotlib-devel] [PATCH] Fix line color setting on Qt4

Hello, on matplotlib 1.0, using qt4agg backend, the 'edit curves and lines' option doesn't works. This is a quick patch that fix that problem. It doesn't fix this snippet though: (on lib/matplotlib/backends/qt4_editor/formlayout.py, FormWidget.setup) elif isinstance(value, (list, tuple)): se

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

When you press Ctrl-., the client prompts you to make sure that you really want to restart the kernel. Your work is not at risk from a careless key press. Evan On Wed, Sep 8, 2010 at 9:58 AM, Nathaniel Smith wrote: > On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez wrote: >> ps - tip: Ctrl-. res

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez wrote: > ps - tip: Ctrl-. restarts the kernel Tangentially... please make this something that's a little harder to hit by accident, like Ctrl-Alt-. or a menu item or something? My ipython's regularly hold state that would take a few CPU-days to reco

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

Hi Jeff, On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker wrote: > Fernando: Got it, thanks.  Sounds reasonable to me.  Just playing with it a > bit, one thing I found myself looking for was a way to save the entire > session (inline figures included) to html. > Of course! When is the patch coming?

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On 9/5/10 6:32 PM, Fernando Perez wrote: > Hi Jeff, > > On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker wrote: >> Fernando: That works, but it seems like I have to run show() to make the >> plot appear inline. draw() doesn't do it. Is this the expected behavior? >> > Yes, currently it is, becau

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

Hi Jeff, On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker wrote: > Fernando:  That works, but it seems like I have to run show() to make the > plot appear inline.  draw() doesn't do it.  Is this the expected behavior? > Yes, currently it is, because the show() you're running is actually *our* show(

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On 9/5/10 3:15 PM, Fernando Perez wrote: > Hi Jeff, > > On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker wrote: >> Fernando: I've got ipython-newkernal ipythonqt working on my mac - how do I >> tell it to switch between external plot windows and inline plots? External >> windows seems to be the

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

Hi Jeff, On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker wrote: > > Fernando:  I've got ipython-newkernal ipythonqt working on my mac - how do I > tell it to switch between external plot windows and inline plots?  External > windows seems to be the default... if you start it with --rich, it will

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On 8/30/10 1:21 AM, Fernando Perez wrote: > Hi Eric, > > On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing wrote: >> Impressive--but I don't think I understand why one would want plots rendered >> inline rather than in separate windows. Fernando: I've got ipython-newkernal ipythonqt working on my m

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik wrote: > Ok, I'll give it a shot then. As I mentioned elsewhere, getting it going is a bit rough right now. So unless you really want to play with real bleeding edge code, give us a couple of weeks. It will be much nicer then. Cheers, f -

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez wrote: > On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik wrote: >> >> That'd be great. I think I either want to use regular terminal, or a >> worksheet in the browser. > > You may change your mind when you start playing with the new Qt > terminal :)

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik wrote: > > That'd be great. I think I either want to use regular terminal, or a > worksheet in the browser. You may change your mind when you start playing with the new Qt terminal :) It feels very much like a terminal, except with a ton of little u

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez wrote: > On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: >> Dude, that just blew my mind! >> > > Glad you like it :) > > And needless to say, once the dust settles and someone is willing, the > obvious thing to do is to put a zeromq-http bridg

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: > Dude, that just blew my mind! > > Awesome idea! By the way, I don't know if it was clear, but this wasn't just an idea, it's already implemented: http://fperez.org/tmp/ip-multiclient.png The two windows are talking to the same kernel, the

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: > Dude, that just blew my mind! > Glad you like it :) And needless to say, once the dust settles and someone is willing, the obvious thing to do is to put a zeromq-http bridge and make a web browser-based client, so you can use ipython/matplo

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez wrote: > Hi Eric, > > On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing wrote: > > > > Impressive--but I don't think I understand why one would want plots > rendered > > inline rather than in separate windows. > > It's not 'rather than', it's 'in additio

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

Hi Eric, On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing wrote: > > Impressive--but I don't think I understand why one would want plots rendered > inline rather than in separate windows. It's not 'rather than', it's 'in addition to' :) Imagine you and I are working on a problem together, you have

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On 08/28/2010 09:38 AM, Fernando Perez wrote: > On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing wrote: >> I committed it. >> > > Many thanks Eric, for being so responsive! Fernando, I'm glad to help; ipython is a crucial part of the tool set. > > Some eye candy to give you an idea of what we're g

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing wrote: > I committed it. > Many thanks Eric, for being so responsive! Some eye candy to give you an idea of what we're getting from this work: http://fperez.org/tmp/multiplot.png http://fperez.org/tmp/multiplot2.png The second is the MPL contours e

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

Eric, On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing wrote: > On 08/26/2010 05:13 PM, Brian Granger wrote: >> Hi, >> >> We are in the process of getting our new Qt IPython GUI working with >> matplotlib.  One problem we have found is that the matplotlib qt4 >> backend always creates a QApplication

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

On 08/26/2010 05:13 PM, Brian Granger wrote: > Hi, > > We are in the process of getting our new Qt IPython GUI working with > matplotlib. One problem we have found is that the matplotlib qt4 > backend always creates a QApplication. This is problematic in > situations where another part of an appl

[matplotlib-devel] Patch for Qt4 backend for IPython GUI

Hi, We are in the process of getting our new Qt IPython GUI working with matplotlib. One problem we have found is that the matplotlib qt4 backend always creates a QApplication. This is problematic in situations where another part of an application has already created a QApplication. The fix is

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

Hmm, it seems that somehow I only applied the patch to the trunk. http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8418 But I think the patch also need to be applied to the maint. version. I'll see what I can do. Regards, -JJ On Wed, Aug 25, 2010 at 3:42 AM, Erik

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

Did this fix ever get applied? I was looking at some other svn changes and it still says none of this part of legend.py has been altered... On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee wrote: > On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud wrote: >> Jae-Joon, your patch looks to be effectively

Re: [matplotlib-devel] [PATCH] doc/make.py clean don't fail if directories are missing

On 07/01/2010 10:24 AM, Sandro Tosi wrote: > Hello, > while preparing a test debian pacakge with mpl 1.0rc1, I noticed > doc/make.py clean fails if the directories to remove are missing. > > The simple attached patch (svn diff against tr...@8480) resolves it; > Thanks, committed as r8481. -

[matplotlib-devel] [PATCH] doc/make.py clean don't fail if directories are missing

Hello, while preparing a test debian pacakge with mpl 1.0rc1, I noticed doc/make.py clean fails if the directories to remove are missing. The simple attached patch (svn diff against tr...@8480) resolves it; it might also be nice to wrap the os.remove() calls below in a try: .. except OSError: pass

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud wrote: > Jae-Joon, your patch looks to be effectively the same except for > slightly different behavior when more than 3 points are present... but > that was what was originally intended - the numpoints-> scatterpoints > was a good catch! I'm not sure

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

Jae-Joon, your patch looks to be effectively the same except for slightly different behavior when more than 3 points are present... but that was what was originally intended - the numpoints-> scatterpoints was a good catch! As for allowing an array markerscale, I agree with Jae-Joon... I think the

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

I'm not very kin to implement every possible options for every possible cases. If you need customization beyond what the current "legend" class provide, I recommend you to use proxy artists. http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist I personally think that the d

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

I was trying the patch and I realized a possible use-case that might not have been thought of before. Consider the situation where a user does a scatter plot with markers of two different sizes. Then, it isn't that far-fetched that the user might also want to control the markerscale for each mark

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

Thanks for reporting these. I took a look at your patch and slight revised it (see the attached). While I believe that my patch is compatible to yours, it'll be great if you check my patch to see if I missed anything. I'll commit the change soon. Regards, -JJ On Tue, Jun 8, 2010 at 3:16 PM, Eri

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

Erik, Thanks for addressing this. I actually ran into this problem once a while back, but just figured that I was doing something wrong. I will check out your patch to see how well it works. Ben Root On Tue, Jun 8, 2010 at 2:16 PM, Erik Tollerud wrote: > I noticed some odd behavior in the leg

[matplotlib-devel] Patch/fix for two legend oddities/bugs

I noticed some odd behavior in the legend and managed to track down the source of the problem and make a fix (a diff against the current svn is attached). Specifically, two things were fixed: *The "markerscale" argument for the legend seems to do nothing... The attached diff properly applies the

Re: [matplotlib-devel] [patch] Major/Minor Grid z-order

Jed Frechette wrote: > I made a one line change to matplotlib.axis.Axis.draw (attached) that > simply reverses the order that ticks are plotted in. Argh, I knew that was to easy. This is only a partial fix because the horizontal minor grid still gets drawn above the vertical major grid. -- Je

[matplotlib-devel] [patch] Major/Minor Grid z-order

With the current release 0.99.1 minor grid lines get drawn above major grid lines. This makes it impossible, for example, to have a dark gray major grid and a light gray minor grid because the minor grid will overwrite the major grid. I'm assuming this is a bug but maybe there is a design

[matplotlib-devel] Patch to extend functionality of Figure.legend

Hello all, I have written a small patch which extends the functionality of Figure.legend and pyplot.figlegend to match that of Axes.legend. This patch allows figlegend to automatically build a legend for lines with the "label" property set when figlegend is called without a list of strings or

Re: [matplotlib-devel] patch submission - rectangle selector button select

On Tue, Feb 23, 2010 at 10:22 AM, Ben Axelrod wrote: > Here is a patch for a new feature for the rectangle selector.  it allows the > user to specify which mouse button or buttons to use for the rectangle > selection.  Also included in the diff is a one line change to the > rectangle_selector e

[matplotlib-devel] patch submission - rectangle selector button select

Here is a patch for a new feature for the rectangle selector. it allows the user to specify which mouse button or buttons to use for the rectangle selection. Also included in the diff is a one line change to the rectangle_selector example code to demonstrate the use of the feature. Thanks,

  1   2   3   >