matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Planning for 1.3.0

[Derek H. <de...@as...>]

Hi Michiel,

> This RuntimeError is there for a reason: If your Python is not installed as  a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).

I have used the MacOSX backend ever since I started working with Python,
and there only was a warning for the last 3 years or so. Other than my plot
windows evading the control of Exposé/Application switcher I have never
noticed any problems with this. Thus my request in my initial post to leave it
as a mere warning, since I'd think people can switch on their own decision
if they do not like the interaction (or lack thereof) with the window manager.
Otherwise I would have to grudgingly switch to another backend (seems now
that I could live with QT4Agg-Quartz or the like though), since installation as
as framework is not an option with Fink.
Of course if there are any other possible negative effects besides the window
handling, I'd take your point.

Best,
						Derek

Re: [matplotlib-devel] Planning for 1.3.0

[Michiel de H. <mjl...@ya...>]

Hi Derek,

--- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
> The RuntimeError was enforced by the #ifdef
> WITH_NEXT_FRAMEWORK check that
> does not allow to use the backend at all, so I had to change
> this to a RuntimeWarning
> to be able to test the backend in the 1.3 branch.

This RuntimeError is there for a reason: If your Python is not installed as  a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).

Best,
-Michiel

Re: [matplotlib-devel] Planning for 1.3.0

[Derek H. <de...@as...>]

Hi Michiel,

> That is good to hear.
> The slowdown was caused by the performance of Quartz itself, but it depends strongly on the line width. In your example, the plot appears immediately if you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if you use linewidth=1.0. The change in set_dpi caused the line width actually used for drawing to increase slightly. The increase was very small, but big enough to trigger the ultraslow behavior of Quartz. As I mentioned, we solved this by breaking up the path into many subpaths, which solved the problem (without having to change set_dpi back).
> Anyway, if I understand your mail correctly, the problem has been fixed in HEAD. Is the 1.3 branch also OK now? In your first post you mentioned that there was some RuntimeError.

I saw a couple of warnings with Friday's checkout on 10.8, but the current one seems to
work fine (now on 10.7 however…). I've run the full test suite and only had three failures
in test_font_styles (basically all created fonts look like 'light'/'condensed').
The same with python3.2 after I upgraded pyparsing, only at the end of 'setup.py install'
there was an additional error, but this did not seem to affect the install (appended below).

The RuntimeError was enforced by the #ifdef WITH_NEXT_FRAMEWORK check that
does not allow to use the backend at all, so I had to change this to a RuntimeWarning
to be able to test the backend in the 1.3 branch.

Cheers,
					Derek

--
Processing matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
creating /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
Extracting matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg to /Users/derek/lib/python3.2/site-packages
Adding matplotlib 1.3.x to easy-install.pth file

Installed /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
Processing dependencies for matplotlib==1.3.x
Traceback (most recent call last):
 File "setup.py", line 228, in <module>
   'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
 File "/sw/lib/python3.2/distutils/core.py", line 148, in setup
   dist.run_commands()
 File "/sw/lib/python3.2/distutils/dist.py", line 917, in run_commands
   self.run_command(cmd)
 File "/sw/lib/python3.2/distutils/dist.py", line 936, in run_command
   cmd_obj.run()
 File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 73, in run
   self.do_egg_install()
 File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 101, in do_egg_install
   cmd.run()
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 358, in run
   self.easy_install(spec, not self.no_deps)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 582, in easy_install
   return self.install_item(None, spec, tmpdir, deps, True)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 634, in install_item
   self.process_distribution(spec, dist, deps)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 686, in process_distribution
   [requirement], self.local_index, self.easy_install
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 586, in resolve
   dist = best[req.key] = env.best_match(req, self, installer)
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 829, in best_match
   for dist in self[req.key]:
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 799, in __getitem__
   _sort_dists(dists)
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 2613, in _sort_dists
   tmp.sort()
TypeError: unorderable types: NoneType() < str()

Re: [matplotlib-devel] Planning for 1.3.0

[Michiel de H. <mjl...@ya...>]

Hi Derek,

That is good to hear.
The slowdown was caused by the performance of Quartz itself, but it depends strongly on the line width. In your example, the plot appears immediately if you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if you use linewidth=1.0. The change in set_dpi caused the line width actually used for drawing to increase slightly. The increase was very small, but big enough to trigger the ultraslow behavior of Quartz. As I mentioned, we solved this by breaking up the path into many subpaths, which solved the problem (without having to change set_dpi back).
Anyway, if I understand your mail correctly, the problem has been fixed in HEAD. Is the 1.3 branch also OK now? In your first post you mentioned that there was some RuntimeError.

Best,
-Michiel.

--- On Sat, 4/13/13, Derek Homeier <de...@as...> wrote:

> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "matplotlib development list" <mat...@li...>
> Date: Saturday, April 13, 2013, 9:03 AM
> Hi Michiel,
> 
> On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:
> 
> > The slow speed for long paths like the one in your
> example was due to a limitation to Quartz itself. This was
> solved by breaking the path up into subpaths of up to 100
> points. But you mentioned that releases before 1.2 were not
> slow (and I verified this with matplotlib 1.1.1), suggesting
> that something else is going on. Can you check which change
> between 1.1.1 and 1.2 is causing the slowdown for your
> example?
> 
> It's the passing of set_dpi (commit 6533674) - that's still
> unchanged in master,
> but I don't see any speed penalty compared to 1.1.1 any
> more. I don't know if
> the change you mentioned above completely fixed this or just
> made up for it
> by speeding it up otherwise…
> I have just merged all updates to backend_maxosx.py and
> _macosx.m back
> into 1.2.1, and this seems to solve the issue and passes all
> tests as well.
> 
> Cheers,
>            
>         Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Re: [matplotlib-devel] Planning for 1.3.0

[Derek H. <de...@as...>]

Hi Michiel,

On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:

> The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?

It's the passing of set_dpi (commit 6533674) - that's still unchanged in master,
but I don't see any speed penalty compared to 1.1.1 any more. I don't know if
the change you mentioned above completely fixed this or just made up for it
by speeding it up otherwise…
I have just merged all updates to backend_maxosx.py and _macosx.m back
into 1.2.1, and this seems to solve the issue and passes all tests as well.

Cheers,
					Derek

[matplotlib-devel] Timers independent of canvases

[Michiel de H. <mjl...@ya...>]

Dear all,

The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in

>>> f = pylab.figure()
>>> timer = f.canvas.new_timer()

This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed.

I would therefore propose to make timers independent of canvases. Something like this:

>>> from matplotlib import events
>>> timer = events.Timer()

This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it.

I have made a branch on github that does exactly this; see
https://github.com/mdehoon/matplotlib/tree/Timer
I have verified that the animation examples still work correctly with all backends.

Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request.

Best,
-Michiel.

[matplotlib-devel] interesting article about visualization

[Michael D. <md...@st...>]

http://blogs.hbr.org/cs/2013/04/the_science_of_what_we_do_and_dont_know_about_data_visualization.html

Re: [matplotlib-devel] Planning for 1.3.0

[Michiel de H. <mjl...@ya...>]

Hi Derek,

The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?

Best,
-Michiel.

--- On Fri, 4/12/13, Derek Homeier <de...@as...> wrote:

> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "mat...@li... list" <mat...@li...>
> Date: Friday, April 12, 2013, 5:16 PM
> On 11.04.2013, at 6:38PM, Michael
> Droettboom <md...@st...>
> wrote:
> 
> > Congrats to everyone on a successful 1.2.1 -- there was
> a relatively 
> > small influx of bug reports following it -- perhaps a
> sign of improving 
> > quality?
> 
> Thanks and congratulations to everyone involved as well;
> I've built 1.2.1 on MacOS X with fink for 
> Python2.6-3.2 without any failures in the test suite!
> I did run into a problem though that has actually existed
> since the first 1.2 release - with the MacOSX
> backend line plots of somewhat larger arrays with
> significant "high-frequency" power had extremely
> degraded, e.g. something like
> 
> x = np.linspace(0,10,1.e6)
> y =
> np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
> plt.plot(x, y)
> 
> would display within less than 2 seconds with 1.1.1, but
> with 1.2.x you literally have to wait minutes,
> and it takes similarly long to zoom in as long as you have a
> substantial part of the line in the window.
> 
> I found in the current HEAD (9e477b3) this has finally been
> fixed - thanks for that as well, whatever
> the problem was, but now in the 1.3 branch the _macosx
> backend has been altogether disabled!
> I verified after removing that RuntimeError from _macosx.m
> that the backend still works and is indeed
> up to its old speed; but if that change stays in, it won't
> be usable from non-framework Python installs
> like the fink ones. 
> Personally, I am aware of the problems with the missing
> window manager control, and occasionally
> am annoyed by hunting for a plot window that has sneaked
> somewhere underneath other windows,
> but with that in mind I still prefer the MacOSX backend to
> any of the others, and I would suggest to
> leave it at a warning rather than an error, so users can
> still decide for themselves if they want to put
> up with the possible troubles.
> 
> Cheers,
>            
>            
>     Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Re: [matplotlib-devel] Planning for 1.3.0

[Derek H. <de...@as...>]

On 11.04.2013, at 6:38PM, Michael Droettboom <md...@st...> wrote:

> Congrats to everyone on a successful 1.2.1 -- there was a relatively 
> small influx of bug reports following it -- perhaps a sign of improving 
> quality?

Thanks and congratulations to everyone involved as well; I've built 1.2.1 on MacOS X with fink for 
Python2.6-3.2 without any failures in the test suite!
I did run into a problem though that has actually existed since the first 1.2 release - with the MacOSX
backend line plots of somewhat larger arrays with significant "high-frequency" power had extremely
degraded, e.g. something like

x = np.linspace(0,10,1.e6)
y = np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
plt.plot(x, y)

would display within less than 2 seconds with 1.1.1, but with 1.2.x you literally have to wait minutes,
and it takes similarly long to zoom in as long as you have a substantial part of the line in the window.

I found in the current HEAD (9e477b3) this has finally been fixed - thanks for that as well, whatever
the problem was, but now in the 1.3 branch the _macosx backend has been altogether disabled!
I verified after removing that RuntimeError from _macosx.m that the backend still works and is indeed
up to its old speed; but if that change stays in, it won't be usable from non-framework Python installs
like the fink ones. 
Personally, I am aware of the problems with the missing window manager control, and occasionally
am annoyed by hunting for a plot window that has sneaked somewhere underneath other windows,
but with that in mind I still prefer the MacOSX backend to any of the others, and I would suggest to
leave it at a warning rather than an error, so users can still decide for themselves if they want to put
up with the possible troubles.

Cheers,
							Derek

Re: [matplotlib-devel] Planning for 1.3.0

[Phil E. <pel...@gm...>]

Great news! A lot of fantastic work has been done by a whole host of people
to go into this release. It's exciting stuff!

May 27th sounds like a sensible target to me. As you know, I'm an advocate
of releasing often - the more frequently we make a release, the less we
will have the "impending release rush" that can really hamper the whole
release process.

Cheers,




On 11 April 2013 17:38, Michael Droettboom <md...@st...> wrote:

> Congrats to everyone on a successful 1.2.1 -- there was a relatively
> small influx of bug reports following it -- perhaps a sign of improving
> quality?
>
> In any event, as Phil Elson likes to repeatedly point out (<wink>), we
> have a great deal of awesome new features in master that it would be
> great to get out.  As for time frame, I think if we aim for a 1.3.0rc1
> of May 27, that's within a good time frame to get something out in time
> for Scipy.  That will put us about 8 months past 1.2.0, which is not far
> off from my eventual goal of 6 month releases once things get
> streamlined.  We can, of course, adjust the date as necessary as we go
> along.
>
> So... let the bug triaging begin!  As there are lot of new features in
> the queue, I think it's important to distinguish the "nice to have" from
> the "must have".  I've created a new milestone "1.3.x blocker" that we
> should use for critical bugs that should hold up the release.  All other
> new features that are looking close to ready for 1.3.x should be
> milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.
> Simple bugs that apply to 1.2.x as well as master should be milestoned
> as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as
> I still think we should reserve the right to make another 1.2.2 bugfix
> release if necessary.
>
> There are a couple major ongoing projects that I think we'll need to get
> to a steady interim state before we can make another release.
>
>    MEP10: Documentation
>
>       We already have a number of improved docstrings, and better
> organization throughout.  I don't think we need to finish all of this
> work before the next release, but we should get it back into shape so
> that the doc build has fewer warnings (#1896) and the LaTeX build works
> again (#1836).
>
>    MEP12: Reorganize and cleanup examples
>
>       Again, I think a lot of great work has already been done, and we
> don't necessarily have to wait until it's done.
>
> For both of the above, it would be nice to divide the work up so the
> leaders of those projects are less individually burdened.  Nelle and
> Tony, if you know of any critical blockers or loose ends that should be
> tied up before a release should be made, please make issues for them and
> milestone them as "1.3.x blocker".
>
> Cheers,
> Mike
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Planning for 1.3.0

[Michael D. <md...@st...>]

Congrats to everyone on a successful 1.2.1 -- there was a relatively 
small influx of bug reports following it -- perhaps a sign of improving 
quality?

In any event, as Phil Elson likes to repeatedly point out (<wink>), we 
have a great deal of awesome new features in master that it would be 
great to get out.  As for time frame, I think if we aim for a 1.3.0rc1 
of May 27, that's within a good time frame to get something out in time 
for Scipy.  That will put us about 8 months past 1.2.0, which is not far 
off from my eventual goal of 6 month releases once things get 
streamlined.  We can, of course, adjust the date as necessary as we go 
along.

So... let the bug triaging begin!  As there are lot of new features in 
the queue, I think it's important to distinguish the "nice to have" from 
the "must have".  I've created a new milestone "1.3.x blocker" that we 
should use for critical bugs that should hold up the release.  All other 
new features that are looking close to ready for 1.3.x should be 
milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.  
Simple bugs that apply to 1.2.x as well as master should be milestoned 
as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as 
I still think we should reserve the right to make another 1.2.2 bugfix 
release if necessary.

There are a couple major ongoing projects that I think we'll need to get 
to a steady interim state before we can make another release.

   MEP10: Documentation

      We already have a number of improved docstrings, and better 
organization throughout.  I don't think we need to finish all of this 
work before the next release, but we should get it back into shape so 
that the doc build has fewer warnings (#1896) and the LaTeX build works 
again (#1836).

   MEP12: Reorganize and cleanup examples

      Again, I think a lot of great work has already been done, and we 
don't necessarily have to wait until it's done.

For both of the above, it would be nice to divide the work up so the 
leaders of those projects are less individually burdened.  Nelle and 
Tony, if you know of any critical blockers or loose ends that should be 
tied up before a release should be made, please make issues for them and 
milestone them as "1.3.x blocker".

Cheers,
Mike

Re: [matplotlib-devel] Bug in imsave

[gary r. <gar...@gm...>]

ceil doesn't work for me
I tried
figsize = [np.ceil(x / float(dpi)) for x in (arr.shape[1], arr.shape[0])]
and it fails on my second test when dpi=2 and i=25
result=26x26

Gary


On 9 April 2013 07:03, Michael Droettboom <md...@st...> wrote:

>  On 04/08/2013 02:38 PM, Benjamin Root wrote:
>
>
>
>
> On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm...> wrote:
>
>>   Hi, I haven't looked at this list for a long time, so hi to all the
>> active devs.
>>  I just came across a problem in the image.py imsave() function.
>>
>> Problem:
>> At an ipython --pylab prompt, typing
>>
>> a = rand(29,29)
>> imsave('test.png', a)
>>
>>  incorrectly generates a 28x28 pixel image.
>> This happens for several array sizes (I initially saw it for 226x226).
>>
>> Line 1272 of image.py is
>> figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>> figsize interacts with the bounding box code somehow to create off-by-one
>> results for certain values of array shape.
>>
>>
>> Possible solution:
>> To fix this properly, I think the float cast should be removed and
>> integer-based math should be used, but I thought that since it was rounding
>> down in the cases I saw, a change to the following should fix this:
>>
>> figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>>  and indeed this seems to work.
>>  To verify this, I ran the following brute-force test of all image sizes
>> up to 1024x1024 at some common dpi values:
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>> import os
>>
>> for dpi in [75, 100, 150, 300, 600, 1200]:
>>     for i in range(1,1025):
>>         print dpi, i,
>>         im = np.random.random((i,i))
>>         fname = 'test{:03d}.png'.format(i)
>>         plt.imsave(fname, im, dpi=dpi)
>>         im = plt.imread(fname)[:,:,0]
>>         print im.shape
>>         assert im.shape == (i, i)
>>         os.remove(fname)
>>
>>  and everything passed.
>>
>>  For completeness I also explored the dpi-space with these loop ranges
>> and the above loop body:
>>
>> for dpi in range(1, 101):
>>     for i in range(25, 36):
>>         ...
>>
>> and all was still well.
>>
>>
>>  Workaround:
>>  For the moment I've set dpi=1 in my call to imsave which effectively
>> reverts its behaviour to the original imsave code prior to the introduction
>> of the dpi parameter.
>>
>>  I think this testing is rigorous enough to make this change.
>>  If you agree, has anyone got time to change this, or shall I do a pull
>> request when I have time?
>>
>>  thanks,
>>  Gary
>>
>>
>  Good catch on this.  So you are saying that this bug was introduced
> relatively recently with the dpi kwarg?  I would suggest you make a PR so
> that this doesn't get lost (or at the very least file a bug report).  As
> for the fix itself, off the top of my head, wouldn't math.ceil() do what we
> want?  I prefer to be explicit in any intents rather than just simply (x +
> 0.5) / float(dpi).  As for the test, I would wonder if some sort of
> restricted version of that test might not be good to do?  I am thinking
> about 10 different sized plots and we wouldn't even need to have a the
> assert check or file removal test, as the image comparison framework would
> throw an exception when attempting to compare two images of different sizes
> (I think...).
>
>
> I think this bug goes back at least to hash 17192518, by me in May 2010.
> The suggested fix (probably using ceil to be more explicit as you suggest)
> seems right.
>
> As for the test, I think just `imsave` to a buffer, and loading that
> buffer back in with `imread` and asserting the sizes are the same should be
> sufficient.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Bug in imsave

[Michael D. <md...@st...>]

On 04/08/2013 02:38 PM, Benjamin Root wrote:
>
>
>
> On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm... 
> <mailto:gar...@gm...>> wrote:
>
>     Hi, I haven't looked at this list for a long time, so hi to all
>     the active devs.
>     I just came across a problem in the image.py imsave() function.
>
>     Problem:
>     At an ipython --pylab prompt, typing
>
>     a = rand(29,29)
>     imsave('test.png', a)
>
>     incorrectly generates a 28x28 pixel image.
>     This happens for several array sizes (I initially saw it for 226x226).
>
>     Line 1272 of image.py is
>     figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
>     figsize interacts with the bounding box code somehow to create
>     off-by-one results for certain values of array shape.
>
>
>     Possible solution:
>     To fix this properly, I think the float cast should be removed and
>     integer-based math should be used, but I thought that since it was
>     rounding down in the cases I saw, a change to the following should
>     fix this:
>
>     figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1],
>     arr.shape[0])]
>
>     and indeed this seems to work.
>     To verify this, I ran the following brute-force test of all image
>     sizes up to 1024x1024 at some common dpi values:
>
>     import matplotlib.pyplot as plt
>     import numpy as np
>     import os
>
>     for dpi in [75, 100, 150, 300, 600, 1200]:
>         for i in range(1,1025):
>             print dpi, i,
>             im = np.random.random((i,i))
>             fname = 'test{:03d}.png'.format(i)
>             plt.imsave(fname, im, dpi=dpi)
>             im = plt.imread(fname)[:,:,0]
>             print im.shape
>             assert im.shape == (i, i)
>             os.remove(fname)
>
>     and everything passed.
>
>     For completeness I also explored the dpi-space with these loop
>     ranges and the above loop body:
>
>     for dpi in range(1, 101):
>         for i in range(25, 36):
>             ...
>
>     and all was still well.
>
>
>     Workaround:
>     For the moment I've set dpi=1 in my call to imsave which
>     effectively reverts its behaviour to the original imsave code
>     prior to the introduction of the dpi parameter.
>
>     I think this testing is rigorous enough to make this change.
>     If you agree, has anyone got time to change this, or shall I do a
>     pull request when I have time?
>
>     thanks,
>     Gary
>
>
> Good catch on this.  So you are saying that this bug was introduced 
> relatively recently with the dpi kwarg?  I would suggest you make a PR 
> so that this doesn't get lost (or at the very least file a bug 
> report).  As for the fix itself, off the top of my head, wouldn't 
> math.ceil() do what we want?  I prefer to be explicit in any intents 
> rather than just simply (x + 0.5) / float(dpi).  As for the test, I 
> would wonder if some sort of restricted version of that test might not 
> be good to do?  I am thinking about 10 different sized plots and we 
> wouldn't even need to have a the assert check or file removal test, as 
> the image comparison framework would throw an exception when 
> attempting to compare two images of different sizes (I think...).

I think this bug goes back at least to hash 17192518, by me in May 
2010.  The suggested fix (probably using ceil to be more explicit as you 
suggest) seems right.

As for the test, I think just `imsave` to a buffer, and loading that 
buffer back in with `imread` and asserting the sizes are the same should 
be sufficient.

Mike

Re: [matplotlib-devel] Bug in imsave

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

On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm...> wrote:

> Hi, I haven't looked at this list for a long time, so hi to all the active
> devs.
> I just came across a problem in the image.py imsave() function.
>
> Problem:
> At an ipython --pylab prompt, typing
>
> a = rand(29,29)
> imsave('test.png', a)
>
> incorrectly generates a 28x28 pixel image.
> This happens for several array sizes (I initially saw it for 226x226).
>
> Line 1272 of image.py is
> figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> figsize interacts with the bounding box code somehow to create off-by-one
> results for certain values of array shape.
>
>
> Possible solution:
> To fix this properly, I think the float cast should be removed and
> integer-based math should be used, but I thought that since it was rounding
> down in the cases I saw, a change to the following should fix this:
>
> figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> and indeed this seems to work.
> To verify this, I ran the following brute-force test of all image sizes up
> to 1024x1024 at some common dpi values:
>
> import matplotlib.pyplot as plt
> import numpy as np
> import os
>
> for dpi in [75, 100, 150, 300, 600, 1200]:
>     for i in range(1,1025):
>         print dpi, i,
>         im = np.random.random((i,i))
>         fname = 'test{:03d}.png'.format(i)
>         plt.imsave(fname, im, dpi=dpi)
>         im = plt.imread(fname)[:,:,0]
>         print im.shape
>         assert im.shape == (i, i)
>         os.remove(fname)
>
> and everything passed.
>
> For completeness I also explored the dpi-space with these loop ranges and
> the above loop body:
>
> for dpi in range(1, 101):
>     for i in range(25, 36):
>         ...
>
> and all was still well.
>
>
> Workaround:
> For the moment I've set dpi=1 in my call to imsave which effectively
> reverts its behaviour to the original imsave code prior to the introduction
> of the dpi parameter.
>
> I think this testing is rigorous enough to make this change.
> If you agree, has anyone got time to change this, or shall I do a pull
> request when I have time?
>
> thanks,
> Gary
>
>
Good catch on this.  So you are saying that this bug was introduced
relatively recently with the dpi kwarg?  I would suggest you make a PR so
that this doesn't get lost (or at the very least file a bug report).  As
for the fix itself, off the top of my head, wouldn't math.ceil() do what we
want?  I prefer to be explicit in any intents rather than just simply (x +
0.5) / float(dpi).  As for the test, I would wonder if some sort of
restricted version of that test might not be good to do?  I am thinking
about 10 different sized plots and we wouldn't even need to have a the
assert check or file removal test, as the image comparison framework would
throw an exception when attempting to compare two images of different sizes
(I think...).

Cheers!
Ben Root

Re: [matplotlib-devel] png error with git master, is it just me?

[Michael D. <md...@st...>]

Hey there,

Just getting to this after a vacation.  I think I was stymied by the 
fact that the Fedora package for pycxx provides a pkg-config file, 
whereas, as you point out, it is not upstream.

I'll put my further comments on the issue.

Cheers,
Mike

On 04/05/2013 11:23 PM, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 2:51 PM, Julian Taylor
> <jta...@go...> wrote:
>
>> I filed an issue:
>> https://github.com/matplotlib/matplotlib/issues/1884
> Go figure, it was an actual bug! Well, thanks a lot for tracking it down :)
>
> I guess for now I'll just remove pycxx-dev from my system.
> Fortunately I don't need it for anything else.  But it means that
> right now, mpl can't be built on a system with the matplotlib
> build-deps loaded, which is a bummer.
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Bug in imsave

[gary r. <gar...@gm...>]

Hi, I haven't looked at this list for a long time, so hi to all the active
devs.
I just came across a problem in the image.py imsave() function.

Problem:
At an ipython --pylab prompt, typing

a = rand(29,29)
imsave('test.png', a)

incorrectly generates a 28x28 pixel image.
This happens for several array sizes (I initially saw it for 226x226).

Line 1272 of image.py is
figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]

figsize interacts with the bounding box code somehow to create off-by-one
results for certain values of array shape.


Possible solution:
To fix this properly, I think the float cast should be removed and
integer-based math should be used, but I thought that since it was rounding
down in the cases I saw, a change to the following should fix this:

figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]

and indeed this seems to work.
To verify this, I ran the following brute-force test of all image sizes up
to 1024x1024 at some common dpi values:

import matplotlib.pyplot as plt
import numpy as np
import os

for dpi in [75, 100, 150, 300, 600, 1200]:
    for i in range(1,1025):
        print dpi, i,
        im = np.random.random((i,i))
        fname = 'test{:03d}.png'.format(i)
        plt.imsave(fname, im, dpi=dpi)
        im = plt.imread(fname)[:,:,0]
        print im.shape
        assert im.shape == (i, i)
        os.remove(fname)

and everything passed.

For completeness I also explored the dpi-space with these loop ranges and
the above loop body:

for dpi in range(1, 101):
    for i in range(25, 36):
        ...

and all was still well.


Workaround:
For the moment I've set dpi=1 in my call to imsave which effectively
reverts its behaviour to the original imsave code prior to the introduction
of the dpi parameter.

I think this testing is rigorous enough to make this change.
If you agree, has anyone got time to change this, or shall I do a pull
request when I have time?

thanks,
Gary

Re: [matplotlib-devel] png error with git master, is it just me?

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

On Fri, Apr 5, 2013 at 2:51 PM, Julian Taylor
<jta...@go...> wrote:

> I filed an issue:
> https://github.com/matplotlib/matplotlib/issues/1884

Go figure, it was an actual bug! Well, thanks a lot for tracking it down :)

I guess for now I'll just remove pycxx-dev from my system.
Fortunately I don't need it for anything else.  But it means that
right now, mpl can't be built on a system with the matplotlib
build-deps loaded, which is a bummer.

Cheers,

f

Re: [matplotlib-devel] png error with git master, is it just me?

[Julian T. <jta...@go...>]

On 05.04.2013 23:35, Julian Taylor wrote:
> On 05.04.2013 23:16, Fernando Perez wrote:
>> On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
>> <jta...@go...> wrote:
>>
>>> strange, it isn't linked against libpng at all. I can't reproduce that
>>> on my Ubuntu machine with git head.
>>>
>>> Do you still have a buildlog?
>>> Maybe do a new build from a clean folder (and save the log).
>>
>> I just did a fully clean rebuild in a fresh clone, and the same thing
>> happens.  Build log here:
>>
>> http://pastebin.com/eCGbEvKb
>>
>> The only thing that jumpts at me is:
>>
>> Package PyCXX was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `PyCXX.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'PyCXX' found
>>
>> which I don't understand, as pycxx is clearly installed:
>>
>> (master)longs[matplotlib]> apt-cache policy python-cxx
>> python-cxx:
>>   Installed: 6.2.4-1
>>   Candidate: 6.2.4-1
>>   Version table:
>>  *** 6.2.4-1 0
>>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
>>         100 /var/lib/dpkg/status
>>
>>
>> Puzzled...
>>
> 
> 
> actually the presence of the PyCXX package seems to be the problem. If I
> have it installed it fails, if not it works. Looks like some weird bug
> in the build system.
> Why is it looking for a pkg-config file? PyCXX does not provide one.
> 
> I though system PyCXX could not be used because it needed unmerged patches?
> Btw. I could merge the patches into the Debian package if they are
> forwarded to me.
> 

I filed an issue:
https://github.com/matplotlib/matplotlib/issues/1884

Re: [matplotlib-devel] png error with git master, is it just me?

[Julian T. <jta...@go...>]

On 05.04.2013 23:16, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
> <jta...@go...> wrote:
> 
>> strange, it isn't linked against libpng at all. I can't reproduce that
>> on my Ubuntu machine with git head.
>>
>> Do you still have a buildlog?
>> Maybe do a new build from a clean folder (and save the log).
> 
> I just did a fully clean rebuild in a fresh clone, and the same thing
> happens.  Build log here:
> 
> http://pastebin.com/eCGbEvKb
> 
> The only thing that jumpts at me is:
> 
> Package PyCXX was not found in the pkg-config search path.
> Perhaps you should add the directory containing `PyCXX.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'PyCXX' found
> 
> which I don't understand, as pycxx is clearly installed:
> 
> (master)longs[matplotlib]> apt-cache policy python-cxx
> python-cxx:
>   Installed: 6.2.4-1
>   Candidate: 6.2.4-1
>   Version table:
>  *** 6.2.4-1 0
>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
>         100 /var/lib/dpkg/status
> 
> 
> Puzzled...
> 


actually the presence of the PyCXX package seems to be the problem. If I
have it installed it fails, if not it works. Looks like some weird bug
in the build system.
Why is it looking for a pkg-config file? PyCXX does not provide one.

I though system PyCXX could not be used because it needed unmerged patches?
Btw. I could merge the patches into the Debian package if they are
forwarded to me.

Re: [matplotlib-devel] png error with git master, is it just me?

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

On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
<jta...@go...> wrote:

> strange, it isn't linked against libpng at all. I can't reproduce that
> on my Ubuntu machine with git head.
>
> Do you still have a buildlog?
> Maybe do a new build from a clean folder (and save the log).

I just did a fully clean rebuild in a fresh clone, and the same thing
happens.  Build log here:

http://pastebin.com/eCGbEvKb

The only thing that jumpts at me is:

Package PyCXX was not found in the pkg-config search path.
Perhaps you should add the directory containing `PyCXX.pc'
to the PKG_CONFIG_PATH environment variable
No package 'PyCXX' found

which I don't understand, as pycxx is clearly installed:

(master)longs[matplotlib]> apt-cache policy python-cxx
python-cxx:
  Installed: 6.2.4-1
  Candidate: 6.2.4-1
  Version table:
 *** 6.2.4-1 0
        500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
        100 /var/lib/dpkg/status


Puzzled...

f

Re: [matplotlib-devel] png error with git master, is it just me?

[Julian T. <jta...@go...>]

On 05.04.2013 22:32, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 10:06 AM, Julian Taylor
> <jta...@go...> wrote:
>>
>> whats the output of:
>> ldd
>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
>> apt-cache policy libpng12-dev
>>
>> the system libpng in ubuntu 12.10 does have this symbol defined, maybe
>> you are picking up some other installation.
> 
> Here's what I get:
> 
> longs[~]> ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
> linux-vdso.so.1 =>  (0x00007fff56dff000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f97ecaeb000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f97ec8d4000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97ec6b7000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97ec2f8000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f97ebffb000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f97ed04b000)
> 
> 
> longs[~]> apt-cache policy libpng12-dev
> libpng12-dev:
>   Installed: 1.2.49-1ubuntu1
>   Candidate: 1.2.49-1ubuntu1
>   Version table:
>  *** 1.2.49-1ubuntu1 0
>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> 
> Thanks for any insights you may provide...
> 
> f
> 


strange, it isn't linked against libpng at all. I can't reproduce that
on my Ubuntu machine with git head.

Do you still have a buildlog?
Maybe do a new build from a clean folder (and save the log).

Re: [matplotlib-devel] png error with git master, is it just me?

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

On Fri, Apr 5, 2013 at 10:06 AM, Julian Taylor
<jta...@go...> wrote:
>
> whats the output of:
> ldd
> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
> apt-cache policy libpng12-dev
>
> the system libpng in ubuntu 12.10 does have this symbol defined, maybe
> you are picking up some other installation.

Here's what I get:

longs[~]> ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
linux-vdso.so.1 =>  (0x00007fff56dff000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f97ecaeb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f97ec8d4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97ec6b7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97ec2f8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f97ebffb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f97ed04b000)


longs[~]> apt-cache policy libpng12-dev
libpng12-dev:
  Installed: 1.2.49-1ubuntu1
  Candidate: 1.2.49-1ubuntu1
  Version table:
 *** 1.2.49-1ubuntu1 0
        500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status


Thanks for any insights you may provide...

f

Re: [matplotlib-devel] png error with git master, is it just me?

[Julian T. <jta...@go...>]

On 05.04.2013 07:37, Fernando Perez wrote:
> Well, I'm using the system libpng, which is what puzzles me: there
> should be no need for me to modify my LD_..., and I haven't done so in
> the past.  I'll have to dig into the build tomorrow to figure out
> exactly what's going on there...
> 

whats the output of:
ldd
/home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
apt-cache policy libpng12-dev

the system libpng in ubuntu 12.10 does have this symbol defined, maybe
you are picking up some other installation.


> Will report back.
> 
> 
> On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
> <dam...@gm... <mailto:dam...@gm...>> wrote:
> 
> 
> 
> 
>     On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez
>     <fpe...@gm... <mailto:fpe...@gm...>> wrote:
> 
>         Thanks, Damon, for this info.
> 
>         Based on this, I've tested now on another, different system with
>         the same version of linux and can't reproduce it either.  Very
>         odd, but it looks like something is amiss on my end, so let me
>         investigate further before anyone burns further cycles on the issue.
> 
>         Cheers,
> 
>         f
> 
> 
>         On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall
>         <dam...@gm... <mailto:dam...@gm...>>
>         wrote:
> 
>             On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez
>             <fpe...@gm... <mailto:fpe...@gm...>> wrote:
> 
>                 Hi folks,
> 
>                 I'm getting the following error from a clean build of
>                 master on an
>                 ubuntu 12.10 machine:
> 
>                 longs[junk]> python -c 'import matplotlib._png'
>                 Traceback (most recent call last):
>                   File "<string>", line 1, in <module>
>                 ImportError:
>                 /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>                 undefined symbol: png_create_read_struct
> 
> 
>                 I hadn't seen anything like this recently, nor can I
>                 find similar
>                 reports, so I'm wondering if anyone knows what's going
>                 on, or if it's
>                 an error on my side.  I can try to bisect it but I
>                 figured I'd ask
>                 first in case it's obvious to someone else...
> 
>                 Cheers,
> 
>                 f
> 
> 
>             Hi Fernando,
> 
>             I can't recreate this on OS X with the current git master
>             branch, which is at 11e7ed.
> 
>             Best wishes,
>             Damon
> 
>             -- 
>             Damon McDougall
>             http://www.damon-is-a-geek.com
>             Institute for Computational Engineering Sciences
>             201 E. 24th St.
>             Stop C0200
>             The University of Texas at Austin
>             Austin, TX 78712-1229
> 
> 
> 
>     Any time, Fernando.
> 
>     Out of curiosity, is the png_create_read_struct a symbol from
>     libpng?  If so, try adding wherever your libpng lives to your
>     LD_LIBRARY_PATH and see what happens.
> 
>     Best wishes,
>     Damon
> 
>     -- 
>     Damon McDougall
>     http://www.damon-is-a-geek.com
>     Institute for Computational Engineering Sciences
>     201 E. 24th St.
>     Stop C0200
>     The University of Texas at Austin
>     Austin, TX 78712-1229
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire 
> the most talented Cisco Certified professionals. Visit the 
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Re: [matplotlib-devel] png error with git master, is it just me?

[Mike K. <mc...@gm...>]

I've had problems like this using a git-source matplotlib and macports. 
This usually happens after libpng is upgraded.

Turns out a 'python setup.py install ...' in matplotlib will not solve 
things until you manually delete the contents of the matplotlib build/ 
directory. After which new go at setup.py install will link to the new 
libpng library. 'make clean' will not do this for you (which is probably 
an oversight in the matplotlib Makefile). Don't know if this will help 
for linux.

M

On 4/5/13 1:37 AM, Fernando Perez wrote:
> Well, I'm using the system libpng, which is what puzzles me: there
> should be no need for me to modify my LD_..., and I haven't done so in
> the past.  I'll have to dig into the build tomorrow to figure out
> exactly what's going on there...
>
> Will report back.
>
>
> On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
> <dam...@gm... <mailto:dam...@gm...>> wrote:
>
>
>
>
>     On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez
>     <fpe...@gm... <mailto:fpe...@gm...>> wrote:
>
>         Thanks, Damon, for this info.
>
>         Based on this, I've tested now on another, different system with
>         the same version of linux and can't reproduce it either.  Very
>         odd, but it looks like something is amiss on my end, so let me
>         investigate further before anyone burns further cycles on the issue.
>
>         Cheers,
>
>         f
>
>
>         On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall
>         <dam...@gm... <mailto:dam...@gm...>>
>         wrote:
>
>             On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez
>             <fpe...@gm... <mailto:fpe...@gm...>> wrote:
>
>                 Hi folks,
>
>                 I'm getting the following error from a clean build of
>                 master on an
>                 ubuntu 12.10 machine:
>
>                 longs[junk]> python -c 'import matplotlib._png'
>                 Traceback (most recent call last):
>                    File "<string>", line 1, in <module>
>                 ImportError:
>                 /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>                 undefined symbol: png_create_read_struct
>
>
>                 I hadn't seen anything like this recently, nor can I
>                 find similar
>                 reports, so I'm wondering if anyone knows what's going
>                 on, or if it's
>                 an error on my side.  I can try to bisect it but I
>                 figured I'd ask
>                 first in case it's obvious to someone else...
>
>                 Cheers,
>
>                 f
>
>
>             Hi Fernando,
>
>             I can't recreate this on OS X with the current git master
>             branch, which is at 11e7ed.
>
>             Best wishes,
>             Damon
>
>             --
>             Damon McDougall
>             http://www.damon-is-a-geek.com
>             Institute for Computational Engineering Sciences
>             201 E. 24th St.
>             Stop C0200
>             The University of Texas at Austin
>             Austin, TX 78712-1229
>
>
>
>     Any time, Fernando.
>
>     Out of curiosity, is the png_create_read_struct a symbol from
>     libpng?  If so, try adding wherever your libpng lives to your
>     LD_LIBRARY_PATH and see what happens.
>
>     Best wishes,
>     Damon
>
>     --
>     Damon McDougall
>     http://www.damon-is-a-geek.com
>     Institute for Computational Engineering Sciences
>     201 E. 24th St.
>     Stop C0200
>     The University of Texas at Austin
>     Austin, TX 78712-1229
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] png error with git master, is it just me?

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

Well, I'm using the system libpng, which is what puzzles me: there should
be no need for me to modify my LD_..., and I haven't done so in the past.
 I'll have to dig into the build tomorrow to figure out exactly what's
going on there...

Will report back.


On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
<dam...@gm...>wrote:

>
>
>
> On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez <fpe...@gm...>wrote:
>
>> Thanks, Damon, for this info.
>>
>> Based on this, I've tested now on another, different system with the same
>> version of linux and can't reproduce it either.  Very odd, but it looks
>> like something is amiss on my end, so let me investigate further before
>> anyone burns further cycles on the issue.
>>
>> Cheers,
>>
>> f
>>
>>
>> On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall <
>> dam...@gm...> wrote:
>>
>>> On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez <fpe...@gm...>wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I'm getting the following error from a clean build of master on an
>>>> ubuntu 12.10 machine:
>>>>
>>>> longs[junk]> python -c 'import matplotlib._png'
>>>> Traceback (most recent call last):
>>>>   File "<string>", line 1, in <module>
>>>> ImportError:
>>>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>>>> undefined symbol: png_create_read_struct
>>>>
>>>>
>>>> I hadn't seen anything like this recently, nor can I find similar
>>>> reports, so I'm wondering if anyone knows what's going on, or if it's
>>>> an error on my side.  I can try to bisect it but I figured I'd ask
>>>> first in case it's obvious to someone else...
>>>>
>>>> Cheers,
>>>>
>>>> f
>>>>
>>>
>>> Hi Fernando,
>>>
>>> I can't recreate this on OS X with the current git master branch, which
>>> is at 11e7ed.
>>>
>>> Best wishes,
>>> Damon
>>>
>>> --
>>> Damon McDougall
>>> http://www.damon-is-a-geek.com
>>> Institute for Computational Engineering Sciences
>>> 201 E. 24th St.
>>> Stop C0200
>>> The University of Texas at Austin
>>> Austin, TX 78712-1229
>>>
>>
>>
> Any time, Fernando.
>
> Out of curiosity, is the png_create_read_struct a symbol from libpng?  If
> so, try adding wherever your libpng lives to your LD_LIBRARY_PATH and see
> what happens.
>
> Best wishes,
> Damon
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>