Re: [matplotlib-devel] Patch for PostScript backend
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 +
> +++ backend_ps.py 2007-11-20 12:09:00.100300100 +
> @@ -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/vse012070mrt/direct/01/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Patch for PostScript backend
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 +
+++ backend_ps.py 2007-11-20 12:09:00.100300100 +
@@ -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/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] events.key broken in latest svn
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] events.key broken in latest svn
On Nov 20, 2007 7:44 AM, Rob Hetland <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] events.key broken in latest svn
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 (Thu, 14 Jun 2007)) 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] events.key broken in latest svn
On Nov 20, 2007 9:15 AM, Rob Hetland <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] events.key broken in latest svn
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 >>> -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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 18, 2007 10:10 PM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > > On Nov 18, 2007 11:33 AM, Eric Firing <[EMAIL PROTECTED]> 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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
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 <[EMAIL PROTECTED]> wrote: >> On Nov 18, 2007 11:33 AM, Eric Firing <[EMAIL PROTECTED]> 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/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
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 <[EMAIL PROTECTED]> wrote: >>> On Nov 18, 2007 11:33 AM, Eric Firing <[EMAIL PROTECTED]> 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/vse012070mrt/direct/01/ >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgba formats
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] events.key broken in latest svn
On Nov 20, 2007 11:24 AM, Rob Hetland <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] rgb versus cmyk
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
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 <[EMAIL PROTECTED]> > > 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/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
Jeff Whitaker wrote: > 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. sure, but if there was an existing general purpose binding that met your needs, you wouldn't need this. > The ability of pyrex to do loops in C makes it a > lot faster than the Shapely ctypes interface though. True -- that is key. If the C lib doesn't provide a "vectorized" API, then you do need to find a way to loop in C yourself. > 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. Cool -- that is open-source collaboration as it should be! > Eric mentioned the fact that ctypes often has a hard time finding the > shared library to load. > 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. Wow! that does seem an oversight. I haven't used ctypes myself -- frankly, I think people are trying to push it a bit too far, it's an excellent solution for calling the occasional system lib, but maybe not so much for writing full-featured wrappers. Pyrex is very cool though. For the moment, I'm struggling with SWIG, and sadly it is a bit of a struggle. However I'm doing 'cause it's used by wxPython, GDAL, and VTK, all of which I want to be able to hack on a bit, so I might as well learn it. Anyway -- basemap is looking better and better! -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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
