matplotlib-devel Mailing List for matplotlib (Page 4)

On 7/8/06, Travis Oliphant <oli...@ie...> wrote:
> Fernando Perez wrote:
> > Hi all,
> >
> > I was trying to track down a problem with current numpy/scipy from
> > svn, and realized that mpl doesn't build anymore:
> >
> >
> Get the latest SVN of matplotlib.   I fixed it there to use
> numpy/oldnumeric.h
>
> It compiles and runs for me.

Mmh, odd.  I must have caught things again in-between updates, because
I /was/ using SVN mpl for the test at the moment.

Thanks for the info, I'll update again.

Cheers,

f

Hi all,

I was trying to track down a problem with current numpy/scipy from
svn, and realized that mpl doesn't build anymore:

...

compile options:
'-I/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.4 -c'
extra options: '-DSCIPY=1'
gcc: src/_ns_cntr.c
src/_ns_cntr.c: In function 'build_cntr_list_v2':
src/_ns_cntr.c:1376: warning: unused variable 'point'
src/_ns_cntr.c: In function 'Cntr_init':
src/_ns_cntr.c:1617: error: 'PyArray_SBYTE' undeclared (first use in
this function)
src/_ns_cntr.c:1617: error: (Each undeclared identifier is reported only once
src/_ns_cntr.c:1617: error: for each function it appears in.)
src/_ns_cntr.c: In function 'build_cntr_list_v2':
src/_ns_cntr.c:1376: warning: unused variable 'point'
src/_ns_cntr.c: In function 'Cntr_init':
src/_ns_cntr.c:1617: error: 'PyArray_SBYTE' undeclared (first use in
this function)
src/_ns_cntr.c:1617: error: (Each undeclared identifier is reported only once
src/_ns_cntr.c:1617: error: for each function it appears in.)
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -fPIC
-I/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.4 -c
src/_ns_cntr.c -o build/temp.linux-i686-2.4/src/_ns_cntr.o -DSCIPY=1"
failed with exit status 1


There have been changes to the C API in numpy which are probably
causing this (See Travis' recent messages on that list).

Cheers,

f

On 7/7/06, Jeff Whitaker <js...@fa...> wrote:

> John:  setupext.py in svn 2545 uses numpy.get_include(), which
> apparently is not available in 0.9.8.  In 0.9.8, it's get_numpy_include().

And in current numpy, get_numpy_include fires a deprecation warning (I
just fixed this in my code).  Such are the joys of living on the
bleeding edge :)

Cheers,

f

John Hunter wrote:
> We'd like to do a bugfix release for the next release of enthought
> python, which will include the latest mpl.  Apparently, there is a
> problem with 0.87.3 and numpy which has been fixed in svn.
>
> If there is anything we should wait on, let us know, otherwise we'll
> probably try to roll out 0.87.4 early next week.
>
> Thanks,
> JDH
>
>   

John:  setupext.py in svn 2545 uses numpy.get_include(), which 
apparently is not available in 0.9.8.  In 0.9.8, it's get_numpy_include().

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Jul 7, 2006, at 5:16 PM, John Hunter wrote:

> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.

I only use PDF figures.  They are useful both in pdflatex (how I  
write), and play nice with all of the other mac utilities, in  
particular Keynote (how I present).  They are generally small, and  
good looking at any size because of the vector graphics.

When converting MPL figures to pdf I usually just export to eps, then  
convert using ghostscript.  In fact, if you open an eps file, OS X  
will do the conversion automagically, and open your new pdf in  
Preview.  For publication quality (with annotations, etc), I export  
to eps, edit in Illustrator, and eventually export to pdf.

I'm not suggesting immediate development for a PDF backend (although  
if it came automatically with kiva, I would use it), I think eps 
+ghostscript is good enough for now.  However, general pdf support is  
an important issue for me.

-Rob

On Friday 07 July 2006 17:16, John Hunter wrote:
> >>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:
>
>     Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
>     >> Ideally, I would like to see PS, SVG, Agg and
>     >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
>     >> people feel differently.
>
>     Ga=EBl>     pdf seems very important to me.
>
> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.  I often make pdf documents but
> incorporate PNG figures into them (eg PDF latex).

I would prefer to use pdf figures in my latex documents. They are smaller,=
=20
they support alpha blending, and unlike png they are scalable. Unfortunatel=
y,=20
most academic journals still request postscript files, but this may change=
=20
some day. Printers may eventually use pdf as their native format instead of=
=20
postscript.

Not that I am advocating adding more backends to mpl, just more=20
contributors. :)

On 7/7/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:
>
>     Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
>     >> Ideally, I would like to see PS, SVG, Agg and
>     >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
>     >> people feel differently.
>
>     Ga=EBl>     pdf seems very important to me.
>
> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.  I often make pdf documents but
> incorporate PNG figures into them (eg PDF latex).  My backend list
> above is not a list of backends that I think matplotlib should support
> as much as it is a list of backends that I personally find useful and
> would personally support even if noone else did.  Any backend that is
> supported by someone should remain in, even if they are the only one
> using it, in my opinion.  But most backends are not supported.
>
> Only PS and Agg (and by extension all of the GTK* backends) support
> all of matplotlib's features.  This should give some indication of how
> much work it is to develop a fully compliant backend, and why we have
> an incentive to minimize the number of them.

PDF has one important combination that neither PS nor png provide:
vector (hence, resolution independent) images with proper
transparency.  I know SVG has that, but I don't know how well SVGs
embed in PDFs (last I tried, I couldn't make it work satisfactorily).

Cheers,

f

>>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:

    Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
    >> Ideally, I would like to see PS, SVG, Agg and
    >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
    >> people feel differently.

    Ga=EBl>     pdf seems very important to me.

PDF is certainly an important document format, but it doesn't seem to
be widely used for figures.  I often make pdf documents but
incorporate PNG figures into them (eg PDF latex).  My backend list
above is not a list of backends that I think matplotlib should support
as much as it is a list of backends that I personally find useful and
would personally support even if noone else did.  Any backend that is
supported by someone should remain in, even if they are the only one
using it, in my opinion.  But most backends are not supported.

Only PS and Agg (and by extension all of the GTK* backends) support
all of matplotlib's features.  This should give some indication of how
much work it is to develop a fully compliant backend, and why we have
an incentive to minimize the number of them.

JDH=20

On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
> Ideally, I would like to see PS, SVG, Agg and [Tk|GTK|WX|Qt|FLTK]Agg
> and no more.  But I know that other people feel differently.

    pdf seems very important to me.

	Just my two cents,

    Ga=EBl

    This question triggers another one from myself (that was raised by
colleagues).

    I know that there is some traits lying in mpl. Will there be one day
some traitsUI code too, to generate GUI to modify properties of objects
one the display ? This is fully related to backends.
    I find that this is one of the most requested features for mpl by my
colleagues (mind you, not by myself).

        Ga=EBl

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, All this brings to mind something I wanted to bring up
    Eric> anyway: we have a proliferation of backends, and occasional
    Eric> requests for more--are there any we can simply drop now, or
    Eric> soon?  For example, gd? And what are the prospects that
    Eric> several backends could be consolidated via cairo?  And/or
    Eric> via more extensive subclassing?

    Eric> I am worried that we are increasingly going to get into
    Eric> trouble with lack of up-to-date support for all these
    Eric> backends.  Major improvements sometimes depend on backend
    Eric> changes, and the more backends we have that lack active
    Eric> maintainers, the harder this gets; and the worse for users,
    Eric> as features work on one backend but break on another.

It's a concern, and I have no problem dropping some (gd is a good
example, it was really just a proof-of-concept backend to prove that
we could mix and match GUIs with pure image backends as I was
developing agg).  A number of backends are incomplete and get little
attention but do little harm either -- in my opinion they are
unsupported.  paint and emf is another example of a backend that noone uses
except for the authors.  I think almost noone uses gdk, gtk, cairo or
gtkcairo, but I hesitate to pull these because Steve Chaplin, the GTK
maintainer, wrote them, uses them, and has done a great job with GTK.

Ideally, I would like to see PS, SVG, Agg and [Tk|GTK|WX|Qt|FLTK]Agg
and no more.  But I know that other people feel differently.

Taking the long view, enthought's kiva/chaco uses the pdf drawing
model, which is a nice model and superior to the matplotlib GTK
model.  I've talked with Eric Jones many times about the desirability
of sharing a single low-level drawing model, probably based on
PDF/KIVA, that have backends for PS, SVG, PDF and one raster format
(eg Agg or Cairo).  But nothing has ever happened here because we both
have lots to do and a lot of code that depends on what is already in
place.

JDH

John,

All this brings to mind something I wanted to bring up anyway: we have a 
proliferation of backends, and occasional requests for more--are there 
any we can simply drop now, or soon?  For example, gd? And what are the 
prospects that several backends could be consolidated via cairo?  And/or 
via more extensive subclassing?

I am worried that we are increasingly going to get into trouble with 
lack of up-to-date support for all these backends.  Major improvements 
sometimes depend on backend changes, and the more backends we have that 
lack active maintainers, the harder this gets; and the worse for users, 
as features work on one backend but break on another.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> Martin, When I try your example with svn matplotlib, I get a
>     Eric> 34 MB eps file, and looking at it, I don't see much room for
>     Eric> making it smaller--there is one obvious optimization,
>     Eric> abbreviating "marker", but that's it.  (The svg file is 456
>     Eric> MB!)  So, maybe some major optimization has already been
>     Eric> done between mpl 0.87.2 and svn.
> 
> Yep, Darren got "draw_markers" properly implemented for backend PS.
> This function is much better in time and space; I believe only *Agg
> and PS implement it, but it could be ported over to SVG fairly easily
> by modifying the PS implementation.
> 
>     Eric> The bigger problem is that each file format has basic
>     Eric> characteristics and limitations.  If you draw a million
>     Eric> markers and line segments, you are inevitably going to have
>     Eric> a big postscript file, unless the postscript backend somehow
>     Eric> detects the fact that almost all of your points are
>     Eric> indistinguishable and therefore deletes most of them--and
>     Eric> this is really asking too much of a plotting backend, I
> 
> Agg does this for draw_lines -- it drops points in the path that are
> less one pixel away from the previous point.  
> 
> JDH

We'd like to do a bugfix release for the next release of enthought
python, which will include the latest mpl.  Apparently, there is a
problem with 0.87.3 and numpy which has been fixed in svn.

If there is anything we should wait on, let us know, otherwise we'll
probably try to roll out 0.87.4 early next week.

Thanks,
JDH

Hi Kevin,

On Wednesday 05 July 2006 23:30, Kevin Mueller wrote:
> Hi all
>    I ported the QtAgg backend over to Qt4 and created a patch for adding
> this backend to matplotlib with the name, Qt4Agg.  I include it here, for
> anyone interested.   I also noticed an earlier message like this, seemingly
> without resolution.   Is there other- maybe, better- code for Qt4 available
> somewhere?

There is a qt4agg backend in svn version of matplotlib. The svn version of 
ipython also includes support for qt4.

Darren

Hi all
   I ported the QtAgg backend over to Qt4 and created a patch for adding this 
backend to matplotlib with the name, Qt4Agg.  I include it here, for anyone 
interested.   I also noticed an earlier message like this, seemingly without 
resolution.   Is there other- maybe, better- code for Qt4 available 
somewhere?

Kevin Mueller
Dept. Atmospheric Science, Univ. Illinois Urbana-Qt4Champaign

Oops.  The earlier patch was reversed by accident.  Here is the fixed patch.

On Wednesday 05 July 2006 22:30, you wrote:
> Hi all
>    I ported the QtAgg backend over to Qt4 and created a patch for adding
> this backend to matplotlib with the name, Qt4Agg.  I include it here, for
> anyone interested.   I also noticed an earlier message like this, seemingly
> without resolution.   Is there other- maybe, better- code for Qt4 available
> somewhere?
>
> Kevin Mueller
> Dept. Atmospheric Science, Univ. Illinois Urbana-Qt4Champaign