matplotlib-devel Mailing List for matplotlib

[oops, meant on-list ]
On Nov 21, 2007 12:52 PM, Andrew Straw <str...@as...> wrote:
> Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
> Looks like I'll now have to find a way to do the one thing in emacs that
> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
I recently switched to the 'pretty emacs' from
http://peadrop.com/blog/2007/09/17/pretty-emacs-reloaded/
so I could get decent fonts in emacs. I had to tweak my config a bit,
and for M-g I put this by hand in my config file:
(global-set-key "\M-g" 'goto-line) ; standard XEmacs
I can send you my configs which allow me to start this emacs (with
"emacs-snapshot-gtk --enable-font-backend") or plain xemacs in a
reasonably functional state for both.
Cheers,
f

Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
Looks like I'll now have to find a way to do the one thing in emacs that
keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
-Andrew
John Hunter wrote:
> On Nov 21, 2007 1:37 PM, Andrew Straw <str...@as...> wrote:
> 
>> Can you give me a pointer about what exactly you did? Just now, I just
>> discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
>> nice if there was something that automatically showed just tabs and
>> end-of-line whitespace. As it is, I found
>> whitespace-visual-set-whitespace-chars doesn't seem to have quite that
>> level of granularity. Have you configured anything beyond this?
> 
> I ended up adding both of these to .emacs and restarting. Probably
> one or the other would work. For some reason I had to restart, and
> not just eval them in .emacs (??)
> 
> (add-hook 'python-mode-hook
> (lambda ()
> 	 (setq show-trailing-whitespace t)
> 	 ))
> 
> (mapc (lambda (hook)
> (add-hook hook (lambda ()
> (setq show-trailing-whitespace t))))
> '(python-mode-hook))

On Nov 21, 2007 1:37 PM, Andrew Straw <str...@as...> wrote:
> Can you give me a pointer about what exactly you did? Just now, I just
> discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
> nice if there was something that automatically showed just tabs and
> end-of-line whitespace. As it is, I found
> whitespace-visual-set-whitespace-chars doesn't seem to have quite that
> level of granularity. Have you configured anything beyond this?
I ended up adding both of these to .emacs and restarting. Probably
one or the other would work. For some reason I had to restart, and
not just eval them in .emacs (??)
(add-hook 'python-mode-hook
 (lambda ()
	 (setq show-trailing-whitespace t)
	 ))
(mapc (lambda (hook)
 (add-hook hook (lambda ()
 (setq show-trailing-whitespace t))))
 '(python-mode-hook))

John Hunter wrote:
> ( I configured my emacs to detect
> whitespace) and suspect I may have been a trailing whitespace
> contributer,
Can you give me a pointer about what exactly you did? Just now, I just
discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
nice if there was something that automatically showed just tabs and
end-of-line whitespace. As it is, I found
whitespace-visual-set-whitespace-chars doesn't seem to have quite that
level of granularity. Have you configured anything beyond this?
Thanks,
Andrew

Thank you for tracking this down, Mike.
Darren 
On Wednesday 21 November 2007 11:17:04 am Michael Droettboom wrote:
> It seems that the set of callbacks held by the Axis objects was not
> being cleared by cla().
>
> This has been fixed in SVN r4404, and does seem to correct your example
> script. I'd appreciate a sanity check by the other developers to make
> sure that change makes sense -- i.e. that the Axis callbacks don't
> really need to stick around beyond the call to cla() for any reason I'm
> not aware of.
>
> An alternative and more general solution would be to change the
> implementation of CallbackRegistry so it uses a WeakValueDictionary, so
> that it won't keep callback targets alive that have otherwise been
> orphaned. But I can't decide whether that is a good thing or would just
> hide easily fixed errors.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I should have some time today to look at this, unless any other
> > developers already know an obvious solution.
> >
> > Cheers,
> > Mike
> >
> > Darren Dale wrote:
> >> I have been working on an application which is basically a dressed up
> >> version of embedding_in_qt4.py. I have two canvases, one is just a plot,
> >> the other an image with a colorbar, both of which should get updated
> >> about once a second as data is acquired. I noticed that for larger
> >> images, it was taking longer to update the canvases as time went on.
> >>
> >> Attached is a script that demonstrates the problem (png's are also
> >> attached for those who dont have PyQt4). At each timeout, I check the
> >> time, generate a new random array, update the image's data, draw it,
> >> collect garbage, and check the time again. The plot in the upper window
> >> shows how long it took to update the image canvas as a function of
> >> iteration number.
> >>
> >> When the image has a colorbar, the time to update the image canvas
> >> increases linearly, about 0.3 ms/iteration. This can really add up:
> >> after 20,000 iterations it takes about 5-6 seconds to update the image
> >> canvas. If I comment out the line that creates the colorbar (line 64),
> >> the time to update the image canvas does not increase.
> >>
> >> A couple other observations and benchmarks from this test:
> >>
> >> * The intercept for the update time with a color bar was 0.17 seconds
> >> * With the colorbar enabled but garbage collection turned off, the
> >> application slowly consumed memory, roughly 12KB/iteration
> >> * Updating an image without a colorbar took 0.1 seconds per iteration,
> >> and did not increase
> >> * Turning off both garbage collection and the colorbar decreased the
> >> update time to 0.043 seconds, with maybe 1.7 KB/iteration increase in
> >> memory usage.
> >>
> >> I don't know if I'll get a chance to dig any further into this in the
> >> next two weeks. For now, I'll just disable the colorbar in my
> >> application.
> >>
> >> Darren
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> ------------------------------------------------------------------------
> >>- 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
-- 
Darren S. Dale, Ph.D.
dd...@co...

It seems that the set of callbacks held by the Axis objects was not 
being cleared by cla().
This has been fixed in SVN r4404, and does seem to correct your example 
script. I'd appreciate a sanity check by the other developers to make 
sure that change makes sense -- i.e. that the Axis callbacks don't 
really need to stick around beyond the call to cla() for any reason I'm 
not aware of.
An alternative and more general solution would be to change the 
implementation of CallbackRegistry so it uses a WeakValueDictionary, so 
that it won't keep callback targets alive that have otherwise been 
orphaned. But I can't decide whether that is a good thing or would just 
hide easily fixed errors.
Cheers,
Mike
Michael Droettboom wrote:
> I should have some time today to look at this, unless any other 
> developers already know an obvious solution.
> 
> Cheers,
> Mike
> 
> Darren Dale wrote:
>> I have been working on an application which is basically a dressed up version 
>> of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
>> image with a colorbar, both of which should get updated about once a second 
>> as data is acquired. I noticed that for larger images, it was taking longer 
>> to update the canvases as time went on.
>>
>> Attached is a script that demonstrates the problem (png's are also attached 
>> for those who dont have PyQt4). At each timeout, I check the time, generate a 
>> new random array, update the image's data, draw it, collect garbage, and 
>> check the time again. The plot in the upper window shows how long it took to 
>> update the image canvas as a function of iteration number.
>>
>> When the image has a colorbar, the time to update the image canvas increases 
>> linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
>> iterations it takes about 5-6 seconds to update the image canvas. If I 
>> comment out the line that creates the colorbar (line 64), the time to update 
>> the image canvas does not increase.
>>
>> A couple other observations and benchmarks from this test:
>>
>> * The intercept for the update time with a color bar was 0.17 seconds
>> * With the colorbar enabled but garbage collection turned off, the application 
>> slowly consumed memory, roughly 12KB/iteration
>> * Updating an image without a colorbar took 0.1 seconds per iteration, and did 
>> not increase
>> * Turning off both garbage collection and the colorbar decreased the update 
>> time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
>>
>> I don't know if I'll get a chance to dig any further into this in the next two 
>> weeks. For now, I'll just disable the colorbar in my application.
>>
>> Darren
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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

Sorry -- I accidentally used a feature only available in Python 2.4 and 
above.
I have added a fix in SVN r4402. Since I don't have a Python2.3 to test 
with, can you please let me know if that fixes your problem?
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
> 
> I have installed matplotlib via svn on Centos (x86-64 
> python2.3). If I try to import pylab I get
> 
> Python 2.3.4 (#1, May 2 2007, 19:18:17)
> [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
> Type "help", "copyright", "credits" or "license" for more 
> information.
>>>> from pylab import plot, show
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py", 
> line 1, in ?
> from matplotlib.pylab import *
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py", 
> line 94, in ?
> from rcsetup import defaultParams, validate_backend, 
> validate_toolbar
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py", 
> line 12, in ?
> from matplotlib.fontconfig_pattern import 
> parse_fontconfig_pattern
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py", 
> line 21, in ?
> from matplotlib.pyparsing import Literal, OneOrMore, 
> ZeroOrMore, Optional, Regex, \
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
> line 3151, in ?
> commonHTMLEntity = Combine("&" + oneOf("gt lt amp 
> nbsp quot").setResultsName("entity") +";")
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
> line 2849, in oneOf
> symbols.sort(reverse=True)
> TypeError: sort() takes no keyword arguments
> 
> Any pointer would be appreciated.
> 
> Nils
> 
> 
> -------------------------------------------------------------------------
> 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 all,
I have installed matplotlib via svn on Centos (x86-64 
python2.3). If I try to import pylab I get
Python 2.3.4 (#1, May 2 2007, 19:18:17)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from pylab import plot, show
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py", 
line 1, in ?
 from matplotlib.pylab import *
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py", 
line 94, in ?
 from rcsetup import defaultParams, validate_backend, 
validate_toolbar
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py", 
line 12, in ?
 from matplotlib.fontconfig_pattern import 
parse_fontconfig_pattern
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py", 
line 21, in ?
 from matplotlib.pyparsing import Literal, OneOrMore, 
ZeroOrMore, Optional, Regex, \
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
line 3151, in ?
 commonHTMLEntity = Combine("&" + oneOf("gt lt amp 
nbsp quot").setResultsName("entity") +";")
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
line 2849, in oneOf
 symbols.sort(reverse=True)
TypeError: sort() takes no keyword arguments
Any pointer would be appreciated.
Nils

I should have some time today to look at this, unless any other 
developers already know an obvious solution.
Cheers,
Mike
Darren Dale wrote:
> I have been working on an application which is basically a dressed up version 
> of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
> image with a colorbar, both of which should get updated about once a second 
> as data is acquired. I noticed that for larger images, it was taking longer 
> to update the canvases as time went on.
> 
> Attached is a script that demonstrates the problem (png's are also attached 
> for those who dont have PyQt4). At each timeout, I check the time, generate a 
> new random array, update the image's data, draw it, collect garbage, and 
> check the time again. The plot in the upper window shows how long it took to 
> update the image canvas as a function of iteration number.
> 
> When the image has a colorbar, the time to update the image canvas increases 
> linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
> iterations it takes about 5-6 seconds to update the image canvas. If I 
> comment out the line that creates the colorbar (line 64), the time to update 
> the image canvas does not increase.
> 
> A couple other observations and benchmarks from this test:
> 
> * The intercept for the update time with a color bar was 0.17 seconds
> * With the colorbar enabled but garbage collection turned off, the application 
> slowly consumed memory, roughly 12KB/iteration
> * Updating an image without a colorbar took 0.1 seconds per iteration, and did 
> not increase
> * Turning off both garbage collection and the colorbar decreased the update 
> time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
> 
> I don't know if I'll get a chance to dig any further into this in the next two 
> weeks. For now, I'll just disable the colorbar in my application.
> 
> Darren
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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,
On Nov 21, 2007 3:39 PM, Gael Varoquaux <gae...@no...> wrote:
> I have had some problems printing posters on a plot where indeed the
> colors came out a bit wrong. I was told by the staff that it was because
> the conversion RGB->CMYK was handled differently by different printers
> and screens. I don't know if providing and ICC profile would solve the
> problem, but it can't harm.
The ICC profile maps the device-dependent RGB (or CMYK) values stored
in the plot to a device-independent color space (either CIE Lab or the
equivalent XYZ). This independent color space describes *absolute*
color - a point in Lab space is therefore intended to look the same on
any screen or printer. When this profile is combined with a second ICC
profile for the target screen or printer on which the plot is to be
viewed/printed, it allows the color management software to convert the
RGB values in the PDF to the appropriate RGB or CMYK values that will
produce the intended absolute color on the target device.
It is therefore important to realise that both RGB and CMYK are
*relative* color spaces, relative to some device. The R, G and B
values are merely weights mixing together the device's interpretation
of true R, G and B (the same goes for CMYK).
Some problems:
- Devices produce different subsets of the set of all visible colors
(the issue of color gamut). For example, CMYK printers struggle with
highly saturated green. If you make an RGB plot on your LCD screen, a
pure green line with color 'g' or 0x00FF00 may not ever come out the
same way on your printer.
- Matplotlib plots typically use an abstract concept of color. Lines
are usually colored to distinguish them from each other, and
frequently the absolute color is not that important. More importantly,
there is typically no device associated with the input color (as is
the case with images derived from scanners or digital cameras), and
therefore no way to map the RGB relative values to absolute color.
Possible solutions:
- Use colors that are safe for printing and displaying (less saturated colors?).
- Use Lab color, which is absolute. This is cumbersome, and RGB is
much more commonplace and well-understood in plotting packages,
including Matlab.
- Associate a generic ICC profile with the mpl plot, to attach
absolute color values to the RGB values in the plot in a consistent
way. Maybe this is the default in many graphics file formats and
therefore redundant, or maybe it does make a difference specifying it
explicitly, I'm not sure.
> Is this also possible for EPS, or are we stuck with the problem without a
> good solution?
As far as I can tell, you can embed ICC profiles in most graphic file
formats, including PDF, EPS, JPG, PNG, SVG, TIFF, etc.
Regards,
Ludwig

I have had some problems printing posters on a plot where indeed the
colors came out a bit wrong. I was told by the staff that it was because
the conversion RGB->CMYK was handled differently by different printers
and screens. I don't know if providing and ICC profile would solve the
problem, but it can't harm.
Is this also possible for EPS, or are we stuck with the problem without a
good solution? By the way, what is the status of TeX support in PDF. On
the version I have on my box it is not running, but I don't run svn.
Cheers,
Gaël

Ludwig Schwardt wrote:
>> 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?
 >
> PDF/X-3 might be a worthwhile standard to follow for mpl figure output
> (even only as an option). At least embedding ICC profiles is probably
> a good idea.
That seems like a great suggestion (without knowing the details of what 
is really involved). I wonder if that would appease some of the 
publisher's requirements that Eric mentioned. I vaguely recall seeing 
CMYK requirements myself in the past, but I can't dig up any of them. I 
just wonder what *specifically* publishers may require, and whether 
providing an ICC profile in the PDF or converting rgb colors to cmyk on 
output (within matplotlib) is the better way to go.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
> 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?
I don't understand color systems very well, either, but I ran into
this problem when I printed out some color figures recently.
I saved a mpl line plot containing 'r', 'g' and 'b' lines to a PDF
file. The file displayed on-screen as expected, using both Linux
acroread and Mac OS X Preview as viewer. It also printed out as
expected on an HP Color Laserjet via Linux acroread. On the Mac,
however, a straightforward printout resulted in purple instead of blue
lines. The problem disappeared when I selected ColorSync -> Color
Conversion -> In Printer in the print dialog.
When I printed out an OmniGraffle PDF diagram, however, the colors
were messed up using "In Printer" and correct when using "Standard"
color conversion. This forced me to print the color pages in my thesis
containing OmniGraffle diagrams and mpl figures using different
printer settings, which is quite annoying.
There is another option, which makes Linux and Mac PDFs much more
compatible (especially for color), and that is PDF/X-3
(http://en.wikipedia.org/wiki/PDF/X). This subset of PDF forces the
document to include all fonts and color profiles, leaving nothing to
chance. While the file is possibly bigger, it is more likely to
display correctly on all manner of printers and screens. I eventually
converted my Omnigraffle diagrams to PDF/X-3, and now their colors and
shadows appear correct on Linux, while they were psychedelic before.
PDF/X-3 might be a worthwhile standard to follow for mpl figure output
(even only as an option). At least embedding ICC profiles is probably
a good idea.
Regards,
Ludwig

I have been working on an application which is basically a dressed up version 
of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
image with a colorbar, both of which should get updated about once a second 
as data is acquired. I noticed that for larger images, it was taking longer 
to update the canvases as time went on.
Attached is a script that demonstrates the problem (png's are also attached 
for those who dont have PyQt4). At each timeout, I check the time, generate a 
new random array, update the image's data, draw it, collect garbage, and 
check the time again. The plot in the upper window shows how long it took to 
update the image canvas as a function of iteration number.
When the image has a colorbar, the time to update the image canvas increases 
linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
iterations it takes about 5-6 seconds to update the image canvas. If I 
comment out the line that creates the colorbar (line 64), the time to update 
the image canvas does not increase.
A couple other observations and benchmarks from this test:
* The intercept for the update time with a color bar was 0.17 seconds
* With the colorbar enabled but garbage collection turned off, the application 
slowly consumed memory, roughly 12KB/iteration
* Updating an image without a colorbar took 0.1 seconds per iteration, and did 
not increase
* Turning off both garbage collection and the colorbar decreased the update 
time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
I don't know if I'll get a chance to dig any further into this in the next two 
weeks. For now, I'll just disable the colorbar in my application.
Darren

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
Chr...@no...