[matplotlib-devel] Matplotlib daily builds PPA

Apologies if you receive this twice - I joined the mailing list with one address, then posted from another. Mods, feel free to bin the other copy of the post. If you want to get more people testing the next version, I've set up a PPA to build the development version of matplotlib nightly for Ubunt

[matplotlib-devel] Fwd: Docs failing to build

Hi, In the last couple of days, the daily builds on Launchpad have been choking on the docs. They get to "reading sources... [ 91%] faq/howto_faq", then seemingly lock up until the queue manager aborts the build. It claims there's 2h30 of inactivity before that happens, so it looks like something

Re: [matplotlib-devel] wxMPL patch

On 1 May 2012 17:26, Chris Barker wrote: > Would there be a problem bringing it in to MPL in that case? Not from the license point of view - the X11 license is another permissive BSD-style license. I was just furnishing that detail. ;-) Thomas ---

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

On 12 May 2012 10:56, Sandro Tosi wrote: > It would be really awesome to have a python3 matplotlib in Debian, and > i'd be happy to test any new RC you'd like to release. Just to mention: I've set up a daily builds PPA for matplotlib, and it's been happily producing Python 3 builds for a while, s

Re: [matplotlib-devel] python 3 fork?

On 30 May 2012 20:05, Tom Lippman wrote: > I'm on OS X 10.7, using the python 3.2 I saw someone recently who'd managed to get it built for Python 3 on OS X. I suggested he come here to help simplify the process - this is what he did: http://stackoverflow.com/a/10574470/434217 Thomas ---

Re: [matplotlib-devel] python 3 fork?

On 30 May 2012 19:49, Tom Lippman wrote: > I saw that matplotlib had been ported to python 3 (here), and that the > matplotlib-py3 branch was merged back into the main branch.  So I assumed > matplotlib was compatible with python 3, and went ahead and tried to use it. >  It didn't work.  Is there

Re: [matplotlib-devel] MEP10: Modernizing the documentation

On 26 August 2012 18:19, Michael Droettboom wrote: > I understand the comments about the difficulty of introspection. The > reason it works the way it does is so that additional parameters can be > added to the artist layer without needing to update every single > plotting function. A real world

Re: [matplotlib-devel] MEP10: Modernizing the documentation

On 5 September 2012 00:32, Michael Droettboom wrote: > I wonder if there's any possibility of using that on earlier versions (I > suspect not). Not easily, I think. You'd have to get introspection tools like IPython to separately check for a __signature__ attribute, and I suspect we'd feel that t

[matplotlib-devel] Fwd: A common name for the scipy stack - pylab?

Hi, (Apologies if you get this twice - I forgot which address I subscribed to the list with) As some of you may have seen, there's a discussion underway on the scipy-user mailing list about developing a common name for the scipy stack. At present, the discussion is centring on adopting the name p

Re: [matplotlib-devel] 1.2.0rc1 is cut

On 12 September 2012 15:44, Michael Droettboom wrote: > For those creating distro packages, now is a good time to let us know what > can be done to make the inclusion of matplotlib 1.2.0 as smooth as possible. I think I've mentioned before, but whoever does the Debian packages is welcome to use c

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

On 27 September 2012 11:41, Todd wrote: > I would prefer to get the details worked out before I start coding > since there are a few different approaches. First thing is to figure > out a good name, I am not sure this is the best name for it. As someone from a field that doesn't regularly use th

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

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 lists about standardising a set of packages making up the

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

On 14 October 2012 21:22, Eric Firing wrote: > 3) The potential disagreement is over whether the PEP8 changes should be > cherry-picked into v1.2.x, or simply left in master. I favor the latter > course. I'm not familiar with matplotlib's merge strategy, but I'd agree with you that making those

[matplotlib-devel] Trove classifiers

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 automated tools checking Python 3 compatibility that matplotlib is now compatible. Here are the classi

Re: [matplotlib-devel] master vs maintenance branches (current process and proposal for future workflow)

On 12 November 2012 20:52, Benjamin Root wrote: > There are other git workflows, which are all perfectly valid. If you can > convince us to use another, feel free to propose one. However, we have > done a couple of releases with gitwash, and it has worked quite well for us > given how small our

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

Drat, re-sending on the list. On 1 December 2012 16:40, Thomas Kluyver wrote: > On 1 December 2012 14:44, Michiel de Hoon wrote: > >> At the same time, to minimize errors, we could use Cython to create the >> initial Python/C glue code, and then add the generated code to

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

On 10 December 2012 22:43, Tony Yu wrote: > This MEP only concerns the main gallery. I think user-contributed examples > were (are?) the intended focus of SciPy Central: > > http://scipy-central.org/ > > (and before that, the SciPy Cookbook). I'm not sure about the status of > SciPy Central.

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

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 that the documentation on the website is now versioned, so the >> examples that shipped wi

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

On 15 December 2012 23:38, Damon McDougall wrote: > Maybe the best thing is to host the binaries on Sourceforge. Having recently tried to do it, Sourceforge tries really hard to avoid giving you a direct link that can repeatably be used to download a file automatically, i.e. without a browser. I

Re: [matplotlib-devel] Problem in backporting Matplotlib for Py3 on Kubuntu Precise

On 29 December 2012 13:53, Shriramana Sharma wrote: > Hello. I don't use Matplotlib directly (yet) but I wish to use > https://github.com/scios/IPyXt which needs it, and I'm using IPython > and SymPy both with Python 3. (Current version on my Kubuntu Precise > system is 3.2.3.) So I'm trying to b

Re: [matplotlib-devel] autoconf+python

On 7 January 2013 16:57, Benjamin Root wrote: > I was just reading some comments from Richard Stallman on ./ when I > noticed that he pointed out a useful autoconf feature that was added > somewhat recently. Essentially, this feature would allow one to do a > build/install of a python module usi

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

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 anyone is interested in putting in the time to solve this > problem properly then

[matplotlib-devel] Matplotlib PPA

As a couple of people have noticed, my matplotlib-daily PPA has become broken the other day, especially for 64-bit users. The root cause of this is that building the docs now requires numpydoc, which is only packaged in the development release of Ubuntu. I've taken this as a prompt to switch the d

Re: [matplotlib-devel] Matplotlib PPA

On 28 January 2013 15:57, Michael Droettboom wrote: > 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. > That's fine. I think I did see the discus

[matplotlib-devel] Docs build hitting an ImportError - any guesses?

The Launchpad daily builds have recently started failing on the docs build. I get the error message "Error: matplotlib must be installed before building the documentation", which means that there's an ImportError raised when it tries to import matplotlib. Unfortunately, it hides any other informati

Re: [matplotlib-devel] Docs build hitting an ImportError - any guesses?

On 2 March 2013 23:19, Thomas Kluyver wrote: > Not directly - it runs on a completely automated build server. I've just > pushed a commit to the packaging rules which will try this the next time it > does the build. But it's not exactly instant feedback for debugging ;-). >

Re: [matplotlib-devel] RFC: Moving plots out of axes

On 15 March 2013 17:18, Nathaniel Smith wrote: > On 15 Mar 2013 16:50, "Todd" wrote: > > Within the axes constructor, the constructor would run through each of > these modules and store them as attributes with the same name as the > function and the function itself being the contents. At least

Re: [matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master

On 19 June 2013 00:09, Fernando Perez wrote: > I wish we could just fix this plugin issue. When we drop support for Python 2.6, I think we can use the expectedFailure mechanism included in unittest from 2.7 onwards. So long as nose recognises that, we should be able to drop our copy of the Know

Re: [matplotlib-devel] Reviving the matplotlib survey

On 1 July 2013 16:09, Michael Droettboom wrote: > Everyone else: Are there any other changes you think we should make before > we put this out? We also started preparing a second user survey for IPython, but we haven't yet launched it. I think our questions are broadly similar to yours, but if

Re: [matplotlib-devel] NavigationToolbar2TkAgg changes in v1.2.0 win32 py2.6?

On 4 July 2013 13:27, Brasier, Steve wrote: > When I look in the svn browser > here(which > I assume is the current code?) > With no updates for the last couple of ye

Re: [matplotlib-devel] basemap installation problem with mpl master

On 6 July 2013 18:20, Damon McDougall wrote: > Long story. The short story is that distutils was merged into setuptools. > So setuptools is now the recommended way to install python packages. *distribute*, which was a fork of setuptools, was merged into setuptools. *distutils* is the componen

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

On 7 August 2013 12:54, Russell E. Owen wrote: > P.S. the Mac binary installer for numpy used to be easy to find. I was > quite dismayed to find how buried it had become when I went looking for > it a week or two ago. > Is this down to the redesign of the SciPy site. If so, blame me ;-). I felt,

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

On 8 August 2013 09:56, Russell E. Owen wrote: > BTW: pip refuses to install pytz for me, claiming a suitable version was > not found, and listing dozens of versions. Anyone else seen this? I > don't recall seeing it before recently. I ended up downloading the > source and using distutils. > Rec

Re: [matplotlib-devel] unicodeescape traceback on build of latest master in IPython

On 6 December 2013 04:55, Joel B. Mohler wrote: > C:\Python27\lib\site-packages\matplotlib\__init__.py in Verbose() > --> 252 for arg in map(six.u, sys.argv[1:]): > C:\Python27\lib\site-packages\six.pyc in u(s) > --> 468 return unicode(s, "unicode_escape") > UnicodeDecodeError: 'unico

Re: [matplotlib-devel] unicodeescape traceback on build of latest master in IPython

On 6 December 2013 10:37, Joel B. Mohler wrote: > It seems to me that this changeset needs to be rolled back, but I don't > clearly see the problem that it was intended to fix. > I assume that someone wanted to work with the arguments as text (i.e. unicode) strings. A robust way to do this would

Re: [matplotlib-devel] Automatic builds without NDEBUG?

On 19 April 2014 07:53, Jouni K. Seppänen wrote: > Do any of our Travis, Launchpad, or other daily builds undefine NDEBUG? I don't think the Launchpad builds undefine that, unless Launchpad does it for all builds by default. Thomas --

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

On 16 May 2014 01:17, "Eric Firing" wrote: > Maybe this problem could be reduced by having a directory for CHANGELOG > chunks, one file per PR, with the PR number as the filename. Then at > release time they could be concatenated, edited, appended to the real > CHANGELOG, and deleted. We already

Re: [matplotlib-devel] Please consider Html Help

On 28 July 2014 11:27, Benjamin Root wrote: > Going to the sourceforge page you have, I see that you mean "HTML Help" as > in ".chm" files. That is something different that I am not familiar with. > All of our documentation is generated from sphinx, so whatever sphinx > supports, we can generate.

Re: [matplotlib-devel] Capitalization of Matplotlib

On 16 February 2015 at 10:53, Nelle Varoquaux wrote: > 2. you are used to having sentences start with capital letter, but > this is mostly cultural. German People capitalize almost all Words in > a Sentence. It just looks weird too… > FWIW, I tried naming a few small projects with all-lowercase

Re: [matplotlib-devel] Fwd: python data vis Slack channels?

On 4 May 2015 at 09:45, Thomas Caswell wrote: > IPython and scikit image both have gitter rooms running that seem to > working well for them as well, is there any reason to go with slack over > gitter? > Gitter rooms are closely tied to Github repositories or organisations, so if you wanted to u