matplotlib-devel Mailing List for matplotlib

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> The problem is in draw_line_collection, and it looks
    Darren> complicated.


I wrote that mess :-)  This is the baseclass method for backends that
do not implement draw line collection.  I will fix it for the new
API.  You may want to look over the draw_*_collection methods in
backend bases and see if there are any significant performance boosts
to be had by implementing them in backend_ps.  If you need more
distraction, that is :-)

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> The reason is that TextWithDash has a Text object
    Darren> attribute and delegates most of its methods to that object
    Darren> via __getattr__ and __setattr__. Can anyone tell me why
    Darren> this approach was favored over deriving TextWithDash from
    Darren> Text?

I think __getattr__ and __setattr__ are mostly evil since they lead to
hard to debug code and break things like tab completion in ipython and
object inspection.  I'm +1 for refactoring TextWiithDashes to use
inheritance or otherwise expose the attributes directly.

JDH

On Tuesday 21 March 2006 18:25, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> However, the transform is not being passed to draw_lines,
>     Darren> and so the method works as if the old API were being
>     Darren> used. Is this a bug? Shouldn't the transform be provided
>     Darren> to draw_lines when using the new API?
>
> Yes, it should be passed.  I recommend removing the transform=None
> functionality to *require* the transform be passed.  If it is not,
> then an exception will be raised and it will be easy to track down the
> errant call.

The problem is in draw_line_collection, and it looks complicated.

Here is a bug report related to the output of setp(axes().get_yticklabels()), 
the complaint is that you can set the size but size is not listed.
 
https://sourceforge.net/tracker/index.php?func=detail&aid=1357969&group_id=80706&atid=560720

The reason is that TextWithDash has a Text object attribute and delegates most 
of its methods to that object via __getattr__ and __setattr__. Can anyone 
tell me why this approach was favored over deriving TextWithDash from Text?

Thanks, 
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> However, the transform is not being passed to draw_lines,
    Darren> and so the method works as if the old API were being
    Darren> used. Is this a bug? Shouldn't the transform be provided
    Darren> to draw_lines when using the new API?

Yes, it should be passed.  I recommend removing the transform=None
functionality to *require* the transform be passed.  If it is not,
then an exception will be raised and it will be easy to track down the
errant call.

JDH

On 18/03/06, John Hunter <jdh...@ac...> wrote:
>
>     Jose>   The usual trick in rpms it to require a nest X to test for
>     Jose> pygtk.
>
> I'm not sure I understand this.  We have the following
>
> if BUILD_GTK:
>     try:
>         import gtk
>     except ImportError:
>         print 'GTK requires pygtk'
>         BUILD_GTK=3D0
>     except RuntimeError:
>         print 'pygtk present but import failed'
>
>
> The ImportError is designed to catch the case where pygtk is not
> present and the RuntimeError is designed to warn but not fail if X is
> not present.  I'll do some testing tonight to see if I can isolate
> where this is failing.

  I see what you mean. It makes sense. :-)
  I was talking about using xnest to make that code pass the test.
Clearly your approach is more appropriate. :-)

> JDH

--
Jos=E9 Ab=EDlio

Darren Dale wrote:
> On Tuesday 21 March 2006 17:25, Jeff Whitaker wrote:
>   
>> Darren Dale wrote:
>>     
>>> On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
>>>       
>>>> Jeff Whitaker wrote:
>>>>         
>>>>> I've noticed two problems with the postscript backend with today's
>>>>> svn.  Running the basemap examples and saving to an eps or ps file:
>>>>>
>>>>> 1) dotted lines (the meridians and parallels on the basemap) show up
>>>>> as solid
>>>>>
>>>>> 2) line and text colors are wrong - if a contour plot is created, any
>>>>> lines or text that are then plotted after that show up with the same
>>>>> color as the end of the colormap (blue for a red-->blue colormap).
>>>>>
>>>>> I'll try to build a concise example that shows this later on today.
>>>>>
>>>>> -Jeff
>>>>>           
>>>> contourf_demo.py illustrates these problems - just run it and save the
>>>> output to a postscript file.
>>>>         
>>> This is fixed as of svn 2202.
>>>       
>> Darren:
>>
>> contourf_demo.py still produces the same postscript output for me with
>> svn 2202 (title shows up in red text and the dashed contours are munged).
>>     
>
> It looks fine on my system.
>   
You're right - my bad.  I was looking at the old postscript file, the 
new one is indeed fine.  Thanks Darren.

-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 Tuesday 21 March 2006 17:25, Jeff Whitaker wrote:
> Darren Dale wrote:
> > On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
> >> Jeff Whitaker wrote:
> >>> I've noticed two problems with the postscript backend with today's
> >>> svn.  Running the basemap examples and saving to an eps or ps file:
> >>>
> >>> 1) dotted lines (the meridians and parallels on the basemap) show up
> >>> as solid
> >>>
> >>> 2) line and text colors are wrong - if a contour plot is created, any
> >>> lines or text that are then plotted after that show up with the same
> >>> color as the end of the colormap (blue for a red-->blue colormap).
> >>>
> >>> I'll try to build a concise example that shows this later on today.
> >>>
> >>> -Jeff
> >>
> >> contourf_demo.py illustrates these problems - just run it and save the
> >> output to a postscript file.
> >
> > This is fixed as of svn 2202.
>
> Darren:
>
> contourf_demo.py still produces the same postscript output for me with
> svn 2202 (title shows up in red text and the dashed contours are munged).

It looks fine on my system.

Darren Dale wrote:
> On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
>   
>> Jeff Whitaker wrote:
>>     
>>> I've noticed two problems with the postscript backend with today's
>>> svn.  Running the basemap examples and saving to an eps or ps file:
>>>
>>> 1) dotted lines (the meridians and parallels on the basemap) show up
>>> as solid
>>>
>>> 2) line and text colors are wrong - if a contour plot is created, any
>>> lines or text that are then plotted after that show up with the same
>>> color as the end of the colormap (blue for a red-->blue colormap).
>>>
>>> I'll try to build a concise example that shows this later on today.
>>>
>>> -Jeff
>>>       
>> contourf_demo.py illustrates these problems - just run it and save the
>> output to a postscript file.
>>     
>
> This is fixed as of svn 2202.
>
>   
Darren:

contourf_demo.py still produces the same postscript output for me with 
svn 2202 (title shows up in red text and the dashed contours are munged).

-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 Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
> Jeff Whitaker wrote:
> > I've noticed two problems with the postscript backend with today's
> > svn.  Running the basemap examples and saving to an eps or ps file:
> >
> > 1) dotted lines (the meridians and parallels on the basemap) show up
> > as solid
> >
> > 2) line and text colors are wrong - if a contour plot is created, any
> > lines or text that are then plotted after that show up with the same
> > color as the end of the colormap (blue for a red-->blue colormap).
> >
> > I'll try to build a concise example that shows this later on today.
> >
> > -Jeff
>
> contourf_demo.py illustrates these problems - just run it and save the
> output to a postscript file.

This is fixed as of svn 2202.

However, the transform is not being passed to draw_lines, and so the method 
works as if the old API were being used. Is this a bug? Shouldn't the 
transform be provided to draw_lines when using the new API? 

Jeff Whitaker wrote:
>
> I've noticed two problems with the postscript backend with today's 
> svn.  Running the basemap examples and saving to an eps or ps file:
>
> 1) dotted lines (the meridians and parallels on the basemap) show up 
> as solid
>
> 2) line and text colors are wrong - if a contour plot is created, any 
> lines or text that are then plotted after that show up with the same 
> color as the end of the colormap (blue for a red-->blue colormap).
>
> I'll try to build a concise example that shows this later on today.
>
> -Jeff
>
contourf_demo.py illustrates these problems - just run it and save the 
output to a postscript file.

-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

I've noticed two problems with the postscript backend with today's svn.  
Running the basemap examples and saving to an eps or ps file:

1) dotted lines (the meridians and parallels on the basemap) show up as 
solid

2) line and text colors are wrong - if a contour plot is created, any 
lines or text that are then plotted after that show up with the same 
color as the end of the colormap (blue for a red-->blue colormap).

I'll try to build a concise example that shows this later on today.

-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

Darren Dale wrote:
> As of svn 2181, if you use a *Agg backend or the postscript backend with the 
> new API, the following script will yield a gap in the line, see attached. I 
> guess we need to decide if this is desireable behavior


+1

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Andrew Straw wrote:
> Taking John up on his offer to close some bugs, it looks like Jeff
> closed SF bug 1372239[1], by moving the #include "Python.h" statement
> ahead of the other includes.
>
> As mentioned in the bug report, the "official" Python/C API docs[2]
> state this is the correct behavior.
>
> Unfortunately, on my Debian sarge amd64 system, this "fix" of a compiler
> warning results in a compile error:
>
> gcc: src/_image.cpp
> In file included from /usr/include/png.h:363,
>                  from src/_image.cpp:6:
> /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
> with some additional fixup.
> In file included from /usr/include/png.h:363,
>                  from src/_image.cpp:6:
> /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
> with some additional fixup.
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
> -Wstrict-prototypes -fPIC
> -I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include
> -I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
> -I/usr/local/include -I/usr/include -I.
> -I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include/freetype2
> -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
> -Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
> -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
> -I/usr/include/python2.3 -c src/_image.cpp -o
> build/temp.linux-x86_64-2.3/src/_image.o -DSCIPY=1" failed with exit
> status 1
>
> Googling on this indicates this libpng's setjmp() redefinition may be
> responsible[3]. This looks like a real issue with Python.h and png.h and
> not something we have much control over, at least for the versions
> present in Debian sarge.
>
> I've been playing with various things, but I can't get MPL to compile
> unless I put #include <png.h> before #include "Python.h".  I certainly
> don't consider myself a C include-file-order expert, so perhaps there's
> a way to avert this situation without reverting Jeff's patch.
>
> On the flipside, I went ahead and located several locations in the code
> where Python.h is included after system headers. I'm attaching a patch
> with the fruits of this labor. (Unfortunately, it also includes png.h
> before Python.h, because otherwise I can't get MPL to compile.) I'm not
> committing this because it seems like a rather significant change, and
> I'm not sure what it fixes other than more compiler warnings. And given
> Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
> on anyone.
>
> In fact, I suggest simply reverting the changes in svn 2185 to
> src/_image.cpp, which, apart from a compiler warning, was apparently
> working just fine.
>
> [1] SF bug 1372239
> http://sourceforge.net/tracker/index.php?func=detail&aid=1372239&group_id=80706&atid=560720
> [2] Python/C API docs http://docs.python.org/api/includes.html
> [3] libpng's setjmp() redefinition
> http://lists.debian.org/debian-devel/2005/02/msg00892.html
>
>   
Andrew:  Thanks - it seemed like a harmless change, but I should know 
better.  I have libpng 1.2.8 on my MacOS X system and it worked fine - 
is that newer than the version you have?

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Andrew Straw wrote:

>On the flipside, I went ahead and located several locations in the code
>where Python.h is included after system headers. I'm attaching a patch
>with the fruits of this labor. (Unfortunately, it also includes png.h
>before Python.h, because otherwise I can't get MPL to compile.) I'm not
>committing this because it seems like a rather significant change, and
>I'm not sure what it fixes other than more compiler warnings. And given
>Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
>on anyone.
>
Whoops, forgot the attachment. Here it is.

Taking John up on his offer to close some bugs, it looks like Jeff
closed SF bug 1372239[1], by moving the #include "Python.h" statement
ahead of the other includes.

As mentioned in the bug report, the "official" Python/C API docs[2]
state this is the correct behavior.

Unfortunately, on my Debian sarge amd64 system, this "fix" of a compiler
warning results in a compile error:

gcc: src/_image.cpp
In file included from /usr/include/png.h:363,
                 from src/_image.cpp:6:
/usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
with some additional fixup.
In file included from /usr/include/png.h:363,
                 from src/_image.cpp:6:
/usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
with some additional fixup.
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC
-I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include
-I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
-I/usr/local/include -I/usr/include -I.
-I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/usr/include/python2.3 -c src/_image.cpp -o
build/temp.linux-x86_64-2.3/src/_image.o -DSCIPY=1" failed with exit
status 1

Googling on this indicates this libpng's setjmp() redefinition may be
responsible[3]. This looks like a real issue with Python.h and png.h and
not something we have much control over, at least for the versions
present in Debian sarge.

I've been playing with various things, but I can't get MPL to compile
unless I put #include <png.h> before #include "Python.h".  I certainly
don't consider myself a C include-file-order expert, so perhaps there's
a way to avert this situation without reverting Jeff's patch.

On the flipside, I went ahead and located several locations in the code
where Python.h is included after system headers. I'm attaching a patch
with the fruits of this labor. (Unfortunately, it also includes png.h
before Python.h, because otherwise I can't get MPL to compile.) I'm not
committing this because it seems like a rather significant change, and
I'm not sure what it fixes other than more compiler warnings. And given
Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
on anyone.

In fact, I suggest simply reverting the changes in svn 2185 to
src/_image.cpp, which, apart from a compiler warning, was apparently
working just fine.

[1] SF bug 1372239
http://sourceforge.net/tracker/index.php?func=detail&aid=1372239&group_id=80706&atid=560720
[2] Python/C API docs http://docs.python.org/api/includes.html
[3] libpng's setjmp() redefinition
http://lists.debian.org/debian-devel/2005/02/msg00892.html

Andrew,

I did not get as far as I would have liked this evening, but 
Axes.set_position() is now working again in svn, as is the colorbar.

I'm sorry for the disruption.  This turned out to be more complicated 
than I thought.

To be continued...

Eric

Andrew Straw wrote:
> Eric Firing wrote:
> 
> 
>>John Hunter wrote:
>>
>>
>>>Eric, what is the status of the aspect code w/ respect to the presence
>>>of colorbars, or more generally, multiple axes?  
>>
>>
>>John,
>>
>>Broken!  I assumed it would be OK, but now I see that is not the case.
>>I know why, and I can fix it easily on my next pass.  But this does
>>highlight the question of more complex positioning situations.
> 
> 
> Hi Eric,
> 
> I don't know if you're aware of this, but Axes.set_position() seems to
> have broken in the last day or two, also.
> 
> Cheers!
> Andrew

On Monday 20 March 2006 10:02 pm, John Hunter wrote:
> We've fallen behind in the bugs, features and patches submitted to
> sourceforge.  Over the last couple of days, after letting them
> languish for too long, I've managed to close about 10 or so feature
> requests and patches in the last few days.  There are a lot of
> bug-reports yet to be dealt with.
>
> Some of these are trivial and take just a few minutes time.  For
> example, I just closed the feature request to add a reversed colormap
> for grayscale.  Jeff's recent contribution adds reversed colormaps for
> all colormaps so it was just a simple response pointing to cm.gray_r
>
> It would be a big help if any of you on the devel list could take a
> read through the latest bugs, features and patches and see if you know
> something about them.  We are particularly behind on bug reports
>
>   http://sourceforge.net/tracker/?group_id=80706&atid=560720
>
> with 50 some-odd open bugs.  If you're on the devel list, try taking
> on one or a few of these.  If not, but know enough matplotlib to
> answer these  problems, let me know and I'll add you to the devel list
> so you can handle them.

I've closed quite a few myself over the last week. There seems to be plenty of 
low-hanging fruit.

Darren

We've fallen behind in the bugs, features and patches submitted to
sourceforge.  Over the last couple of days, after letting them
languish for too long, I've managed to close about 10 or so feature
requests and patches in the last few days.  There are a lot of
bug-reports yet to be dealt with.

Some of these are trivial and take just a few minutes time.  For
example, I just closed the feature request to add a reversed colormap
for grayscale.  Jeff's recent contribution adds reversed colormaps for
all colormaps so it was just a simple response pointing to cm.gray_r

It would be a big help if any of you on the devel list could take a
read through the latest bugs, features and patches and see if you know
something about them.  We are particularly behind on bug reports

  http://sourceforge.net/tracker/?group_id=80706&atid=560720

with 50 some-odd open bugs.  If you're on the devel list, try taking
on one or a few of these.  If not, but know enough matplotlib to
answer these  problems, let me know and I'll add you to the devel list
so you can handle them.

Thanks!
JDH

Darren Dale wrote:
....
> As of svn 2181, if you use a *Agg backend or the postscript backend with the 
> new API, the following script will yield a gap in the line, see attached. I 
> guess we need to decide if this is desireable behavior in general, I think it 
> is pretty useful myself.

Darren,

Yes, this is *very* desireable behavior.  It should be in all backends. 
  If it were, then the masked array line plotting could take advantage 
of it, resulting in faster and simpler code.  I can't think of any 
possible disadvantage to this behavior.

Thanks for doing it.

Eric

On Monday 20 March 2006 17:57, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> I havent modified extension code before, and this change
>     Darren> would affect all the *agg backends, so I dont want to
>     Darren> commit before checking.
>
> Here is a quick checklist of things to consider before committing Agg
> changes
>
>   1) makes a plot that you can interact with

check

>   2) passes backend_driver.py screening for Agg

check

>   3) passes unit/memleak_hawaii3.py with no appreciable memory leak

Average memory consumed per loop: -0.1637k bytes (? thats odd.)

>   4) does something useful....

It helped me procrastinate, that's sort of useful.

> If it satisfies these, in my view it is suitable for public consumption.

As of svn 2181, if you use a *Agg backend or the postscript backend with the 
new API, the following script will yield a gap in the line, see attached. I 
guess we need to decide if this is desireable behavior in general, I think it 
is pretty useful myself.

a=arange(21, dtype='d')
a[10]=nan
plot(a, '-o')
savefig('nan_masked.png')