You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(1) |
3
(8) |
4
(4) |
5
|
6
(2) |
|
7
(1) |
8
(7) |
9
(2) |
10
(3) |
11
(14) |
12
(3) |
13
|
|
14
|
15
(6) |
16
(4) |
17
(3) |
18
(1) |
19
|
20
(1) |
|
21
|
22
|
23
|
24
(1) |
25
|
26
(2) |
27
|
|
28
|
29
|
30
(1) |
31
|
|
|
|
|
From: Martin R. <law...@gm...> - 2007-01-30 10:40:38
|
Hello everyone,
in my programs I need the RectangleSelector. It's quiet easy to use but I
discovered that there isn't a really easy way to switch it off once it is
activated. I thought about the following lines to matplotlib/widgets.py:
#--------------------------------------------------------------------------------------------
#at the beginning of RectangleSelector's __init__:
... docstring ...
self.ax = ax # like before
self.visible = True # like before
self.canvas = ax.figure.canvas # like before
self.connect_id = [] # will contain the connection id's
self.active = True # for activation / deactivation
self.is_active(True)
... snip ...
#and an additional method:
#--------------------------------------------------------------------------------------------
def is_active(self, active):
""" Use this to activate the RectangleSelector from your program.
"""
self.active = active
if active and len(self.connect_id) == 0: # you want to activate and it
# isn't already active
self.connect_id.append(self.canvas.mpl_connect(
'motion_notify_event', self.onmove))
self.connect_id.append(self.canvas.mpl_connect(
'button_press_event', self.press))
self.connect_id.append(self.canvas.mpl_connect(
'button_release_event', self.release))
self.connect_id.append(self.canvas.mpl_connect(
'draw_event', self.update_background))
if not active and len(self.connect_id) != 0: # you want to deactivate
for index in self.connect_id: # and it isn't already inactive
self.canvas.mpl_disconnect(index)
self.connect_id = []
#--------------------------------------------------------------------------------------------
With these changes you can check the following example:
#--------------------------------------------------------------------------------------------
from matplotlib.widgets import RectangleSelector
from pylab import *
def onselect(eclick, erelease):
'eclick and erelease are matplotlib events at press and release'
print 'startposition : (%f,%f)'%(eclick.xdata, eclick.ydata)
print 'endposition : (%f,%f)'%(erelease.xdata, erelease.ydata)
print 'used button : ', eclick.button
def toggle_Selector(event):
print "Key pressed."
if event.key in ["Q", "q"] and toggle_Selector.RS.active:
print " RectangleSelector deactivated."
toggle_Selector.RS.is_active(False)
if event.key in ["A", "a"] and not toggle_Selector.RS.active:
print " RectangleSelector activated."
toggle_Selector.RS.is_active(True)
x = arange(100)/(99.0)
y = sin(x)
fig = figure
ax = subplot(111)
ax.plot(x,y)
toggle_Selector.RS = RectangleSelector(ax, onselect,drawtype='box')
connect("key_press_event", toggle_Selector)
show()
#--------------------------------------------------------------------------------------------
I hope this is usefull to someone,
Martin
PS: Maybe the above example can replace the RectangleSelector's
docstring. I think it's easier to read and understand.
|
|
From: John H. <jdh...@ac...> - 2007-01-26 21:52:17
|
>>>>> "David" == David Huard <dav...@gm...> writes:
David> Hi, unles I'm doing something stupid, setp is buggy.
David> I'm creating a bunch of images using imshow and I want the
David> colormap to be consistent among images. So once they're all
David> drawn, I want to uniformize the color scale. But
>>>> setp(ax.images, clim= [0,1])
David> does not work because it sets vmin to [0,1] and doesn't
David> affect vmax.
David> On the other hand,
>>>> ax.images[0].set_clim([0,1])
The latter should not work. The set_clim function in
cm.ScalarMappable has the signature
def set_clim(self, vmin=None, vmax=None):
Ie, it does not accept the sequence argument, though
ax.images[0].set_clim(*[0,1])
should work.
The setp behavior is more of a bug with set_clim than it is with setp.
For properties to work with setp, we need to have all setters work
with a single argument, and so in this we would want to support a
single non-keyword argument which is a length two sequence mean
"[vmin, vmax]"
I just committed changes to support this so if you have svn access
give it a test drive.
JDH
|
|
From: David H. <dav...@gm...> - 2007-01-26 20:50:53
|
Hi,
unles I'm doing something stupid, setp is buggy.
I'm creating a bunch of images using imshow and I want the colormap to be
consistent among images. So once they're all drawn, I want to uniformize the
color scale. But
>>> setp(ax.images, clim= [0,1])
does not work because it sets vmin to [0,1] and doesn't affect vmax.
On the other hand,
>>> ax.images[0].set_clim([0,1])
works fine.
Should I file a ticket ?
David
In [1]: ax = axes()
In [2]: ax.imshow(rand(10,10))
Out[2]: <matplotlib.image.AxesImage instance at 0x2aaaad22a830>
In [3]: setp(ax.images, 'clim', [0,1])
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most recent
call last)
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in
expose_event(self, widget, event)
282 x, y, w, h = self.allocation
283 self._pixmap_prepare (w, h)
--> 284 self._render_figure(self._pixmap, w, h)
285 self._need_redraw = False
286
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py
in _render_figure(self, pixmap, width, height)
71 def _render_figure(self, pixmap, width, height):
72 if DEBUG: print 'FigureCanvasGTKAgg.render_figure'
---> 73 FigureCanvasAgg.draw(self)
74 if DEBUG: print 'FigureCanvasGTKAgg.render_figure pixmap',
pixmap
75 #agg_to_gtk_drawable(pixmap, self.renderer._renderer, None)
/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py in
draw(self)
390
391 renderer = self.get_renderer()
--> 392 self.figure.draw(renderer)
393
394 def get_renderer(self):
/usr/local/lib/python2.4/site-packages/matplotlib/figure.py in draw(self,
renderer)
567
568 # render the axes
--> 569 for a in self.axes: a.draw(renderer)
570
571 # render the figure text
/usr/local/lib/python2.4/site-packages/matplotlib/axes.py in draw(self,
renderer, inframe)
1105 if len(self.images)<=1 or renderer.option_image_nocomposite
():
1106 for im in self.images:
-> 1107 im.draw(renderer)
1108 else:
1109 # make a composite image blending alpha
/usr/local/lib/python2.4/site-packages/matplotlib/image.py in draw(self,
renderer, *args, **kwargs)
179 def draw(self, renderer, *args, **kwargs):
180 if not self.get_visible(): return
--> 181 im = self.make_image(renderer.get_image_magnification())
182 l, b, widthDisplay, heightDisplay =
self.axes.bbox.get_bounds()
183 renderer.draw_image(l, b, im, self.axes.bbox)
/usr/local/lib/python2.4/site-packages/matplotlib/image.py in
make_image(self, magnification)
122 im.is_grayscale = False
123 else:
--> 124 x = self.to_rgba(self._A, self._alpha)
125 im = _image.fromarray(x, 0)
126 if len(self._A.shape) == 2:
/usr/local/lib/python2.4/site-packages/matplotlib/cm.py in to_rgba(self, x,
alpha)
54 if hasattr(x, 'shape') and len(x.shape)>2: return x
55 x = ma.asarray(x)
---> 56 x = self.norm(x)
57 x = self.cmap(x, alpha)
58 return x
/usr/local/lib/python2.4/site-packages/matplotlib/colors.py in
__call__(self, value, clip)
749 self.autoscale(val)
750 vmin, vmax = self.vmin, self.vmax
--> 751 if vmin > vmax:
752 raise ValueError("minvalue must be less than or equal to
maxvalue")
753 elif vmin==vmax:
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
|
|
From: David H. <dav...@gm...> - 2007-01-24 17:00:36
|
Hi,
this used to work a couple of months ago.
In [1]: from pylab import *
In [2]: mappable=cm.ScalarMappable(cmap=cm.jet)
In [3]: mappable.set_array(array([0,1]))
In [4]: cb=colorbar(mappable, orientation='horizontal')
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent
call last)
/home/huardda/Conferences/Luxembourg/src/<ipython console>
/usr/local/lib/python2.4/site-packages/matplotlib/pylab.py in
colorbar(mappable, cax, **kw)
340 if mappable is None:
341 mappable = gci()
--> 342 ret = gcf().colorbar(mappable, cax = cax, **kw)
343 draw_if_interactive()
344 return ret
/usr/local/lib/python2.4/site-packages/matplotlib/figure.py in
colorbar(self, mappable, cax, **kw)
701 if cax is None:
702 cax, kw = cbar.make_axes(ax, **kw)
--> 703 cb = cbar.Colorbar(cax, mappable, **kw)
704 mappable.add_observer(cb)
705 mappable.set_colorbar(cb, cax)
/usr/local/lib/python2.4/site-packages/matplotlib/colorbar.py in
__init__(self, ax, mappable, **kw)
474 kw['cmap'] = mappable.cmap
475 kw['norm'] = mappable.norm
--> 476 kw['alpha'] = mappable.get_alpha()
477 if isinstance(mappable, ContourSet):
478 CS = mappable
AttributeError: ScalarMappable instance has no attribute 'get_alpha'
Ciao,
David
|
|
From: Rob H. <he...@ta...> - 2007-01-20 21:27:42
|
There is a bug in PolygonInteractor -- the non-existent 'verts' is
reference. Note, there is a verts attribute in some of the inherited
Polygon classes, but not in the Polygon class itself. This is easy
to fix. Just remove the unnecessary line:
self.poly.verts = list(self.poly.verts)
and change all references of poly.verts to poly.xy.
This works fine for me. I found this while creating an interactive
polygon creator, attached for those interested. Feel free to use
this routine however you wish.
|
|
From: Christopher B. <Chr...@no...> - 2007-01-18 21:54:14
|
Hi all, Russell Owen just built an installer for MPL on OS_X for Python2.5, wxPython2.8. To do it, he needed to patch _wxagg.cpp, at line 238 as follows: OLD: wxBitmap *bitmap = new wxBitmap(image); NEW wxBitmap *bitmap = new wxBitmap(*image); Thanks to a hint from Robin Dunn. It now seems to work OK, except that when you use pylab.show() and then click on the toolbar buttons to zoom, etc, the buttons no longer display Also, it doesn't work with Numeric 24.2 either -- I think that's a known issue, but I can't find a note about it at the moment. Is anyone maintaining the wx back-end now? Is MPL working with wxPython 2.8 on other platforms? If anyone wants to try this binary out, it's temporarily at: <http://www.astro.washington.edu/rowen/pythonpackages/Python%202.5/> >>> matplotlib.__version__ '0.87.7' >>> wx.__version__ '2.8.0.1' >>> numpy.__version__ '1.0.1' >>> Numeric.__version__ '24.2' -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... |
|
From: Darren D. <dd...@co...> - 2007-01-17 19:47:57
|
On Monday 15 January 2007 23:37, be...@fi... wrote:
> Hello:
> I am getting an identical error to the error encountered by Charlie Moad
> (posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
> 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
> 0.87.7. my system is:
>
> XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
>
> the error thread is exactly the same:
[...]
> File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
> in TexManager
> dvipngVersion = get_dvipng_version()
> File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
> in get_dvipng_version
> raise RuntimeError('Could not obtain dvipng version')
> RuntimeError: Could not obtain dvipng version
>
> I saw in the message thread that a fix was committed, is this universal?
I think what you are seeing is not exactly the same what Charlie reported.
Charlie observed that texmanager was being loaded, and the dvipng version
checked, when he had usetex : False in his rc options. dvipng is only
required by usetex, and therefore should not have been checked. The fix from
April 2006 fixed that problem. If you have usetex : False in your rc options,
and are still getting this dvipng version error, then it is a bug and I need
to investigate.
However, I suspect that you have set usetex : True in your rc settings, but
haven't installed all the required dependencies. Do you have dvipng
installed, and is it on your PATH? If so, opening a DOS window and
running "dvipng --version" should yield something like:
This is dvipng 1.8 Copyright 2002-2006 Jan-Ake Larsson
dvipng 1.8
kpathsea version 3.5.5
Copyright (C) 2002-2005 Jan-Ake Larsson.
There is NO warranty. You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files
named COPYING and dvipng.c.
Darren
|
|
From: bernski <be...@ro...> - 2007-01-17 18:11:13
|
Hello:
I am getting an identical error to the error encountered by Charlie Moad
(posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
0.87.7. my system is:
XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
the error thread is exactly the same:
Traceback (most recent call last):
File "C:\Python24\test.py", line 33, in -toplevel-
pylab.savefig(filename)#,dpi=100)
File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 813, in
savefig
return fig.savefig(*args, **kwargs)
File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 682, in
savefig
self.canvas.print_figure(*args, **kwargs)
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 456, in print_figure
self.draw()
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 392, in draw
self.figure.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 544, in
draw
for a in self.axes: a.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 1063, in
draw
a.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 561, in draw
tick.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 161, in draw
if self.label1On: self.label1.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 838, in draw
Text.draw(self, renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 340, in draw
bbox, info = self._get_layout(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 187, in
_get_layout
w,h = renderer.get_text_width_height(
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 239, in get_text_width_height
texmanager = self.get_texmanager()
File "C:\Python24\Lib\site-packages\matplotlib\backend_bases.py", line
413, in get_texmanager
from matplotlib.texmanager import TexManager
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 61,
in -toplevel-
class TexManager:
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
in TexManager
dvipngVersion = get_dvipng_version()
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
in get_dvipng_version
raise RuntimeError('Could not obtain dvipng version')
RuntimeError: Could not obtain dvipng version
I saw in the message thread that a fix was committed, is this universal?
many thanks,
bernard
--
View this message in context: http://www.nabble.com/matplotlib-vidpgn-version-error-tf3028905.html#a8415685
Sent from the matplotlib - devel mailing list archive at Nabble.com.
|
|
From: Matt W. <ma...@ma...> - 2007-01-17 04:34:14
|
I want to calculate the intersection of the edge of a marker with a line
running from the center to another marker. I want to do this in order to
decorate the intersection.
I'm using the following code(derived from some code in axes.py) to try
and "divine" the size:
node_sz=sqrt(size*(ax.figure.dpi.get()/72.0))
This is not right. Clearly, I just don't have an idea what I'm doing
(when it comes to calculating the distance along a vector(the along a
vector part is easy) of the size of scatter marker). Anyway, who can
point me in the right direction would be my hero for atleast 2 or 3
hours.
--
Matt
|
|
From: Julius L. <jul...@gm...> - 2007-01-16 17:08:02
|
Hi All, I am new to this list, but a real fan of matplotlib, so I thought I would post this here. I am not sure if a bug report is more appropriate - please let me know! I have recently come across some font loading errors when using matplotlib 0.87.7-2 (and previous versions). I have tracked these errors down to font_manager.py in the matplotlib distribution, which is why I am emailing you guys (I saw your email addresses in the file). My installation details are as follows: I am using python 2.5 with matplotlib 0.87.7-2 on OSX 10.4 both installed with fink ( http://fink.sourceforge.net). I also encountered the same errors I will describe with python 2.3 and an earlier version of matplotlib. I have 2 font path environment variables set TTFPATH=/sw/lib/X11/fonts/applettf, and AFMPATH=/sw/share/texmf-dist/fonts/afm (/sw is where fink installs all files). The crux of the matter is that my TTFPATH directory contains a bunch of .ttf files, while my AFMPATH directory contains subdirectories that themselves contain .afm files. The existing version of font_manager.py does not step through these subdirectories, and thus none of my afm fonts were being included in the search for fonts. Furthermore, there was a problem in parsing binary .ttf files when I was trying to load only ascii-encoded afm files. I tracked this down to the findSystemFonts(fontpaths,fontext) method in font_manager.py and modified it in 2 places to step through subdirectories (with os.walk), and to make sure it only loads the correct font with extension fontext. Below I give a diff of my modifications (each commented with a #JBL), and the existing file: diff font_manager.py font_manager_broken.py 42,43d41 < #JBL import re to match to file extension < import re 209,212c207,208 < #JBL ONLY load if the proper fontext extension < if re.match(fontext,f): < fontfiles[f] = 1 < --- > fontfiles[f] = 1 > 216,225c212,217 < #JBL < #Supposed to be searching recursively here < # for path in fontpaths: < # use os.walk to walk through any directories listed < for root_path in fontpaths: < for path, dirs, file_names in os.walk(root_path): < files = glob.glob(os.path.join(path, '*.'+fontext)) < files.extend(glob.glob(os.path.join(path, '*.'+fontext.upper()))) < for fname in files: < fontfiles[os.path.abspath(fname)] = 1 --- > for path in fontpaths: > files = glob.glob(os.path.join(path, '*.'+fontext)) > files.extend(glob.glob(os.path.join(path, '*.'+fontext.upper()))) > for fname in files: > fontfiles[os.path.abspath(fname)] = 1 > These changes fix all the font loading problems I noticed. I think this is an important fix for those users that have installed fonts in non-standard ways and who use the environment variables to point to them. Do you recommend me contributing this fix to the matplotlib project? Should I make a patch, or contribute via svn? I hope this is helpful, and appreciate any feedback anyone can give. Sincerely, Julius B. Lucks ----------------------------------------------------- http://openwetware.org/wiki/User:Lucks ----------------------------------------------------- |
|
From: Nils W. <nw...@ia...> - 2007-01-16 16:18:30
|
On Tue, 16 Jan 2007 09:38:54 +0800
Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007-01-15 at 10:57 -0800,
> mat...@li... wrote:
>> Hi,
>> =20
>> I cannot install the latest matplotlib on=20
>>openSUSE10.2
>> python setup.py install yields
>> =20
> OK, I've updated _image.cpp to work on 64-bit systems=20
>with new versions
> of Python, but you will need to test it for me.
>=20
> Steve
>=20
Hi Steve,
This is to let you know that I was able to install
matplotlib via latest svn version. Thank you !
Cheers,
Nils
|
|
From: <be...@Fi...> - 2007-01-16 04:40:20
|
Hello:
I am getting an identical error to the error encountered by Charlie Moad
(posted Apr 10, 2006; 08:46am). I am running Python 2.4.4 (#71, Oct 18
2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 with Matplotlib v
0.87.7. my system is:
XP home, SP2 on a Dell XPS600, Dual Core P4 3.40GHz, 1 GB RAM
the error thread is exactly the same:
Traceback (most recent call last):
File "C:\Python24\test.py", line 33, in -toplevel-
pylab.savefig(filename)#,dpi=100)
File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 813, in
savefig
return fig.savefig(*args, **kwargs)
File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 682, in
savefig
self.canvas.print_figure(*args, **kwargs)
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 456, in print_figure
self.draw()
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 392, in draw
self.figure.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 544, in
draw
for a in self.axes: a.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 1063, in draw
a.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 561, in draw
tick.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 161, in draw
if self.label1On: self.label1.draw(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 838, in draw
Text.draw(self, renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 340, in draw
bbox, info = self._get_layout(renderer)
File "C:\Python24\Lib\site-packages\matplotlib\text.py", line 187, in
_get_layout
w,h = renderer.get_text_width_height(
File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 239, in get_text_width_height
texmanager = self.get_texmanager()
File "C:\Python24\Lib\site-packages\matplotlib\backend_bases.py", line
413, in get_texmanager
from matplotlib.texmanager import TexManager
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 61,
in -toplevel-
class TexManager:
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 83,
in TexManager
dvipngVersion = get_dvipng_version()
File "C:\Python24\Lib\site-packages\matplotlib\texmanager.py", line 58,
in get_dvipng_version
raise RuntimeError('Could not obtain dvipng version')
RuntimeError: Could not obtain dvipng version
I saw in the message thread that a fix was committed, is this universal?
many thanks,
bernard
|
|
From: Steve C. <ste...@ya...> - 2007-01-16 01:47:30
|
On Mon, 2007-01-15 at 08:26 -0700, Fernando Perez wrote:
> Those lines also work fine from an ipython prompt:
>
> In [1]: from matplotlib.backends import backend_cairo
>
> In [2]: from matplotlib.backends.backend_gtk import *
They work, but they are not relevant to this problem. Darren has
confused the issue by applying a fix to backend_gtkcairo.py (with no
CHANGELOG comment) while you and I are investigating the problem. So we
are executing the workaround command and are unable to reproduce the
bug.
However, if I put the line
import matplotlib.backends.backend_cairo as be_cairo
back into backend_gtkcairo.py I can now see the problem.
$ python
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
[GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.backends.backend_gtkcairo
$ ipython
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import matplotlib.backends.backend_gtkcairo.py
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most
recent call last)
/home/iuser/<ipython console>
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py
52
53 # a hack to keep old versions of ipython working with mpl
54 if 'IPython.Shell' in sys.modules:
---> 55 new_figure_manager, draw_if_interactive, show =
pylab_setup()
56
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
22 backend_name = 'backend_'+backend.lower()
23 backend_mod =
__import__('matplotlib.backends.'+backend_name,
---> 24 globals(),locals(),[backend_name])
25
26 # Things we pull in from all backends
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
8
9 #from matplotlib.backends import backend_cairo
---> 10 import matplotlib.backends.backend_cairo as be_cairo
11 from matplotlib.backends.backend_gtk import *
12
AttributeError: 'module' object has no attribute 'backends'
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: Darren D. <dd...@co...> - 2007-01-15 19:28:34
|
On Monday 15 January 2007 14:21, Nils Wagner wrote: > On Mon, 15 Jan 2007 14:03:47 -0500 > > Darren Dale <dd...@co...> wrote: > > Nils, > > > > Please don't post to matplotlib when you have problems > >with svn-matplotlib. > > Post to matplotlib-devel. > > > > Darren > > I have removed the build directory. > > The CHANGELOG has a new entry > > 2007-01-15 src/_image.cpp combine buffer_argb32() and > buffer_bgra32() into > a new method color_conv(format) - SC > > I guess my installation problem is connected with that > change. Do you agree ? Yes, that was probably the cause. |
|
From: Nils W. <nw...@ia...> - 2007-01-15 19:21:31
|
On Mon, 15 Jan 2007 14:03:47 -0500
Darren Dale <dd...@co...> wrote:
> Nils,
>=20
> Please don't post to matplotlib when you have problems=20
>with svn-matplotlib.=20
> Post to matplotlib-devel.
>=20
> Darren
=20
I have removed the build directory.
The CHANGELOG has a new entry
2007-01-15 src/_image.cpp combine buffer_argb32() and=20
buffer_bgra32() into
a new method color_conv(format) - SC
I guess my installation problem is connected with that
change. Do you agree ?
Nils
=20
|
|
From: Fernando P. <fpe...@gm...> - 2007-01-15 15:26:40
|
On 1/14/07, Steve Chaplin <ste...@ya...> wrote: > Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My > view is that the lines > from matplotlib.backends import backend_cairo > from matplotlib.backends.backend_gtk import * > work fine when called from the Python prompt. They are using the > absolute package path and are correct and should not be "fixed" to use > relative imports (which is bad style). So if there is a bug it is > elsewhere and from the traceback it looked like ipython is involved. > > The traceback shows that this code is being executed > # a hack to keep old versions of ipython working with mpl > if 'IPython.Shell' in sys.modules: > new_figure_manager, draw_if_interactive, show = pylab_setup() > > which is ipython-specific code. > I don't usually use IPython, but I installed it today and ran a few > simple matplotlib plots with the GTKCairo backend and they worked OK! So > I can't offer more info, perhaps Darren can produce a minimal test case > to isolate the problem. Those lines also work fine from an ipython prompt: In [1]: from matplotlib.backends import backend_cairo In [2]: from matplotlib.backends.backend_gtk import * The point is that for some bizarre reason, /inside/ the ipython/matplotlib initialization, Darren was seeing a problem. It may very well be that the real culprit is ipython, but after looking at the issue I can't see anything, and Darren also tried to understand it and failed. So given this, Darren found a solution by modifying matplotlib. Unless you can suggest a proper fix, I think we'll have for now to live with this, even if it's in principle not ideal. If none of us can figure out the real problem, at least Darren's solution works, so it's better than leaving the bug in place. Cheers, f |
|
From: Steve C. <ste...@ya...> - 2007-01-15 12:04:10
|
On Fri, 2007-01-12 at 08:44 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> I propose this new version of buffer_bgra32 (and > Steve> buffer_argb32). I tested it with cairo and it seems to work > Steve> OK. > > This looks good -- please test it with one of the memleak scripts, eg > a variant of units/memleak_hawaii.py to make sure everything is being > cleaned up properly. If you feel motivated, please port these over to > the other buffer methods. One way to do this cleanly would be to set > up an enum of the agg pixel formats supported by agg::color_conv and > then simply allow the user to pass in the pixel format desired. Ie, > support > > color_conv_rgba32_to_abgr32 > color_conv_rgba32_to_argb32 > color_conv_rgba32_to_bgra32 > > in a single function with a single arg. I've replaced buffer_argb32() and buffer_bgra32() with Image::color_conv(format) and tested it for memory leaks and it seems OK. I think this only affects the cairo backend, since the other backends seem to use rgba and don't need to use a color conversion method. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Darren D. <dd...@co...> - 2007-01-15 11:36:28
|
On Monday 15 January 2007 12:16 am, Steve Chaplin wrote: > On Thu, 2007-01-11 at 00:01 -0700, Fernando Perez wrote: > > On 1/10/07, Steve Chaplin <ste...@ya...> wrote: > > > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > > > > I had to alter the following lines from backend_gtkcairo, from > > > > > > > > import matplotlib.backends.backend_cairo as be_cairo > > > > from matplotlib.backends.backend_gtk import * > > > > > > > > to > > > > > > > > import backend_cairo as be_cairo > > > > from backend_gtk import * > > > > > > > > in order to prevent the following traceback: > > > > > > > > Traceback (most recent call last): > > > > File "/usr/bin/ipython", line 27, in ? > > > > IPython.Shell.start().mainloop() > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 1034, in start > > > > return shell(user_ns = user_ns) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 945, in __init__ > > > > shell_class=MatplotlibMTShell) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 622, in __init__ > > > > on_kill=[mainquit]) > > > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line > > > > 90, in make_IPython > > > > embedded=embedded,**kw) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 506, in __init__ > > > > user_ns,b2 = self._matplotlib_config(name,user_ns) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 397, in _matplotlib_config > > > > from matplotlib import backends > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > > line 55, in ? > > > > new_figure_manager, draw_if_interactive, show = pylab_setup() > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > > line 23, in pylab_setup > > > > globals(),locals(),[backend_name]) > > > > > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkca > > > >iro.py", line 11, in ? > > > > import matplotlib.backends.backend_cairo as be_cairo > > > > AttributeError: 'module' object has no attribute 'backends' > > > > > > The original matplotlib code is correct, you should be editing IPython > > > and correcting their bug! > > > > Well, I'd be delighted to correct the ipython bug, if only I > > understood exactly what the problem was... As far as I can see, that > > code in ipython is simply calling > > > > # Initialize matplotlib to interactive mode always > > import matplotlib > > from matplotlib import backends > > > > inside a function (the _matplotlib_config method). I don't see a bug > > in that, but if you provide some pointers, I'll be happy to fix any > > issues that are on ipython's side of the fence. > > Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My > view is that the lines > from matplotlib.backends import backend_cairo > from matplotlib.backends.backend_gtk import * > work fine when called from the Python prompt. They are using the > absolute package path and are correct and should not be "fixed" to use > relative imports (which is bad style). So if there is a bug it is > elsewhere and from the traceback it looked like ipython is involved. > > The traceback shows that this code is being executed > # a hack to keep old versions of ipython working with mpl > if 'IPython.Shell' in sys.modules: > new_figure_manager, draw_if_interactive, show = pylab_setup() > > which is ipython-specific code. > I don't usually use IPython, but I installed it today and ran a few > simple matplotlib plots with the GTKCairo backend and they worked OK! So > I can't offer more info, perhaps Darren can produce a minimal test case > to isolate the problem. They work ok now, after changing the import statement so that it doesnt rename backend_cairo to be_cairo in the gtkcairo namespace. I can't think of a more minimal example than the one I already provided: starting IPython without the pylab flag and importing matplotlib.backends.backend_gtkcairo. I looked at this for a couple hours last week, and was not able to determine whether it was an IPython bug or a matplotlib bug that is exposed by IPython's magic. I do agree that the absolute path imports are correct and are not the source of the problem. Since a workaround has been committed, I don't think I should spend more time on this issue (unless another problem emerges). Darren |
|
From: Steve C. <ste...@ya...> - 2007-01-15 04:16:46
|
On Thu, 2007-01-11 at 00:01 -0700, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>
> > > I had to alter the following lines from backend_gtkcairo, from
> > >
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > from matplotlib.backends.backend_gtk import *
> > >
> > > to
> > >
> > > import backend_cairo as be_cairo
> > > from backend_gtk import *
> > >
> > > in order to prevent the following traceback:
> > >
> > > Traceback (most recent call last):
> > > File "/usr/bin/ipython", line 27, in ?
> > > IPython.Shell.start().mainloop()
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > > start
> > > return shell(user_ns = user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > > __init__
> > > shell_class=MatplotlibMTShell)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > > __init__
> > > on_kill=[mainquit])
> > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > > make_IPython
> > > embedded=embedded,**kw)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > > __init__
> > > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > > _matplotlib_config
> > > from matplotlib import backends
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 55, in ?
> > > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 23, in pylab_setup
> > > globals(),locals(),[backend_name])
> > >
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > > line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
>
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
>
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My
view is that the lines
from matplotlib.backends import backend_cairo
from matplotlib.backends.backend_gtk import *
work fine when called from the Python prompt. They are using the
absolute package path and are correct and should not be "fixed" to use
relative imports (which is bad style). So if there is a bug it is
elsewhere and from the traceback it looked like ipython is involved.
The traceback shows that this code is being executed
# a hack to keep old versions of ipython working with mpl
if 'IPython.Shell' in sys.modules:
new_figure_manager, draw_if_interactive, show = pylab_setup()
which is ipython-specific code.
I don't usually use IPython, but I installed it today and ran a few
simple matplotlib plots with the GTKCairo backend and they worked OK! So
I can't offer more info, perhaps Darren can produce a minimal test case
to isolate the problem.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: John H. <jdh...@ac...> - 2007-01-12 14:44:58
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> I propose this new version of buffer_bgra32 (and
Steve> buffer_argb32). I tested it with cairo and it seems to work
Steve> OK.
This looks good -- please test it with one of the memleak scripts, eg
a variant of units/memleak_hawaii.py to make sure everything is being
cleaned up properly. If you feel motivated, please port these over to
the other buffer methods. One way to do this cleanly would be to set
up an enum of the agg pixel formats supported by agg::color_conv and
then simply allow the user to pass in the pixel format desired. Ie,
support
color_conv_rgba32_to_abgr32
color_conv_rgba32_to_argb32
color_conv_rgba32_to_bgra32
in a single function with a single arg.
JDH
|
|
From: Rich S. <rsh...@ap...> - 2007-01-12 01:08:59
|
On Thu, 11 Jan 2007, John Hunter wrote: > Hmm, what version of wx are you using? Charlie Moad wrote some > extension code to make the transfer from agg to the wx canvas more > efficient. This looks like the module in question. Can you John, et al.: Running 0.87.7 on my Slackware-11.0 box does not produce the segmentation fault that it does on my Slackware-10.2 box. So, the latter will be upgraded on Saturday and it won't be an issue any more. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Steve C. <ste...@ya...> - 2007-01-12 00:53:28
|
On Thu, 2007-01-11 at 09:56 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> Steve> This is the official definition from the manual:
> Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
> Steve> alpha in the upper 8 bits, then red, then green, then
> Steve> blue. The 32-bit quantities are stored
> Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
> Steve> transparent red is 0x80800000, not 0x80ff0000.)
>
> Steve> What I think this means is: cairo ARGB32 is stored not as 4
> Steve> 8-bit quantities, but as one 32-bit int. On big-endian
> Steve> systems the byte order is ARGB, as you would expect, but on
> Steve> little-endian systems (like a PC) the byte order is BGRA.
>
> Steve> I imagine the reason is that its easier/faster to
> Steve> read/write one 32-bit int than it is to read/write four
> Steve> bytes.
>
> OK, I see the source of my confusion. argb determines the order but
> it doesn't determine whether the most significant bit is first or
> last....
>
> I added a method buffer_bgra32 to the image backend. I'm not sure
> this is the right way to deal with the endianness bit it's easy and
> will probably work. I'll leave it to you guys to fix the cairo
> backend to selectively call the right method and test it across
> platforms, or propose a better solution if you don't like this one...
Thanks, I used the new buffer_bgra32 and now examples/image_demo.py
looks correct (except that sometimes it looks like the pixels right at
the edge of the image might be corrupted).
The backend_cairo.py code does look a little strange, it calls
rows, cols, str_ = im.buffer_bgra32()
and then
X = numx.fromstring (str_, numx.UInt8)
which is used merely to convert the (readonly) string returned from
buffer_bgra32 into a read-write buffer for cairo. If buffer_bgra32
returned a buffer (as its name suggests!) instead of a string this would
not be needed, and it would save copying the image around in memory.
I propose this new version of buffer_bgra32 (and buffer_argb32). I
tested it with cairo and it seems to work OK.
Py::Object
Image::buffer_bgra32(const Py::Tuple& args) {
//"Return the image object as bgra32";
_VERBOSE("RendererAgg::buffer_bgra32");
args.verify_length(0);
int row_len = colsOut * 4;
PyObject* py_buffer = PyBuffer_New(row_len * rowsOut);
if (py_buffer ==NULL)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
unsigned char* buf;
int buffer_len;
int ret = PyObject_AsWriteBuffer(py_buffer, (void **)&buf,
&buffer_len);
if (ret !=0)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
agg::rendering_buffer rtmp;
rtmp.attach(buf, colsOut, rowsOut, row_len);
agg::color_conv(&rtmp, rbufOut, agg::color_conv_rgba32_to_bgra32());
PyObject* o = Py_BuildValue("llN", rowsOut, colsOut, py_buffer);
return Py::asObject(o);
}
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: Darren D. <dd...@co...> - 2007-01-11 21:45:20
|
On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---------------------------------------------------------------------------
> exceptions.AttributeError Traceback (most recent
> call last)
>
> /home/darren/<ipython console>
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
> 54
> 55 # a hack to keep old versions of ipython working with mpl
> 56 if 'IPython.Shell' in sys.modules:
> ---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 58
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
> pylab_setup()
> 24 time.sleep(1)
> 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 26 globals(),locals(),[backend_name])
> 27
> 28 # Things we pull in from all backends
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
> 7 import cairo.gtk
> 8
> ----> 9 import matplotlib.backends.backend_cairo as be_cairo
> 10 from matplotlib.backends.backend_gtk import *
> 11
>
> AttributeError: 'module' object has no attribute 'backends'
I found a workaround, and committed it. I don't understand what the root of
the problem was, probably because the AttributeError at the end of the
Traceback is misleading. Changing this:
import matplotlib.backends.backend_cario as be_cairo
to this:
from matplotlib.backends import backend_cairo
and updating references to be_cairo was all that was needed. The fix is in svn
2979.
Darren
|
|
From: Rich S. <rsh...@ap...> - 2007-01-11 21:26:36
|
On Thu, 11 Jan 2007, Rich Shepard wrote: > When I ran the script with -dWXAgg, it segfaulted. But, when I run with -dWX, it completes and displays the plot. Ergo, there's something wrong with Agg here, I suppose. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Rich S. <rsh...@ap...> - 2007-01-11 21:23:24
|
On Thu, 11 Jan 2007, Rich Shepard wrote: The last output files are attached. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |