matplotlib-devel Mailing List for matplotlib (Page 4)

On Mon, Jun 23, 2008 at 04:43, Charles Moad <cw...@gm...> wrote:
> The releases and builds are up.  Please test them out, and I'll leave the
> announcements to you, John.

I just downloaded it (MD5Sum: 1f673f82eb4f7422c1e45545f8e083d4) and I
plan to upgrade the package in Debian this evening.

Thanks a lot for the huge work you've done to fulfill Debian requirements!

Cheers,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Fri, 20 Jun 2008, John Hunter wrote:
> On Thu, Jun 19, 2008 at 11:52 AM, Olle Engdegård <ol...@fy...> wrote:
>>
>> Here is a patch to add linestyles to patches.py. I have tried it with
>> unfilled step histograms (important for b/w print and colour blind people).
>
> I'm happy to include this, but we need to make sure it is supported in
> PS, PDF, SVG and Agg.  Can you check these backends to make sure they
> are respecting the new parameter?
>

Tested, seems to work fine with Agg, Cairo, PS, PDF, SVG, GTK, GTKAgg and 
GTKCairo

Cheers,
Olle

The releases and builds are up.  Please test them out, and I'll leave  
the announcements to you, John.

- Charlie

On Jun 22, 2008, at 12:43 PM, John Hunter wrote:

> On Fri, Jun 20, 2008 at 10:20 AM, Charlie Moad <cw...@gm...>  
> wrote:
>> Can we shoot for Sunday night?  It would be much more convenient  
>> for me at
>> least.
>
> I'll be traveling most of the day so I will be mostly out of
> touch(some blackberry access), but I did a round of testing on the
> branch and the trunk and things look good to go from my end.
>
> JDH

On Fri, Jun 20, 2008 at 10:20 AM, Charlie Moad <cw...@gm...> wrote:
> Can we shoot for Sunday night?  It would be much more convenient for me at
> least.

I'll be traveling most of the day so I will be mostly out of
touch(some blackberry access), but I did a round of testing on the
branch and the trunk and things look good to go from my end.

JDH

Hi Brian,

On Sunday 22 June 2008 11:01:36 B Clowers wrote:
> p, li { white-space: pre-wrap; }
>
> I have a small program that displays a embeds a figure along with the
> navigation toolbar into a PyQt4 application.  In version 0.91 it works
> fine, however, I get the following error when I try to run the program with
> 0.98 .  An exception is raised at line 296 of the backend_qt4.py .  I've
> attached the output from Eric4.  Is there something I can do to my program
> or is this a more fundamental issue?ThanksBrian--ps this issue only seems
> to be a problem if I'm using the navigation toolbar, a regular plot is ok.
> The debugged program raised the exception unhandled AttributeError
> "coordinates"
> File: /usr/lib/python2.5/site-packages/matplotlib/backends/backend_qt4.py,
> Line: 296StdErr: QLayout: Attempting to add QLayout "" to
> MyNavigationToolbar "", which already has a layout

Version 98 changed the backend_qt4 toolbar so it is a true Qt toolbar, which 
already has a layout. I guess you need to use the existing layout, rather than 
adding a new one.

If that doesn't help you, please post a *short* standalone script that 
reproduces the problem. Its hard to diagnose these things based on so little 
information.

Darren

p, li { white-space: pre-wrap; }

I have a small program that displays a embeds a figure along with the navigation toolbar into a PyQt4 application.  In version 0.91 it works fine, however, I get the following error when I try to run the program with 0.98 .  An exception is raised at line 296 of the backend_qt4.py .  I've attached the output from Eric4.  Is there something I can do to my program or is this a more fundamental issue?ThanksBrian--ps this issue only seems to be a problem if I'm using the navigation toolbar, a regular plot is ok.
The debugged program raised the exception unhandled AttributeError
"coordinates"
File: /usr/lib/python2.5/site-packages/matplotlib/backends/backend_qt4.py, Line: 296StdErr: QLayout: Attempting to add QLayout "" to MyNavigationToolbar "", which already has a layout



      

Yes, it is weird as I don't have gdk installed.  I wasn't using a config file but now that you mention it if I do use a config file it will compile correctly.

Thanks

Brian

--- On Sat, 6/21/08, Eric Firing <ef...@ha...> wrote:
From: Eric Firing <ef...@ha...>
Subject: Re: [matplotlib-devel] matplotlib-0.98 Failure to Build
To: clo...@ya...
Cc: mat...@li...
Date: Saturday, June 21, 2008, 8:46 PM

It is trying to build the gdk extension but you don't have the devel 
package installed, so it can't find the headers.  What puzzles me is 
that it *knows* it can't find the headers, so it shouldn't be trying to

build the extension.  Are you using a setup.cfg file?  (Ordinarily, one 
should not.)

Eric

B Clowers wrote:
> After downloading the source and following the instructions, I've been

> unable to build matplotlib on Ubuntu Hardy.  Any ideas?
> 
> BUILDING MATPLOTLIB
>             matplotlib: 0.98.0
>                 python: 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)  [GCC
>                         4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
>               platform: linux2
> 
> REQUIRED DEPENDENCIES
>                  numpy: 1.1.0
>              freetype2: 9.16.3
> 
> OPTIONAL BACKEND DEPENDENCIES
>                 libpng: 1.2.15beta5
>                Tkinter: no
>                         * Using default library and include directories
for
>                         * Tcl and Tk because a Tk window failed to open.
>                         * You may need to define DISPLAY for Tk to work so
>                         * that setup can determine where your libraries
are
>                         * located. Tkinter present, but header files are
not
>                         * found. You may need to install development
>                         * packages.
>               wxPython: 2.8.7.1
>                         * WxAgg extension not required for wxPython >=
2.8
>                   Gtk+: gtk+: 2.12.9, glib: 2.16.3, pygtk: 2.12.1,
>                         pygobject: 2.14.1
>                         * Could not find Gtk+ headers in any of
>                         * '/usr/local/include',
'/usr/include', '.'
>                     Qt: no
>                    Qt4: no
>                  Cairo: 1.4.0
> 
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>               datetime: present, version unknown
>               dateutil: 1.3
>                   pytz: 2007k
> 
> OPTIONAL USETEX DEPENDENCIES
>                 dvipng: 1.9
>            ghostscript: 8.61
>                  latex: 3.141592
>                pdftops: 3.00
> 
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
>              configobj: 4.4.0
>       enthought.traits: 2.0.1b1
> 
> [Edit setup.cfg to suppress the above messages]
>
============================================================================
> running build
> running build_py
> copying lib/matplotlib/mpl-data/matplotlibrc -> 
> build/lib.linux-i686-2.5/matplotlib/mpl-data
> copying lib/matplotlib/mpl-data/matplotlib.conf -> 
> build/lib.linux-i686-2.5/matplotlib/mpl-data
> running build_ext
> building 'matplotlib.backends._backend_gdk' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fPIC 
>
-I/usr/lib/python2.5/site-packages/numpy-1.1.0-py2.5-linux-i686.egg/numpy/core/include

> -I/usr/local/include -I/usr/include -I. -I/usr/local/include 
> -I/usr/include -I. -I/usr/include/python2.5 -c src/backend_gdk.c -o 
> build/temp.linux-i686-2.5/src/backend_gdk.o
> src/backend_gdk.c:9:25: error: pygtk/pygtk.h: No such file or directory
> src/backend_gdk.c: In function ‘pixbuf_get_pixels_array’:
> src/backend_gdk.c:28: error: ‘PyGObject’ undeclared (first use in this

> function)
> src/backend_gdk.c:28: error: (Each undeclared identifier is reported 
> only once
> src/backend_gdk.c:28: error: for each function it appears in.)
> src/backend_gdk.c:28: error: ‘py_pixbuf’ undeclared (first use in this

> function)
> src/backend_gdk.c:29: error: ‘GdkPixbuf’ undeclared (first use in this

> function)
> src/backend_gdk.c:29: error: ‘gdk_pixbuf’ undeclared (first use in
this 
> function)
> src/backend_gdk.c:37: warning: implicit declaration of function
‘GDK_PIXBUF’
> src/backend_gdk.c:43: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_height’
> src/backend_gdk.c:44: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_width’
> src/backend_gdk.c:45: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_has_alpha’
> src/backend_gdk.c:48: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_pixels’
> src/backend_gdk.c:53: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_rowstride’
> src/backend_gdk.c: In function ‘init_backend_gdk’:
> src/backend_gdk.c:72: warning: implicit declaration of function
‘init_pygtk’
> error: command 'gcc' failed with exit status 1
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


      

On Friday 20 June 2008 13:32:46 Eric Firing wrote:
> John Hunter wrote:
> > Sandro has been working hard packaging matplotlib 0.98.0 for debian
> > ahead of the next major debian feature freeze, and says he can get
> > 0.98.1 in if we release it by June 24th.  Charlie, can you do a
> > release on Monday?  All developers, please take some time to fix any
> > bugs you are aware of and let's release 0.91.4 and 0.98.1 on Monday
> > pending Charlie's availability.  These major debian releases only
> > happen once every couple of years so we want to get good versions in.
> >
> > JDH
>
> It is probably too late for this upcoming release, but I would like to
> raise a relevant question for discussion:
>
> Can and should we rearrange the code, or install warnings and
> documentation, to make it absolutely clear what is supported and what is
> not?  Ideally, if someone installs 0.98.x from any distribution, or from
> the tarball, the user should be able to expect *everything* to work,
> including all backends, examples, and plotting-related classes.
>
> The simplest way to deal with this would be to leave everything where it
> is, if there is any hope that it will ever be fixed and maintained, but
> to put a warnings.warn and a docstring comment in any module or example
> that does not currently work.  That way, if someone imports axes3d, they
> would (or at least might, unless it goes by too fast) see the warning
> and know that if they want it to work, they will simply have to take on
> its maintenance.
>
> A second step would be to have one or more separate subdirectories to
> separate the maintained from the unmaintained.  Doing this in a nice,
> consistent, easy-to-use way would take a little more work.  For example,
> one would want to make it very easy for someone to restore a backend
> from broken and segregated to fully operational and available.

I think we should do warnings, documentation, and consider removing 
unmaintained code like axes3d. We talked a while back about adding separately 
distributable toolkits for unmaintained and license-incompatible projects. 
Maybe we could revisit that idea.

Darren

It is trying to build the gdk extension but you don't have the devel 
package installed, so it can't find the headers.  What puzzles me is 
that it *knows* it can't find the headers, so it shouldn't be trying to 
build the extension.  Are you using a setup.cfg file?  (Ordinarily, one 
should not.)

Eric

B Clowers wrote:
> After downloading the source and following the instructions, I've been 
> unable to build matplotlib on Ubuntu Hardy.  Any ideas?
> 
> BUILDING MATPLOTLIB
>             matplotlib: 0.98.0
>                 python: 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)  [GCC
>                         4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
>               platform: linux2
> 
> REQUIRED DEPENDENCIES
>                  numpy: 1.1.0
>              freetype2: 9.16.3
> 
> OPTIONAL BACKEND DEPENDENCIES
>                 libpng: 1.2.15beta5
>                Tkinter: no
>                         * Using default library and include directories for
>                         * Tcl and Tk because a Tk window failed to open.
>                         * You may need to define DISPLAY for Tk to work so
>                         * that setup can determine where your libraries are
>                         * located. Tkinter present, but header files are not
>                         * found. You may need to install development
>                         * packages.
>               wxPython: 2.8.7.1
>                         * WxAgg extension not required for wxPython >= 2.8
>                   Gtk+: gtk+: 2.12.9, glib: 2.16.3, pygtk: 2.12.1,
>                         pygobject: 2.14.1
>                         * Could not find Gtk+ headers in any of
>                         * '/usr/local/include', '/usr/include', '.'
>                     Qt: no
>                    Qt4: no
>                  Cairo: 1.4.0
> 
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>               datetime: present, version unknown
>               dateutil: 1.3
>                   pytz: 2007k
> 
> OPTIONAL USETEX DEPENDENCIES
>                 dvipng: 1.9
>            ghostscript: 8.61
>                  latex: 3.141592
>                pdftops: 3.00
> 
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
>              configobj: 4.4.0
>       enthought.traits: 2.0.1b1
> 
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> running build
> running build_py
> copying lib/matplotlib/mpl-data/matplotlibrc -> 
> build/lib.linux-i686-2.5/matplotlib/mpl-data
> copying lib/matplotlib/mpl-data/matplotlib.conf -> 
> build/lib.linux-i686-2.5/matplotlib/mpl-data
> running build_ext
> building 'matplotlib.backends._backend_gdk' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fPIC 
> -I/usr/lib/python2.5/site-packages/numpy-1.1.0-py2.5-linux-i686.egg/numpy/core/include 
> -I/usr/local/include -I/usr/include -I. -I/usr/local/include 
> -I/usr/include -I. -I/usr/include/python2.5 -c src/backend_gdk.c -o 
> build/temp.linux-i686-2.5/src/backend_gdk.o
> src/backend_gdk.c:9:25: error: pygtk/pygtk.h: No such file or directory
> src/backend_gdk.c: In function ‘pixbuf_get_pixels_array’:
> src/backend_gdk.c:28: error: ‘PyGObject’ undeclared (first use in this 
> function)
> src/backend_gdk.c:28: error: (Each undeclared identifier is reported 
> only once
> src/backend_gdk.c:28: error: for each function it appears in.)
> src/backend_gdk.c:28: error: ‘py_pixbuf’ undeclared (first use in this 
> function)
> src/backend_gdk.c:29: error: ‘GdkPixbuf’ undeclared (first use in this 
> function)
> src/backend_gdk.c:29: error: ‘gdk_pixbuf’ undeclared (first use in this 
> function)
> src/backend_gdk.c:37: warning: implicit declaration of function ‘GDK_PIXBUF’
> src/backend_gdk.c:43: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_height’
> src/backend_gdk.c:44: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_width’
> src/backend_gdk.c:45: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_has_alpha’
> src/backend_gdk.c:48: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_pixels’
> src/backend_gdk.c:53: warning: implicit declaration of function 
> ‘gdk_pixbuf_get_rowstride’
> src/backend_gdk.c: In function ‘init_backend_gdk’:
> src/backend_gdk.c:72: warning: implicit declaration of function ‘init_pygtk’
> error: command 'gcc' failed with exit status 1
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Fernando Perez wrote:
> Hey Michael,
>
> On Fri, Jun 20, 2008 at 7:47 AM, Michael Droettboom <md...@st...> wrote:
>   
>> John Hunter wrote:
>>     
>>> On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:
>>>
>>>
>>>       
>>>> The current version of graphviz uses either cairo or gd (the default being
>>>> cairo on most modern installations.)
>>>>
>>>>         
>>>       
>>>> Now that you've uploaded the docs, I see that the font you're getting isn't
>>>> as nice as mine.  I was setting "fontname" to "sans", which is supposed to
>>>> get the default sans serif font on the system.  It appears, from testing,
>>>> one can provide a list of fonts to dot, so I'll change it to try good fonts
>>>> first, with sans as the last resort fallback.
>>>>
>>>>         
>>> I'm building and uploading the docs in a nightly cron on a linux box
>>> that Fernando maintains.  Can you tell him what package(s) need to be
>>> installed to insure cairo rendering so he can update the box?
>>>       
>> My understanding is that gd doesn't support antialiasing at all, so if
>> you're seeing antialiasing you're using Cairo.  To be absolutely certain
>> you're using Cairo, you can change the "-Tpng" to "-Tpng:cairo" (though
>> I don't know if we should do that in general, since it will break for
>> users who don't have Cairo, if such users exist...).
>>
>> With my latest updates, you should ensure that there is a decent-looking
>> font, such as Vera Sans, on the fontconfig path.  You should also make
>> sure that libpango is being used by your graphviz.  It's optional in
>> graphviz, but is used by the pre-built packages on Debian Etch and
>> Ubuntu Hardy at least.
>>     
>
> Unfortunately this is a Fedora 8 box that was given to me.  I do have
> sudo access, so I can install whatever we want, but it's not ubuntu.
> I may update it to Ubuntu later (that's what I use on all my regular
> machines) but right now I'm too busy for that.
>   
I didn't mean to imply that Debian/Ubuntu was required, those are just 
the ones that I looked at as a sampling.  It looks like Fedora 8 also 
links graphviz with libpango, according to its rpm spec.
> Do you have any clue as to what packages might do the trick for
> Fedora?  I'm happy to add anything, I just don't know what to look
> for...
>   
It looks like you're already good to go, judging by what's now up on 
matplotlib.sf.net.  My change this morning to use "Vera Sans", if 
available, rather than "sans" (which maps to the default sans-serif font 
on the system), seems to have done the trick.

The issues John pointed out -- the fuzzy rectangles, bad arrowhead 
alignment -- seem to just be what graphviz does.  We're not going to get 
any better without being clever.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hey Michael,

On Fri, Jun 20, 2008 at 7:47 AM, Michael Droettboom <md...@st...> wrote:
> John Hunter wrote:
>> On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:
>>
>>
>>> The current version of graphviz uses either cairo or gd (the default being
>>> cairo on most modern installations.)
>>>
>>
>>
>>> Now that you've uploaded the docs, I see that the font you're getting isn't
>>> as nice as mine.  I was setting "fontname" to "sans", which is supposed to
>>> get the default sans serif font on the system.  It appears, from testing,
>>> one can provide a list of fonts to dot, so I'll change it to try good fonts
>>> first, with sans as the last resort fallback.
>>>
>>
>> I'm building and uploading the docs in a nightly cron on a linux box
>> that Fernando maintains.  Can you tell him what package(s) need to be
>> installed to insure cairo rendering so he can update the box?
> My understanding is that gd doesn't support antialiasing at all, so if
> you're seeing antialiasing you're using Cairo.  To be absolutely certain
> you're using Cairo, you can change the "-Tpng" to "-Tpng:cairo" (though
> I don't know if we should do that in general, since it will break for
> users who don't have Cairo, if such users exist...).
>
> With my latest updates, you should ensure that there is a decent-looking
> font, such as Vera Sans, on the fontconfig path.  You should also make
> sure that libpango is being used by your graphviz.  It's optional in
> graphviz, but is used by the pre-built packages on Debian Etch and
> Ubuntu Hardy at least.

Unfortunately this is a Fedora 8 box that was given to me.  I do have
sudo access, so I can install whatever we want, but it's not ubuntu.
I may update it to Ubuntu later (that's what I use on all my regular
machines) but right now I'm too busy for that.

Do you have any clue as to what packages might do the trick for
Fedora?  I'm happy to add anything, I just don't know what to look
for...

Cheers,

f

Hi,

I've encountered behavior in the svn trunk that I think is a bug.
Namely, the axes view limits are reset to the data limits upon a UI
event callback. In the attached test script for example, the plot
initially displays with the correct view limits (between -10 and 10 on
the X axis). However, when a key is pressed, the view is automatically
(and falsely) reset to encompass the entire data limits. I believe this
behavior has changed since 0.91.

Thanks,
Andrew

John Hunter wrote:
> Sandro has been working hard packaging matplotlib 0.98.0 for debian
> ahead of the next major debian feature freeze, and says he can get
> 0.98.1 in if we release it by June 24th.  Charlie, can you do a
> release on Monday?  All developers, please take some time to fix any
> bugs you are aware of and let's release 0.91.4 and 0.98.1 on Monday
> pending Charlie's availability.  These major debian releases only
> happen once every couple of years so we want to get good versions in.
> 
> JDH

It is probably too late for this upcoming release, but I would like to 
raise a relevant question for discussion:

Can and should we rearrange the code, or install warnings and 
documentation, to make it absolutely clear what is supported and what is 
not?  Ideally, if someone installs 0.98.x from any distribution, or from 
the tarball, the user should be able to expect *everything* to work, 
including all backends, examples, and plotting-related classes.

The simplest way to deal with this would be to leave everything where it 
is, if there is any hope that it will ever be fixed and maintained, but 
to put a warnings.warn and a docstring comment in any module or example 
that does not currently work.  That way, if someone imports axes3d, they 
would (or at least might, unless it goes by too fast) see the warning 
and know that if they want it to work, they will simply have to take on 
its maintenance.

A second step would be to have one or more separate subdirectories to 
separate the maintained from the unmaintained.  Doing this in a nice, 
consistent, easy-to-use way would take a little more work.  For example, 
one would want to make it very easy for someone to restore a backend 
from broken and segregated to fully operational and available.

Eric

On Thu, Jun 19, 2008 at 5:46 PM, John Hunter <jd...@gm...> wrote:
> I believe there is a bug in the figimage handling when multiple images
> are present.  It looks like there is a negative sign in the
> transformation that shouldn't be there.  It is common to get upside
> down in mpl, since bottom is 0 for us and usually bottom is top

Well, it almost killed me but I finally figured out the cause of this
bug: the origin rc param was being ignored for composite images.  I
fixed in r5618 this for fig and axes images.

JDH

There is a bug in gtkagg that is exposed by creating the figure with
figure(frameon=False) and then resizing it.  "screen noise" appears,
as in the attached figure, which indicates the pixel buffer is not
being initialized  This totally mystified me, because the agg backend
does clear the image background with (1,1,1,0) (all white,
transparent),

  rendererBase->clear(agg::rgba(1, 1, 1, 0));

In gtkagg, we do

pixbuf = gtk.gdk.pixbuf_new_from_data(
            buf, gtk.gdk.COLORSPACE_RGB,  True, 8, w, h, w*4)

where buf is the agg rgba buffer including the image.  Apparently
there is an "optimization" that skips data when alpha=0.  If in
_backend_agg we clear the background with (1,1,1,1) the screen noise
problem goes away, which is why I suspect the copy method in gtk is
ignoring the alpha =0 case.  But this isn't really an option since
people like to have transparent figures (well, I suppose it is an
option for gtkagg only).

I have a fairly old gtk (2.6).  Do others see a similar problem with
more recent gtk?

If recent pygtk versions have fixed this bug, I'm ok to ignore it.
But if it is present in others, we probably need to rethink how we
create and initialize the gtk pixel buffer in gtkagg.

JDH

On Fri, Jun 20, 2008 at 1:16 PM, Fernando Perez <fpe...@gm...> wrote:

> Yes, it's meant to be up 24/7.  The mess on Monday/Tuesday was because
> I was adding backup drives, so I needed to reboot it multiple times.
> That's done now and it should just work.  I meant more if you needed
> anything new installed for the release, or any other unusual request.
> I don' want to cause a delay for you at the last minute, because I
> really would like to see 0.98.1 in debian.

Oh I see.  No, the docs stuff is a longer term project that will have
no impact on the release.  Thanks, though.

JDH

On Fri, Jun 20, 2008 at 12:54 PM, Fernando Perez <fpe...@gm...> wrote:

> John, do you need anything from BIC?  I'm out for a few hours (car
> troubles) and will be in and out on Saturday, but likely with a laptop
> in tow.  So just call me on my cell if anything from bic is needed for
> the release builds, I'll keep it turned on.

Nothing today -- Sunday I'll need access.  I assumed bic was up more
or less all the time unless it was being maintained.  Is this right?

Thanks for your help!
JDH

After downloading the source and following the instructions, I've been unable to build matplotlib on Ubuntu Hardy.  Any ideas?

BUILDING MATPLOTLIB
            matplotlib: 0.98.0
                python: 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)  [GCC
                        4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
              platform:
 linux2

REQUIRED
 DEPENDENCIES
                 numpy: 1.1.0
             freetype2: 9.16.3

OPTIONAL BACKEND DEPENDENCIES
                libpng: 1.2.15beta5
               Tkinter: no
                        * Using default library and include directories for
                        * Tcl and Tk because a Tk window failed to
 open.
                        * You may need to define DISPLAY for Tk to work so
                        * that setup can determine where your libraries are
                        * located. Tkinter present, but header files are not
                        * found. You may need to install development
                        *
 packages.
              wxPython: 2.8.7.1
                        * WxAgg extension not required for wxPython >= 2.8
                  Gtk+: gtk+: 2.12.9, glib: 2.16.3, pygtk: 2.12.1,
                        pygobject: 2.14.1
                        * Could not find Gtk+ headers in any of
                        *
 '/usr/local/include', '/usr/include', '.'
                    Qt: no
                   Qt4: no
                 Cairo: 1.4.0

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              datetime: present, version unknown
              dateutil: 1.3
                  pytz: 2007k

OPTIONAL USETEX DEPENDENCIES
                dvipng:
 1.9
           ghostscript: 8.61
                 latex: 3.141592
               pdftops: 3.00

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
             configobj: 4.4.0
      enthought.traits: 2.0.1b1

[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-i686-2.5/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf -> build/lib.linux-i686-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib.backends._backend_gdk' extension
gcc
 -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/lib/python2.5/site-packages/numpy-1.1.0-py2.5-linux-i686.egg/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/backend_gdk.c -o build/temp.linux-i686-2.5/src/backend_gdk.o
src/backend_gdk.c:9:25: error: pygtk/pygtk.h: No such file or directory
src/backend_gdk.c: In function ‘pixbuf_get_pixels_array’:
src/backend_gdk.c:28: error: ‘PyGObject’ undeclared (first use in this function)
src/backend_gdk.c:28: error: (Each undeclared identifier is reported only once
src/backend_gdk.c:28: error: for each function it appears in.)
src/backend_gdk.c:28: error: ‘py_pixbuf’ undeclared (first use in this function)
src/backend_gdk.c:29: error: ‘GdkPixbuf’ undeclared (first use in this function)
src/backend_gdk.c:29: error: ‘gdk_pixbuf’ undeclared (first
 use in this function)
src/backend_gdk.c:37: warning: implicit declaration of function ‘GDK_PIXBUF’
src/backend_gdk.c:43: warning: implicit declaration of function ‘gdk_pixbuf_get_height’
src/backend_gdk.c:44: warning: implicit declaration of function ‘gdk_pixbuf_get_width’
src/backend_gdk.c:45: warning: implicit declaration of function ‘gdk_pixbuf_get_has_alpha’
src/backend_gdk.c:48: warning: implicit declaration of function ‘gdk_pixbuf_get_pixels’
src/backend_gdk.c:53: warning: implicit declaration of function ‘gdk_pixbuf_get_rowstride’
src/backend_gdk.c: In function ‘init_backend_gdk’:
src/backend_gdk.c:72: warning: implicit declaration of function ‘init_pygtk’
error: command 'gcc' failed with exit status 1





      

On Fri, Jun 20, 2008 at 6:10 PM, Andrew Straw <str...@as...> wrote:
> Hmm, I'm sending this directly to you guys... My post to MPL devel still
> seems to be in the queue somewhere...
>
> -Andrew
>
> Hi,
>
> I've encountered behavior in the svn trunk that I think is a bug.
> Namely, the axes view limits are reset to the data limits upon a UI
> event callback. In the attached test script for example, the plot
> initially displays with the correct view limits (between -10 and 10 on
> the X axis). However, when a key is pressed, the view is automatically
> (and falsely) reset to encompass the entire data limits. I believe this
> behavior has changed since 0.91.

Feature, not bug.  The keypress callback in this example calls "plot"
which engages the autoscale machinery.  If you comment out the plot
call in the keypress callback, you don't see the rescaling. If you
want to disable the autoscaling on the calls to plot and friends, you
need to set the axes property autoscale_on=False

ax1 =fig.add_subplot(2,1,1,autoscale_on=False)

Sorry, I'm stumped.

Mike

Charlie Moad wrote:
> Here's that file.
>
> Thanks,
>      Charlie
>
> On Fri, Jun 20, 2008 at 9:25 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     Have you updated Sphinx from SVN lately?  I have r64374.
>
>     Sphinx should have dumped a full traceback into a tmp file (and
>     told you where it is, which I don't see in your log output).  Can
>     you send that?
>
>     Cheers,
>     Mike
>
>     Charlie Moad wrote:
>
>         Python2.5 on OSX.5
>
>         On Thu, Jun 19, 2008 at 11:14 PM, Michael Droettboom
>         <md...@st... <mailto:md...@st...>
>         <mailto:md...@st... <mailto:md...@st...>>> wrote:
>
>            What version of Python are you running?  All I can think from
>            looking at the code is that something in the regex is behaving
>            differently for you than me (on Python 2.5).
>
>            If you just want the docs to build (minus the inheritance
>            diagrams), you can put a "return []" at the top of
>            "inheritance_diagram_directive_run" in inheritance_diagram.py
>
>            Cheers,
>            Mike
>
>            Charles Moad wrote:
>
>                Just jumped into the new docs to take a look and
>         immediately
>                having  problems building.  I am hoping someone can make a
>                quick fix so I  don't have to debug.
>
>                quaternion:doc cmoad$ ./make.py html
>                Sphinx v0.3, building html
>                trying to load pickled env... not found
>                building [html]: targets for 45 source files that are
>         out of date
>                updating environment: 45 added, 0 changed, 0 removed
>                reading... api/artist_api Exception occurred:
>                  File "/Users/cmoad/workspace/matplotlib/doc/sphinxext/
>                inheritance_diagram.py", line 78, in
>         _import_class_or_module
>                    "Invalid class '%s' specified for inheritance
>         diagram" % name)
>                ValueError: Invalid class 'matplotlib.patches'
>         specified for
>                 inheritance diagram
>
>                Thanks,
>                       Charlie
>
>              
>          -------------------------------------------------------------------------
>                Check out the new SourceForge.net Marketplace.
>                It's the best place to buy or sell services for
>                just about anything Open Source.
>                http://sourceforge.net/services/buy/index.php
>                _______________________________________________
>                Matplotlib-devel mailing list
>                Mat...@li...
>         <mailto:Mat...@li...>
>                <mailto:Mat...@li...
>         <mailto:Mat...@li...>>
>
>              
>          https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>                
>
>
>
>     -- 
>     Michael Droettboom
>     Science Software Branch
>     Operations and Engineering Division
>     Space Telescope Science Institute
>     Operated by AURA for NASA
>
>

Hi Andrew,

On Friday 20 June 2008 19:28:20 Andrew Straw wrote:
> When I attempt to plot small-scale features with the PS backend, it
> seems that there's a granularity at which things cannot be further
> specified. I cannot remember encoutering this before, although I can't
> be sure it's not an old phenomenon. Anyhow, the following script
> illustrates the issue. With the PS backend, zooming in on the output
> shows the points spread significantly away from their locations that
> would be expected.
>
> import matplotlib
> matplotlib.use('PS')
> import pylab
> import numpy
>
> x=numpy.linspace(-100,100,2000)
> x+=0.001*numpy.random.rand(len(x))
>
> y=numpy.sin(x/30.0)
> y+=0.001*numpy.random.rand(len(x))
>
> pylab.plot(x,y,'.',ms=0.1)
> pylab.savefig('dots_dynamic_range')
>
> With the Agg and PDF backends, this does not occur. I'm attaching a few
> example images which hopefully make the issue clear. (These have all
> seen a little bit of processing to reduce the file sizes.)

I see this also. I checked the text contents of the ps file, and the precision 
after the decimal place is lost. This is surprising behavior to me:

In [4]: '%1.3g %1.3g'% (429.120463939, 155.230815676)
Out[4]: '429 155'

I changed it back to "%g %g", like it is in the v91 branch.

Darren

On Fri, Jun 20, 2008 at 8:22 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Jun 20, 2008 at 10:20 AM, Charlie Moad <cw...@gm...> wrote:
>> Can we shoot for Sunday night?  It would be much more convenient for me at
>> least.
>
> Absolutely.  I suggested Monday because I thought it would be better,
> but Sunday works fine too.  I'll do a round of testing Sunday morning.

John, do you need anything from BIC?  I'm out for a few hours (car
troubles) and will be in and out on Saturday, but likely with a laptop
in tow.  So just call me on my cell if anything from bic is needed for
the release builds, I'll keep it turned on.

Cheers,

f

Hi,

When I attempt to plot small-scale features with the PS backend, it
seems that there's a granularity at which things cannot be further
specified. I cannot remember encoutering this before, although I can't
be sure it's not an old phenomenon. Anyhow, the following script
illustrates the issue. With the PS backend, zooming in on the output
shows the points spread significantly away from their locations that
would be expected.

import matplotlib
matplotlib.use('PS')
import pylab
import numpy

x=numpy.linspace(-100,100,2000)
x+=0.001*numpy.random.rand(len(x))

y=numpy.sin(x/30.0)
y+=0.001*numpy.random.rand(len(x))

pylab.plot(x,y,'.',ms=0.1)
pylab.savefig('dots_dynamic_range')

With the Agg and PDF backends, this does not occur. I'm attaching a few
example images which hopefully make the issue clear. (These have all
seen a little bit of processing to reduce the file sizes.)

On Fri, Jun 20, 2008 at 11:18 AM, Michael Droettboom <md...@st...> wrote:

> I didn't mean to imply that Debian/Ubuntu was required, those are just the
> ones that I looked at as a sampling.  It looks like Fedora 8 also links
> graphviz with libpango, according to its rpm spec.

Oh, no worries: I'm also much more familiar with the ubuntu packages,
so I was just mentioning it because I'm a bit lost with the recent
Fedora package structure.  I hadn't used Fedora in years until I got
this box recently.

>> Do you have any clue as to what packages might do the trick for
>> Fedora?  I'm happy to add anything, I just don't know what to look
>> for...
>>
>
> It looks like you're already good to go, judging by what's now up on
> matplotlib.sf.net.  My change this morning to use "Vera Sans", if available,
> rather than "sans" (which maps to the default sans-serif font on the
> system), seems to have done the trick.
>
> The issues John pointed out -- the fuzzy rectangles, bad arrowhead alignment
> -- seem to just be what graphviz does.  We're not going to get any better
> without being clever.

OK, just let me know if anything is needed, and good luck with the release!

Cheers,

f

On Fri, Jun 20, 2008 at 11:13 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Jun 20, 2008 at 12:54 PM, Fernando Perez <fpe...@gm...> wrote:
>
>> John, do you need anything from BIC?  I'm out for a few hours (car
>> troubles) and will be in and out on Saturday, but likely with a laptop
>> in tow.  So just call me on my cell if anything from bic is needed for
>> the release builds, I'll keep it turned on.
>
> Nothing today -- Sunday I'll need access.  I assumed bic was up more
> or less all the time unless it was being maintained.  Is this right?
>
> Thanks for your help!

Yes, it's meant to be up 24/7.  The mess on Monday/Tuesday was because
I was adding backup drives, so I needed to reboot it multiple times.
That's done now and it should just work.  I meant more if you needed
anything new installed for the release, or any other unusual request.
I don' want to cause a delay for you at the last minute, because I
really would like to see 0.98.1 in debian.

Cheers,

f