matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix

[John H. <jd...@gm...>]

On Thu, Oct 13, 2011 at 10:06 AM, Daniel Hyams <dh...@gm...> wrote:

> Isn't the purpose of interpolation to handle situations where the image is
> being displayed at a different size than its native resolution?  It seems

Not solely, it can also be used to do local average of noisy images to
get a smoother view, eg bilinear or bicubic averaging of neighboring
pixels.

Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix

[Daniel H. <dh...@gm...>]

>
>
> imshow() does take an "interpolation" kwarg, where you can specify
> "nearest" for pre v1.1.0 versions and "none" (not None) in the recent
> release.  "nearest" would be close to what you want, while "none" is exactly
> what you want.
>
> Personally, I don't think it would be a good idea to automatically turn
> interpolation off on such a specific set of conditions, but I could be
> wrong.  I would rather have the user explicitly state their interpolation
> intentions.
>
> Ben Root


Hello Ben,

Isn't the purpose of interpolation to handle situations where the image is
being displayed at a different size than its native resolution?  It seems
appropriate to me to turn interpolation off in such a case.

Just some context of what I was up to when I ran into this one....I'm trying
to allow the user to paste images (either from file or clipboard) onto a
matplotlib canvas and be able to drag and resize them, very similar to the
way powerpoint works.  So I wanted to work with the appropriate image object
in matplotlib, and BboxImage was the best I found after digging in the code
for a bit; imshow() is too tied to the axis....these are supposed to be just
free floating images.

What I ran into was that, on initial paste (where I am sizing the BboxImage
the same width/height as the incoming picture), the image was very blurry
(because of the interpolation).  I still want the interpolation on so that
the image looks nice when it is resized by the user with the grab handles,
but in the specific case where no interpolation is needed, this patch turns
it off.

The pasting/dragging/resizing has actually turned out pretty well...once I
get it cleaned up and working how I want it to, I'll submit it to you guys
for inclusion into matplotlib if you want it.  I was hoping to formulate it
as a mixin that will work for any artist (not just BboxImage) within
reasonable limits.






-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix

[Benjamin R. <ben...@ou...>]

On Thursday, October 13, 2011, Daniel Hyams <dh...@gm...> wrote:
> I was playing around with images.BboxImage, and found that if I displayed,
say a 100x100 image at its native resolution (exactly 100x100 pixels on the
plotting window), it was blurred.  This is because of the interpolation
jumping in and interpolating when it is not needed.
> This might not be the best way to fix, but it does work....in matplotlib
1.0.0, it is image.py around line 1102 (this is BboxImage.make_image).  Just
after numrows and numcols is set in that routine, do
>  if (r-l) == numcols and (t-b) == numrows:
>             im.set_interpolation(0)
> As you can see, all this does is just flip the interpolation off if the
size of the image is the same size that it is about to be rendered as...and
the regular interpolation is used otherwise.
>
> I do apologize for the lack of a proper patch, but for little things like
this I think a word description works as well or better; I need to sit down
and both learn git and set of a development environment for matplotlib, but
after reading through the docs on the web site about it, decided that would
take me more time than I had at the moment.
>
> In context:
>     def make_image(self, renderer, magnification=1.0):
>         if self._A is None:
>             raise RuntimeError('You must first set the image array or the
image attribute')
>         if self._imcache is None:
>             if self._A.dtype == np.uint8 and len(self._A.shape) == 3:
>                 im = _image.frombyte(self._A, 0)
>                 im.is_grayscale = False
>             else:
>                 if self._rgbacache is None:
>                     x = self.to_rgba(self._A, self._alpha)
>                     self._rgbacache = x
>                 else:
>                     x = self._rgbacache
>                 im = _image.fromarray(x, 0)
>                 if len(self._A.shape) == 2:
>                     im.is_grayscale = self.cmap.is_gray()
>                 else:
>                     im.is_grayscale = False
>             self._imcache = im
>             if self.origin=='upper':
>                 im.flipud_in()
>         else:
>             im = self._imcache
>         # image input dimensions
>         im.reset_matrix()
>         im.set_interpolation(self._interpd[self._interpolation])
>
>
>         im.set_resample(self._resample)
>         l, b, r, t = self.get_window_extent(renderer).extents
#bbox.extents
>         widthDisplay = (round(r) + 0.5) - (round(l) - 0.5)
>         heightDisplay = (round(t) + 0.5) - (round(b) - 0.5)
>         widthDisplay *= magnification
>         heightDisplay *= magnification
>         numrows, numcols = self._A.shape[:2]
>
>         if (r-l) == numcols and (t-b) == numrows:    # <-----------------
add this
>             im.set_interpolation(0)
#<-------------- and this
>         # resize viewport to display
>         rx = widthDisplay / numcols
>         ry = heightDisplay  / numrows
>         #im.apply_scaling(rx*sx, ry*sy)
>         im.apply_scaling(rx, ry)
>         #im.resize(int(widthDisplay+0.5), int(heightDisplay+0.5),
>         #          norm=self._filternorm, radius=self._filterrad)
>         im.resize(int(widthDisplay), int(heightDisplay),
>                   norm=self._filternorm, radius=self._filterrad)
>         return im
>
> --
> Daniel Hyams
> dh...@gm...
>

Daniel,

imshow() does take an "interpolation" kwarg, where you can specify "nearest"
for pre v1.1.0 versions and "none" (not None) in the recent release.
 "nearest" would be close to what you want, while "none" is exactly what you
want.

Personally, I don't think it would be a good idea to automatically turn
interpolation off on such a specific set of conditions, but I could be
wrong.  I would rather have the user explicitly state their interpolation
intentions.

Ben Root

[matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix

[Daniel H. <dh...@gm...>]

I was playing around with images.BboxImage, and found that if I displayed,
say a 100x100 image at its native resolution (exactly 100x100 pixels on the
plotting window), it was blurred.  This is because of the interpolation
jumping in and interpolating when it is not needed.

This might not be the best way to fix, but it does work....in matplotlib
1.0.0, it is image.py around line 1102 (this is BboxImage.make_image).  Just
after numrows and numcols is set in that routine, do

 if (r-l) == numcols and (t-b) == numrows:
            im.set_interpolation(0)

As you can see, all this does is just flip the interpolation off if the size
of the image is the same size that it is about to be rendered as...and the
regular interpolation is used otherwise.


I do apologize for the lack of a proper patch, but for little things like
this I think a word description works as well or better; I need to sit down
and both learn git and set of a development environment for matplotlib, but
after reading through the docs on the web site about it, decided that would
take me more time than I had at the moment.


In context:

    def make_image(self, renderer, magnification=1.0):
        if self._A is None:
            raise RuntimeError('You must first set the image array or the
image attribute')

        if self._imcache is None:
            if self._A.dtype == np.uint8 and len(self._A.shape) == 3:
                im = _image.frombyte(self._A, 0)
                im.is_grayscale = False
            else:
                if self._rgbacache is None:
                    x = self.to_rgba(self._A, self._alpha)
                    self._rgbacache = x
                else:
                    x = self._rgbacache
                im = _image.fromarray(x, 0)
                if len(self._A.shape) == 2:
                    im.is_grayscale = self.cmap.is_gray()
                else:
                    im.is_grayscale = False
            self._imcache = im

            if self.origin=='upper':
                im.flipud_in()
        else:
            im = self._imcache

        # image input dimensions
        im.reset_matrix()

        im.set_interpolation(self._interpd[self._interpolation])



        im.set_resample(self._resample)

        l, b, r, t = self.get_window_extent(renderer).extents #bbox.extents
        widthDisplay = (round(r) + 0.5) - (round(l) - 0.5)
        heightDisplay = (round(t) + 0.5) - (round(b) - 0.5)
        widthDisplay *= magnification
        heightDisplay *= magnification

        numrows, numcols = self._A.shape[:2]

        if (r-l) == numcols and (t-b) == numrows:    # <-----------------
add this
            im.set_interpolation(0)
#<-------------- and this

        # resize viewport to display
        rx = widthDisplay / numcols
        ry = heightDisplay  / numrows
        #im.apply_scaling(rx*sx, ry*sy)
        im.apply_scaling(rx, ry)
        #im.resize(int(widthDisplay+0.5), int(heightDisplay+0.5),
        #          norm=self._filternorm, radius=self._filterrad)
        im.resize(int(widthDisplay), int(heightDisplay),
                  norm=self._filternorm, radius=self._filterrad)
        return im


-- 
Daniel Hyams
dh...@gm...

[matplotlib-devel] ANN: matplotlib-1.1.0

[John H. <jd...@gm...>]

A new release of matplotlib is available for download at

  https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0

There are lots of nifty new features like Sankey diagrams, an API for
animations and movie making, enhanced 3D support, support for
auto-layout of subplots with titles, xlabels and ylabels to prevent
text from running off the edge of the figure (tight_layout), pyside
supoprt, enhanced legends, and tons of other minor features and
bug-fixes.  See what's new at

  http://matplotlib.sourceforge.net/users/whats_new.html

and the CHANGELOG at

  https://github.com/matplotlib/matplotlib/blob/v1.1.x/CHANGELOG

and the commit history at

  https://github.com/matplotlib/matplotlib/commits/v1.1.x/

Please post issues on the github issue tracker and questions on the mailing list

  https://github.com/matplotlib/matplotlib/issues

Thanks to all the matplotlib developers who contributed to this
release, with special thanks to Michael Droettboom, Eric Firing,
Benjamin Root, Jouni Seppänen, Kevin Davies and Jae-Joon Lee for lots
of code contributions and bug fixes and to Christoph Gohlke and
Russell Owen for the windows and OX X binary installers.

JDH

Re: [matplotlib-devel] I and my wife recommend you to visit this site and your problem will be solved!

[Phil E. <phi...@ho...>]

...Forget about visiting local drugstores! Visit this on-line shop now!  http://j13.free.fr/friends.page.php?atgoogle=73si5
 		 	   		  

[matplotlib-devel] KnownFailure getting added as a global nose plugin in ubuntu 11.10 - bad idea

[Fernando P. <fpe...@gm...>]

Hi all,

I'm writing here in the hopes that both the ubuntu packagers are on
this list, and that we change things a bit in mpl to prevent this
problem from happening.  After a nasty debugging marathon with the
IPython test suite failing on Ubuntu 11.10 beta -- see details at
https://github.com/ipython/ipython/issues/823, I finally tracked the
problem down to this little gem:

amirbar[matplotlib-1.0.1.egg-info]> pwd
/usr/share/pyshared/matplotlib-1.0.1.egg-info
amirbar[matplotlib-1.0.1.egg-info]> cat entry_points.txt
[nose.plugins]
KnownFailure = matplotlib.testing.noseclasses:KnownFailure


I'm not sure why the packagers decided to register this as a global
plugin, but it makes a mess. You can read some of the details in the
thread above if you're really interested.  I've filed the ubuntu bug
here:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176

But I suggest we actually *remove* this code from matplotlib
altogether.  In ipython we do carry a copy of the same code, but we
load it very conditionally, only if numpy isn't found:

https://github.com/ipython/ipython/blob/master/IPython/external/decorators/_numpy_testing_noseclasses.py

This ensures we'll never collide with the 'real' version in numpy.
For IPython, numpy isn't a dependency, so we have to do this.  But mpl
always has numpy around, so perhaps it would be better to simply use
it from numpy?

Cheers,

f

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Sandro T. <mo...@de...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Russell O. <ro...@uw...>]

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 <jd...@gm...> 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...

Re: [matplotlib-devel] Problem with proposed 1.0.1 release

[Russell O. <ro...@uw...>]

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?

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Fernando P. <fpe...@gm...>]

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

Re: [matplotlib-devel] Problem with proposed 1.0.1 release

[Benjamin R. <ben...@ou...>]

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

[matplotlib-devel] Problem with proposed 1.0.1 release

[Russell E. O. <ro...@uw...>]

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.

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Christoph G. <cg...@uc...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Benjamin R. <ben...@ou...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Christoph G. <cg...@uc...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[John H. <jd...@gm...>]

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.

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Benjamin R. <ben...@ou...>]

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?

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[John H. <jd...@gm...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Sandro T. <mo...@de...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Christoph G. <cg...@uc...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[John H. <jd...@gm...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Sandro T. <mo...@de...>]

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[John H. <jd...@gm...>]

On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> 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.

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

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[John H. <jd...@gm...>]

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