matplotlib-devel Mailing List for matplotlib

Christopher Barker wrote:
> Jeff,
>
> as you mentioned license as one issue in not using shapely, I thought 
> you might be interested in this:
>
> -------- Original Message --------
> Subject: [Community] Proposal to change Shapely license from LGPL to BSD
> From: Sean Gillies <sgi...@fr...>
>
> I propose that the Shapely license be changed to the 3 clause modified
> BSD used by OWSLib, GeoJSON, Rtree, and WorldMill. I choose LGPL
> orginally to match the GEOS license, but I think consistency across the
> new GIS-Python projects is more important.
> --------
>
>
> As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex 
> for dependency reasons -- there are lot of folks that using ctypes to 
> asve the hassles of compiliation, particularly on Windows (see 
> geoGjango, for instance). But I guess MPL required compilation anyway.
>
> I'm just poking at this 'cause I'd really like to see as little 
> redundancy of python bindings for stuff as possible. WE alrady have 
> geos bound by ogr, shapely (I think geoDjango), and who knows who else.
>
> Oh well, we all need to do what works best for our needs. I guess it's 
> real credit to tools like swig, ctypes and pyrex (and python itself) 
> that anyone would even consider writing their own bindings to something!
>
> -Chris
>
>
>
Chris: I don't consider the pyrex GEOS interface I created for basemap 
a general-purpose binding - it's limited to the only the functionality 
that basemap needs. The ability of pyrex to do loops in C makes it a 
lot faster than the Shapely ctypes interface though. I have 
corresponded with Sean Gillies about this (and the LGPL licensing 
issue), and as a result I think Shapley 2.0 will be based on Pyrex and 
will have a BSD license. Perhaps then I can switch basemap back to 
using it.
Eric mentioned the fact that ctypes often has a hard time finding the 
shared library to load. I view this as a potential support nightmare 
for matplotlib if we use ctypes to interface with external libs, which 
might be installed anywhere. You can't even tell ctypes where to look - 
it's hard-coded into the Shapely __init__ and there's no way I can see 
to override the search path that ctypes uses.
-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

Christopher Barker wrote:
[...]
> As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex for 
> dependency reasons -- there are lot of folks that using ctypes to asve 
> the hassles of compiliation, particularly on Windows (see geoGjango, for 
> instance). But I guess MPL required compilation anyway.
Not just dependency reasons. When I tried to use Jeff's version with 
Shapely, I had to set LD_LIBRARY_PATH=/usr/local/lib for ctypes to find 
my geos library. I couldn't find any cleaner way to do it, and I don't 
consider that acceptable. Is there a clean way to tell ctypes where a 
library is? I was surprised it was not even checking that standard 
location.
Also, pyrex does a *lot* more than ctypes, and I think Jeff will tell 
you he has put that power to good use in his new basemap version.
Eric

Jeff,
as you mentioned license as one issue in not using shapely, I thought 
you might be interested in this:
-------- Original Message --------
Subject: [Community] Proposal to change Shapely license from LGPL to BSD
From: Sean Gillies <sgi...@fr...>
I propose that the Shapely license be changed to the 3 clause modified
BSD used by OWSLib, GeoJSON, Rtree, and WorldMill. I choose LGPL
orginally to match the GEOS license, but I think consistency across the
new GIS-Python projects is more important.
--------
As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex for 
dependency reasons -- there are lot of folks that using ctypes to asve 
the hassles of compiliation, particularly on Windows (see geoGjango, for 
instance). But I guess MPL required compilation anyway.
I'm just poking at this 'cause I'd really like to see as little 
redundancy of python bindings for stuff as possible. WE alrady have geos 
bound by ogr, shapely (I think geoDjango), and who knows who else.
Oh well, we all need to do what works best for our needs. I guess it's 
real credit to tools like swig, ctypes and pyrex (and python itself) 
that anyone would even consider writing their own bindings to something!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Publishers sometimes require electronic figures as tif or eps, and using 
the cymk color system. We do everything in rgb. I don't understand 
color systems well. What would be needed to give mpl the ability to 
produce files using the cymk system?
Thanks.
Eric

On Nov 20, 2007 11:24 AM, Rob Hetland <he...@ta...> wrote:
> 2007年11月20日 18:13:23.074 Python[24184] *** _NSAutoreleaseNoPool():
> Object 0x409e190 of class NSCarbonWindowContentView autoreleased with
> no pool in place - just leaking
I googled this message and found this:
http://www.cocoabuilder.com/archive/message/cocoa/2004/6/25/110592
I think we are going to need some help from a cocoa person.... I CCd
Charlie, who did some of the work on the cocoa agg backend...
JDH

I'm not sure that this consumes enough cycles to warrant the additional 
complexity of doing things differently on a per-backend basis (the 
choice to stick with 8-bit colors would have to be made higher than the 
backend to see any savings). The pcolor images are an exception, since 
that code is common to all backends -- we can do whatever works best.
To see what the "upper limit" on the performance increase would be, I 
modified draw_quad_mesh in the Agg backend so that it doesn't look up or 
multiply colors at all (it just uses a hard-coded 8-bit black always), 
and on the included pcolormesh benchmark, there was no significant 
difference (I ran each 3 times, since the difference is so small):
trunk:
	5.518 fps
	5.530 fps
	5.530 fps
trunk (hard-coded color):
	5.507 fps
	5.567 fps
	5.302 fps
I did notice, however, that draw_quad_mesh makes an unnecessary 
temporary buffer to convert the floating-point colors to 8-bit color. 
Since each color is only converted once, it is slightly faster to do the 
conversion on the fly and avoid the heap alloc/dealloc.
trunk (no alloc):
	5.630 fps
	5.618 fps
	5.617 fps
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> I think I'm a little confused by the question. From the Python
>> perspective, everything in the Agg backend takes floats. Agg
>> actually has color types for both floating point and 8-bit-per-plane
>> colors, though obviously it's converted to 8-bit-per-plane
>> eventually. But, of course, that is done on the fly without much
>> memory copying, so I'm quite surprised that the speed up is
>> significant... Where exactly is this conversion happening, and how
>> are you now avoiding it? (Is this in code that is not checked in,
>> perhaps?)
> 
> I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. 
> Both work directly with agg::rgba8, and can benefit from doing a color 
> table lookup directly in 8-bit space instead of using floats and then 
> converting.
> 
> Eric
> 
>>
>> As for the other backends, it's a mixed bag. PDF, PS and Cairo want
>> floats, SVG wants ints. Personally, I just *like* floats better, as
>> it feels more future proof, even though most people aren't using the
>> extra color resolution now. (Of course, if your plot relies on
>> high-resolution color, you probably need to rethink your plot
>> anyway... ;)
>>
>> Cheers, Mike
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> It made my merge from trunk to branch a little harder than it had to be, 
> too.
> 
> I understand the drive for this, but there is that downside as well.
John, Mike,
Yes, I understand, and I am sorry--but I hope it is one-time pain to 
avoid continuing pin-pricks. If svn ignored trailing whitespace, then 
there would be no problem; I could continue to use an editor that 
removes it, and you could continue to use editors that gratuitously add 
it, and usually it would make no difference. This is not the case, 
however. As it is now, if a file comes into svn without any trailing 
whitespace, and one of you loads it up, maybe makes a trivial change 
after running your cursor through it, and saves it--it will end up with 
a big changeset--lots of trailing whitespace. This is just plain bad. 
All downside, no upside.
Eric
> 
> Cheers,
> Mike
> 
> John Hunter wrote:
>> On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>>> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
>>>> Trailing whitespace introduces noise--sometimes a *lot* of noise--into
>>>> svn changesets. I would very much appreciate it if everyone would try
>>>> to eliminate trailing whitespace before committing any changes to svn.
>>>> (And also eliminate hard tabs--I haven't seen many new ones creeping 
>>>> in,
>>>> but continuing vigilence is appreciated.)
>>
>> While I'm happy to play along ( I configured my emacs to detect
>> whitespace) and suspect I may have been a trailing whitespace
>> contributer, I fear this may be a case where the cure is worse than
>> the disease. As we all make commits to fix the trailing whitespaces,
>> since they are now glaringly ugly in my emacs buffer, I fear we will
>> see significantly more changesets which are whitespace only, than if
>> we simply configured our editors to ignore them.
>>
>> JDH
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

It made my merge from trunk to branch a little harder than it had to be, 
too.
I understand the drive for this, but there is that downside as well.
Cheers,
Mike
John Hunter wrote:
> On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
>>> Trailing whitespace introduces noise--sometimes a *lot* of noise--into
>>> svn changesets. I would very much appreciate it if everyone would try
>>> to eliminate trailing whitespace before committing any changes to svn.
>>> (And also eliminate hard tabs--I haven't seen many new ones creeping in,
>>> but continuing vigilence is appreciated.)
> 
> While I'm happy to play along ( I configured my emacs to detect
> whitespace) and suspect I may have been a trailing whitespace
> contributer, I fear this may be a case where the cure is worse than
> the disease. As we all make commits to fix the trailing whitespaces,
> since they are now glaringly ugly in my emacs buffer, I fear we will
> see significantly more changesets which are whitespace only, than if
> we simply configured our editors to ignore them.
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> 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

On Nov 20, 2007, at 5:09 PM, John Hunter wrote:
> Are you on this box now to verify the problem? There was a bug in
> keypress_demo, because the demo was using 'g' to turn the grid on and
> off and the default key interaction was doing the same, resulting in a
> double toggle and no change. I fixed this bug in svn. I looked
> through the diffs from r3393 to present and cannot find anything which
> explains the difference.
>
> I'm assuming that some of the other key events (eg press 'x' when
> panning to constrain the zoom to the x axis) are also failing. And
> you have the window focus (click on the subplot) when testing...
So I re-installed from the latest SVN, and can re-confirm that 
keypress events do not work. I also noticed that this error message 
shows up (the one you allude to above):
2007年11月20日 18:13:23.074 Python[24184] *** _NSAutoreleaseNoPool(): 
Object 0x409e190 of class NSCarbonWindowContentView autoreleased with 
no pool in place - just leaking
This error message does _not_ appear when I revert back to the 
2007年11月7日 version where keypress events work. I am not sure if they 
are related, but it seems likely. This error shows up when a figure 
is created (I used ipython and debug-annoying, as the error does not 
appear in a debug log):
 >>> figure()
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=640.0, height=480.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
2007年11月20日 18:21:32.073 Python[24293] *** _NSAutoreleaseNoPool(): 
Object 0x180822b0 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=654.0, height=494.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
 <matplotlib.figure.Figure instance at 0x18618e40>
 >>>
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Nov 18, 2007 10:10 PM, Jarrod Millman <mi...@be...> wrote:
>
> On Nov 18, 2007 11:33 AM, Eric Firing <ef...@ha...> wrote:
> > Trailing whitespace introduces noise--sometimes a *lot* of noise--into
> > svn changesets. I would very much appreciate it if everyone would try
> > to eliminate trailing whitespace before committing any changes to svn.
> > (And also eliminate hard tabs--I haven't seen many new ones creeping in,
> > but continuing vigilence is appreciated.)
While I'm happy to play along ( I configured my emacs to detect
whitespace) and suspect I may have been a trailing whitespace
contributer, I fear this may be a case where the cure is worse than
the disease. As we all make commits to fix the trailing whitespaces,
since they are now glaringly ugly in my emacs buffer, I fear we will
see significantly more changesets which are whitespace only, than if
we simply configured our editors to ignore them.
JDH

On Nov 20, 2007 9:15 AM, Rob Hetland <he...@ta...> wrote:
>
> On Nov 20, 2007, at 3:12 PM, John Hunter wrote:
> I am using Mac OS X 10.4.11, python 2.5, and svn versions of numpy
> and mpl. I use Tk/Tcl 8.4.7 that (if I remember right) came with the
> OS. I did not use the simple_plot, but I did try the 'g' trick on a
> normal plot, and tried to run the keypress_demo. So, although I
> didn't do _exactly_ what you are doing, it is essentially the same.
Are you on this box now to verify the problem? There was a bug in
keypress_demo, because the demo was using 'g' to turn the grid on and
off and the default key interaction was doing the same, resulting in a
double toggle and no change. I fixed this bug in svn. I looked
through the diffs from r3393 to present and cannot find anything which
explains the difference.
I'm assuming that some of the other key events (eg press 'x' when
panning to constrain the zoom to the x axis) are also failing. And
you have the window focus (click on the subplot) when testing...
JDH

On Nov 20, 2007, at 3:12 PM, John Hunter wrote:
> I am using tkagg with svn and key events are working. Just to make
> sure we are doing exactly the same thing, I am running
> examples/simple_plot.py with -dTkAgg and clicking in the subplot area
> and then pressing 'g' to toggle the grid on and off. Does this not
> work for you. In your earlier post, you mentioned something about
> carbon. Can you give some more details on your exact environment?
I am using Mac OS X 10.4.11, python 2.5, and svn versions of numpy 
and mpl. I use Tk/Tcl 8.4.7 that (if I remember right) came with the 
OS. I did not use the simple_plot, but I did try the 'g' trick on a 
normal plot, and tried to run the keypress_demo. So, although I 
didn't do _exactly_ what you are doing, it is essentially the same.
I am using Rev: 3393 (Last Changed Date: 2007年06月14日 20:29:49 +0200 
(2007年6月14日)) right now, and it works there.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Nov 20, 2007 7:44 AM, Rob Hetland <he...@ta...> wrote:
>
>
> I sent a note a while ago about a key events being broken. I have a
> bit more information, but still no solution:
>
> - Other mouse-based events seem to work just fine
> - Key events broke somewhere between 2007年11月7日 and 2007年11月10日
I am using tkagg with svn and key events are working. Just to make
sure we are doing exactly the same thing, I am running
examples/simple_plot.py with -dTkAgg and clicking in the subplot area
and then pressing 'g' to toggle the grid on and off. Does this not
work for you. In your earlier post, you mentioned something about
carbon. Can you give some more details on your exact environment?
JDH

I sent a note a while ago about a key events being broken. I have a 
bit more information, but still no solution:
 - Other mouse-based events seem to work just fine
 - Key events broke somewhere between 2007年11月7日 and 2007年11月10日
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Seems like a good idea to me. I'm a little surprised we haven't seen 
this case before. Thanks for the patch -- it's committed in SVN r4391.
Cheers,
Mike
Ben North wrote:
> Hi,
> 
> I think there is a bug in the PostScript backend, when trying to draw a
> polygon with zero linewidth. If you have a zero linewidth, the
> generated PostScript is along the lines of
> 
> 173.31 49.274 m
> 305.066 57.999 l
> 173.533 46.684 l
> closepath
> gsave
> fill
> grestore
> 
> whereas if there is a non-zero linewidth, you get
> 
> 173.31 49.274 m
> 305.066 57.999 l
> 173.533 46.684 l
> closepath
> gsave
> fill
> grestore
> stroke
> 
> The problem is that in the zero-linewidth case, the path is not cleared.
> Therefore, next time there is a 'stroke', that part of the path is
> stroked. In theory, this doesn't matter because its linewidth is zero,
> but the PostScript docs say not completely unambiguously that a
> zero-width line is as thin as the device allows. Ghostview, for
> instance, makes this noticeably non-zero-width and the result looks
> wrong. Besides, it seems cleaner to leave the current path in the same
> state (i.e., empty) in both cases. The below patch, against SVN head,
> seems to fix this.
> 
> Ben.
> 
> - - - - 8< - - - -
> 
> --- SVN--backend_ps.py 2007年11月20日 12:08:51.036996600 +0000
> +++ backend_ps.py 2007年11月20日 12:09:00.100300100 +0000
> @@ -947,6 +947,9 @@
> 
> if self.linewidth > 0:
> write("stroke\n")
> + else:
> + write("newpath\n")
> +
> if cliprect:
> write("grestore\n")
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> 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,
I think there is a bug in the PostScript backend, when trying to draw a
polygon with zero linewidth. If you have a zero linewidth, the
generated PostScript is along the lines of
 173.31 49.274 m
 305.066 57.999 l
 173.533 46.684 l
 closepath
 gsave
 fill
 grestore
whereas if there is a non-zero linewidth, you get
 173.31 49.274 m
 305.066 57.999 l
 173.533 46.684 l
 closepath
 gsave
 fill
 grestore
 stroke
The problem is that in the zero-linewidth case, the path is not cleared.
Therefore, next time there is a 'stroke', that part of the path is
stroked. In theory, this doesn't matter because its linewidth is zero,
but the PostScript docs say not completely unambiguously that a
zero-width line is as thin as the device allows. Ghostview, for
instance, makes this noticeably non-zero-width and the result looks
wrong. Besides, it seems cleaner to leave the current path in the same
state (i.e., empty) in both cases. The below patch, against SVN head,
seems to fix this.
Ben.
- - - - 8< - - - -
--- SVN--backend_ps.py 2007年11月20日 12:08:51.036996600 +0000
+++ backend_ps.py 2007年11月20日 12:09:00.100300100 +0000
@@ -947,6 +947,9 @@
 if self.linewidth > 0:
 write("stroke\n")
+ else:
+ write("newpath\n")
+
 if cliprect:
 write("grestore\n")

Christopher Barker wrote:
> Jeff Whitaker wrote:
> 
>> 1) an external dependency on the GEOS lib (which is LGPL).
>> 
>
> Would it be any better to depend on an existing python binding GEOS? 
> Here's one option:
>
> http://trac.gispython.org/projects/PCL/wiki/Shapely
>
> -Chris
>
>
> 
Chris: I prototyped the code changes with Shapely (which uses ctypes), 
then coded my own pyrex replacement, both to get more speed and to avoid 
depending on ctypes too.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Christopher Barker wrote:
> 
> Jeff Whitaker wrote:
>> 1) an external dependency on the GEOS lib (which is LGPL).
> 
> Would it be any better to depend on an existing python binding GEOS? 
> Here's one option:
> 
> http://trac.gispython.org/projects/PCL/wiki/Shapely
That is what Jeff started with, but it uses ctypes, and adds complexity 
to the licensing and the installation. Therefore he wrote his own pyrex 
binding to the C API of GEOS, which avoids all that and works fine for 
basemap purposes.
Eric
> 
> -Chris
> 
> 

Jeff Whitaker wrote:
> 1) an external dependency on the GEOS lib (which is LGPL).
Would it be any better to depend on an existing python binding GEOS? 
Here's one option:
http://trac.gispython.org/projects/PCL/wiki/Shapely
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...