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 wrote:
> Hi all,
>
> I am trying to get a dev build of matplot
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 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, 2015, 11:13 PM N
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 02:
ase,
Best,
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
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 wrote:
> Thanks Tom,
>
> I ran the test suite on OSX 10.10 wi
tube.com/watch?v=POnAkPpe770.
Finally, to all those taking some time off this festive season, I wish you
a very happy holiday and wish you all the best for the new year.
Phil Elson
--
Dive into the World of Parallel Programm
P.S. I just found
http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker
On 22 December 2014 at 11:21, Phil Elson 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, and I'd
&g
nteresting 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
wrote:
> Hi all,
>
> I had a discussion with Phil Elson about this last weekend during the
> Bloomberg Open Source Day. I
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 the
cation, is this proposed 2.0 release different from
>> the 1.5 release?
>>
>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson
>> wrote:
>>
>>> Many of you will be aware of there has been an ongoing issue (#875,
>>> http://goo.gl/xLZvuL) which recommends
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 d
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
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 wrote:
> I can reproduce it with the following traceback. Can you please open a bug
> report on Github for this issue?
>
> ```
> Traceback (most recent call l
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 wrote:
> And with my continuing saga of backend-specific things...
>
> I was using conda, but because it does not ship with pygtk support, I had
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 P
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
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 fee
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
an
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 wrote:
> Hello everyb
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 enhan
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 shout-o
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 pa
Very nice.
Thanks for sharing Jason.
On 15 November 2013 13:18, Jason Grout 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 matplotlib
> > and ipython).
>
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()
) an
Wooho. New year, new release! It's going to be a busy Christmas :-)
On 18 September 2013 16:14, Michael Droettboom 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 1.4.0. I th
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 wrote:
> On Tue, Sep 17, 2013 at 8:03 AM, Michael Droettboom
> wrote:
> > I think there's enough good bug fixes on 1.3.x
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
ano
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 i
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.com&ctz=America/New_Yorkas
linked from the matplotlib wiki).
Cheers,
Phil
On 5 August 20
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 Eri
I'm not quite back to normality here after getting back from over a month
out of the office (Scipy'13 taking a chunk of that time) and didn't manage
to fill in the questionnaire. I guess it doesn't matter too much that I
didn't manage to fill it in (I know my own users, all 250+ of them, pretty
wel
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 = numpy.random.ran
gt; quality?
>
> In any event, as Phil Elson likes to repeatedly point out (), 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 som
>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 wrote:
> I am putting together a beginne
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 McDo
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 colorb
hen
regular updates 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 wrote:
> Thanks for this Joe, mpldatacursor looks like an excellent piec
x27;m trying 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 qu
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 aroun
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 wrote:
> The Launchpad daily build
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 wrote:
> On Fri, Jan 11, 2013 at 12:33 PM, Eric Firing wrote:
> > On 2013/01/11 5:38 AM, Michael Droettboom wrote:
> >> As pointed out in #1650, we have a bug on Python 3.x handli
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 in
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
Th
Mike working his magic:
https://github.com/matplotlib/matplotlib.github.com/commits/master
On 22 November 2012 03:21, Paul Ivanov wrote:
>
> On Tue, Nov 20, 2012 at 2:21 PM, Damon McDougall <
> damon.mcdoug...@gmail.com> wrote:
>
>> http://matplotlib.org/devel/coding_guide.html
>>
>> Scroll dow
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 2012
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 indicatio
> 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 (
https://github.com/matplotlib/ma
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 al
> 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 i
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 deprec
@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 wrote:
>
>
> On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom wrote:
>
>> I have tagged and created a tarball for 1.2.0rc2.
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 wrote:
>
>
> On Wednesday
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 wrote:
>
> On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:
>
> > On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen wrote:
> >> In article <50509
@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 refle
>>> 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 wil
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 wrote:
> On 2012/08/21 10:21 AM, Eric Firing wrote:
> > I have run into
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 th
> 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 wrote:
> I wasn't involved at the time, but was it because
> matplotlib.github.com is slower?
>
&
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 do
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 August
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
team.
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 wrote:
>
>
> On Wed,
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, b
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 n
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 an
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 wa
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 a
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
invalida
In much the same way Basemap can take an image in a Plate Carree map
projection (e.g. blue marble) and transform it onto another projection
in a non-affine way, I would like to be able to apply a non-affine
transformation to an image, only using the proper matplotlib Transform
framework.
To me, thi
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 specifyin
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
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 & cu
>> 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
Sorry, that link was bad, it should have read:
https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e4
To: matplotlib-devel@lists.sourceforge.net
Date: Thu, 15 Sep 2011 18:19:49 +
Subject: [matplotlib-devel] Initialising projections in matplotlib
Hi,
I would like the ability to setup a plot projection in MPL that can be defined
by various parameters and does not need to be serialised as a string and
registered with matplotlib.projections.register_projection. For example, an
extension of /examples/api/custom_projection_example.py migh
> I think the only case where this would work correctly is if the plot command
> would also trigger the creation of a new axes object.
Can't see how this can ever happen given the pyplot.plot code, which creates a
standard axes without passing through any arguments.
I agree that there are situ
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
autogenera
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 attrib
84 matches
Mail list logo
