matplotlib-devel Mailing List for matplotlib (Page 2)

On Wed, Sep 22, 2010 at 1:14 PM, Jeremy Lounds <lo...@gm...> wrote:
> Nevermind, I think I solved it...
>
> $ cd /usr/local/lib/python2.6/dist-packages
> $ sudo cp -R * /usr/lib/python2.6/dist-packages/
>
> Maybe worth a note somewhere? Or maybe it is there, I just completely
> missed
> the right configuration/installation step.
>
> ~ Jeremy
>
>
>
I am not 100% certain on this, but if I remember correctly, the issue was
that the python search path doesn't go into /usr/local/lib. That or that
the OS wasn't searching for library files in /usr/local/lib. I can't
remember... Whatever it was, I don't think it was specific to matplotlib.
I really should write notes to myself when I encounter these situations...
Ben Root

Nevermind, I think I solved it...
$ cd /usr/local/lib/python2.6/dist-packages
$ sudo cp -R * /usr/lib/python2.6/dist-packages/
Maybe worth a note somewhere? Or maybe it is there, I just completely missed
the right configuration/installation step.
~ Jeremy
On Wed, Sep 22, 2010 at 2:00 PM, Jeremy Lounds <lo...@gm...> wrote:
> Hello,
>
> I am new to python, matplotlib and basemap, but I _am_ familiar with Linux.
>
> I have dome some searching on this but am still not sure where I am
> going wrong. It looks like basemap is being installed as an "egg" even
> though I used this command when installing:
>
> python setup.py install
>
> When I try an example, it won't run ... "ImportError: No module named basemap"
>
> Here are some additional details:
>
> ~$ uname -r
> 2.6.28-15-server
>
> ~$ cat /etc/issue
> Ubuntu 9.04
>
> ~$ python --version
> Python 2.6.2
>
> I installed matplotlib, numpy and other requirements via the package management
>
> ~$ sudo apt-get install python-numpy-ext
> ~$ sudo apt-get install python-matplotlib
> ~$ sudo aptitude update && sudo aptitude install g++
> ~$ sudo apt-get install build-essential
> ~$ sudo apt-get install python-dev
>
> ~$ ls /usr/local/lib/libgeos*
> /usr/local/lib/libgeos-3.2.0.so
> /usr/local/lib/libgeos_c.so.1
> /usr/local/lib/libgeos.a
> /usr/local/lib/libgeos_c.so.1.6.0
> /usr/local/lib/libgeos_c.a
> /usr/local/lib/libgeos.la
> /usr/local/lib/libgeos_c.la
> /usr/local/lib/libgeos.so
> /usr/local/lib/libgeos_c.so
>
> When installing, here is the command I have been running and the
> subsequent output
>
> ~/Downloads/basemap-1.0$ sudo python setup.py install
> checking for GEOS lib in /home/myusername ....
> checking for GEOS lib in /usr ....
> checking for GEOS lib in /usr/local ....
> GEOS lib (version 3.2.0) found in /usr/local
> checking to see if required version of pydap installed ..
> pydap installed, checking version ...
> pydap version OK, will not be installed
> checking to see if httplib2 installed ..
> httplib2 installed
> checking to see if pyshapelib installed ..
> pyshapelib installed
> running install
> running build
> running config_cc
> unifing config_cc, config, build_clib, build_ext, build commands
> --compiler options
> running config_fc
> unifing config_fc, config, build_clib, build_ext, build commands
> --fcompiler options
> running build_src
> building extension "mpl_toolkits.basemap._proj" sources
> building extension "mpl_toolkits.basemap._geod" sources
> building extension "_geoslib" sources
> running build_py
> running build_ext
> customize UnixCCompiler
> customize UnixCCompiler using build_ext
> running scons
> running install_lib
> running install_egg_info
> Writing /usr/local/lib/python2.6/dist-packages/basemap-1.0.egg-info
>
> ~$ ls /usr/local/lib/python2.6/dist-packages/basemap-1.0*
> /usr/local/lib/python2.6/dist-packages/basemap-1.0.egg-info
>
> ~$ ls /usr/local/lib/python2.6/dist-packages/mpl_toolkits
> basemap
> __init__.py
> __init__.pyc
>
> Sorry if this is too much info!
>
> Thanks for any pointers.
>
> ~ Jeremy
>

Hello,
I am new to python, matplotlib and basemap, but I _am_ familiar with Linux.
I have dome some searching on this but am still not sure where I am
going wrong. It looks like basemap is being installed as an "egg" even
though I used this command when installing:
python setup.py install
When I try an example, it won't run ... "ImportError: No module named basemap"
Here are some additional details:
~$ uname -r
2.6.28-15-server
~$ cat /etc/issue
Ubuntu 9.04
~$ python --version
Python 2.6.2
I installed matplotlib, numpy and other requirements via the package management
~$ sudo apt-get install python-numpy-ext
~$ sudo apt-get install python-matplotlib
~$ sudo aptitude update && sudo aptitude install g++
~$ sudo apt-get install build-essential
~$ sudo apt-get install python-dev
~$ ls /usr/local/lib/libgeos*
/usr/local/lib/libgeos-3.2.0.so
/usr/local/lib/libgeos_c.so.1
/usr/local/lib/libgeos.a
/usr/local/lib/libgeos_c.so.1.6.0
/usr/local/lib/libgeos_c.a
/usr/local/lib/libgeos.la
/usr/local/lib/libgeos_c.la
/usr/local/lib/libgeos.so
/usr/local/lib/libgeos_c.so
When installing, here is the command I have been running and the
subsequent output
~/Downloads/basemap-1.0$ sudo python setup.py install
checking for GEOS lib in /home/myusername ....
checking for GEOS lib in /usr ....
checking for GEOS lib in /usr/local ....
GEOS lib (version 3.2.0) found in /usr/local
checking to see if required version of pydap installed ..
pydap installed, checking version ...
pydap version OK, will not be installed
checking to see if httplib2 installed ..
httplib2 installed
checking to see if pyshapelib installed ..
pyshapelib installed
running install
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands
--fcompiler options
running build_src
building extension "mpl_toolkits.basemap._proj" sources
building extension "mpl_toolkits.basemap._geod" sources
building extension "_geoslib" sources
running build_py
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
running scons
running install_lib
running install_egg_info
Writing /usr/local/lib/python2.6/dist-packages/basemap-1.0.egg-info
~$ ls /usr/local/lib/python2.6/dist-packages/basemap-1.0*
/usr/local/lib/python2.6/dist-packages/basemap-1.0.egg-info
~$ ls /usr/local/lib/python2.6/dist-packages/mpl_toolkits
basemap
__init__.py
__init__.pyc
Sorry if this is too much info!
Thanks for any pointers.
~ Jeremy

(CC'ing list this time)
On Tue, Sep 21, 2010 at 4:30 AM, Dieter Weber <di...@ue...> wrote:
> Hi Ryan,
> well, I was rethinking the patch again after sending it, and I got it
> wrong. :-/ Accessing a deprecated property would give a KeyError with my
> previous patch, as this property is never set. To support deprecated
> options and display warning messages, one needs some kind of custom
> __getitem__ method. I've appended a diff where such a method is created
> "on demand" if the verbosity level is 'helpful' or more.
Which is why I left it to people more familiar with the code to do a
more, ahem, thorough review. Still, I wonder if there's a better way
to maintain the runtime boost without needing a __getitem__...
Need coffee for that.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Mon, Sep 20, 2010 at 6:04 PM, Dieter Weber <di...@ue...> wrote:
> Hi,
> I'm currently working on speeding up the legend rendering of matplotlib
> as this turns out to be a bottleneck for my application. With some
> tracing and profiling, I found that
> matplotlib.__init__.RcParams.__getitem__() makes up around 10% of the
> total function calls (by number) in my little test program. It is called
> continuously all over the matplotlib code, whenever a configuration
> parameter is accessed.
>
> Therefore removed the __getitem__ method and moved the key validation to
> a newly written __init__ function, so that validation only happens once
> the object is created, and otherwise the native lookup of the dict()
> class is used. This made my program around 10% faster! :-)
>
> The diff ("svn diff") is appended. If you are interested in the
> profiling results (not only regarding this piece of code), please let me
> know!
First glance looks alright to me, though I haven't looked in heavy
detail. I will defer, however, to those much more familiar with this
code.
Thanks for the patch,
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I'm currently working on speeding up the legend rendering of matplotlib
as this turns out to be a bottleneck for my application. With some
tracing and profiling, I found that
matplotlib.__init__.RcParams.__getitem__() makes up around 10% of the
total function calls (by number) in my little test program. It is called
continuously all over the matplotlib code, whenever a configuration
parameter is accessed.
Therefore removed the __getitem__ method and moved the key validation to
a newly written __init__ function, so that validation only happens once
the object is created, and otherwise the native lookup of the dict()
class is used. This made my program around 10% faster! :-)
The diff ("svn diff") is appended. If you are interested in the
profiling results (not only regarding this piece of code), please let me
know!
Hope that helps!
Dieter

Hello,
on matplotlib 1.0, using qt4agg backend, the 'edit curves and lines' option 
doesn't works.
This is a quick patch that fix that problem.
It doesn't fix this snippet though:
(on lib/matplotlib/backends/qt4_editor/formlayout.py, FormWidget.setup)
elif isinstance(value, (list, tuple)):
 selindex = value.pop(0)
tuple don't have pop.
However with the patch this bug is not triggered anymore.
Thanks!
Riccardo

 On 09/17/2010 03:04 AM, Eric Firing wrote:
> On 09/16/2010 09:27 PM, Jason Grout wrote:
>>
>>
>> I see the change that you made (keep the old order for linux, do the new
>> thing for everything else). This seems like a bad thing to do. Looking
>> at setjmp.h, it includes features.h. features.h relies on the POSIX and
>> XOPEN variables that are defined in Python.h to set up the environment,
>> and the actions from setjmp.h depend on that environment. I think the
>> warning from the Python docs (if I read correctly) is that the
>> environment must be set up according to the requirements, and Python.h
>> sets up those requirements. In other words, by undefining the POSIX and
>> XOPEN variables, it seems you have a very real likelihood of including a
>> different setjmp.h in the Python.h compared to the libpng (because the
>> conditions set up by features.h may be different).
> Before making that change, I verified that at least on my linux system,
> Python.h defines those two variables the same way that features.h does,
> so the redefinition would be harmless if we did not undefine the
> variables. I don't think we are any worse off than before with respect
> to linux, and we should be better off with respect to other
> platforms--mpl on Solaris now compiles, right?. But I am certainly
> still not comfortable with the whole setjmp mess. I would love to see
> someone come up with a clean, clearly understandable solution, and
> resolve it once and for all.
Okay, I'm glad you checked on your box. I agree that we wouldn't be any 
worse than before. Hopefully everyone's feature.h defaults are the same 
as what Python assumes. And hopefully Python hasn't changed those 
definitions over the supported releases.
However, wouldn't it be good to leave the redefinitions in, though? 
They are warnings (and they are not spurious), and that would remind us 
that we should investigate the situation in the future (maybe after we 
stop supporting old versions of libpng). At least on your system, the 
redefinition would not change anything. I would prefer a warning 
reminding me of an ugly situation that could really potentially be a 
problem, rather than a hack to disable the warning because it doesn't 
affect a particular system or two.
Thanks,
Jason

On Fri, Sep 17, 2010 at 3:04 AM, Eric Firing <ef...@ha...> wrote:
> Before making that change, I verified that at least on my linux system,
> Python.h defines those two variables the same way that features.h does,
> so the redefinition would be harmless if we did not undefine the
> variables. I don't think we are any worse off than before with respect
> to linux, and we should be better off with respect to other
> platforms--mpl on Solaris now compiles, right?. But I am certainly
> still not comfortable with the whole setjmp mess. I would love to see
> someone come up with a clean, clearly understandable solution, and
> resolve it once and for all.
One more test point -- on my solaris x86 box running python2.4, svn
HEAD (and r8707) appear to work fine.
johnh@udesktop191:tests> uname -a
SunOS udesktop191 5.10 Generic_139556-08 i86pc i386 i86pc
johnh@udesktop191:tests> python -V
Python 2.4.5
johnh@udesktop191:tests> /opt/app/g++lib6/gcc-4.2/bin/gcc --version
gcc (GCC) 4.2.2

On 09/16/2010 09:27 PM, Jason Grout wrote:
> On 9/17/10 1:57 AM, Eric Firing wrote:
>> On 09/16/2010 08:21 PM, Christoph Gohlke wrote:
>>>
>>>
>>> On 9/16/2010 8:15 PM, Jason Grout wrote:
>>>> On 9/16/10 10:00 PM, Eric Firing wrote:
>>>>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>>>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>>>>
>>>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>>>>> following:
>>>>>>>>>
>>>>>>>>
>>>>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>
>>>>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>>>>> that extra #def so that libpng doesn't try to include it?
>>>>>>>
>>>>>>> #include "Python.h"
>>>>>>> #def PNG_SKIP_SETJMP_CHECK
>>>>>>> #include<png.h>
>>>>>>>
>>>>>>
>>>>>> Let me try again:
>>>>>>
>>>>>> In _backend_agg.cpp and _png.cpp, just add
>>>>>>
>>>>>> #define PNG_SKIP_SETJMP_CHECK
>>>>>>
>>>>>> right above
>>>>>>
>>>>>> #include<png.h>
>>>>>>
>>>>>> Does that fix it?
>>>>>
>>>>> Sure does. Your patch with that modification is committed to branch and
>>>>> trunk, 8706, 8707. Thank you!
>>>>>
>>>>
>>>> Did someone check on Windows? I was hoping things wouldn't break in
>>>> WrapPython.h when I switched the order of includes, but you never know...
>>>>
>>>> Jason
>>>
>>> Trunk and 1.0 branch build OK on Windows.
>>
>> Christoph,
>>
>> Once again, thanks very much for testing on Windows.
>>
>> I found a problem on linux (or rather, the buildbot found it because it
>> is running an older version) so I have committed one more change to the
>> branch. If that survives the buildbot, I will propagate it to the
>> trunk, but I don't consider it the last word; I am hoping that someone
>> else can do a better job of cleaning this up.
>>
>
>
> I see the change that you made (keep the old order for linux, do the new
> thing for everything else). This seems like a bad thing to do. Looking
> at setjmp.h, it includes features.h. features.h relies on the POSIX and
> XOPEN variables that are defined in Python.h to set up the environment,
> and the actions from setjmp.h depend on that environment. I think the
> warning from the Python docs (if I read correctly) is that the
> environment must be set up according to the requirements, and Python.h
> sets up those requirements. In other words, by undefining the POSIX and
> XOPEN variables, it seems you have a very real likelihood of including a
> different setjmp.h in the Python.h compared to the libpng (because the
> conditions set up by features.h may be different).
Before making that change, I verified that at least on my linux system, 
Python.h defines those two variables the same way that features.h does, 
so the redefinition would be harmless if we did not undefine the 
variables. I don't think we are any worse off than before with respect 
to linux, and we should be better off with respect to other 
platforms--mpl on Solaris now compiles, right?. But I am certainly 
still not comfortable with the whole setjmp mess. I would love to see 
someone come up with a clean, clearly understandable solution, and 
resolve it once and for all.
Eric
>
> Again, I don't see a good way out of the mess. And I guess in this
> imperfect world, I can't argue with what appears to work! And as a big
> disclaimer; I knew almost nothing about all of this a couple of days ago.
>
> Thanks,
>
> Jason
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 9/17/10 1:57 AM, Eric Firing wrote:
> On 09/16/2010 08:21 PM, Christoph Gohlke wrote:
>>
>>
>> On 9/16/2010 8:15 PM, Jason Grout wrote:
>>> On 9/16/10 10:00 PM, Eric Firing wrote:
>>>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>>>
>>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>>>> following:
>>>>>>>>
>>>>>>>
>>>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>
>>>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>>>> that extra #def so that libpng doesn't try to include it?
>>>>>>
>>>>>> #include "Python.h"
>>>>>> #def PNG_SKIP_SETJMP_CHECK
>>>>>> #include<png.h>
>>>>>>
>>>>>
>>>>> Let me try again:
>>>>>
>>>>> In _backend_agg.cpp and _png.cpp, just add
>>>>>
>>>>> #define PNG_SKIP_SETJMP_CHECK
>>>>>
>>>>> right above
>>>>>
>>>>> #include<png.h>
>>>>>
>>>>> Does that fix it?
>>>>
>>>> Sure does. Your patch with that modification is committed to branch and
>>>> trunk, 8706, 8707. Thank you!
>>>>
>>>
>>> Did someone check on Windows? I was hoping things wouldn't break in
>>> WrapPython.h when I switched the order of includes, but you never know...
>>>
>>> Jason
>>
>> Trunk and 1.0 branch build OK on Windows.
>
> Christoph,
>
> Once again, thanks very much for testing on Windows.
>
> I found a problem on linux (or rather, the buildbot found it because it
> is running an older version) so I have committed one more change to the
> branch. If that survives the buildbot, I will propagate it to the
> trunk, but I don't consider it the last word; I am hoping that someone
> else can do a better job of cleaning this up.
>
I see the change that you made (keep the old order for linux, do the new 
thing for everything else). This seems like a bad thing to do. Looking 
at setjmp.h, it includes features.h. features.h relies on the POSIX and 
XOPEN variables that are defined in Python.h to set up the environment, 
and the actions from setjmp.h depend on that environment. I think the 
warning from the Python docs (if I read correctly) is that the 
environment must be set up according to the requirements, and Python.h 
sets up those requirements. In other words, by undefining the POSIX and 
XOPEN variables, it seems you have a very real likelihood of including a 
different setjmp.h in the Python.h compared to the libpng (because the 
conditions set up by features.h may be different).
Again, I don't see a good way out of the mess. And I guess in this 
imperfect world, I can't argue with what appears to work! And as a big 
disclaimer; I knew almost nothing about all of this a couple of days ago.
Thanks,
Jason

On 09/16/2010 08:21 PM, Christoph Gohlke wrote:
>
>
> On 9/16/2010 8:15 PM, Jason Grout wrote:
>> On 9/16/10 10:00 PM, Eric Firing wrote:
>>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>>
>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>>> following:
>>>>>>>
>>>>>>
>>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>
>>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>>> that extra #def so that libpng doesn't try to include it?
>>>>>
>>>>> #include "Python.h"
>>>>> #def PNG_SKIP_SETJMP_CHECK
>>>>> #include<png.h>
>>>>>
>>>>
>>>> Let me try again:
>>>>
>>>> In _backend_agg.cpp and _png.cpp, just add
>>>>
>>>> #define PNG_SKIP_SETJMP_CHECK
>>>>
>>>> right above
>>>>
>>>> #include<png.h>
>>>>
>>>> Does that fix it?
>>>
>>> Sure does. Your patch with that modification is committed to branch and
>>> trunk, 8706, 8707. Thank you!
>>>
>>
>> Did someone check on Windows? I was hoping things wouldn't break in
>> WrapPython.h when I switched the order of includes, but you never know...
>>
>> Jason
>
> Trunk and 1.0 branch build OK on Windows.
Christoph,
Once again, thanks very much for testing on Windows.
I found a problem on linux (or rather, the buildbot found it because it 
is running an older version) so I have committed one more change to the 
branch. If that survives the buildbot, I will propagate it to the 
trunk, but I don't consider it the last word; I am hoping that someone 
else can do a better job of cleaning this up.
Eric
>
> --
> Christoph

On 09/16/2010 08:45 PM, Jason Grout wrote:
> On 9/16/10 11:16 PM, Eric Firing wrote:
>> On 09/16/2010 05:15 PM, Jason Grout wrote:
>>> On 9/16/10 10:00 PM, Eric Firing wrote:
>>>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>>>
>>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>>>> following:
>>>>>>>>
>>>>>>>
>>>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>
>>>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>>>> that extra #def so that libpng doesn't try to include it?
>>>>>>
>>>>>> #include "Python.h"
>>>>>> #def PNG_SKIP_SETJMP_CHECK
>>>>>> #include<png.h>
>>>>>>
>>>>>
>>>>> Let me try again:
>>>>>
>>>>> In _backend_agg.cpp and _png.cpp, just add
>>>>>
>>>>> #define PNG_SKIP_SETJMP_CHECK
>>>>>
>>>>> right above
>>>>>
>>>>> #include<png.h>
>>>>>
>>>>> Does that fix it?
>>>>
>>>> Sure does. Your patch with that modification is committed to branch and
>>>> trunk, 8706, 8707. Thank you!
>>>>
>>>
>>> Did someone check on Windows? I was hoping things wouldn't break in
>>> WrapPython.h when I switched the order of includes, but you never know...
>>
>> Jason,
>>
>> Big trouble, even without Windows. First, after doing more reading, I
>> am far from sure that skipping the check is OK. Second, it doesn't work
>> on earlier Linux versions, for which pngconf.h lacks that SKIP variable
>> entirely.
>>
>> What a pain. I see that Andrew Straw ran into this wall a couple years ago.
>>
>> Time to revert and re-think. It may be that your patch is almost OK,
>> but will need a tweak for Linux.
>
>
> An equivalent, but very hackish, fix is to just undef _SETJMP_H. That's
> almost as bad as the original undef, though.
>
> Maybe putting this:
>
> #ifdef __linux__
> #undef _SETJMP_H
> #endif
> #define PNG_SKIP_SETJMP_CHECK
>
> right before including png.h would work, at least until distros
> (eventually) upgrade to a libpng past April 2009 (when the check was
> added) or until we stop supporting the old distros.
I don't think that any of these hacks is desirable, so I am trying what 
I hope is a less-bad hack. Maybe Mike or John will be able to figure 
out a cleaner solution.
I'm still worried about the possibility of a conflict between the 
versions of setjmp expected by png and by python. I think that if there 
were such a conflict, it would show up as a crash as part of the error 
handling in one or the other. Therefore it could lurk undetected for a 
long time. On the other hand, if there were such a conflict, I don't 
see how the pre-patched versions would have avoided it any better than 
the present version.
I could not find any evidence that _backend_agg even needs to include 
png.h, so I deleted that inclusion, leaving only _png.cpp as the trouble 
spot.
Eric
>
> Thanks,
>
> Jason

On 9/16/10 11:16 PM, Eric Firing wrote:
> On 09/16/2010 05:15 PM, Jason Grout wrote:
>> On 9/16/10 10:00 PM, Eric Firing wrote:
>>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>>
>>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>>> following:
>>>>>>>
>>>>>>
>>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>
>>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>>> that extra #def so that libpng doesn't try to include it?
>>>>>
>>>>> #include "Python.h"
>>>>> #def PNG_SKIP_SETJMP_CHECK
>>>>> #include<png.h>
>>>>>
>>>>
>>>> Let me try again:
>>>>
>>>> In _backend_agg.cpp and _png.cpp, just add
>>>>
>>>> #define PNG_SKIP_SETJMP_CHECK
>>>>
>>>> right above
>>>>
>>>> #include<png.h>
>>>>
>>>> Does that fix it?
>>>
>>> Sure does. Your patch with that modification is committed to branch and
>>> trunk, 8706, 8707. Thank you!
>>>
>>
>> Did someone check on Windows? I was hoping things wouldn't break in
>> WrapPython.h when I switched the order of includes, but you never know...
>
> Jason,
>
> Big trouble, even without Windows. First, after doing more reading, I
> am far from sure that skipping the check is OK. Second, it doesn't work
> on earlier Linux versions, for which pngconf.h lacks that SKIP variable
> entirely.
>
> What a pain. I see that Andrew Straw ran into this wall a couple years ago.
>
> Time to revert and re-think. It may be that your patch is almost OK,
> but will need a tweak for Linux.
An equivalent, but very hackish, fix is to just undef _SETJMP_H. That's 
almost as bad as the original undef, though.
Maybe putting this:
#ifdef __linux__
 #undef _SETJMP_H
#endif
#define PNG_SKIP_SETJMP_CHECK
right before including png.h would work, at least until distros 
(eventually) upgrade to a libpng past April 2009 (when the check was 
added) or until we stop supporting the old distros.
Thanks,
Jason

On 9/16/2010 8:15 PM, Jason Grout wrote:
> On 9/16/10 10:00 PM, Eric Firing wrote:
>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>
>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>> following:
>>>>>>
>>>>>
>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>
>>>>> Eric
>>>>>
>>>>
>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>> that extra #def so that libpng doesn't try to include it?
>>>>
>>>> #include "Python.h"
>>>> #def PNG_SKIP_SETJMP_CHECK
>>>> #include<png.h>
>>>>
>>>
>>> Let me try again:
>>>
>>> In _backend_agg.cpp and _png.cpp, just add
>>>
>>> #define PNG_SKIP_SETJMP_CHECK
>>>
>>> right above
>>>
>>> #include<png.h>
>>>
>>> Does that fix it?
>>
>> Sure does. Your patch with that modification is committed to branch and
>> trunk, 8706, 8707. Thank you!
>>
>
> Did someone check on Windows? I was hoping things wouldn't break in
> WrapPython.h when I switched the order of includes, but you never know...
>
> Jason
Trunk and 1.0 branch build OK on Windows.
--
Christoph

On 09/16/2010 05:15 PM, Jason Grout wrote:
> On 9/16/10 10:00 PM, Eric Firing wrote:
>> On 09/16/2010 04:12 PM, Jason Grout wrote:
>>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>>
>>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>>> following:
>>>>>>
>>>>>
>>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>>
>>>>> Eric
>>>>>
>>>>
>>>> Ah, good catch. So we just need to include Python.h first, and then set
>>>> that extra #def so that libpng doesn't try to include it?
>>>>
>>>> #include "Python.h"
>>>> #def PNG_SKIP_SETJMP_CHECK
>>>> #include<png.h>
>>>>
>>>
>>> Let me try again:
>>>
>>> In _backend_agg.cpp and _png.cpp, just add
>>>
>>> #define PNG_SKIP_SETJMP_CHECK
>>>
>>> right above
>>>
>>> #include<png.h>
>>>
>>> Does that fix it?
>>
>> Sure does. Your patch with that modification is committed to branch and
>> trunk, 8706, 8707. Thank you!
>>
>
> Did someone check on Windows? I was hoping things wouldn't break in
> WrapPython.h when I switched the order of includes, but you never know...
Jason,
Big trouble, even without Windows. First, after doing more reading, I 
am far from sure that skipping the check is OK. Second, it doesn't work 
on earlier Linux versions, for which pngconf.h lacks that SKIP variable 
entirely.
What a pain. I see that Andrew Straw ran into this wall a couple years ago.
Time to revert and re-think. It may be that your patch is almost OK, 
but will need a tweak for Linux.
Eric
>
> Jason
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 9/16/10 10:15 PM, Jason Grout wrote:
>> Sure does. Your patch with that modification is committed to branch and
>> trunk, 8706, 8707. Thank you!
>>
>
> Did someone check on Windows? I was hoping things wouldn't break in
> WrapPython.h when I switched the order of includes, but you never know...
>
Also, since you guys already have a relationship with upstream (CXX), 
could you report the bug and fix upstream?
Thanks,
Jason

On 9/16/10 10:00 PM, Eric Firing wrote:
> On 09/16/2010 04:12 PM, Jason Grout wrote:
>> On 9/16/10 9:03 PM, Jason Grout wrote:
>>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>>
>>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>>> following:
>>>>>
>>>>
>>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>>
>>>> Eric
>>>>
>>>
>>> Ah, good catch. So we just need to include Python.h first, and then set
>>> that extra #def so that libpng doesn't try to include it?
>>>
>>> #include "Python.h"
>>> #def PNG_SKIP_SETJMP_CHECK
>>> #include<png.h>
>>>
>>
>> Let me try again:
>>
>> In _backend_agg.cpp and _png.cpp, just add
>>
>> #define PNG_SKIP_SETJMP_CHECK
>>
>> right above
>>
>> #include<png.h>
>>
>> Does that fix it?
>
> Sure does. Your patch with that modification is committed to branch and
> trunk, 8706, 8707. Thank you!
>
Did someone check on Windows? I was hoping things wouldn't break in 
WrapPython.h when I switched the order of includes, but you never know...
Jason

On 09/16/2010 04:12 PM, Jason Grout wrote:
> On 9/16/10 9:03 PM, Jason Grout wrote:
>> On 9/16/10 8:00 PM, Eric Firing wrote:
>>
>>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>>> following:
>>>>
>>>
>>> Python.h includes pyfpe.h which includes setjmp.h.
>>>
>>> Eric
>>>
>>
>> Ah, good catch. So we just need to include Python.h first, and then set
>> that extra #def so that libpng doesn't try to include it?
>>
>> #include "Python.h"
>> #def PNG_SKIP_SETJMP_CHECK
>> #include<png.h>
>>
>
> Let me try again:
>
> In _backend_agg.cpp and _png.cpp, just add
>
> #define PNG_SKIP_SETJMP_CHECK
>
> right above
>
> #include<png.h>
>
> Does that fix it?
Sure does. Your patch with that modification is committed to branch and 
trunk, 8706, 8707. Thank you!
Eric
>
> Thanks,
>
> Jason

On 9/16/10 9:03 PM, Jason Grout wrote:
> On 9/16/10 8:00 PM, Eric Firing wrote:
>
>>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>>> that something is including setjmp.h before libpng.h tries to do so via
>>>> pngconf.h, resulting in an error as the compiler trips over the
>>>> following:
>>>
>>
>> Python.h includes pyfpe.h which includes setjmp.h.
>>
>> Eric
>>
>
> Ah, good catch. So we just need to include Python.h first, and then set
> that extra #def so that libpng doesn't try to include it?
>
> #include "Python.h"
> #def PNG_SKIP_SETJMP_CHECK
> #include<png.h>
>
Let me try again:
In _backend_agg.cpp and _png.cpp, just add
#define PNG_SKIP_SETJMP_CHECK
right above
#include<png.h>
Does that fix it?
Thanks,
Jason

On 9/16/10 8:00 PM, Eric Firing wrote:
>>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>>> that something is including setjmp.h before libpng.h tries to do so via
>>> pngconf.h, resulting in an error as the compiler trips over the
>>> following:
>>
>
> Python.h includes pyfpe.h which includes setjmp.h.
>
> Eric
>
Ah, good catch. So we just need to include Python.h first, and then set 
that extra #def so that libpng doesn't try to include it?
#include "Python.h"
#def PNG_SKIP_SETJMP_CHECK
#include <png.h>
or something like that?
Jason

On 09/16/2010 01:04 PM, Jason Grout wrote:
> On 9/16/10 5:24 PM, Eric Firing wrote:
>> On 09/16/2010 09:50 AM, Jason Grout wrote:
>>> As a follow-up, I've implemented the patch for CXX and also patches for
>>> the other files which do not include Python.h first here:
>>>
>>> http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b
>>>
>>>
>>> I've also attached the patch.
>>>
>>> This patch gets rid of the warnings about redefining things on OSX
>>> 10.6.4 (see my last message on this thread).
>>>
>>> Thanks,
>>>
>>> Jason
>>
>> Jason,
>>
>> I tested your patch with Ubuntu 10.10, and it failed. The problem is
>> that something is including setjmp.h before libpng.h tries to do so via
>> pngconf.h, resulting in an error as the compiler trips over the following:
>
>
> What file caused the error (i.e., what file was compiling?)
Sorry, I wasn't thinking straight, or I would have included that. It 
was _backend_agg.cpp. However, if I swap the order of inclusion of 
png.h and Python.h in that file, then redefinition warnings are 
generated when it compiles,
In file included from /usr/include/python2.6/Python.h:8,
 from src/backend_agg.cpp:6:
/usr/include/python2.6/pyconfig.h:1031: warning: "_POSIX_C_SOURCE" redefined
//usr/include/features.h:162: note: this is the location of the previous 
definition
/usr/include/python2.6/pyconfig.h:1040: warning: "_XOPEN_SOURCE" redefined
//usr/include/features.h:164: note: this is the location of the previous 
definition
...
the compilation proceeds, and then fails with _png.cpp:
In file included from /usr/include/libpng12/png.h:518,
 from src/_png.cpp:4:
/usr/include/libpng12/pngconf.h:371: error: expected constructor, 
destructor, or type conversion before ‘.’ token
/usr/include/libpng12/pngconf.h:372: error: ‘__dont__’ does not name a type
error: command 'gcc' failed with exit status 1
Eric
>
> Thanks,
>
> Jason
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 9/16/10 5:24 PM, Eric Firing wrote:
> On 09/16/2010 09:50 AM, Jason Grout wrote:
>> As a follow-up, I've implemented the patch for CXX and also patches for
>> the other files which do not include Python.h first here:
>>
>> http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b
>>
>>
>> I've also attached the patch.
>>
>> This patch gets rid of the warnings about redefining things on OSX
>> 10.6.4 (see my last message on this thread).
>>
>> Thanks,
>>
>> Jason
>
> Jason,
>
> I tested your patch with Ubuntu 10.10, and it failed. The problem is
> that something is including setjmp.h before libpng.h tries to do so via
> pngconf.h, resulting in an error as the compiler trips over the following:
What file caused the error (i.e., what file was compiling?)
Thanks,
Jason

On 09/16/2010 09:50 AM, Jason Grout wrote:
> As a follow-up, I've implemented the patch for CXX and also patches for
> the other files which do not include Python.h first here:
>
> http://github.com/jasongrout/matplotlib/commit/a961c299f5d589dae87e06caf54975eb657ebf3b
>
>
> I've also attached the patch.
>
> This patch gets rid of the warnings about redefining things on OSX
> 10.6.4 (see my last message on this thread).
>
> Thanks,
>
> Jason
Jason,
I tested your patch with Ubuntu 10.10, and it failed. The problem is 
that something is including setjmp.h before libpng.h tries to do so via 
pngconf.h, resulting in an error as the compiler trips over the following:
# ifndef PNG_SKIP_SETJMP_CHECK
# ifdef __linux__
# ifdef _BSD_SOURCE
# define PNG_SAVE_BSD_SOURCE
# undef _BSD_SOURCE
# endif
# ifdef _SETJMP_H
 /* If you encounter a compiler error here, see the explanation
 * near the end of INSTALL.
 */
 __pngconf.h__ in libpng already includes setjmp.h;
 __dont__ include it again.;
# endif
# endif /* __linux__ */
# endif /* PNG_SKIP_SETJMP_CHECK */
The relevant part of INSTALL is:
If you encounter a compiler error message complaining about the
lines
 __png.h__ already includes setjmp.h;
 __dont__ include it again.;
this means you have compiled another module that includes setjmp.h,
which is hazardous because the two modules might not include exactly
the same setjmp.h. If you are sure that you know what you are doing
and that they are exactly the same, then you can comment out or
delete the two lines. Better yet, use the cexcept interface
instead, as demonstrated in contrib/visupng of the libpng distribution.
For the most part your patch looks like the right thing, but I don't 
know what to do about this show-stopping glitch. I looked around, but 
could not figure out what was including setjmp.h after your patch, but 
not before. Maybe Mike will see it.
Eric

That's very cool.
Unrelated to %loadpy, but is anyone else bothered/confused by the fact that
the both the plot in the website and the plot embedded in the app are wrong?
 There are lines that should be blue (they don't intersect the bbox) in both
that are red. I presume this is a bug in either the intersect calculation,
or the plot command in the example code.
-MinRK
On Thu, Sep 16, 2010 at 13:36, Fernando Perez <fpe...@gm...> wrote:
> On Tue, Sep 14, 2010 at 8:21 AM, John Hunter <jd...@gm...> wrote:
> >
> > How about this as an alternative: on my box, I can drag the "source
> > code" link from the browser into my terminal, which by default pastes
> > the URL of the referenced *.py into the terminal. If "run" supported
> > a -w (web) option, or automatically detected that the URL starts with
> > http, it could do a web run of the file. Of course, you may want the
> > source code pasted in for illustrative purposes... To support this,
> > you could add a -u (url) option to "paste" which assumes the input is
> > a url, fetches it, and pastes the contents into ipython. So you could
> > type "paste -u" and then drag the link into the terminal, and it would
> > fetch it and paste the code into an input block.
>
> Ask and ye shall receive (yes, the url was drag-dropped from the
> 'source code' link in the mpl page), welcome %loadpy:
>
> http://fperez.org/tmp/iqlab_mpl_loadpy.png
>
> Full credits go to Brian and Evan!
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>