Re: [matplotlib-devel] Pull #2210 adding namespace package mpl_toolkits and Python 2.7

On 2015/07/14 3:59 AM, Albert Chin wrote: > I've built matplotlib-1.4.3 with Python 2.7.5, 3.3.2, 3.4.3. Python > 3.3.2 and 3.4.3 work ok. With Python 2.7.5, I get: > File "/tmp/lines3d_demo.py", line 2, in >from mpl_toolkits.mplot3d import Axes3D >ImportError: No module named mpl

[matplotlib-devel] Important thread on IPython-dev

There is a long thread on IPython-dev discussing how to make matplotlib "just work" in a notebook without requiring "%matplotlib inline" or any other such magic at the top. As a side topic in the thread, there are comments as to how useful "%pylab" still is for real work. http://article.gmane.

Re: [matplotlib-devel] Colormap survey results

On 2015/07/01 1:56 PM, Nathaniel Smith wrote: > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith wrote: > > [...snip discussion of how option D was the favorite of 80% of people > in the survey...] > >> So the next question is where we go from here. One thing we need to do is get some of these ma

Re: [matplotlib-devel] pyplot functions: do you rely on the "hold" kwarg?

On 2015/06/07 12:05 PM, Nathaniel Smith wrote: > On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing wrote: >> Matplotlib's pyplot retains quite a few vestiges from its original >> Matlab-workalike heritage; we would like to gradually eliminate those >> that no longer make sen

[matplotlib-devel] pyplot functions: do you rely on the "hold" kwarg?

Matplotlib's pyplot retains quite a few vestiges from its original Matlab-workalike heritage; we would like to gradually eliminate those that no longer make sense. One such candidate is the "hold" kwarg that every pyplot function has, with a "True" default. I don't think it serves any useful

Re: [matplotlib-devel] RFC: candidates for a new default colormap

On 2015/06/04 9:52 AM, Alexander Heger wrote: > When used in talks, you can see the green laser pointer > better on top of C. And perhaps a red laser pointer better on top of D? --

Re: [matplotlib-devel] RFC: candidates for a new default colormap

On 2015/06/03 12:27 PM, Nathaniel Smith wrote: We also tried tweaking it a bit to end on a more saturated yellow, which I think helps increase contrast in the deuteranomalous version in particular, and put this on the website as an "option D": https://bids.github.io/colormap/images/screenshot

Re: [matplotlib-devel] RFC: candidates for a new default colormap

On 2015/06/02 7:58 PM, Nathaniel Smith wrote: On Tue, Jun 2, 2015 at 10:03 PM, Paul Ivanov wrote: That said, if you want to play around with the editor tool, it's linked on the webpage :-). This is a really nice tool! Attached is an example of a map that circles the other direction, and t

Re: [matplotlib-devel] RFC: candidates for a new default colormap

On 2015/06/02 3:46 PM, Nathaniel Smith wrote: > Hi all, > > As was hinted at in a previous thread, Stéfan van der Walt and I have > been using some Fancy Color Technology to attempt to design a new > colormap intended to become matplotlib's new default. (Down with jet!) > > Unfortunately, while our

Re: [matplotlib-devel] Question about getters and setters.

ugh interest. Eric > > Cheers, > > Brian > > On Wed, May 13, 2015 at 9:36 PM, Eric Firing <mailto:efir...@hawaii.edu>> wrote: > > On 2015/05/13 5:47 PM, Neil Girdhar wrote: > > You're right. My angle is I just want the setters and getters. Writ

Re: [matplotlib-devel] Question about getters and setters.

On 2015/05/13 5:47 PM, Neil Girdhar wrote: > You're right. My angle is I just want the setters and getters. Writing > set_ and get_ feels like the C++ prison I thought I had escaped :) > John Hunter once commented that if he were doing it over again he would not have put in all the set_ and get_

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

mailto:tcasw...@gmail.com>> wrote: >> >>> The other thing that should be done is to unify the (I think >>> 7?!?) unique ways to draw arrows in mpl. >>> >>> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar >&g

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

exchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 > > The first two look like garbage. The last one is the only one that > looks good imho. That depends on the application, and the observer. Eric > > Best, > > Neil > >

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

On 2015/05/13 9:36 AM, Neil Girdhar wrote: > I don't know matplotlib well enough (yet) to know what the change would > consist of. > > I suggest you take a look at the beautiful tikz manual: > http://pgf.sourceforge.net/pgf_CVS.pdf Very helpful, thank you. > > The arrows.meta on page 201–212 are

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

On 2015/05/13 12:39 AM, Neil Girdhar wrote: > TikZ is an extremely well-designed library for generating professional > figures within the cumbersome TeX framework. Currently, my work flow is > to generate TikZ code using Python. The TikZ is compiled into PDFs, > which are then included in my LaTe

Re: [matplotlib-devel] Why num in manager?

On 2015/05/06 9:19 AM, Federico Ariza wrote: > Hello > > Is there any reason why the "num" property is assigned to the manager > and not to the figure? I think this is because the figure is at the object-oriented API level. The manager is in the pyplot state-machine level. > Pyplot.gcf is to g

Re: [matplotlib-devel] release strategy and the color revolution

d. To my eye, there is no bar of uniform color, and, even more general, no duplication of color. The only quibble may be the saturation toward 0 and toward 1. This is a good scheme, actually, I'd be interesting in the algorithm to implement in idl. Niklas On Sun, Apr 5, 2015 at 8:38 AM, E

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/04/04 9:20 PM, Nathaniel Smith wrote: > While it's taking longer than hoped, just to reassure you that this > isn't total vaporware, here's a screenshot from the colormap designer > that Stéfan van der Walt and I have been working on... still needs > fine-tuning (which at this point probab

Re: [matplotlib-devel] Alternative way of specifying plot layout

On 2015/03/18 7:42 AM, Benjamin Root wrote: > A thought... could this perhaps be extended somehow to specify colorbars > in the layout? A lower-case letter could indicate a colorbar-size Axes: layout = ["ABc", "DE ", "ff "] would put a vertical think axes to the right of B,

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/18 2:39 PM, Nathaniel Smith wrote: > On Feb 16, 2015 3:39 PM, "Eric Firing" wrote: >> >> On 2015/02/16 1:29 PM, Michael Waskom wrote: >> >>> Nathaniel's January 9 message in that thread (can't figure out how to >>> link to i

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/23 8:16 AM, Benjamin Root wrote: > Interesting choices, and I think we are on the right paths (no pun > intended) through the two possible colors. However, I think the same > problem arises that I noted before. Both ends of the colormap are nearly > black to nearly white. IIRC, our perce

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/18 2:39 PM, Nathaniel Smith wrote: > On Feb 16, 2015 3:39 PM, "Eric Firing" wrote: >> >> On 2015/02/16 1:29 PM, Michael Waskom wrote: >> >>> Nathaniel's January 9 message in that thread (can't figure out how to >>> link to i

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/18 2:42 PM, Olga Botvinnik wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. Provided we can find a good colormap for that p

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/18 6:31 AM, Benjamin Root wrote: > The problem I have with hcl is that while it is technically "colorful" > (or whatever the term may be), only the reds really come out because the > other colors are only used when either really light or really dark. > Perhaps squashing the brightness ra

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/16 1:29 PM, Michael Waskom wrote: > Nathaniel's January 9 message in that thread (can't figure out how to > link to it in the archives) had a suggestion that I thought was very > promising, to do something similar to Parula but rotate around the hue > circle the other direction so that

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/16 1:19 PM, Michael Waskom wrote: > Here are two palettes that are optimized for colorblindness: > http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/#a-colorblind-friendly-palette > Strange--they have both red and green, so I would never have expected them to work. The yellow look

Re: [matplotlib-devel] release strategy and the color revolution

first two colors be blue and red would be better, I think. Eric > On Mon, Feb 16, 2015 at 14:40 Eric Firing <mailto:efir...@hawaii.edu>> wrote: > > On 2015/02/16 12:01 PM, Eric Firing wrote: > > > > > Proposals for the new co

Re: [matplotlib-devel] release strategy and the color revolution

On 2015/02/16 12:01 PM, Eric Firing wrote: > > Proposals for the new color cycle for line plots? Here is a proposal: we simply adopt seaborn's cycle. Eric -- Download BIRT iHub F-Type - The Free Enterprise

[matplotlib-devel] release strategy and the color revolution

For a long time there has been discussion of replacing the matplotlib default color map and color cycle, but we still haven't done it. We need a clear set of criteria, and a small set of good alternatives, leading to a decision, a PR, and a release. Now is the time. Here is what I think is the

Re: [matplotlib-devel] Capitalization of Matplotlib

On 2015/02/16 8:38 AM, Nelle Varoquaux wrote: > On 16 February 2015 at 19:36, Eric Firing wrote: >> On 2015/02/16 8:23 AM, Nelle Varoquaux wrote: >>> IMO, never. >> >> Rationale, please? > > Consistency: it is never capitalized in matplotlib's documentatio

Re: [matplotlib-devel] Capitalization of Matplotlib

On 2015/02/16 8:23 AM, Nelle Varoquaux wrote: > IMO, never. Rationale, please? Eric -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashb

Re: [matplotlib-devel] Capitalization of Matplotlib

On 2015/02/16 8:16 AM, Benjamin Root wrote: > I am in the final rounds of edits for my book and a question has come up > between me and the editors. When should the matplotlib be capitalized? > > 1) never > 2) mostly never (even in the beginning of a sentence), except when used > in a title > 3) us

Re: [matplotlib-devel] Release planning/milestones

On 2015/02/08 12:05 PM, Thomas Caswell wrote: > The goal of pulling pyplot out of backend_bases is exactly that, to be > able to do everything using the OO interface in a convenient way. > https://github.com/matplotlib/matplotlib/pull/4082 The above PR is an illustration of one approach to making

Re: [matplotlib-devel] ginput in nbagg backend to use in IPython Notebooks

On 2015/01/27 6:51 AM, Mark wrote: > ginput works fine in a GUI window, but there is no matplotlib widget > where I can type text or numbers in a box. Like the FloatTextWidget in > IPython. Or am I missing something? I think you are correct. John Hunter explicitly avoided the temptation to keep

Re: [matplotlib-devel] using waffle.io for issue management

ht > need to log in to see it). It has been set up for a while now and no > one has complained about GH breaking, so I think it is pretty > side-effect less. > > Tom > > On Tue Jan 20 2015 at 5:10:47 PM Eric Firing <mailto:efir...@hawaii.edu>> wrote: > > L

Re: [matplotlib-devel] using waffle.io for issue management

Looks good to me. As far as I can see, it is not doing anything that would interfere with ordinary direct github use. What determines the column assignments? A combination of tags and open/closed status? Is there something else going on? Eric On 2015/01/20 6:13 AM, Michael Droettboom wrote:

Re: [matplotlib-devel] using waffle.io for issue management

On 2015/01/17 9:29 AM, Thomas Caswell wrote: > Hey all, > > We have set up waffle.io to try and help manage our > issues: https://waffle.io/matplotlib/ That link gives me a 404. Eric > > If you have commit rights, you should be able to move the cards around. > > Any thoughts o

Re: [matplotlib-devel] Date overhaul?

On 2015/01/09 9:54 AM, Paul Ganssle wrote: > Thanks for the responses. If no one minds, I'm take a look at how to > best implement datetime64 this weekend and the degree to which it might > be useful, then maybe I can start an MEP for it. Paul, I think everyone will be delighted to have you do th

Re: [matplotlib-devel] Date overhaul?

On 2015/01/07 11:48 AM, Paul Ganssle wrote: > Recently I took a crack at fixing some of the bugs in dates.py, and it > seems like there's been some talk of overhauling how dates are handled. > I don't see an MEP for that, so I'm wondering if anyone can give me some > more details about what the im

Re: [matplotlib-devel] Who runs our twitter account?

On 2014/12/20, 10:45 AM, Thomas Caswell wrote: > We have a Twitter account?!? It's news to me, too. Maybe it was started by someone not closely connected with matplotlib. I've never paid any attention to twitter, and don't expect to in the future. If I had any control over it, I would oppose

Re: [matplotlib-devel] basemap development

On 2014/12/10, 8:01 AM, Benjamin Root wrote: > I just noticed that the last update to basemap's master branch was March > 31st, but there are bug reports piling up, so people are still > interested in at least seeing it still supported. Perhaps some of us > should make a concerted effort to address

Re: [matplotlib-devel] subtle design difference with Wx backend from others

On 2014/11/23, 12:18 PM, Benjamin Root wrote: > Reading through the backend_wx.py code, I noticed a small deviation from > the other interactive backends. All other > new_figure_manager_given_figure() separately creates a canvas and > manager object (which, in turn, creates the window object) and h

Re: [matplotlib-devel] cocoaagg figure not have a navigation toolbar?

On 2014/11/22, 7:43 PM, Benjamin Root wrote: > I don't have a mac to double-check, but reading through the > backend_cocoaagg.py, I don't see any creation of a navigation toolbar? > Is this assumption right? Probably so: from matplotlib import cbook cbook.warn_deprecated( '1.3', message

Re: [matplotlib-devel] Better defaults all around?

On 2014/11/22, 9:06 AM, gary ruben wrote: > A few thoughts to add to the excellent ones to date, to do with colorbar > behaviour. > My general comment would be that if the axis tick formatter defaults are > changed not to forget about the colorbar as I typically find it needs > more tweaking than t

Re: [matplotlib-devel] Matplotlib's new default colormap

On 2014/11/21, 4:42 PM, Nathaniel Smith wrote: > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale wrote: >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson wrote: >>> >>> Please use this thread to discuss the best choice for a new default >>> matplotlib colormap. >>> >>> This follows on from a discussio

Re: [matplotlib-devel] tk backend broken (somehow?)

On 2014/11/18, 9:55 PM, Benjamin Root wrote: > Why do we have a function in setupext.py called > "hardcoded_tcl_config()"? In any case, it looks like all I needed to do > was change the default value for line 156 to be the prefix location of > my miniconda install, and things started to work again!

Re: [matplotlib-devel] Development issue: Assign labels to colorbar extensions

On 2014/11/16, 10:21 AM, j1 wrote: > I have posted this in the user sub forum as well because i'm not sure that it > is a user issue or development issue. > Information about my problem and my code are here > > http://matplotlib.1069221.n5.nabble.com/Assign-labels-to-colorbar-extensions-user-or-dev

Re: [matplotlib-devel] Tk backend different from others

On 2014/11/15, 6:14 AM, Benjamin Root wrote: > I was working on my embedding chapter of my book when I noticed a subtle > difference in the tkagg backend from other interactive backends. First, > all other interactive Canvas classes inherit their respective backend's > widget: > > ``` > ben@tigger:

Re: [matplotlib-devel] remove old branches

On 2014/11/01, 5:49 AM, Thomas Caswell wrote: > Does anyone protest to removing all of the branches from the main repo > except: > > - master > - v1.4.x > - v1.4.2-doc > > Having old branches around can lead to confusion (see > https://github.com/matplotlib/matplotlib/pull/3748#issuecomment-6

Re: [matplotlib-devel] Matlab parula colormap

On 2014/10/28, 10:30 PM, Pierre Haessig wrote: > Le 21/10/2014 10:09, Eric Firing a écrit : >> That's the big question: what is the IP status? > So Nathaniel and I asked, and the blog post author, Steve Eddins, took > the time to answer : > > Nathaniel and Pierre—T

Re: [matplotlib-devel] Interesting mpl wrapper

On 2014/10/26, 4:52 AM, Thomas Caswell wrote: > https://github.com/HamsterHuey/easyplot?utm_content=buffer48700&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer > > I have not looked at it carefully, but it is something we might want to > be aware of when thinking about API re-designs.

Re: [matplotlib-devel] Matlab parula colormap

On 2014/10/21, 6:27 AM, Nathaniel Smith wrote: > On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig > wrote: >> Hi, >> >> Matlab is now shipping with a new default colormap, named "parula" >> [1,2]. It is meant to overcome the many issues of the current default >> "jet". It seems that the RGB values

Re: [matplotlib-devel] Matlab parula colormap

On 2014/10/20, 9:50 PM, Pierre Haessig wrote: > Hi, > > Matlab is now shipping with a new default colormap, named "parula" > [1,2]. It is meant to overcome the many issues of the current default > "jet". It seems that the RGB values of this new colormap are already > onnline [3]. > > So my question

Re: [matplotlib-devel] v1.4.1rc1 delayed :(

I'm not sure what to do about https://github.com/matplotlib/matplotlib/issues/3621 either. In general, I think it is best to have strings like this left in their native mode, not coerced to unicode, but that is contrary to the strategy decided upon when "from __future__ import unicode_literals

Re: [matplotlib-devel] pyplot-OO convergence

On 2014/09/28, 12:42 PM, Till Stensitzki wrote: > One point which is often neglected while discussing > oo- vs the pyplot-api is that today introspection tools > quite often fail to work with mpl-oo but are > perfectly fine with the pyplot module. E.g. if i am writing > some kind of helper oder plo

Re: [matplotlib-devel] pyplot-OO convergence

Tom, Thanks for https://github.com/matplotlib/matplotlib/pull/3587, which provides a concise draft implementation of your proposal, in concept if not in detail. Although this provides a way to get interactive drawing while specifying axes and figures explicitly, it is still using two interface

Re: [matplotlib-devel] pyplot-OO convergence

On 2014/09/28, 8:22 AM, Thomas Caswell wrote: > On Sun, Sep 28, 2014 at 1:52 PM, Eric Firing wrote: >> >> I don't understand your objection. In which cases do the returns depend on >> the arguments? "title" returns the title text object, regardless of whether

Re: [matplotlib-devel] pyplot-OO convergence

resent, this doesn't work well, because the OO approach is not interactive enough, and using the getters and setters is clumsy when typing at the console--in demonstrating, teaching, learning, and exploring interactively, every keystroke counts! Eric > > Tom > > > On Sat, Sep 2

[matplotlib-devel] pyplot-OO convergence

One of the biggest causes of controversy in mpl, and of difficulty in teaching and learning mpl, is the divide between pyplot and the rest of the library. There are at least two aspects: 1) plt.title() versus ax.set_title(), etc; that is, all the clunky getters and setters on the OO side. JDH

Re: [matplotlib-devel] OSX framework detection

On 2014/08/15, 10:53 AM, Derek Homeier wrote: > On 15 Aug 2014, at 10:39 pm, Eric Firing > wrote: > >> On 2014/08/15, 9:37 AM, Derek Homeier wrote: >> >>> Just to make sure I understand - this is about whether the MPL >>> macosx backend would run with non-fr

[matplotlib-devel] ipython slowdown with qt

On 2014/08/15, 9:37 AM, Derek Homeier wrote: > When using MPL with ipython —pylab and the Quartz version of PyQT4, > the interpreter seems to be slow down extremely after running for a > little while. Weirdly this is not connected to any graphics display > and in fact happens even without any plott

Re: [matplotlib-devel] macosx broken on py3.4 (homebrew, anaconda)

On 2014/08/13, 1:19 PM, Eric Firing wrote: > Unless there is something odd about my machine and attempted setups, we > have a very bad situation. I have OS X 10.9 (Mavericks). I am seeing > the same problem with homebrew python and pip-installed numpy, > pip-installed mpl from git

[matplotlib-devel] macosx broken on py3.4 (homebrew, anaconda)

Unless there is something odd about my machine and attempted setups, we have a very bad situation. I have OS X 10.9 (Mavericks). I am seeing the same problem with homebrew python and pip-installed numpy, pip-installed mpl from git 1.4rc3, and from Anaconda 2.0.1, all with python 3.4. Do the

Re: [matplotlib-devel] 1.4.0rc1 has been tagged

On 2014/07/12, 7:20 PM, Thomas Caswell wrote: > Hey all, > > After a very productive sprint at scipy (according to pluse, we merged > 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged > the first release candidate (1.4.0rc1). > > There are a good number of outstanding issues wi

[matplotlib-devel] numpy indexing changes

This is just a heads-up: some indexing changes in the numpy 1.9rc break matplotlib, as revealed in the mpl tests; there is a discussion on the numpy-discussion list about what to do about it. It looks like they will back off on the changes and put in deprecations, giving us time to modify mpl.

[matplotlib-devel] Add a cookbook doc repo to github?

Documentation is critical for helping people use mpl effectively (or at all). Our core documentation has many shortcomings, and needs much more attention than it gets. But that's another topic. This message is prompted by https://github.com/matplotlib/matplotlib/pull/3088, which has led to t

Re: [matplotlib-devel] nosetests: too slow, too much memory

On 2014/06/04 6:26 AM, Benjamin Root wrote: > A theory... > > If I remember correctly, the nosttests was set up to execute in parallel > using the default Multiprocessing settings, which is to have a process > worker for each available CPU core. Perhaps this might be the crux of > the issue with so

[matplotlib-devel] nosetests: too slow, too much memory

Our standard test has gotten out of control. The most serious problem is that running a full test suite now fails on a linux VM with 4 GB--it's out of memory. Half-way through the set, it is already using more than 2 GB. That's ridiculous. Running nosetests separately on each test module keep

Re: [matplotlib-devel] v1.4 feature freeze + release timeline

On 2014/05/15 5:16 PM, Thomas Caswell wrote: > Sorry for dropping the ball on moving things forward. On the contrary, you have been doing a great job on this, and you deserve a lot of thanks from all of us. > > I would propose a feature freeze this weekend and the goal of getting > the first RC

[matplotlib-devel] big memory leak when running tests?

When I try to run matplotlib/tests.py on master, linux, python 2.7, in a virtual machine with 4GB, the memory use grows out of control. Just running the test_axes chews up 1.5 G. Has anyone else seen this? Eric -- "Ac

[matplotlib-devel] PEP 8 change in Travis

Does anyone know why we are seeing a huge number of PEP 8 failures now? It looks to me like it is a change in which modules are subject to the test, or in which tests are grounds for failure. I don't know how all this is set up, though. Eric -

Re: [matplotlib-devel] unused variables

On 2014/03/06 3:47 AM, Federico Ariza wrote: > Hello everybody > > Stupid simple question > Is there a policy/tradition/convention to name unused variables inside the > code? Not yet. > > Even better, if I see '''var''', can I replace it with '''_var''' and > nobody is going to complain? That m

Re: [matplotlib-devel] Developer summit at Scipy?

On 2014/02/27 6:28 AM, Michael Droettboom wrote: > How many matplotlib developers are planning to attend SciPy this year? Most likely I will not. Eric > > If we used some of our funds to support an extra hotel night, would any > of you be interested in spending an extra day for a "matplotlib > d

[matplotlib-devel] New contouring algorithm

On 2014/01/30 10:22 PM, Ian Thomas wrote: > (Taking this away from the mailing list as it is going off topic). I'm putting it on the devel list; it will be good for others to know this is in the works, and be able to advise on strategy before it gets to the PR stage. > > The new contour code c

Re: [matplotlib-devel] Plot or Not Results Summary

On 2014/01/13 9:58 AM, Chris Beaumont wrote: > Hi Everyone, > > I found some time to look at the votes from the "Plot or Not?" > experiment Adrian Price-Whelan and I ran during SciPy last summer. You > can take a look at my summary at > http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-r

Re: [matplotlib-devel] MEP22 new proposal for user interaction

On 2014/01/13 5:11 AM, Michael Droettboom wrote: > This looks quite good to me. > And to me. If the implementation works out well, this will be a very nice and much needed refactoring. Eric > I'd like some feedback from Thomas Caswell, who's looked at this part of > the code much more than I h

Re: [matplotlib-devel] Introducing myself

On 2013/12/15 3:54 PM, rajan2...@csproto.net wrote: > Hi all, > My name is Nagarajan (Rajan for short) and I have been a matplotlib user > over the last 4 years (used it on/off). I wanted to thank you all for > creating an excellent software, and also wanted to contribute back to > the project. > >

Re: [matplotlib-devel] Gtk3 app that calls matplotlib

the module, so long as one does not call that one highest-level function. To embed, one simply includes the contents of that function but without the pyplot parts. Eric > > Federico > > On Fri, Oct 11, 2013 at 1:32 PM, Eric Firing wrote: >> On 2013/10/11 7:12 AM, Federico Ariz

Re: [matplotlib-devel] Gtk3 app that calls matplotlib

On 2013/10/11 7:12 AM, Federico Ariza wrote: > I am not embedding, just launching, as the example shows. No, your example shows that you *are* embedding. You are running your own Gtk.main(). That's embedding. -- Octobe

Re: [matplotlib-devel] Directories for C/C++ extensions

On 2013/10/06 10:09 AM, Ian Thomas wrote: > Fellow developers, > > I am working on a PR to replace the use of matplotlib.delaunay with the > Qhull library. Installation will be similar to the existing packages > LibAgg and CXX in that if the system already has a sufficiently recent > version of Qh

Re: [matplotlib-devel] matplotlib user guide

On 2013/09/24 10:19 PM, mark wrote: > hi matplotlib developers > > I have been considering the matplotlib user guide structure and it > has occured to me that there are two user guides interleaved here: >1. Introduction for new users >2. Library tour for developers > > I think that this str

Re: [matplotlib-devel] master macosx backend broken?

On 2013/09/17 4:14 PM, Damon McDougall wrote: > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > wrote: >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing wrote: >>> When I build mpl from master on python.org python 2.7, Mountain Lion, >>> and try to plot anything

Re: [matplotlib-devel] master macosx backend broken?

Eric > > -matt > > On Sep 17, 2013 7:15 PM, "Damon McDougall" <mailto:damon.mcdoug...@gmail.com>> wrote: > > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > mailto:damon.mcdoug...@gmail.com>> wrote: > > On Tue, Sep 17, 2013

[matplotlib-devel] master macosx backend broken?

When I build mpl from master on python.org python 2.7, Mountain Lion, and try to plot anything with the macosx backend, I am now getting an Apple crash--the plot window flashes up and vanishes, and a big OS X crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have never seen an

Re: [matplotlib-devel] matplotlib 1.3.1

On 2013/09/17 3:03 AM, Michael Droettboom wrote: > I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1 > release. We have 6 blocker and 12 known bugs on that branch still. I > hope to devote some time to triaging and closing as many of these as I > can this week, and then maybe

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

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] 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] 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] 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] 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

[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

[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

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

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] 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] 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 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:efir...@hawaii.edu>> wrote: >

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 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

  1   2   3   4   5   6   7   8   9   10   >