Are you wanting to link against anything other than that installed with
conda?
The output of setup.py is normally pretty helpful at letting you know which
library it has found to build against.
On 20 July 2015 at 01:54, Brian Granger elliso...@gmail.com wrote:
Hi all,
I am trying to get a dev
For what it is worth, if D were made the default colormap, I would be very
happy.
On 1 July 2015 at 22:35, Thomas Caswell tcasw...@gmail.com wrote:
We would like to tag 1.5 around scipy and it would be nice to get the new
color maps out, even if they are not yet the default.
On Wed, Jul 1,
,
Phil Elson
(github: @pelson | twitter: @pypelson)
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things
Orchestrating MPL tutorials and talks in this thread would be a good idea.
I'd be happy to help anybody planning on submitting anything relating
specifically to matplotlib, and wonder if we should do a state of
matplotlib type talk similar to the one Mike did 2 years ago.
On 13 March 2015 at
Awesome work! Full credit to Tom who has driven this release.
The nbagg backend is looking great - some pretty swish new features thanks
to hard work from Steven Silvester and Thomas Caswell!
On 2 February 2015 at 10:58, Jens Nielsen jenshniel...@gmail.com wrote:
Thanks Tom,
I ran the test
post to show various color spaces in d3.js which may be
of interest http://bl.ocks.org/mbostock/3014589.
On 4 December 2014 at 14:38, Maximilian Albert maximilian.alb...@gmail.com
wrote:
Hi all,
I had a discussion with Phil Elson about this last weekend during the
Bloomberg Open Source Day
P.S. I just found
http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker
On 22 December 2014 at 11:21, Phil Elson pelson@gmail.com wrote:
Thanks for all the contributions so far. Looks like matplotlib is blessed
with people who are far more knowledgeable than I on the subject
There will be an open source Python sprint, hosted by Bloomberg, this
weekend in London. The event will be attended by core developers of many of
the major scientific Python packages (IPython, numpy, scipy, pandas,
scikit-learn) who will act as mentors to those who would like to get
involved in
?
On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com
wrote:
Many of you will be aware of there has been an ongoing issue (#875,
http://goo.gl/xLZvuL) which recommends the removal of Jet as the
default colormap in matplotlib.
The argument against Jet is compelling and I think
Please use this thread to discuss the best choice for a new *default*
matplotlib colormap.
This follows on from a discussion on the matplotlib-devel mailing list
entitled How to move beyond JET as the default matplotlib colormap.
It is accepted that there can never be a *best* colormap for *all*
Many of you will be aware of there has been an ongoing issue (#875,
http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
colormap in matplotlib.
The argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously
Isn't the XKCD stuff baked into the Agg backend. Is it even possible to
produce XKCD svg or PDFs?
On 18 November 2014 17:01, Jens Nielsen jenshniel...@gmail.com wrote:
I can reproduce it with the following traceback. Can you please open a bug
report on Github for this issue?
```
Traceback
Mike made some changes to this recently.
https://github.com/matplotlib/matplotlib/pull/3778
May be the cause.
On 16 November 2014 18:12, Benjamin Root ben.r...@ou.edu wrote:
And with my continuing saga of backend-specific things...
I was using conda, but because it does not ship with pygtk
I just wanted to let you know that there is currently a vacancy for a
full-time developer at the Met Office, the UK's National Weather Service,
within our Analysis, Visualisation and Data (AVD) team.
I'm posting on this list as the Met Office's AVD team are heavily involved
in the development of
Cross posted to IPython-dev and mpl-dev.
Over the Easter holidays I had a chance to take a look at implementing a
new matplotlib backend which would allow interactive figures inline in the
IPython notebook. It's something that has been on the radar for a couple of
years now, with work needed from
I've only just seen this, but thanks for sharing! The blog post was well
thought out and very interesting.
I really liked the latest style idea - I think that is something that
gives us a bit of flexibility to change our minds about styles and continue
to keep everybody moving forward with
Sadly I wont be - it is a bit of a long way for a non-scientific
conference. Hoping to be able to attend SciPy again this year - there was a
strong mpl contingent and we had some really successful introductory
sprints held.
Cheers,
On 10 January 2014 14:49, Federico Ariza
Looks like there could be some white space around that block, as you say. (
https://raw.github.com/matplotlib/matplotlib/master/doc/contents.rst and
https://github.com/matplotlib/matplotlib/blob/master/doc/contents.rst).
Have you ever built the mpl docs? Are you interested in trying to fix this
Hi Federico,
I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.
Keep up the great work, and continue trying to get
Ian Thomas has been working on including some of the functionality from
Qhull into the matplotlib triangulation pipeline (
https://github.com/matplotlib/matplotlib/pull/2504).
After a thorough development and testing cycle this PR has now been merged
onto master, but I just wanted to give a
I'm very pleased to announce Andrew Dawson as a new core developer on the
cartopy project. As well as making significant contributions to many of the
fundamental components of cartopy, he has taken the time to extend
documentation, review other PRs and help users with issues raised on
github. Of
Very nice.
Thanks for sharing Jason.
On 15 November 2013 13:18, Jason Grout jason-s...@creativetrax.com wrote:
On 11/14/13 7:24 PM, Jason Grout wrote:
Following a very helpful conversation with Michael this morning in the
dev hangout, I got this working with the current master (of
For the record, I've spoken to Mark about this face-to-face in the past,
and I think he has some great ideas about how the user guide should look.
Personally I would agree that the user guide is currently not targeted
enough (it takes 3 pages full of text before getting to a simple plt.plot()
)
Is it time to have the discussion about dropping the MacOS backend?
I know an incredible amount of top quality developer time has gone into it,
but in truth it is not up to the *Agg backends and without another massive
amount of work, never will be. Not to mention the drag that having YAB (yet
Sounds good. I'll do what I can to close down some of the bugs too.
Now would also be a good time to announce a v1.4 date IMHO...
On 17 September 2013 22:54, Damon McDougall damon.mcdoug...@gmail.comwrote:
On Tue, Sep 17, 2013 at 8:03 AM, Michael Droettboom md...@stsci.edu
wrote:
I think
Wooho. New year, new release! It's going to be a busy Christmas :-)
On 18 September 2013 16:14, Michael Droettboom md...@stsci.edu wrote:
Looking approximately six months after when 1.3.0 was released
(31-07-2013, after much delay), puts us in the January timeframe for
release candidates for
Thanks Andreas,
I couldn't find any test runner script / method.
There is currently no python setup.py tests type runner (which would be
welcomed), but the obvious test runner is to use nose - something like
nosetests cartopy should do the trick. It'd also be very easy to put a
function in the
Just in case anybody who wanted to attend the discussion knows, this
meeting is taking place in ~40 minutes. (See
https://www.google.com/calendar/embed?src=79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.comctz=America/New_Yorkas
linked from the matplotlib wiki).
Cheers,
Phil
On 5 August
Sounds like a good idea to me.
In terms of when - I think the IPython guys have picked a good time (10am
US Pacific time, or 5pm GMT/UTC) to have the meeting to maximise the
attendance from the Americas and Europe, though I appreciate that no time
is perfect for everybody. For instance, I know
I can't work out if I'm having a brain block or it really can't be done,
but I'm trying to produce a pcolormesh with alpha without the nasty edges
seen in the attached image
[image: Inline images 1]
The code to reproduce:
import matplotlib.pyplot as plt
import numpy.random
d =
event, as Phil Elson likes to repeatedly point out (wink), we
have a great deal of awesome new features in master that it would be
great to get out. As for time frame, I think if we aim for a 1.3.0rc1
of May 27, that's within a good time frame to get something out in time
for Scipy
In general I like the idea, but I'm not sure what behaviour I would expect
in this case:
plt.imshow(z, label='foobar')
plt.imshow(z, label='wibble')
plt.colorbar()
I suppose it is an analogous problem to:
plt.imshow(z, cmap='hot')
plt.imshow(z, cmap='jet')
plt.colorbar()
Which produces a
OOI Is anyone planning to run an advanced matplotlib tutorial this year?
I've added a few ideas to
https://github.com/matplotlib/matplotlib/wiki/Scipy-2013 - some are more
advanced than others and would need a bit of planning should we decide to
run with them.
On 23 March 2013 17:06, Damon
I am putting together a beginners tutorial proposal that I will submit soon
That's great to hear! Are you planning on making the tutorial material part
of mpl's docs or using the content that is already out there?
On 25 March 2013 16:16, Benjamin Root ben.r...@ou.edu wrote:
I am putting
are most likely. Though I should note, I'm not against it
being included in mpl as an extension, if you would prefer that.
Thanks again for sharing!
On 13 March 2013 10:08, Phil Elson pelson@gmail.com wrote:
Thanks for this Joe, mpldatacursor looks like an excellent piece of work -
I for one
to compile your examples, but it seems perhaps you forget to
include a file -- pixel_formats.hpp? It's not in the agg24 source tree.
Mike
On 03/06/2013 12:06 PM, Phil Elson wrote:
Smart rendering of adjacent, anti-aliased patches is a question which
has come up a couple of times
Smart rendering of adjacent, anti-aliased patches is a question which has
come up a couple of times in various guises in the past.
It is my understanding that the lack of this functionality led us to
disable anti-aliasing for contouring and is the reason the following image
has a white stripe
Nothing springs to mind. Perhaps the install is failing due to
https://github.com/matplotlib/matplotlib/pull/1454?
Sounds like you don't have access to the machine to check that
$ python -c import matplotlib
Works?
On 2 March 2013 17:25, Thomas Kluyver tho...@kluyver.me.uk wrote:
The
Hi Todd,
I agree with the principle of properties - it will make much of the mpl
codebase (and user code) more pythonic, so thanks for proposing this.
Would you be able to give an example of how you propose setters such as
Axes.set_xlim might make use of properties. The particular example I have
@mdboom - that sounds like roaring agreement to me. :-)
Lets go for it.
On 14 January 2013 20:34, Damon McDougall damon.mcdoug...@gmail.com wrote:
On Fri, Jan 11, 2013 at 12:33 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/11 5:38 AM, Michael Droettboom wrote:
As pointed out in
I agree with getting going on these two. My preference is for the mandrill
image, but the truth is, I don't have a problem with what is already
there... so any of the following outcomes would be fine with me:
1. We merge mandrill close #1599
2. We merge Ada close #1581
3. We close #1581
I'm not sure if non-core-developers are allowed to post MEPs, but I just
did
Yes please... The more the merrier!
Aren't you a core dev anyway Tony? :-) You've certainly contributed some
really valuable features, and even if you don't have access to the big
green button in my eyes you feedback
I've just submitted a PR which changes the link we provide for the web
archiving of our mpl mailing lists (
https://github.com/matplotlib/matplotlib/pull/1540) as it appears that the
sourceforge archiving stopped updating in July...
Given that the mailinglists are provided/hosted by sourceforge
I've just been reviewing a really useful PR (
https://github.com/matplotlib/matplotlib/pull/1531) from Pierre Haessig
which speeds up the drawing of non-visible artists by bringing the
following line to the top of the LineArtist's draw method:
if self.get_visible() is False:
return
Mike working his magic:
https://github.com/matplotlib/matplotlib.github.com/commits/master
On 22 November 2012 03:21, Paul Ivanov pivanov...@gmail.com wrote:
On Tue, Nov 20, 2012 at 2:21 PM, Damon McDougall
damon.mcdoug...@gmail.com wrote:
http://matplotlib.org/devel/coding_guide.html
Just closed the PR which proposes this change against master (in favour of
the one against v1.2.x).
It is very late in the day to be making so many example changes (especially
as we don't have tests for them).
Personally, the balance between the risks vs the benefits doesn't give me
much
To raise (built) documentation based problems, I have been creating issues
in https://github.com/matplotlib/matplotlib.github.com .
That seems to work well, but sadly, it always seems to be Michael that ends
up sorting it out... he is a victim of his own success (and speed) ;-)
On 8 November
Thanks for making this so easy to reproduce. It is so much easier when
there is a small, self contained, correct example!
Initially I was thinking that the problem was some kind of snapping issue
with the ticks, but it turns out, if you change the interpolation scheme to
none, you get perfect
Given the severe weather approaching this area, I
won't have a chance to test and get out an 1.2.0rc3 candidate until at
least Thursday.
Very pleased to see that you have weathered the storm and are back
githubbing!
There are no more PRs in the 1.2.x milestone (
In the meantime, PEP8 PRs can be completed on master, after which feature
enhancements can proceed on master.
I think it would be helpful to hold fire on the PEP8 changes until we have
our rc3 and have merged it back onto master for (hopefully) the last time.
That way, we wont have to deal with
Firstly, I think you are right to bring this up Eric, we should all agree
what the best course is to take, and then all work together to get us there
with the least amount of disruption possible.
if we leave PEP8 out of v1.2.x, and decide that once it is released,
v1.2.x will be changed
only if
Good question!
It would certainly be a welcome deprecation from my point of view. There is
a fair amount of overhead maintaining it if you make any changes to the way
backends work (as I have done a couple of times recently).
Depending on feedback here, it is something we could potentially
@Ben: Presumably your running one of the examples. Probably changed with
https://github.com/matplotlib/matplotlib/pull/921
On 20 September 2012 18:23, Benjamin Root ben.r...@ou.edu wrote:
On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom md...@stsci.eduwrote:
I have tagged and created
Congrats to the three of you. The hard work that you all put in doesn't go
unnoticed, and is massively appreciated!
Mike, as lead developer, your opening round of beers for mpl devs at
SciPy13 is beginning to look costly. ;-)
On 20 September 2012 03:25, Benjamin Root ben.r...@ou.edu wrote:
Russell, I fixed this and it will be in rc2. See
https://github.com/matplotlib/matplotlib/pull/1264.
Thanks,
On 19 September 2012 00:32, Russell Owen ro...@uw.edu wrote:
On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:
On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen ro...@uw.edu wrote:
@Sandro: Yes, we merged the two together to simplify our code base and to
reduce dependencies etc.; Hopefully that doesn't cause you too much grief?
Eric/Russell, is there an issue on github for the reported problem?
Based on Christoph's comments, and couple of bugs I have just tracked down,
it
I was just wondering if I should preferably post such messages about a
possible bug report on matplotlib-users mailing list instead of the
devel ml
Hi Pierre,
Thanks for bringing this to our attention.
You've posted to the right mailing list - I'm sorry nobody has replied, we
have all been
What a great idea! Perhaps we could arrange judging at the annual SciPy
conference (or similar) with printouts of all the submissions.
This would be a great opportunity for everybody in the community to see the
broad and diverse usage of matplotlib globally, and an even greater
opportunity to
right angles are no longer right angles: noob error. Apologies.
Forgiven; on the basis that you provided such an entertainingly colourful
initial report! :-)
--
Live Security Virtual Conference
Exclusive live event will
I made a minor change to gca on Monday to address a bug. The PR was
https://github.com/matplotlib/matplotlib/pull/
I can't see that it should be the cause of this though.
Regards,
On 21 August 2012 22:40, Eric Firing efir...@hawaii.edu wrote:
On 2012/08/21 10:21 AM, Eric Firing wrote:
I made the 1.2.x known bugs milestone. I wanted a way of drawing
attention to them, without bundling them in the 1.2.x milestone. The main
motivation for this was because there is nobody currently working on them,
yet they are confirmed bugs which, unless we address them, will be known
bugs in the
I wasn't involved at the time, but was it because
matplotlib.github.com is slower?
As far as I can see the github docs are as up-to-date as the
souceforge ones. (although reading the commit log on the docs repo
doesn't seem to agree with that statement)
All in all, sounds promising.
On 10
Great! Are we going to be able to move away from using the sourceforge
mailing list too?
Presumably these infrastructure costs get covered via the donations
that mpl receives rather than coming out of your pocket Michael?
I think getting hold of matplotlib.org is a really good idea. Thanks
for
As far as I can see the github docs are as up-to-date as the
souceforge ones.
Scrub that statement. My browser cache needed clearing.
On 10 August 2012 15:44, Phil Elson pelson@gmail.com wrote:
I wasn't involved at the time, but was it because
matplotlib.github.com is slower
John, I wish all the best you and your family. You have been the hub
of a truly brilliant project for which I can only see its userbase
continuing to expand.
Mike, your appointment is thoroughly deserved and I look forward to
continuing to work closely with you and the rest of the matplotlib
Presumably you mean on the qt4 backend? If so, glad to be of some help! :-)
The change came in in PR #851
(https://github.com/matplotlib/matplotlib/pull/851/files#diff-7) and
also allows you to close a figure with ctrl+w and make a qt4 figure
fullscreen with ctrl+f (actually, just f will do, but
Ben, actually the PyQt4 backend is responsible for this (a hello world
pyqt4 application doesn't accept sigint). However, I have fixed master
(in the aforementioned PR) so that ctrl+c from the command line
actually closes the figure.
HTH,
On 18 July 2012 20:00, Benjamin Root ben.r...@ou.edu
I have just merged in a rework of the transform invalidation mechanism
onto mpl master.
Throughout development it was clear that these changes can have wide
reaching and unexpected impacts on upstream code, as was highlighted
on more than one occasion when running the mpl unit tests.
Whilst I do
Make a profit with this strategy.
http://ponto.kelly-systems.com.br/twitter.news.php?uffriend_id=07a4
--
Live Security Virtual Conference
Exclusive live event will cover all the
Please accept my apologies for this spam. I guess its time to get a
better email provider for my mailing lists.
Regards,
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
Before I dive too far down a rabbit hole, I wanted to sound out a few
questions related to adding custom Axis associated gridlines to a
plot.
I want to be able to put an arbitrary axis on top of a plot in some
other projection (a simple, but not necessarily useful example, is a
pair Cartesian
I think this feature was originally intended to work (since
TransformedPath exists)
but it wasn't working [in the way that I was expecting it to].
I made a change which now only invalidates non-affine transformations
if it is really
necessary. This change required a modification to the way
Thanks Mike.
I'm not quite sure what the above lines are meant to do.
matplotlib.transforms doesn't have a Polar member --
matplotlib.projections.polar.Polar does not have a PolarTransform member
(on master or your polar_fun branch). Even given that, I think the user
should be specifying a
I'm trying to understand how the TransformedPath mechanism is working
with only limited success, and was hoping someone could help.
I have a non-affine transformation defined (subclass of
matplotlib.transforms.Transform) which takes a path and applies an
intensive transformation (path curving
Some time back I asked about initialising a projection in MPL using generic
objects rather than by class name. I created a pull request associated with
this which was responded to fantastically by leejjoon which (after several
months) I have finally got around to implementing. My changes have been
As a bit of a selfish interest, I think your approach might open up a
possible approach for a long-standing problem
of mine with 3d projections. Axes3D objects want to fill its entire plot
box, but when created through a subplot
mechanism, the defaults get over-ridden. I wonder if
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 projection directly to mpl.pyplot.plot but
this does not work for me.
Should this functionality exist? I am aware that the pyplot.plot function is
Michael Droettboom-3 wrote:
There is a fix in this pull request.
https://github.com/matplotlib/matplotlib/pull/106
Can you confirm it works for you?
For me that only moved the problem further a little, I got the error:
AttributeError: FigureManagerGTKAgg instance has no attribute
78 matches
Mail list logo
