Menu
▾
▴
matplotlib-devel
|
From: Sandro T. <mo...@de...> - 2011-10-06 16:05:12
|
On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> 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 . -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: John H. <jd...@gm...> - 2011-10-06 16:09:56
|
On Thu, Oct 6, 2011 at 11:04 AM, Sandro Tosi <mo...@de...> wrote: > On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> 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 . Strange, I am seeing that too, even after deleting and re-uploading. Can you try from the sf page. https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/ I'm going to delete the file from the github download page. JDH |
|
From: Sandro T. <mo...@de...> - 2011-10-06 16:45:49
|
On Thu, Oct 6, 2011 at 18:09, John Hunter <jd...@gm...> wrote: > On Thu, Oct 6, 2011 at 11:04 AM, Sandro Tosi <mo...@de...> wrote: >> On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> 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 . > > > Strange, I am seeing that too, even after deleting and re-uploading. > Can you try from the sf page. > > https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/ > > I'm going to delete the file from the github download page. All fine from SF. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Christoph G. <cg...@uc...> - 2011-10-06 16:43:15
|
On 10/6/2011 7:57 AM, John Hunter wrote: > On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom<md...@st...> wrote: >> On 10/06/2011 10:46 AM, John Hunter wrote: >>> >>> On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote: >>>> >>>> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...> >>>> wrote: >>>> >>>>> Pretty simple. I have a pull request here: >>>>> >>>>> https://github.com/matplotlib/matplotlib/pull/509 >>>> >>>> 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? Do you need eggs (not tested; without pytz and dateutil)? Christoph |
|
From: John H. <jd...@gm...> - 2011-10-06 17:24:13
|
On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...> 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? > 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 |
|
From: Benjamin R. <ben...@ou...> - 2011-10-06 17:42:44
|
On Thursday, October 6, 2011, John Hunter <jd...@gm...> wrote: > On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...> 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? |
|
From: John H. <jd...@gm...> - 2011-10-06 17:55:37
|
On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben...@ou...> 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, 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. |
|
From: Christoph G. <cg...@uc...> - 2011-10-06 17:59:05
|
On 10/6/2011 10:42 AM, Benjamin Root wrote:
>
>
> On Thursday, October 6, 2011, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>> On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...
> <mailto:cg...@uc...>> 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
<https://sourceforge.net/mailarchive/message.php?msg_id=25760379>.
Christoph
|
|
From: Christoph G. <cg...@uc...> - 2011-10-06 22:24:00
|
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<jd...@gm...
>> <mailto:jd...@gm...>> wrote:
>>> On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke<cg...@uc...
>> <mailto:cg...@uc...>> 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
> <https://sourceforge.net/mailarchive/message.php?msg_id=25760379>.
>
> Christoph
>
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="jd...@gm...",
url="http://matplotlib.sourceforge.net",
packages = ['matplotlib.tests'],
package_dir = {'': 'lib'},
package_data = {'matplotlib.tests':['baseline_images/*/*']},
platforms='any'
)
|
|
From: Benjamin R. <ben...@ou...> - 2011-10-06 18:03:41
|
On Thu, Oct 6, 2011 at 12:55 PM, John Hunter <jd...@gm...> wrote: > On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben...@ou...> 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 |
|
From: Russell E. O. <ro...@uw...> - 2011-10-07 18:51:22
|
I'm running into an error building the Mac binary:
d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$
bdist_mpkg
basedirlist is: ['/usr/local']
=========================================================================
===
BUILDING MATPLOTLIB
matplotlib: 1.0.1
python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011,
14:13:39)
[GCC 4.0.1 (Apple Inc. build 5493)]
platform: darwin
REQUIRED DEPENDENCIES
numpy: 1.6.1
freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
libpng: found, but unknown version (no pkg-config)
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line
8, in <module>
load_entry_point('bdist-mpkg==0.4.4', 'console_scripts',
'bdist_mpkg')()
File
"build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line
27, in main
File "setup.py", line 162, in <module>
if check_for_tk() or (options['build_tkagg'] is True):
File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line
832, in check_for_tk
(Tkinter.__version__.split()[-2], Tkinter.TkVersion,
Tkinter.TclVersion))
IndexError: list index out of range
I have ActiveState Tk installed. Tkinter reports the following values:
Tkinter.__version__ = "$Revision$"
Tkinter.TkVersion = "8.4"
Tkinter.TclVersion = "8.4"
I assume I can get past this by hacking up setupext.py; I'm willing to
do that, but I'm wondering if it makes more sense to fix the bug. How
many other users are going to be bit by this?
1.0.1rc1 built with no problems, but I see that setupext.py had some
revisions since then.
-- Russell
P.S. I have no idea why freetype2 and libpng install without pkg-config;
I install them in in /usr/local in the usual way. However, those
warnings have been present for a long time and it never seems to cause
any trouble.
|
|
From: Benjamin R. <ben...@ou...> - 2011-10-07 19:12:19
|
On Fri, Oct 7, 2011 at 1:50 PM, Russell E. Owen <ro...@uw...> wrote:
> I'm running into an error building the Mac binary:
>
> d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$
> bdist_mpkg
> basedirlist is: ['/usr/local']
> =========================================================================
> ===
> BUILDING MATPLOTLIB
> matplotlib: 1.0.1
> python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011,
> 14:13:39)
> [GCC 4.0.1 (Apple Inc. build 5493)]
> platform: darwin
>
> REQUIRED DEPENDENCIES
> numpy: 1.6.1
> freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line
> 8, in <module>
> load_entry_point('bdist-mpkg==0.4.4', 'console_scripts',
> 'bdist_mpkg')()
> File
> "build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line
> 27, in main
> File "setup.py", line 162, in <module>
> if check_for_tk() or (options['build_tkagg'] is True):
> File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line
> 832, in check_for_tk
> (Tkinter.__version__.split()[-2], Tkinter.TkVersion,
> Tkinter.TclVersion))
> IndexError: list index out of range
>
> I have ActiveState Tk installed. Tkinter reports the following values:
> Tkinter.__version__ = "$Revision$"
> Tkinter.TkVersion = "8.4"
> Tkinter.TclVersion = "8.4"
>
> I assume I can get past this by hacking up setupext.py; I'm willing to
> do that, but I'm wondering if it makes more sense to fix the bug. How
> many other users are going to be bit by this?
>
> 1.0.1rc1 built with no problems, but I see that setupext.py had some
> revisions since then.
>
> -- Russell
>
> P.S. I have no idea why freetype2 and libpng install without pkg-config;
> I install them in in /usr/local in the usual way. However, those
> warnings have been present for a long time and it never seems to cause
> any trouble.
>
>
This build you are doing is v1.0.1, which is the old version. Did you grab
the wrong source, or did we upload the wrong stuff?
Ben Root
|
|
From: Russell O. <ro...@uw...> - 2011-10-07 20:33:00
|
Oops. Sorry about that. 1.1.0 built fine under Python 2.7 and passes all tests (except one known skip). I'll build 2.6 next and then upload both. -- Russell On Oct 7, 2011, at 12:11 PM, Benjamin Root wrote: > This build you are doing is v1.0.1, which is the old version. Did you grab the wrong source, or did we upload the wrong stuff? |
|
From: Fernando P. <fpe...@gm...> - 2011-10-07 19:55:40
|
On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> 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. 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 |
|
From: Sandro T. <mo...@de...> - 2011-10-07 22:17:18
|
On Fri, Oct 7, 2011 at 21:55, Fernando Perez <fpe...@gm...> wrote: > On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> 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. > > 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*, +1 Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X