OK, and now I see that Michael removed multi-processing entirely in #507
···
On Thu, Oct 6, 2011 at 9:44 AM, John Hunter <jdh2358@...149...> wrote:
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <mdroe@...31...> wrote:
Pretty simple. I have a pull request here:
Backend qt4 bugs by mdboom · Pull Request #509 · matplotlib/matplotlib · GitHub
I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!
Yeah -- it only really saves around 30seconds anyway. I thought it best to have it work reliably -- we can investigate the cause of Sandro's failure (which I'm not able to reproduce) later -- no need for it to hold up the release.
Mike
···
On 10/06/2011 10:46 AM, John Hunter wrote:
On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jdh2358@...149...> wrote:
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<mdroe@...31...> wrote:
Pretty simple. I have a pull request here:
Backend qt4 bugs by mdboom · Pull Request #509 · matplotlib/matplotlib · GitHub
I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!
OK, and now I see that Michael removed multi-processing entirely in #507
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
if Sandro would like to start with the debian packaging. Russell and
Christoph, if you could point me to some binary builds I'll upload
these to the sf site along with the tarballs and do the ANN.
Thanks all,
JDH
···
On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom <mdroe@...31...> wrote:
On 10/06/2011 10:46 AM, John Hunter wrote:
On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jdh2358@...149...> wrote:
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<mdroe@...31...> >>> wrote:
Pretty simple. I have a pull request here:
Backend qt4 bugs by mdboom · Pull Request #509 · matplotlib/matplotlib · GitHub
I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!
OK, and now I see that Michael removed multi-processing entirely in #507
Yeah -- it only really saves around 30seconds anyway. I thought it best to
have it work reliably -- we can investigate the cause of Sandro's failure
(which I'm not able to reproduce) later -- no need for it to hold up the
release.
Actually, if you can just upload the binaries directly to
https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
that will save a step. Christoph, if you send me you sf ID I'll make
sure you have upload permissions. Russell, you should already be good
to go.
JDH
···
On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jdh2358@...149...> wrote:
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
if Sandro would like to start with the debian packaging. Russell and
Christoph, if you could point me to some binary builds I'll upload
these to the sf site along with the tarballs and do the ANN.
I got an access denied for sample_data (I'm logged in as 'sandrotosi'
on github) while I can get without problem mpl-1.1.0.tar.gz .
···
On Thu, Oct 6, 2011 at 16:57, John Hunter <jdh2358@...149...> wrote:
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Strange, I am seeing that too, even after deleting and re-uploading.
Can you try from the sf page.
I'm going to delete the file from the github download page.
JDH
···
On Thu, Oct 6, 2011 at 11:04 AM, Sandro Tosi <morph@...12...> wrote:
On Thu, Oct 6, 2011 at 16:57, John Hunter <jdh2358@...149...> wrote:
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
I got an access denied for sample_data (I'm logged in as 'sandrotosi'
on github) while I can get without problem mpl-1.1.0.tar.gz .
Is it really intended to include ~36 MB of tests/baseline_images in the binary distributions for end users?
Do you need eggs (not tested; without pytz and dateutil)?
Christoph
···
On 10/6/2011 7:57 AM, John Hunter wrote:
On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom<mdroe@...31...> wrote:
On 10/06/2011 10:46 AM, John Hunter wrote:
On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jdh2358@...149...> wrote:
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<mdroe@...31...> >>>> wrote:
Pretty simple. I have a pull request here:
Backend qt4 bugs by mdboom · Pull Request #509 · matplotlib/matplotlib · GitHub
I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!
OK, and now I see that Michael removed multi-processing entirely in #507
Yeah -- it only really saves around 30seconds anyway. I thought it best to
have it work reliably -- we can investigate the cause of Sandro's failure
(which I'm not able to reproduce) later -- no need for it to hold up the
release.
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
if Sandro would like to start with the debian packaging. Russell and
Christoph, if you could point me to some binary builds I'll upload
these to the sf site along with the tarballs and do the ANN.
Thanks all,
JDH
Is it really intended to include ~36 MB of tests/baseline_images in the
binary distributions for end users?
I'm OK with excluding the test images from the binaries. Does anyone disagree?
Do you need eggs (not tested; without pytz and dateutil)?
I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
JDH
···
On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cgohlke@...244...> wrote:
Is it really intended to include ~36 MB of tests/baseline_images in the
binary distributions for end users?
I’m OK with excluding the test images from the binaries. Does anyone disagree?
What happens if someone tries to test without having the baseline images? I guess it hasn’t been an issue before.
Do you need eggs (not tested; without pytz and dateutil)?
I’m OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?
···
On Thursday, October 6, 2011, John Hunter <jdh2358@…149…> wrote:
On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cgohlke@…244…> wrote:
What happens if someone tries to test without having the baseline images? I
guess it hasn't been an issue before.
Tests will fail. But the tests are already pretty dependent on things
like freetype version so it might be more trouble than it is worth to
try and support them in a generic user environment.
Do you need eggs (not tested; without pytz and dateutil)?
I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?
Yep,
But they have been the source of much pain and annoyance, especially on OSX.
···
On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben.root@...553...> wrote:
> Is it really intended to include ~36 MB of tests/baseline_images in the
> binary distributions for end users?
I'm OK with excluding the test images from the binaries. Does anyone
disagree?
What happens if someone tries to test without having the baseline
images? I guess it hasn't been an issue before.
The baseline images were included in previous binary distributions but they were much smaller (~10 MB uncompressed). Mpl 1.1 includes ~19.5 MB new test_delaunay images.
The mpl 1.1 installers with baseline images are around 30 MB, vs. ~4.2 MB without.
There's a switch in setup.py:
if 0:
# TODO: exclude these when making release?
baseline_images = glob.glob(os.path.join('lib','matplotlib','tests',
'baseline_images','*','*'))
> Do you need eggs (not tested; without pytz and dateutil)?
I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?
Yes, on request for mpl 1.0.1 <[Matplotlib-users] where to find python eggs for matplotlib 1.0.0? | matplotlib.
Christoph
···
On 10/6/2011 10:42 AM, Benjamin Root wrote:
On Thursday, October 6, 2011, John Hunter <jdh2358@...149... > <mailto:jdh2358@…149…>> wrote:
On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cgohlke@...244... > <mailto:cgohlke@…244…>> wrote:
What happens if someone tries to test without having the baseline images? I
guess it hasn’t been an issue before.
Tests will fail. But the tests are already pretty dependent on things
like freetype version so it might be more trouble than it is worth to
try and support them in a generic user environment.
That’s valid. I guess I am just wondering if there is a decent error message to the user explaining that the test could not proceed.
Do you need eggs (not tested; without pytz and dateutil)?
I’m OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?
Yep,
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1
But they have been the source of much pain and annoyance, especially on OSX.
True. Perhaps having fewer installation options available at the download page would be better/clearer. Maybe leave egg distribution to pip and easy_install?
Ben Root
···
On Thu, Oct 6, 2011 at 12:55 PM, John Hunter <jdh2358@…552…149…> wrote:
On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben.root@…553…> wrote:
I am ready to upload installers without the baseline images. How about a separate installer for matplotlib.tests?
# setup_tests.py
from distutils.core import setup
for line in open('lib/matplotlib/__init__.py').readlines():
if (line.startswith('__version__')):
exec(line.strip())
setup(name="matplotlib-tests",
version=__version__,
description="Tests for matplotlib",
author="John D. Hunter",
author_email="jdh2358@...149...",
url="http://matplotlib.sourceforge.net",
packages = ['matplotlib.tests'],
package_dir = {'': 'lib'},
package_data = {'matplotlib.tests':['baseline_images/*/*']},
platforms='any'
)
···
On 10/6/2011 10:58 AM, Christoph Gohlke wrote:
On 10/6/2011 10:42 AM, Benjamin Root wrote:
On Thursday, October 6, 2011, John Hunter<jdh2358@...149... >> <mailto:jdh2358@…149…>> wrote:
On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke<cgohlke@...244... >> <mailto:cgohlke@…244…>> wrote:
Is it really intended to include ~36 MB of tests/baseline_images in the
binary distributions for end users?
I'm OK with excluding the test images from the binaries. Does anyone
disagree?
What happens if someone tries to test without having the baseline
images? I guess it hasn't been an issue before.
The baseline images were included in previous binary distributions but
they were much smaller (~10 MB uncompressed). Mpl 1.1 includes ~19.5 MB
new test_delaunay images.
The mpl 1.1 installers with baseline images are around 30 MB, vs. ~4.2
MB without.
There's a switch in setup.py:
if 0:
# TODO: exclude these when making release?
baseline_images = glob.glob(os.path.join('lib','matplotlib','tests',
'baseline_images','*','*'))
Do you need eggs (not tested; without pytz and dateutil)?
I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?
Yes, on request for mpl 1.0.1
<[Matplotlib-users] where to find python eggs for matplotlib 1.0.0? | matplotlib.
Christoph
Rig the test runner to properly skip them instead of failing? The
test data should be considered a dependency for those tests, and
absent the dependency, the users simply get less tests, but not a ton
of failures.
Not saying this should be done *now*, but I think in general having
users be able to run the test suite in their environments is useful,
even if parts are skipped for some reason. You never know when that
will uncover true failures...
That's the approach we take in ipython: we have a lot of tests that
depend on various tools/environment/os, that simply get skipped. In
fact, there is no way to run the *entire* ipython test suite in one
go, since there are mutually exclusive tests (like things that only
run on OSX or Windows). So inevitably, every test run is *always*
partial. Once you think about it that way, then this is just one more
dependency to be handled just like any other.
Cheers,
f
···
On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben.root@...553...> wrote:
That's valid. I guess I am just wondering if there is a decent error
message to the user explaining that the test could not proceed.
Mac binaries for Python 2.6 and 32-bit Python 2.7 are now uploaded.
– Russell
···
On Oct 6, 2011, at 8:18 AM, John Hunter wrote:
On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jdh2358@…149…> wrote:
…
Actually, if you can just upload the binaries directly to
https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
that will save a step…