matplotlib-devel Mailing List for matplotlib (Page 3)

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> I appreciate the effort. It works fine provided I delete
 Stephen> the line "backend: TkAgg" which I'd had in my
 Stephen> ~/.matplotlibrc file. Otherwise I get a core dump. I
 Stephen> don't recall why I was using this instead of the default
 Stephen> GTKAgg backend.
So you're saying you get a segfault on CVS with tkagg?
Would you be willing to try a few things
 * rm -rf site-packages/matplotlib and your build subdir and do a
 clean build. Do you still see the problem?
 * If so, repeat above but recompile matplotlib setting verbose = True
 in setup.py and rerun. If you get the segfault, post the last
 score or so lines of output
 * send a script that generates the fault.
Thanks!
JDH

Fernando Perez wrote:
> Here's a tarball of current CVS I just made for you (I have ssh dev 
> access, which is up):
I appreciate the effort. It works fine provided I delete the line 
"backend: TkAgg" which I'd had in my ~/.matplotlibrc file. Otherwise I 
get a core dump. I don't recall why I was using this instead of the 
default GTKAgg backend.
> I would tweak the scipy profile to do a 'import scipy as S',
Done. I've been doing this manually in any event.
> John and I (with many others) are working together on an NIH grant 
> proposal which, if it goes through, will give us some funds to work on 
> ipython/pylab/scipy issues for a while.
That would be Way Cool if you can get the money.

Everything Fernando said it exactly right, but your problem is a
common on in pre-CVS matlab. FYI, Here is what is happening. It
appears you have previously plotted some nonpositve data. pre-CVS
matplotlib maintained the data limits as min/max for y and y which it
uses in the autoscaler. CVS matplotlib keeps track of min, max and
min-positive so the log autoscaler can do the right thing.
It also implements lots of other log fixes and optimizations. Once
this last bug is hammered out, we hope that you won't be able to break
matplotlib (in agg, other backends haven't ported the new changes yet)
with log plots, with the possible exception of plotting *all*
nonpositive data. But if do that, you deserve what you get :-)
JDH

Stephen Walton wrote:
> I can't seem to get loglog plots to work. Attached is a dump of ipython 
> showing what I tried and what happened. In case you don't want to wade 
> through this, just try the following:
> 
> hold(False)
> x=arange(25)+1
> loglog(x,x**2) # throws error
> close(1)
> plot(log(x),log(x**2)) # works
> close(1)
> plot(x,x**2)
> plot(log(x),log(x**2)) # throws error
> loglog(x,x**2) # also throws error
This works fine, but only with current CVS. I've been giving John a ton of 
nasty tests for log plotting, and he's fixed most problems. I do still have a 
dataset which causes an abort in the C++ extension code, but he's looking into 
it already. So in short, if you update to CVS, most of your log problems will 
be fixed. And John should have the last remaining nasty killed soon.
Additionally, CVS has dramatic performance improvements in several areas, 
noticeable mostly for plots with many elements.
Best,
f

I can't seem to get loglog plots to work. Attached is a dump of ipython 
showing what I tried and what happened. In case you don't want to wade 
through this, just try the following:
hold(False)
x=arange(25)+1
loglog(x,x**2) # throws error
close(1)
plot(log(x),log(x**2)) # works
close(1)
plot(x,x**2)
plot(log(x),log(x**2)) # throws error
loglog(x,x**2) # also throws error
Here's a result of doing something similar to the above manually, with 
traceback:
freyer:~> ipython -pylab
Python 2.3.4 (#1, Feb 2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.
IPython 0.6.7 -- 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.
 Welcome to pylab, a matplotlib-based Python environment
 help(matplotlib) -> generic matplotlib information
 help(pylab) -> matlab-compatible commands from matplotlib
 help(plotting) -> plotting commands
In [1]: x=arange(10)+1
In [2]: plot(x,x**2)
Out[2]: [<matplotlib.lines.Line2D instance at 0x410f132c>]
In [3]: loglog(x,x**2)
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most 
recent call last)
/home/swalton/<console>
/usr/lib/python2.3/site-packages/matplotlib/pylab.py in loglog(*args, 
**kwargs)
 1869 hold(b)
 1870 else:
-> 1871 draw_if_interactive()
 1872
 1873 hold(b)
/usr/lib/python2.3/site-packages/IPython/genutils.py in wrapper(*args, **kw)
 686 def wrapper(*args,**kw):
 687 wrapper.called = False
--> 688 out = func(*args,**kw)
 689 wrapper.called = True
 690 return out
/usr/lib/python2.3/site-packages/matplotlib/backends/__init__.py in 
draw_if_interactive()
 39 def draw_if_interactive():
 40 draw_if_interactive._called = True
---> 41 __draw_int()
 42 # Flag to store state, so external callers (like ipython) 
can keep track
 43 # of draw calls.
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw_if_interactive()
 56 figManager = Gcf.get_active()
 57 if figManager is not None:
---> 58 figManager.show()
 59
 60
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
show(self)
 275 # anim.py requires this
 276 if sys.platform=='win32' : self.window.update()
--> 277 else: self.canvas.draw()
 278 self._shown = True
 279
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw(self)
 140
 141 def draw(self):
--> 142 FigureCanvasAgg.draw(self)
 143 tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
 144 self._master.update_idletasks()
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py in 
draw(self)
 306 self.renderer = RendererAgg(w, h, self.figure.dpi)
 307 self._lastKey = key
--> 308 self.figure.draw(self.renderer)
 309
 310 def tostring_rgb(self):
/usr/lib/python2.3/site-packages/matplotlib/figure.py in draw(self, 
renderer)
 332
 333 # render the axes
--> 334 for a in self.axes: a.draw(renderer)
 335
 336 # render the figure text
/usr/lib/python2.3/site-packages/matplotlib/axes.py in draw(self, renderer)
 1167 if not self.get_visible(): return
 1168 renderer.open_group('axes')
-> 1169 self.transData.freeze() # eval the lazy objects
 1170 self.transAxes.freeze() # eval the lazy objects
 1171 if self.axison:
ValueError: Cannot take log of nonpositive value
In [4]: plot(log(x),log(x**2))
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most 
recent call last)
/home/swalton/<console>
/usr/lib/python2.3/site-packages/matplotlib/pylab.py in plot(*args, 
**kwargs)
 1957 hold(b)
 1958 else:
-> 1959 draw_if_interactive()
 1960
 1961 hold(b)
/usr/lib/python2.3/site-packages/IPython/genutils.py in wrapper(*args, **kw)
 686 def wrapper(*args,**kw):
 687 wrapper.called = False
--> 688 out = func(*args,**kw)
 689 wrapper.called = True
 690 return out
/usr/lib/python2.3/site-packages/matplotlib/backends/__init__.py in 
draw_if_interactive()
 39 def draw_if_interactive():
 40 draw_if_interactive._called = True
---> 41 __draw_int()
 42 # Flag to store state, so external callers (like ipython) 
can keep track
 43 # of draw calls.
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw_if_interactive()
 56 figManager = Gcf.get_active()
 57 if figManager is not None:
---> 58 figManager.show()
 59
 60
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
show(self)
 275 # anim.py requires this
 276 if sys.platform=='win32' : self.window.update()
--> 277 else: self.canvas.draw()
 278 self._shown = True
 279
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw(self)
 140
 141 def draw(self):
--> 142 FigureCanvasAgg.draw(self)
 143 tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
 144 self._master.update_idletasks()
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py in 
draw(self)
 306 self.renderer = RendererAgg(w, h, self.figure.dpi)
 307 self._lastKey = key
--> 308 self.figure.draw(self.renderer)
 309
 310 def tostring_rgb(self):
/usr/lib/python2.3/site-packages/matplotlib/figure.py in draw(self, 
renderer)
 332
 333 # render the axes
--> 334 for a in self.axes: a.draw(renderer)
 335
 336 # render the figure text
/usr/lib/python2.3/site-packages/matplotlib/axes.py in draw(self, renderer)
 1167 if not self.get_visible(): return
 1168 renderer.open_group('axes')
-> 1169 self.transData.freeze() # eval the lazy objects
 1170 self.transAxes.freeze() # eval the lazy objects
 1171 if self.axison:
ValueError: Cannot take log of nonpositive value
In [5]: close(1)
In [6]: plot(log(x),log(x**2))
Out[6]: [<matplotlib.lines.Line2D instance at 0x4154094c>]
In [7]: close(1)
In [8]: loglog(x,x**2)
Out[8]: [<matplotlib.lines.Line2D instance at 0x4168570c>]
In [9]: Exception in Tkinter callback
Traceback (most recent call last):
 File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
 return self.func(*args)
 File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", 
line 139, in resize
 self.show()
 File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", 
line 142, in draw
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", 
line 308, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line 
334, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1169, 
in draw self.transData.freeze() # eval the lazy objects
ValueError: Cannot take log of nonpositive value

On Thu, 2005年02月10日 at 10:03, Fer...@co... wrote:
> Quoting Perry Greenfield <pe...@st...>:
> 
> > I'm only going from memory but my recollection is that the code to convert
> > arrays to strings is largely written in Python (we took it from Numeric).
> > Perhaps that has changed (for Numeric or numarray). My recollection is
> > that the Python code made use of many array manipulations so it should
> > be faster than element-by-element string conversions, but I also remember
> > thinking that this was an area that could potentially be speeded up by
> > conversion to C. In short, don't assume that the current array2str code
> > is in C (Todd may be able to correct me).
Your impression is correct; array2str was and still is mostly Python.
Todd

Quoting Perry Greenfield <pe...@st...>:
> I'm only going from memory but my recollection is that the code to convert
> arrays to strings is largely written in Python (we took it from Numeric).
> Perhaps that has changed (for Numeric or numarray). My recollection is
> that the Python code made use of many array manipulations so it should
> be faster than element-by-element string conversions, but I also remember
> thinking that this was an area that could potentially be speeded up by
> conversion to C. In short, don't assume that the current array2str code
> is in C (Todd may be able to correct me).
This is actually something which may be worth improving upon for future
numeric(3)/numarray versions. A fast, reliable, _and_ flexible string
formatter for arrays can be extremely useful in many contexts. Something where
you can control the format with precision, the line and item separators, and a
few other things, but with good speed, would be great. In current Numeric, you
can control item but not line (dimension) separators, for example (each line is
bracketed in []).
With such a formatter, this particular problem for PS formatting (and perhaps
others in mpl) could be delegated to the arrays themselves.
Best,
f

Fernando Perez wrote:
> However, I'm afraid to rewrite this in a low-level way, because of the
> numeric/numarray difference. The right approach for this would
> be to generate
> a string representation of the array via numeric/numarray, which
> can do it in
> C. And then, that can be modified to add the m/l end of line
> markers on the
> first/rest lines via a (fast) python string operation.
>
> But since I don't know whether numeric/numarray provide fully consistent
> array2str functions (I only have numeric to test with), I'm a bit
> afraid of
> touching this part. It's also possible that John's backend architectural
> changes end up modifying this, so perhaps such changes are best
> thought about
> after John finishes his reorganization.
>
I'm only going from memory but my recollection is that the code to convert
arrays to strings is largely written in Python (we took it from Numeric).
Perhaps that has changed (for Numeric or numarray). My recollection is
that the Python code made use of many array manipulations so it should
be faster than element-by-element string conversions, but I also remember
thinking that this was an area that could potentially be speeded up by
conversion to C. In short, don't assume that the current array2str code
is in C (Todd may be able to correct me).
Perry

The first matplotlib toolkit has been released.
Matplotlib toolkits are collections of application-specific functions 
that extend matplotlib.
This is hopefully the first of many - additional contributions are 
encouraged!
The basemap toolkit allows matplotlib to plot regularly-space 
latitiude/longitude grids on map projections, including drawing 
coastlines, political boundaries, parallels and meridians. It 
currently supports six map projections (cylindrical equidistant, 
mercator, lambert conformal conic, lambert azimuthal equal area, albers 
equal area and stereographic).
It uses routines from the proj.4 library (http://proj.maptools.org) to 
perform cartographic transformations.
Documentation - http://matplotlib.sourceforge.net/toolkits.html.
Screenshot - http://matplotlib.sourceforge.net/screenshots/plotmap_large.png
Example Code - http://matplotlib.sourceforge.net/screenshots/plotmap.py
Examples for each map projection are included in the source release 
(available at the sf download page 
(http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=142792).
Windows binaries are provided (thanks John!) - but they do not include 
the examples.
Comments/bug reports/suggestions are welcome.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi John,
> Hmm, I thought the point of doing the Skip call
> 
> def _onKeyDown(self, evt):
> """Capture key press."""
> key = self._get_key(evt)
> evt.Skip()
> FigureCanvasBase.key_press_event(self, key)
> 
> would be to prevent the event from being swallowed. So you should be
> able to get those events if you've made a second connection, right?
> 
> If so, what you are arguing for is the ability to get the GUI event
> within the mpl event because this is more convenient than making two
> connections. Is that right?
Yes, it's a matter of convenience. What isn't? If the mpl
event include the GUI event, you can define one MyKeyDown
method, bind it once with
 canvas.mpl_connect('key_press_event',MyKeyDown) 
and have it handle the whole event. To me, this seems cleaner
and easier than having two separate bindings and event handlers
for the mpl and GUI events. I've been doing this, and it's sort 
of ugly to have that many event handlers.
I might be the only one who cares, but I'm binding right-click
over the canvas to show a pop-up menu. I'd like to have similar
functionality in both WX and Tk (WX for new code, but Tk for
legacy apps that currently use Pmw/Blt.graph), and am hoping for
as much overlapping code as possible.
> You can always make the change with guiEvent=None in the
> __init__function so other backends can add it when/if they want it.
> It looks like a good idea to me to add it across backends, though.
Using guiEvent=None in the __init__() is my intention. In fact,
I believe I have this implemented for backend_bases.py,
backend_wx.py, backend_tkagg.py, and backend_gtk.py. I could
not quite figure out how to do this in backend_fltkagg.py or
backend_qtagg.py (any pointers??). I haven't had time to
adequately test this with all event types on wx/tk, and will
probably not get a chance to do so until early next week. 
Again, it's all small changes, basically adding
',guiEvent=guiEvent/None/event/evt' to many argument lists.
--Matt
PS: FWIW, I see a noticeable speed increase with WXAgg on Mac
OSX from matplotlib-0.71 to the cvs version. Excellent!!

 Perry> It might be worth generalizing this to take some optional
 Perry> array/scalar arguments to apply marker by marker scaling
 Perry> (or even independent x/y scaling) as well as overrides to
 Perry> some gc items (e.g. color). This doesn't need to be done
 Perry> right away, but may provide some very useful capability
 Perry> (e.g., error bars could be done as markers if y or x size
 Perry> could be scaled for every x,y location.
What you are describing is basically the draw_*collection methods.
But my experience with them has led me to believe these methods are
not ideal -- for example the i%N indexing of collections is
syntactically convenient but practically rarely useful. In real life,
for a given property, you either want a shared property (marker color)
or you want that property to be different at every pointt (scatter
color with a cmap). And in cases where you have a few properties,
each with lots of segments (read contour) it's fine to create a few
objects rather than have one monolithic object (as Nadia did).
One nice thing about the current draw_marker implementation is that it
is easy (it uses a gc, like all the other drawing methods). Once we
permit scalex and scaley, we'll also want to add rgba (with scalex,
scaley, and rgba as possible len(x) sequences, it could handle
scatters). And then once you allow all these to vary, you might start
thinking about letting every property vary, which is what collections
already do, and which apparently are sufficiently complex that
everyone but agg falls back on the base class implementation, which
while a good bit faster than the bad old days, is still slower than it
should be.
On the subject of speed, the new draw_markers *is* fast. Close to as
fast as you can get, I'd venture, for anti-aliased drawing with alpha
support. I spent a lot of time in the profiler and there isn't much
fat left to be trimmed -- most of the cost is now pure agg, and it's
agg that Maxim helped me optimize by using cached rasters. None of
this precludes your idea, though, because agg is so damned cool that
you can scale and colorize cached rasters pretty cheaply. FYI, here
are my latest benchmark numbers on draw_markers in agg
 0.71 CVS speedup 
 -----------------------------------
 N = 1000 | 0.24s | 0.13s | 1.85x
 N = 5000 | 0.68s | 0.19s | 3.57x
 N = 10000 | 1.17s | 0.28s | 4.19x
 N = 50000 | 5.30s | 0.60s | 8.89x
 N = 100000 | 10.02s | 0.70s | 14.31x
 N = 500000 | 48.81s | 2.32s | 21.03x
As an aside, errorbars, which you mentioned, present a slightly more
complicated case, because the errorbar caplines scale independently of
the x and y error scale.
After discussions with Fernando, who never tires of pointing out the
joys of gnuplot to me :-), I've come to agree that matplotlib ought to
extend the Artists to include "plot items" classees; eg a plot command
should create a LineItem, a scatter command should create a
ScatterItem, an errorbar plot should create and ErrorbarItem. And we
should have, like gnuplot, FuncItems and a few more. This would
satisfy something about the design that has always bothered me --
where should the fundamental plot type functions go? Currently they
are axes methods but this has always stuck me as wrong -- it just
doesn't have the right feel. I think that having high level artists
like ErrorbarItem, which contain the primitives necessary to draw
them, might be the way to go. One could then mix and match various
plot items in different axes and figures.
This might also make the pure OO users happier, who sometimes grumble
that the OO interface is too hard to use. 
JDH

John Hunter wrote:
> def draw_markers(self, gc, path, x, y, transform):
>
It might be worth generalizing this to take some optional array/scalar
arguments to apply marker by marker scaling (or even independent x/y
scaling) as well as overrides to some gc items (e.g. color). This doesn't
need to be done right away, but may provide some very useful capability
(e.g., error bars could be done as markers if y or x size could be scaled
for every x,y location.
Perry

>>>>> "Matt" == Matt Newville <new...@ca...> writes:
 Matt> Hi, I'm working on GUI apps using matplotlib's class library
 Matt> with both WXAgg and TkAgg backends, and am having a
 Matt> love/hate relationship with the FigureCanvase.mpl_connect()
 Matt> methods. These return a platform-neutral, matplotlib-aware
 Matt> Event, which is great for dealing with the Plot canvas, but
 Matt> swallow the native GUI event, complicating working with the
 Matt> GUI toolkit.
Hmm, I thought the point of doing the Skip call
 def _onKeyDown(self, evt):
 """Capture key press."""
 key = self._get_key(evt)
 evt.Skip()
 FigureCanvasBase.key_press_event(self, key)
would be to prevent the event from being swallowed. So you should be
able to get those events if you've made a second connection, right?
If so, what you are arguing for is the ability to get the GUI event
within the mpl event because this is more convenient than making two
connections. Is that right?
You can always make the change with guiEvent=None in the
__init__function so other backends can add it when/if they want it.
It looks like a good idea to me to add it across backends, though.
JDH

Hi, 
I'm working on GUI apps using matplotlib's class library with
both WXAgg and TkAgg backends, and am having a love/hate
relationship with the FigureCanvase.mpl_connect() methods. 
These return a platform-neutral, matplotlib-aware Event, which
is great for dealing with the Plot canvas, but swallow the
native GUI event, complicating working with the GUI toolkit. 
It seems simple enough to include the native event structure as
a member of the the mpl event. That would allow the
backend-specific code to use these backend-specific events. I
think this could be as simple as adding an optional keyword arg
'gui_event' to KeyEvent.__init__, LocationEvent.__init__, and
MouseEvent._init__, and then passing along the native event
objects in the backends. That would simply add a GUI-specific
attribute 'gui_event' to the mpl event, breaking no existing
code or the functionality of the Toolbars, but allow those of us
who want more event information to have it.
Does this change seem reasonable? It would involve many small
changes in backend_bases.py and backends/backend*.py. I'd be
willing to implement it, but am reluctant to step on anyone
else's toes, especially for the different backends....
Thanks,
--Matt Newville <newville @ cars.uchicago.edu>

Hey again,
I was having trouble getting py2exe to include all the libraries in 
matplotlib so I created a very simple GTK + matplotlib program to do 
some testing. The weird thing is that before the reformat + reinstall 
of my Windows desktop this very process was working great.
Included in the attachments is the output of >python setup.py py2exe in 
the file py2exe.out.
Next is the setup.py file just to prove that it should work (setup.py).
Last is the sample application test.py used to demonstrate the py2exe 
failure.
What you will need to do is copy the .dlls from your GTK\bin directory 
to the local copy of the GTK\lib directory (all of this under the dist 
directory that py2exe produces). Also be sure to copy the GTK\etc 
directory there as well and you should be able to get the GTK part up 
and running.
The problem code is the following import statements:
import matplotlib
matplotlib.use('GTKAgg')
import matplotlib.backends.backend_gtkagg
import matplotlib.pylab
I would attach my whole work directory, but that might have been too 
large for the mailing list (the GTK part of it is several MBs alone).
Joe

John Hunter wrote:
> And I think we should seriously consider using enthought traits rather
> than rolling our own. I understand that a C extension doesn't work
> for ipython, but matplotlib has enough extension code that one extra
> piece wouldn't hurt too much. I haven't had much too much luck with
> the GUI component of traits -- it only works with WX currently and
> even then it was flaky on OSX.
> 
> I'm not totally opposed to rolling our own traits-light (whatever we
> call it) because its a basic application of properties, but we would
> probably end up reinventing a fair amount that enthought has already
> done, and my guess is there version will be faster, more feature rich
> and better documented (they have about 100 page user's guide for
> traits2). And we've been accused of failing to build on other
> people's efforts in scipy and chaco, so I think we should be sensitive
> to reinventing another wheel that enthought has put a lot of work
> into.
> 
> The observer pattern would certainly be useful, delegation probably as
> well. 
> 
> We come full-circle back to the same point -- we would like to see a
> free standing traits package outside of envisage and scipy distutils
> that we could simply install w/o having to maintain a separate tree
> that we factor out. This has been mentioned a few times, but I'll
> bring this up on envisage dev again.
> 
> This would also smooth the path toward making matplotlib an envisage
> plugin.
> 
> Sorry if you feel pulled in many directions Abraham -- your work is
> very nice and may be the right way to go. Whether we decide to use
> your properties or enthought traits, the rc framework you've setup
> appears to be readily usable with either.
> 
All well stated and with which I wholeheartedly agree. A lot of work
has gone into traits. I also agree that the gui aspect of it is not
something one would want to use until it was truly made multi-GUI 
supported.
Perry

Hi. Here are a couple thoughts on the problem:
(1) Can we come up with a list of what capabilities we want the config 
library to do? I think it will be difficult to come to a definite plan 
without some sort of specs. Currently the prototype uses traits-lite to 
act as a sentinal to check that the assignment is valid. So if 
assignment-validation is all that is required, it seems a very small 
subsection of the Traits package.
(2) Using the traits package does have several difficulties: (a) 
currently it is difficult to find much written about it (I did not know 
it existed until you pointed it out), (b) it's API is currently changing 
(?), (c) will this require people to download and install SciPy as well? 
Or will it be distributed as a separate library?
(3) I agree. I think the current prototype framework will not need more 
than a couple hours of work to allow either method. Because of this, 
perhaps it's best to go the traits-lite route, until exactly what is 
happening with Traits2 becomes clear .. as long as we can make sure the 
main API doesn't change, it shouldn't affect the end user.
(4) One last thought. Maybe if we can spec out exactly what is required 
of whatever Traits package we use, we can provide a wrapper API so 
either one can be used. We can prefer the Traits package, but if it is 
not used, we can instead use our lite version.
Abe
John Hunter wrote:
>And I think we should seriously consider using enthought traits rather
>than rolling our own. I understand that a C extension doesn't work
>for ipython, but matplotlib has enough extension code that one extra
>piece wouldn't hurt too much. I haven't had much too much luck with
>the GUI component of traits -- it only works with WX currently and
>even then it was flaky on OSX.
>
>I'm not totally opposed to rolling our own traits-light (whatever we
>call it) because its a basic application of properties, but we would
>probably end up reinventing a fair amount that enthought has already
>done, and my guess is there version will be faster, more feature rich
>and better documented (they have about 100 page user's guide for
>traits2). And we've been accused of failing to build on other
>people's efforts in scipy and chaco, so I think we should be sensitive
>to reinventing another wheel that enthought has put a lot of work
>into.
>
>The observer pattern would certainly be useful, delegation probably as
>well. 
>
>We come full-circle back to the same point -- we would like to see a
>free standing traits package outside of envisage and scipy distutils
>that we could simply install w/o having to maintain a separate tree
>that we factor out. This has been mentioned a few times, but I'll
>bring this up on envisage dev again.
>
>This would also smooth the path toward making matplotlib an envisage
>plugin.
>
>Sorry if you feel pulled in many directions Abraham -- your work is
>very nice and may be the right way to go. Whether we decide to use
>your properties or enthought traits, the rc framework you've setup
>appears to be readily usable with either.
>
>JDH
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> If I'm not mistaken, those are the names that the Trait
 Perry> package used originally! They changed the name because of
 Perry> potential confusion with Python properties. Isn't that
 Perry> still an issue?
And I think we should seriously consider using enthought traits rather
than rolling our own. I understand that a C extension doesn't work
for ipython, but matplotlib has enough extension code that one extra
piece wouldn't hurt too much. I haven't had much too much luck with
the GUI component of traits -- it only works with WX currently and
even then it was flaky on OSX.
I'm not totally opposed to rolling our own traits-light (whatever we
call it) because its a basic application of properties, but we would
probably end up reinventing a fair amount that enthought has already
done, and my guess is there version will be faster, more feature rich
and better documented (they have about 100 page user's guide for
traits2). And we've been accused of failing to build on other
people's efforts in scipy and chaco, so I think we should be sensitive
to reinventing another wheel that enthought has put a lot of work
into.
The observer pattern would certainly be useful, delegation probably as
well. 
We come full-circle back to the same point -- we would like to see a
free standing traits package outside of envisage and scipy distutils
that we could simply install w/o having to maintain a separate tree
that we factor out. This has been mentioned a few times, but I'll
bring this up on envisage dev again.
This would also smooth the path toward making matplotlib an envisage
plugin.
Sorry if you feel pulled in many directions Abraham -- your work is
very nice and may be the right way to go. Whether we decide to use
your properties or enthought traits, the rc framework you've setup
appears to be readily usable with either.
JDH

John Hunter wrote"
>
> I don't think we should use the name Trait or HasTrait, since that
> will confuse people into thinking we are using enthought traits
> (Property and HasProperty ?) 
> 
If I'm not mistaken, those are the names that the Trait package used
originally! They changed the name because of potential confusion with
Python properties. Isn't that still an issue?
Perry 

> Which leads me to question one for the backend maintainers: 
> can you support a draw_path method? I"m not sure that GTK and 
> WX can. I have no idea about FLTK, and QT, but both of these 
> are Agg backends so it doesn"t matter. All the Agg backends
> automagically get these for free. I personally would be 
> willing to lose the native GTK and WX backends.
Hmm, it looks to me like WX is technically a 'No', but that
MOVETO and LINETO can be easily emulated (wxDC.Line takes a
start and stop position). That might defeat the purpose, but
it's doable. I don't see how to do ENDPOLY/Fill without knowing
the start of the polygon, which makes it seem a whole lot like
draw_polygon() to me. Perhaps I'm missing something obvious,
but it seems like you'd want to keep some state information (pen
attributes, etc) around?
Anyway, I'm definitely OK with not having the pure WX backend. 
AFAIK, the only consideration for these is speed, and WXAgg is
already much faster than WX. A significant fraction of the time
to create a WXAgg image is in generating the Agg image, so any
work towards speeding up image rendering will improve WXAgg and
all Agg backends. To me, that seems like the way to go!
--Matt Newville <newville @ cars.uchicago.edu>

On Tue, 2005年02月08日 at 08:51 -0600, John Hunter wrote:
> Which leads me to question one for the backend maintainers: can you
> support a draw_path method? I'm not sure that GTK and WX can. I have
> no idea about FLTK, and QT, but both of these are Agg backends so it
> doesn't matter. All the Agg backends automagically get these for
> free. I personally would be willing to lose the native GTK and WX
> backends.
I don't think that GTK can support a draw_path method at the moment, but
when GTK starts to use Cairo it should.
 
> Also, any feedback on the idea of removing GD, native GTK and native
> WX are welcome. I'll bounce this off the user list in any case.
The GTK+ developers have recently announced that Cairo is now a GTK+
dependency
http://www.osnews.com/story.php?news_id=9609
Pango is currently being updated to use Cairo, and later GDK and GTK+
are expected to support/use Cairo. It looks like GTK rendering is in the
process of being improved dramatically, so I'd recommend keeping the
native GTK backend a bit longer to see what happens.
Also it means we can expect all future Linux distributions (that include
GTK+ 2.8 or later) to include Cairo.
Regards
Steve

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> Gee, I'm starting to get the feeling your the first person
 John> who's every actually *used* matplotlib :-(
No, but maybe you're the only one who is stress-testing CVS :-)
This is another CVS bug, introduced when I let the figure store it's
canvas, in response to a request by ChrisBarker to be able to do
 fig.savefig('blah)
which forwards the call on to the canvas.
I was failing to reset the canvas instance for a given figure after a
call to switch_backends (which is what happens when you save a ps fig
from agg).
This is (should be) fixed in CVS.
JDH

Hello,
On Tue, Feb 08, 2005 at 01:39:29PM -0700, Fernando Perez wrote:
> Well, it's true that if there is no easy way to 'reopen' the window in it=
s=20
> exact previous state, Ctrl-q might be a better solution. In gnuplot, an=
=20
> accidental close is just a 'replot' command away, so nothing is ever lost.
we could at least have "q" if show is run from a script
and more use the more complicated key presses only if it
is used interactively. This would be very convenient.
All the best,
Jochen
--=20
http://seehuhn.de/

Hello,
On Tue, Feb 08, 2005 at 02:45:05PM -0600, John Hunter wrote:
> Actually, I think the right way to do it me to save the x and y arrays
> as postscript arrays, and then generate the postscript for loop to
> iterate over the arrays at postscript render time. ...
> The major feature of postscript that the mpl backend
> currently underutilizes, dare I say almost ignores, is that postscript
> is a programming language. ...
=46rom reading parts of the green book ("PostScript Language Program Design=
")
I gathered the impression that the preferred way of generating PostScript
is to do most of the calculations before writing the PostScript.
Some references from the green book:
 p.9: It is better to translate into the PostScript imaging mod-
 el than to maintain another set of graphics primitives
 using the PostScript language for
 p. 80: Remember that the PostScript language is interpreted,
 and that it is a programming language only as one
 aspect of its design. It is best not to defer calculation
 (such as division problems, computing the diameter of a
 circle, or figuring the length of some text) to the inter-
 preter. Instead, perform these calculations on the host
 system as the script is being generated, providing the
 data to the procedures in the format expected by the
 PostScript language and the individual operators used.
 The section "Computation" starting at p. 83 has a similar stance.
The computers matplotlib runs on are probabily many times faster
than the ones built into printers and every PostScript file is
generated only once but potentially printed many times. Therefore
I would rather spend additional CPU cycles in backend_ps.py to
get a compact and computationally simple PostScript file.
Thus I do not think that the "PostScript loop" mentioned above is
a good idea.
> I'll leave it to Jochen to decide on the patch and/or apply it -- on
> my quick read the changes look sensible, and since it passes
> backend_driver, it must be good!
The first version of the patch looked good to me.
Unfortunately I cannot spend any time on this before Thursday.
I suggest that you just apply the patch to CVS and I have
a look at the result on Thursday.
All the best and thank you very much and good night,
Jochen
--=20
http://seehuhn.de/

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Something is remembering state where it shouldn't, and
 Fernando> after a call to savefig() with an eps extension, further
 Fernando> pngs are clobbered into eps. Is this a misuse of the
 Fernando> library on my part? I read the savefig docstring, and I
 Fernando> don't see an error in my usage.
Gee, I'm starting to get the feeling your the first person who's every
actually *used* matplotlib :-(
I'll look into it...
JDH