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

2014-06-04 Thread Damon McDougall
Shall I go ahead and set up a MEP bof? Just got an email for a call for BoFs which reminded me to ask. On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root wrote: > That is unfortunate that we can't have a summit before/after SciPy 2014. I > have also booked my flights and hotel, and the only time I wo

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

2014-06-04 Thread Benjamin Root
Yes please. Last year's BoF was well-attended. I would expect nothing less this year. Ben On Wed, Jun 4, 2014 at 10:39 AM, Damon McDougall wrote: > Shall I go ahead and set up a MEP bof? Just got an email for a call > for BoFs which reminded me to ask. > > On Mon, Jun 2, 2014 at 2:15 PM, Benj

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

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

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

2014-06-04 Thread Benjamin Root
A theory... If I remember correctly, the nosttests was set up to execute in parallel using the default Multiprocessing settings, which is to have a process worker for each available CPU core. Perhaps this might be the crux of the issue with so many simultaneous tests running that the amount of mem

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

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

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

2014-06-04 Thread Benjamin Root
So, I just tried comparing memory usage for a plot displayed via show() versus savefig() as a PNG. It would seem that saving to pngs uses more memory. Not sure why, though. Ben On Jun 4, 2014 12:57 PM, "Eric Firing" wrote: > On 2014/06/04 6:26 AM, Benjamin Root wrote: > >> A theory... >> >> If I

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

2014-06-04 Thread Chris Barker
Hi Russell, > > >Makes we > > think we can drop 32 bit support, too. Maybe the newest 2.7 py.org > binaries > > could be 64 bit only. It would simplify things a bit. > > I hope you will not drop 32-bit support yet.. I still use it to > distribute some Tkinter apps. All recent versions of ActiveSta

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

2014-06-04 Thread Russell E. Owen
In article , Matthew Brett wrote: > Hi, > > On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen > wrote: > > In article > > > public.gmane.org>, > > Chris Barker wrote: > > > >> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett > >> > >> wrote: > >> > >> > > what is this going to do on OS-X 10

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

2014-06-04 Thread Chris Barker
On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen wrote: > What I need is a python, numpy, and matplotlib that support 32-bit and > (preferably) 64-bit for MacOS X 10.6 and later. I have been using > python.org python and the standard binary installers until now. > well we (that is, Matthew) have