Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

s > build only once and only applying transforms for subsequent calls. > > At least it is my understanding of the matplotlib machinery but I may be > wrong. > > > Nicolas > > > > > > > On Mar 7, 2013, at 15:36 , Michael Droettboom wrote: > >> I&#

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

I'm not aware of any discussion about participating in GSoC this year, though I am open to the idea. I was involved as a mentor a few years ago, but I wasn't terribly involved in the administrative side, so I don't know what's involved. I think then we did it under the umbrella of the PSF. I

Re: [matplotlib-devel] "Flash" rendering in the Agg backend

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

Re: [matplotlib-devel] Problem compiling matplotlib from master

I often find that a `git clean -fxd` is enough, rather than blitzing my whole virtualenv. On 03/01/2013 10:16 AM, Nelle Varoquaux wrote: That's weird. Did you try installing a stable numpy version instead? I tried compiling mpl against numpy 1.6.2 and everything worked out fine.

Re: [matplotlib-devel] Problem compiling matplotlib from master

It thinks the Numpy header files are here: /usr/lib/pymodules/python2.6/numpy/core/include are they there and from the right version of Numpy? When you run python (the same copy you're building with), and import numpy and print "numpy.__version__" does that give the expected version. What do

Re: [matplotlib-devel] Travis (hopefully) reliable again

Ugh. It seems I spoke too soon. The illustrious test_bbox_inches_tight test is failing again on master. Mike On 02/25/2013 05:35 PM, Michael Droettboom wrote: > I spent the day getting our test suite into shape again so that it's > passing on Travis. > > Just wanted to let

[matplotlib-devel] Travis (hopefully) reliable again

I spent the day getting our test suite into shape again so that it's passing on Travis. Just wanted to let you know, in case, like me, you've seen so many false positives that you started ignoring Travis. Mike -- Every

Re: [matplotlib-devel] MatPlotLib 1.2.0 for MeeGo Harmattan OS

Great news! I've had a soft spot for Maemo (and it's successors) since I got a N770 a few years ago. Loved the Debian package manager, gnome-ish user space, Python bindings for just about everything on the system -- it was everything a Linux geek would want in a tablet. It's a shame that No

Re: [matplotlib-devel] Getting pull requests merged

On 02/01/2013 09:11 AM, Todd wrote: Is there a process that someone needs to go through to get a pull request merged into master? Is there a particular pull request that you think has stalled, or you just want to know the process in general? If the former -- just ping us on the mailing list

[matplotlib-devel] Financial support for continuous integration

In discussions with Perry Greenfield at STScI, it seems we are in the position of being able to get some financial support to pay for a continuous integration system. Travis has shown itself to be rather glitchy for matplotlib. The tight integration with Github PRs is really convenient. Howev

Re: [matplotlib-devel] Matplotlib PPA

Thanks. Sorry about not communicating the new dependency very well. As this only affects those building the docs (meaning primarily developers and not end-users) it wasn't given the same care. We had had some back-and-forth about whether to include a local copy of numpydoc in matplotlib, but

Re: [matplotlib-devel] Upcoming release schedule thoughts

On 01/16/2013 12:18 PM, Michael Droettboom wrote: > There have been bits and pieces of discussion about future releases on > PRs, and I thought I'd bring it over here to tie loose ends together. > > There have been 83 commits since 1.2.0 -- it's probably time to start &g

Re: [matplotlib-devel] Matplotlib property support

This seems like a good candidate for a MEP. We'd want to take a graceful approach to transitioning to properties. See here for information about MEPs: https://github.com/matplotlib/matplotlib/wiki Mike On 01/16/2013 02:42 PM, Todd wrote: Currently matplotlib uses set_ and get_ functions for

Re: [matplotlib-devel] Font issues in fedora 18 and rawhide

On 01/16/2013 01:32 PM, Paulo César Pereira de Andrade wrote: > 2013/1/16 Michael Droettboom : > >> There was a very silly bug lurking in USE_FONTCONFIG=True mode, and I've >> made a PR with a fix here: >> >> https://github.com/matplotlib/matplotlib/pull/1666 >

Re: [matplotlib-devel] Font issues in fedora 18 and rawhide

On 01/16/2013 12:22 PM, Paulo César Pereira de Andrade wrote: 2013/1/16 Michael Droettboom : -USE_FONTCONFIG = False +USE_FONTCONFIG = True [...] I think this is safe to be made a patch for Linux distros. I believe this could be the default for *Linux and *BSD in matplotlib. This will

[matplotlib-devel] Upcoming release schedule thoughts

There have been bits and pieces of discussion about future releases on PRs, and I thought I'd bring it over here to tie loose ends together. There have been 83 commits since 1.2.0 -- it's probably time to start thinking about a 1.2.1. The release candidate cycle shouldn't be as long for this,

Re: [matplotlib-devel] Font issues in fedora 18 and rawhide

On 01/16/2013 10:38 AM, Paulo César Pereira de Andrade wrote: > 2012/12/8 Paulo César Pereira de Andrade > : >>Hi, >> >>Recently I asked to become comaintainer of matplotlib in Fedora and >> did update to 1.2.0 > [...] > >> doctest:1214: UserWarning: findfont: Font family ['STIXGenera

Re: [matplotlib-devel] Usefulness of Travis-CI

On 01/16/2013 07:15 AM, Thomas Kluyver wrote: On 16 January 2013 08:35, Nathaniel Smith > wrote: When this has come up on the numfocus list before the status was, sure, they can provide resources/funding if you can find someone to do the actual work :-). If any

[matplotlib-devel] Requiring numpy requirement to 1.5 on master?

As pointed out in #1650, we have a bug on Python 3.x handling file-like objects that are UNIX FILEs, but not actual filesystem files, such as the sockets used for a urllib HTTP request. https://github.com/matplotlib/matplotlib/pull/1650 As Christoph helpfully points out, Numpy has already solv

Re: [matplotlib-devel] PR #1599

On 01/10/2013 05:19 AM, Phil Elson wrote: 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

Re: [matplotlib-devel] MEP10: Modernize documentation.

On 01/09/2013 12:20 PM, Nelle Varoquaux wrote: Hi all, A while back, Mike drafted a MEP to modernize the documentation: https://github.com/matplotlib/matplotlib/wiki/Mep10 The main idea behind this MEP is to use the full potential of new tools and conventions available for sphinx, to make the

Re: [matplotlib-devel] MEP10: Modernize documentation.

On 01/09/2013 12:43 PM, Todd wrote: On Wed, Jan 9, 2013 at 6:20 PM, Nelle Varoquaux mailto:nelle.varoqu...@gmail.com>> wrote: - use the autodoc_docstring_signature of sphinx 1.1, which allow to have the explicit function signature instead of the python one in the generated documenta

Re: [matplotlib-devel] autoconf+python

On 01/07/2013 12:38 PM, Eric Firing wrote: > On 2013/01/07 7:29 AM, Michael Droettboom wrote: >> I, also, am not too much up on the details --- but I think if it's >> possible for "make install" to just call "python setup.py install" under >> the h

Re: [matplotlib-devel] autoconf+python

On 01/07/2013 12:24 PM, Benjamin Root wrote: On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver > wrote: On 7 January 2013 16:57, Benjamin Root mailto:ben.r...@ou.edu>> wrote: I was just reading some comments from Richard Stallman on ./ when I no

Re: [matplotlib-devel] Is cbook public?

On 01/07/2013 11:05 AM, Nelle Varoquaux wrote: > On 7 January 2013 16:38, Michael Droettboom wrote: >> I know there's a lot of code in the wild that treats cbook as public and >> would probably be affected by it going away. However, there hasn't been >> much care

Re: [matplotlib-devel] Is cbook public?

I know there's a lot of code in the wild that treats cbook as public and would probably be affected by it going away. However, there hasn't been much care taken within that module as to what we want to support publicly and what would be better left as private. Many things in it, of course, ar

Re: [matplotlib-devel] matplotlib.org website DOWN (again)

I've found the outages to be very infrequent, and certainly much less often then when the hosting was on Sourceforge, but that's completely non-scientific of course. Next time it goes down for you, could you send a traceroute to matplotlib.org? That may help us track down the source of the pr

Re: [matplotlib-devel] Github Downloads going away...

On 12/16/2012 03:44 PM, Eric Firing wrote: > On 2012/12/16 9:21 AM, Damon McDougall wrote: >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> wrote: >>> On 12/14/12 10:55 AM, Nathaniel Smith wrote: sourceforge's horror of an interface. >>> I'll second that. Every time I go to Sourceforge, I

Re: [matplotlib-devel] Github Downloads going away...

On 12/17/2012 07:39 AM, Michael Droettboom wrote: On 12/17/2012 07:36 AM, Michael Droettboom wrote: On 12/16/2012 02:50 PM, Damon McDougall wrote: On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote: On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote: On Sat, Dec 15, 2012 at 8:25 PM, Jason

Re: [matplotlib-devel] Github Downloads going away...

On 12/16/2012 02:38 PM, Todd wrote: On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall mailto:damon.mcdoug...@gmail.com>> wrote: On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout mailto:jason-s...@creativetrax.com>> wrote: > On 12/14/12 10:55 AM, Nathaniel Smith wrote: >> sourcefor

Re: [matplotlib-devel] Github Downloads going away...

On 12/15/2012 09:25 PM, Jason Grout wrote: > On 12/14/12 10:55 AM, Nathaniel Smith wrote: >> sourceforge's horror of an interface. > I'll second that. Every time I go to Sourceforge, I have to figure out > how in the world to download what I want (and I have to figure out which > things *not* to c

Re: [matplotlib-devel] Github Downloads going away...

On 12/17/2012 07:36 AM, Michael Droettboom wrote: On 12/16/2012 02:50 PM, Damon McDougall wrote: On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote: On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote: On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout wrote: On 12/14/12 10:55 AM, Nathaniel Smith

Re: [matplotlib-devel] Github Downloads going away...

On 12/16/2012 02:50 PM, Damon McDougall wrote: On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote: On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote: On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout wrote: On 12/14/12 10:55 AM, Nathaniel Smith wrote: sourceforge's horror of an interface. I'll s

Re: [matplotlib-devel] Github Downloads going away...

On 12/15/2012 08:10 PM, Matt Newville wrote: > Hi, > >> Github has removed the ability to host binaries. They've removed this >> feature without any apparent notification except on their blog saying >> "it's gone today". And the suggested alternative is to use paid services. >> >> https://github.

Re: [matplotlib-devel] Github Downloads going away...

On 12/14/2012 02:25 PM, Todd wrote: On Dec 14, 2012 5:59 PM, "Michael Droettboom" <mailto:md...@stsci.edu>> wrote: > > Github has removed the ability to host binaries. They've removed this feature without any apparent notification except on their blog sayi

[matplotlib-devel] Github Downloads going away...

Github has removed the ability to host binaries. They've removed this feature without any apparent notification except on their blog saying "it's gone today". And the suggested alternative is to use paid services. https://github.com/blog/1302-goodbye-uploads I had planned to complete our set

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

On 12/12/2012 01:17 PM, Paul Hobson wrote: On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom <mailto:md...@stsci.edu>> wrote: http://matplotlib.org/examples/api/clippath_demo.html It's perfectly reasonable code, but seems strange that it's clipped off to

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

On 12/11/2012 07:16 PM, Thomas Kluyver wrote: On 11 December 2012 23:07, Tony Yu > wrote: You suggest keeping the old examples around in some dark corner. Is there some advantage you envision for doing this? I'd just as soon remove them. Note tha

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

On 12/10/2012 05:18 PM, Tony Yu wrote: Hi all, I'm not sure if non-core-developers are allowed to post MEPs, but I just did ;). It's a big tent. Come on in! BTW -- if you want to have access to the big green merge button, let me know. You've certainly been working on matplotlib long enou

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

I think this has been a very helpful and useful discussion. I'm going to attempt to summarize this discussion and propose some ways forward here. The impetus for this discussion is that PyCXX seems to be not adequately maintained. It is difficult to build matplotlib with "vanilla" PyCXX in ce

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

I think this has been a very helpful and useful discussion. I'm going to attempt to summarize this discussion and propose some ways forward here. The impetus for this discussion is that PyCXX seems to be not adequately maintained. It is difficult to build matplotlib with "vanilla" PyCXX in ce

Re: [matplotlib-devel] build failure in v1.2.x branch

ead and reverted my change. Let me know if that fixes things for you when you get a chance. Cheers, Mike On 12/04/2012 10:50 AM, Benjamin Root wrote: On Tue, Dec 4, 2012 at 10:43 AM, Michael Droettboom <mailto:md...@stsci.edu>> wrote: It looks like we're using the "old

Re: [matplotlib-devel] build failure in v1.2.x branch

It looks like we're using the "old" Numpy API there. Did you recently update Numpy by any chance? I hadn't realised these APIs had been turned off yet, but maybe they are in git master. In any event, we should update these to the new APIs (NPY_UBYTE instead of PyArray_UBYTE etc.). Cheers,

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

Also -- this feedback is really helpful when writing some comments in the wrappers as to why certain things are the way they are... I'll make sure to include rationales for raw file fast path and the need to open the files on the Python side. Mike On 12/04/2012 08:45 AM, Michael Droet

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 12/03/2012 08:01 PM, Chris Barker - NOAA Federal wrote: > On Mon, Dec 3, 2012 at 4:16 PM, Nathaniel Smith wrote: > >> Yeah, this is a general problem with the Python file API, trying to >> hook it up to stdio is not at all an easy thing. A better version of >> this code would skip that altogeth

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 12/03/2012 07:16 PM, Nathaniel Smith wrote: > On Mon, Dec 3, 2012 at 11:50 PM, Chris Barker - NOAA Federal > wrote: >> On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith wrote: >>> For the file handle, I would just write >>> >>>cdef FILE *fp = fdopen(file_obj.fileno(), "w") >>> >>> and be don

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 12/03/2012 07:00 PM, Chris Barker - NOAA Federal wrote: > On Mon, Dec 3, 2012 at 12:24 PM, Chris Barker - NOAA Federal > wrote: > > but some of that complexity could be reduced by using Numpy arrays in > place >>> It would at least make this a more fair comparison to have the Cython >>

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

ork PyCXX and release as needed. The maintenance required is primarily when new versions of Python are released, so it wouldn't necessarily be a huge undertaking. However, I know some are reluctant to use a relatively unused tool. > > Michael Droettboom wrote: > >> For the PN

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

On 12/03/2012 04:07 AM, Ian Thomas wrote: I vote for using the raw Python/C API. I've written a couple of PyCXX extensions and whilst it is mostly convenient, PyCXX doesn't support the use of numpy arrays so for them you have to use the Python/C API. This means dealing with the reference coun

Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x

I've pushed a fix to v1.2.x and master for this new problem (35ee2184111fb8f80027869d8ee309c7f4e5a467). Unfortunately, another rebase of your branches is in order in order to get this fix. Mike On 12/02/2012 12:23 PM, Thomas Kluyver wrote: On 2 December 2012 17:02, Damon McDougall

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

this part of the code base. I would be interested to see what others think now that we have an apples-to-apples comparison. Cheers, Mike On 12/01/2012 01:36 PM, Michael Droettboom wrote: For the PNG extension specifically, it was creating callbacks that can be called from C and the setjmp ma

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

Including the Cython-generated C in the tarballs and optionally the git repository as well can certainly be considered to reduce the need for Cython for developers and users alike. However, the Cython source should also be included in the repository for the inevitable times when it does need t

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

ython expert would step up and show the way ;) The Agg backend has more C++-specific challenges, particularly instantiating very complex template expressions -- but I haven't really followed that on through. Mike On 11/30/2012 09:13 AM, Jason Grout wrote: > On 11/29/12 10:59 AM, Micha

Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x

Ok. I'll go ahead and put the workaround in our .travis.yml. Any active pull requests that we want to have good Travis results for will need to be rebased to get the workaround. Mike On 11/30/2012 06:20 PM, Damon McDougall wrote: > Forwarding to list again... > > > -- Forwarded messag

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

ut with the conversion of the other extensions from CXX > to C. I would need some help though to use github appropriately. > > Best, > -Michiel. > > > --- On Thu, 11/29/12, Michael Droettboom wrote: > >> From: Michael Droettboom >> Subject: [matplotlib-devel]

[matplotlib-devel] Experiments in removing/replacing PyCXX

Given the slow pace of development on PyCXX, I know it has been the desire of some here to remove our dependency on it. I thought a helpful starting point to evaluate the alternatives would be to restructure one of our extensions to not use PyCXX anymore. I've taken the PNG extension, which is

Re: [matplotlib-devel] Issues with building Matplotlib 1.2.0 on RHEL5

If I understand it correctly, you are trying to build against custom-built copies of these libraries in a non-default location? You can try setting LDFLAGS to "-L/path/to/your/libraries". Mike On 11/26/2012 12:47 AM, Tejashri Kandolkar wrote: Hi, I am trying to build matplotlib 1.2.0 from so

Re: [matplotlib-devel] Use of meta on Artist

The problem is that I don't think we can do this for all artists. Some may need to create groupings, or push and pop state even if they are "invisible". For instance, this is used in the SVG backend to create named groupings (possibly empty) that are referenced from Javascript to provide inte

Re: [matplotlib-devel] New plot type idea -- EventRaster

On 11/11/2012 11:51 PM, Todd wrote: > On Thu, Sep 27, 2012 at 8:18 PM, Todd wrote: >> On Thu, Sep 27, 2012 at 1:44 PM, Todd wrote: >>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall >>> wrote: Hi Todd, Firstly, thanks for taking the time to crystallise your thoughts in word

[matplotlib-devel] 1.2.0 Final tagged and uploaded

Thanks again to everyone for all of their hard work. This release has been tagged and uploaded. As per the usual drill, once we have the binaries up, I'll make an ANN on matplotlib-users. The documentation is currently being rebuilt, and the default for matplotlib.org will update to 1.2.0 aro

Re: [matplotlib-devel] dead link on matplotlib.org page

This will be addressed when I update the docs to 1.2.0 shortly. Mike On 11/08/2012 11:31 AM, Benjamin Root wrote: And I had completely missed that this was taken care of yesterday. However, the changelog link from the what's new page is still dead. Ben On Thu, Nov 8, 2012 at 11:24 AM, Benja

Re: [matplotlib-devel] dead link on matplotlib.org page

It's actually better to create these issues against the main matplotlib repository since all of the bugs are fixed over there in the source. matplotlib.github.com only contains generated files. Mike On 11/08/2012 11:50 AM, Phil Elson wrote: To raise (built) documentation based problems, I hav

Re: [matplotlib-devel] Last call for 1.2.0

the table to include the gtk3 backend? (and note that the qt3 backend is depreciated) Jens On Thu, Nov 8, 2012 at 3:23 AM, Michael Droettboom <mailto:md...@stsci.edu>> wrote: The milestone is clear. Is there anything we're missing? If not, I plan to cut a final release

Re: [matplotlib-devel] Last call for 1.2.0

ithub.com/matplotlib/matplotlib/pull/1462). Cheers, On 8 November 2012 09:22, Paul Ivanov <mailto:pivanov...@gmail.com>> wrote: On Wed, Nov 7, 2012 at 6:23 PM, Michael Droettboom mailto:md...@stsci.edu>> wrote: > The milestone is clear. Is there anything w

[matplotlib-devel] Last call for 1.2.0

The milestone is clear. Is there anything we're missing? If not, I plan to cut a final release and update the documentation website tomorrow morning. Mike -- Everyone hates slow websites. So do we. Make your web apps f

Re: [matplotlib-devel] colorbar edges in white for PDF output

p... some thought is probably required on this one. http://dl.dropbox.com/u/4496818/bad.pdf http://dl.dropbox.com/u/4496818/good.pdf Andrew On 1 November 2012 16:02, Andrew Dawson <mailto:daw...@atm.ox.ac.uk>> wrote: Yes this seems to work for me. On 1 November 2012 15:25,

Re: [matplotlib-devel] colorbar edges in white for PDF output

On 1 November 2012 15:25, Michael Droettboom mailto:md...@stsci.edu>> wrote: I now have a fix attached to that issue. Andrew: can you confirm it works for you? Mike On 11/01/2012 09:06 AM, Michael Droettboom wrote: I've filed an issue fo

Re: [matplotlib-devel] colorbar edges in white for PDF output

I now have a fix attached to that issue. Andrew: can you confirm it works for you? Mike On 11/01/2012 09:06 AM, Michael Droettboom wrote: I've filed an issue for this here: https://github.com/matplotlib/matplotlib/issues/1444 Mike On 10/31/2012 12:20 PM, Andrew Dawson wrote: Hi al

Re: [matplotlib-devel] colorbar edges in white for PDF output

I've filed an issue for this here: https://github.com/matplotlib/matplotlib/issues/1444 Mike On 10/31/2012 12:20 PM, Andrew Dawson wrote: Hi all, I just noticed that colorbar edges are drawn in white when output in PDF and black when output in PNG. A small test script is attached along with

Re: [matplotlib-devel] Delaying rc3 (again)

ar: Thank you for your hard work and commitment - it really does make the release so much better as a result. All the best, Phil On 29 October 2012 19:10, Michael Droettboom <mailto:md...@stsci.edu>> wrote: Just a quick note: Given the severe weather approaching this area, I

[matplotlib-devel] Delaying rc3 (again)

Just a quick note: 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. Mike -- The Windows 8 Center - In partnership with Sourceforge

Re: [matplotlib-devel] Trove classifiers

Thanks. That would be much appreciated. Mike On 10/23/2012 05:10 PM, Thomas Kluyver wrote: > I've just noticed that matplotlib on PyPI doesn't have any trove > classifiers. I think it would be good to add these for the 1.2 release > - apart from anything else, it will indicate to the various aut

Re: [matplotlib-devel] mpl site down?

Sorry to be late to this -- it does seem to be working for me now. Can you confirm it's also working for you? Mike On 10/19/2012 05:08 PM, Joe Kington wrote: Github has been under a DDOS for the past couple of days: https://status.github.com/ It's probably(?) related, but lots of other gith

[matplotlib-devel] Cutting 1.2rc3

Thanks to everyone for the hard work on getting the last few bugs squashed! I think 1.2.0 is going to be a very high quality release. It looks like we're only down to one last issue marked for 1.2. https://github.com/matplotlib/matplotlib/pull/1326

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

On 10/15/2012 12:52 PM, Eric Firing wrote: > On 2012/10/15 5:50 AM, Michael Droettboom wrote: >> Sorry to be jumping in on this late -- I didn't have a chance to catch >> up with this over the weekend. >> >> I think I generally side with Eric here -- the rc cand

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

On 10/15/2012 08:11 AM, Phil Elson wrote: 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 i

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

Sorry to be jumping in on this late -- I didn't have a chance to catch up with this over the weekend. I think I generally side with Eric here -- the rc candidate cycle is intended to be quite conservative. Nelle's pull requests are very welcome improvements, but they are also quite large and I

Re: [matplotlib-devel] Upload a higher res logo to github

It is now fixed. I just uploaded a higher resolution image of the same thing. Mike On 10/10/2012 04:31 PM, Damon McDougall wrote: > On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root wrote: >> Looks like github has changed the layout of the default landing page for any >> github account. This now

[matplotlib-devel] Interactive Matplotlib in the browser

I have a proof-of-concept way to make interactive plots in the browser work using transparent PNGs described here: http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/ No PRs yet, because this is miles from ready for that, but it would be helpful to get some feedback

[matplotlib-devel] 1.2rc3 -- pushing back

According to the schedule (which I don't consider very rigid), we're set to tag rc3 today. I see there are a number of PRs tagged for 1.2.x that it would be nice to polish a little before putting in, so I'm inclined to push back the rc3 tagging for a bit. I'm attending a conference Tues-Thurs,

Re: [matplotlib-devel] PyGTK vs PyGObject

On 10/06/2012 02:22 PM, Chris Barker wrote: > On Oct 5, 2012, at 12:25 PM, Michael Droettboom wrote: > >> On 10/05/2012 02:53 PM, Chris Barker wrote: >>> The upcoming pycairo version >> supports using image buffers (which can be Numpy arrays), but that's not

Re: [matplotlib-devel] PyGTK vs PyGObject

On 10/05/2012 02:53 PM, Chris Barker wrote: > On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom wrote: > >> We do use pycairo. It certainly would get around the issue, but duplicate a >> lot of effort that pycairo already handles for us. > A bit OT -- but have you added

Re: [matplotlib-devel] PyGTK vs PyGObject

On 10/05/2012 11:40 AM, Damon McDougall wrote: On Friday, October 5, 2012, Michael Droettboom wrote: On 10/05/2012 06:38 AM, todd rme wrote: I am trying to do some experimental packages with python 3 and the latest RC, and I am trying to figure out the situation with some of

Re: [matplotlib-devel] PyGTK vs PyGObject

On 10/05/2012 09:57 AM, Michael Droettboom wrote: On 10/05/2012 06:38 AM, todd rme wrote: I am trying to do some experimental packages with python 3 and the latest RC, and I am trying to figure out the situation with some of the backends. Some are obvious, like wxwidgets and PyQt (Qt3 version

Re: [matplotlib-devel] PyGTK vs PyGObject

On 10/05/2012 06:38 AM, todd rme wrote: I am trying to do some experimental packages with python 3 and the latest RC, and I am trying to figure out the situation with some of the backends. Some are obvious, like wxwidgets and PyQt (Qt3 version). The issue I am running into is with the gtk backe

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

On 10/04/2012 11:56 AM, Chris Barker wrote: > On Wed, Oct 3, 2012 at 10:36 PM, Erik Bray wrote: >> So as you wrote in the MEP, Numpy will simply have to be installed >> separately, I think, if the C++ modules require the Numpy headers. > Which is totally fine -- MPL requires a bunch of non-python

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

On 10/04/2012 06:16 AM, Thomas Kluyver wrote: > On 3 October 2012 22:08, Christoph Gohlke wrote: >> Concerning end user experience, the scipy-stack project seems like a >> better place to address this. > To expand on this, there's a discussion underway on the scipy-user and > numfocus mailing list

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

On 10/03/2012 05:08 PM, Christoph Gohlke wrote: > On 10/3/2012 9:20 AM, Michael Droettboom wrote: >> I invite comments for a new MEP about improving the situation with >> respect to our bundling of third-party Python dependencies. >> >> In particular, I'

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

On 10/03/2012 05:26 PM, Erik Bray wrote: > On 10/03/2012 12:20 PM, Michael Droettboom wrote: >> I invite comments for a new MEP about improving the situation with >> respect to our bundling of third-party Python dependencies. >> >> In particular, I'd love feedba

[matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

I invite comments for a new MEP about improving the situation with respect to our bundling of third-party Python dependencies. In particular, I'd love feedback from the various stakeholders -- those producing binary installers and packages for the various platforms. https://github.com/matplot

Re: [matplotlib-devel] deprecate and remove original Navigation toolbar?

+1 On 10/03/2012 04:36 AM, Phil Elson wrote: 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 feedba

Re: [matplotlib-devel] branch merge strategy

On 09/29/2012 08:07 PM, Eric Firing wrote: > Mike, > > I'm getting confused about branch merge strategy. Usually, it seems > that it has been to periodically merge the maintenance branch into > master. Something like this: > > git fetch upstream > git checkout master > git merge --ff-only upstr

Re: [matplotlib-devel] New plot type idea -- EventRaster

On 09/26/2012 04:35 AM, Todd wrote: On Mon, Sep 24, 2012 at 3:33 PM, Todd > wrote: I would like to add a new plot type to matplotlib. Of course I am willing to implement it myself, but I want to confirm that it is acceptable and iron out the implementation

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

On 09/24/2012 11:33 AM, Damon McDougall wrote: > On Mon, Sep 24, 2012 at 2:05 PM, Michael Droettboom wrote: >> Thanks for pointing this out. It should now be fixed. >> > Nope, it still says 1.2.0rc1: http://matplotlib.org > Obviously my git skills are down today. Should b

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

te recently. Mike On 09/24/2012 01:01 PM, Russell E. Owen wrote: > In article <505a06b4.6080...@stsci.edu>, > Michael Droettboom > wrote: > >> I have tagged and created a tarball for 1.2.0rc2. The githash is >> 656c88f3e546. The tarball is on the github dow

Re: [matplotlib-devel] process for getting a new plot type added

We welcome all volunteers! The threshold for what requires a MEP is somewhat fuzzy, but generally it's for things in the core that affect the system as a whole. Why don't you just start discussing your thoughts and plans here and we can discuss the best way forward. Mike On 09/24/2012 06:1

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

Thanks for pointing this out. It should now be fixed. On 09/22/2012 01:55 PM, Damon McDougall wrote: > On Wed, Sep 19, 2012 at 6:53 PM, Michael Droettboom wrote: >> I have tagged and created a tarball for 1.2.0rc2. The githash is >> 656c88f3e546. The tarball is on the githu

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

On 09/21/2012 09:40 AM, Benjamin Root wrote: On Fri, Sep 21, 2012 at 9:23 AM, Benjamin Root > wrote: On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson mailto:pelson@gmail.com>> wrote: @Ben: Presumably your running one of the examples. Probably chan

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

On 09/20/2012 01:16 PM, Sandro Tosi wrote: > Hi Michael, > > On Wed, Sep 19, 2012 at 7:53 PM, Michael Droettboom wrote: >> I have tagged and created a tarball for 1.2.0rc2. The githash is >> 656c88f3e546. The tarball is on the github download page here: > Thanks for the

[matplotlib-devel] Welcoming new core developers

Damon McDougall, Christoph Gohlke and Russell Owen have been added to the set of core developers with push rights and the ability to upload files to the github download page. Damon has come recently on the scene, but has provided all kinds of helpful bug triaging and fixing during the 1.2.0 rel

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