matplotlib-devel Mailing List for matplotlib

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
>

Howdy,

I just wanted to bump this again: given the speed of Michael's recent
SVG fixes, maybe fixing these two is also quite easy.  They are the
only problem coming from matplotlib right now regarding the use of the
new qt console for ipython.

If not let me know and I'll just file reports on the tracker for
long-term storage :)

Cheers,

f

On Tue, Sep 7, 2010 at 3:39 AM, Fernando Perez <fpe...@gm...> wrote:
> Hi folks,
>
> I've just implemented support in ipython for simultaneous use of the
> interactive mpl gui backends along with inlined figures, as I had
> suggested to Eric things could work.
>
> But I'm seeing two little glitches, illustrated here:
>
> http://fperez.org/tmp/mpl_svg_bug.png
>
> The white console on the right  is IPython, the mpl window was my only
> open figure.
>
> The code I ran was:
>
> x=rand(1000)
> plot (x) # this pops up the normal gui, I tested Qt4Agg and GTKAgg
>
> paste() # this pasted the open figure into the IPython console.
>
> At this point, the plot in the window got that funny size, with the
> x-labels double-drawn.  It seems as if the figure got re-drawn over
> the previous canvas, at a different size.  If I resize the window, the
> problem goes away, but if I don't resize it, it persists through new
> plot/draw operations.
>
> The second problem... I then zoomed the interactive window and issued
> paste again, getting the plot in the bottom right of the figure:
> paste()
>
> And here the bug seems to be related to clipping: while the window
> clips OK, the SVG seems not to.
>
> Is this a fundamental limitation of the SVG backend?
>
> For IPython we can also switch to pngs if that turns out to work
> better, but I figured I'd report these...
>
> All this was done with current mpl from trunk.

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

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

Apologies for the long message---I've really tried to be precise and 
complete.

On 7/7/10 10:23 AM, Jason Grout wrote:
> David Kirkby discovered that a recent SVN version of matplotlib did not
> compile when he was testing a new matplotlib for inclusion in Sage.  A
> bug was opened here:
>
> https://sourceforge.net/tracker/?func=detail&aid=3022815&group_id=80706&atid=560720
>
> It appears that a patch has been committed to 1.0.0 which tries to fix
> the issue.  However, David still reports that matplotlib 1.0.0 still
> doesn't compile on Solaris.  See:
>
> http://trac.sagemath.org/sage_trac/ticket/9221?#comment:7
>
> I'm not sure what the right procedure for reopening a ticket is.
>

I've had some time and access to a solaris box today to try to deal with 
this issue.  I think I've solved it, based on a hint from David Kirkby.


Again, the issue is that matplotlib 1.0.0 will not compile on the 
solaris box t2.sagemath.org (and on another Solaris box too).  David 
Kirkby provided the logs and specs for the systems at

http://trac.sagemath.org/sage_trac/ticket/9221#comment:7


The error is in compiling CXX:

==================================================================
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API 
-DPYCXX_ISO_CPP_LIB=1 
-I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include 
-I/scratch/grout/sage-4.5.3/local/include -I. 
-I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include 
-Isrc -Iagg24/include -I. 
-I/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/numpy/core/include 
-I/scratch/grout/sage-4.5.3/local/include/freetype2 
-I/scratch/grout/sage-4.5.3/local/include -I. 
-I/scratch/grout/sage-4.5.3/local/include/python2.6 -c 
src/backend_agg.cpp -o build/temp.solaris-2.10-sun4v-2.6/src/backend_agg.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
In file included from 
/scratch/grout/sage-4.5.3/local/include/python2.6/Python.h:8,
                  from ./CXX/WrapPython.h:61,
                  from ./CXX/Extensions.hxx:37,
                  from src/ft2font.h:4,
                  from src/backend_agg.cpp:10:
/scratch/grout/sage-4.5.3/local/include/python2.6/pyconfig.h:1013:1: 
warning: "_FILE_OFFSET_BITS" redefined
In file included from /usr/include/sys/types.h:18,
                  from /scratch/grout/sage-4.5.3/local/include/zconf.h:364,
                  from /scratch/grout/sage-4.5.3/local/include/zlib.h:34,
                  from /scratch/grout/sage-4.5.3/local/include/png.h:470,
                  from src/backend_agg.cpp:3:
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h:197:1: 
warning: this is the location of the previous definition
In file included from 
/scratch/grout/sage-4.5.3/local/include/python2.6/Python.h:42,
                  from ./CXX/WrapPython.h:61,
                  from ./CXX/Extensions.hxx:37,
                  from src/ft2font.h:4,
                  from src/backend_agg.cpp:10:
/usr/include/stdlib.h:144: error: declaration of C function 'void 
swab(const char*, char*, ssize_t)' conflicts with
/usr/include/unistd.h:496: error: previous declaration 'void swab(const 
void*, void*, ssize_t)' here
error: command 'gcc' failed with exit status 1

==================================================================

This was reportedly fixed in 1.0.0, but apparently the fix does not work 
for this Solaris box.

Based on a hint from David Kirkby, I changed the CXX/WrapPython.h file 
to be:

==================================================================
#ifndef __PyCXX_wrap_python_hxx__
#define __PyCXX_wrap_python_hxx__

// On some platforms we have to include time.h to get select defined
#if !defined(__WIN32__) && !defined(WIN32) && !defined(_WIN32) && 
!defined(_WIN64)
#include <sys/time.h>
#endif

// pull in python definitions
#include <Python.h>

#endif
==================================================================

(in other words, I just deleted all the defining and undefining of 
variables).  The resulting matplotlib compiled finally, and the result 
of the testing was:



==================================================================
In [1]: import matplotlib
In [2]: matplotlib.__version__
Out[2]: '1.0.0'

In [3]: matplotlib.test()
/scratch/grout/sage-4.5.3/local/lib/python2.6/site-packages/matplotlib/axes.py:2369: 
UserWarning: Attempting to set identical left==right results
in singular transformations; automatically expanding.
left=730139.0, right=730139.0
   + 'left=%s, right=%s') % (left, right))
----------------------------------------------------------------------
Ran 138 tests in 755.419s

OK (KNOWNFAIL=42)
Out[3]: True
==================================================================

so I guess that means everything works.

I also compiled it on Ubuntu 10.04 (64-bit) and OSX 10.6.4, and it 
seemed to compile fine on those systems, though on OSX 10.6.4, I got 
some warnings like:

/home/grout/sage/local/include/python2.6/pyconfig.h:1028:1: warning: 
"_POSIX_C_SOURCE" redefined
/home/grout/sage/local/include/python2.6/pyconfig.h:1037:1: warning: 
"_XOPEN_SOURCE" redefined


This brings up another issue: going against the Python API

As you probably already know, 
http://docs.python.org/c-api/intro.html#includes says that:

"Since Python may define some pre-processor definitions which affect the 
standard headers on some systems, you must include Python.h before any 
standard headers are included."

I notice a lot of other #undef statements for _POSIX_C_SOURCE and 
_XOPEN_SOURCE in matplotlib code.  To my (uneducated) eyes, that seems 
like a recipe for trouble, since defining it one way while including 
some other files, and then undefining the macros and defining them a 
different way may lead to problems.

For example, in _png.cpp, I see:

#include <png.h>

// To remove a gcc warning
#ifdef _POSIX_C_SOURCE
#undef _POSIX_C_SOURCE
#endif

According to the Python API, we should include python.h before including 
png.h.

Thanks,

Jason