matplotlib-devel Mailing List for matplotlib (Page 9)

Eric Firing wrote:
> Nils,
>
> Two more commits, now at 3584, and I think I have it straightened out. 
> I hope so. I'm going offline for 8 hours or so, so if it is not 
> fixed now either someone else will have to do it, or it will have to wait.
>
> Eric
>
> 
 
Hi Eric,
Works for me ! Thank you very much !
Cheers,
 Nils

Nils,
Two more commits, now at 3584, and I think I have it straightened out. 
 I hope so. I'm going offline for 8 hours or so, so if it is not 
fixed now either someone else will have to do it, or it will have to wait.
Eric
Nils Wagner wrote:
> Eric Firing wrote:
>> Nils,
>>
>> I just committed 3582 which reverted numerix to 3573, so please try
>> again. It works for me now.
>>
>> Eric
>>
>>
>> Nils Wagner wrote:
>>> Hi,
>>>
>>> I cannot install matplotlib from latest svn.
>>> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
>>>
>>> Nils
> Hi Eric,
> 
> It doesn't work for me.
> 
> A matplotlib/fft
> A matplotlib/fft/__init__.py
> A matplotlib/npyma
> A matplotlib/npyma/__init__.py
> A matplotlib/linear_algebra
> A matplotlib/linear_algebra/__init__.py
> A matplotlib/mlab
> A matplotlib/mlab/__init__.py
> A matplotlib/mlab/.cvsignore
> A matplotlib/random_array
> A matplotlib/random_array/__init__.py
> A matplotlib/_sp_imports.py
> A matplotlib/ma
> A matplotlib/ma/__init__.py
> A matplotlib/_na_imports.py
> A matplotlib/_nc_imports.py
> Checked out revision 3582.
> 
> cd matplotlib
> rm -rf build
> python setup.py install
> ...
> 
> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
> 
> Nils
> 

Nils,
Rats! I thought I had svn figured out, but I managed to foul it up. 
Ok, stand by, I will try to straighten it out. I know what the 
directory tree should look like, I just don't know exactly how to get 
svn to do what I want it to do. I will have to undo the last fiasco and 
try something else.
Eric
Nils Wagner wrote:
> Eric Firing wrote:
>> Nils,
>>
>> I just committed 3582 which reverted numerix to 3573, so please try
>> again. It works for me now.
>>
>> Eric
>>
>>
>> Nils Wagner wrote:
>>> Hi,
>>>
>>> I cannot install matplotlib from latest svn.
>>> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
>>>
>>> Nils
> Hi Eric,
> 
> It doesn't work for me.
> 
> A matplotlib/fft
> A matplotlib/fft/__init__.py
> A matplotlib/npyma
> A matplotlib/npyma/__init__.py
> A matplotlib/linear_algebra
> A matplotlib/linear_algebra/__init__.py
> A matplotlib/mlab
> A matplotlib/mlab/__init__.py
> A matplotlib/mlab/.cvsignore
> A matplotlib/random_array
> A matplotlib/random_array/__init__.py
> A matplotlib/_sp_imports.py
> A matplotlib/ma
> A matplotlib/ma/__init__.py
> A matplotlib/_na_imports.py
> A matplotlib/_nc_imports.py
> Checked out revision 3582.
> 
> cd matplotlib
> rm -rf build
> python setup.py install
> ...
> 
> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
> 
> Nils
> 

Eric Firing wrote:
> Nils,
>
> I just committed 3582 which reverted numerix to 3573, so please try
> again. It works for me now.
>
> Eric
>
>
> Nils Wagner wrote:
>> Hi,
>>
>> I cannot install matplotlib from latest svn.
>> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
>>
>> Nils
Hi Eric,
It doesn't work for me.
A matplotlib/fft
A matplotlib/fft/__init__.py
A matplotlib/npyma
A matplotlib/npyma/__init__.py
A matplotlib/linear_algebra
A matplotlib/linear_algebra/__init__.py
A matplotlib/mlab
A matplotlib/mlab/__init__.py
A matplotlib/mlab/.cvsignore
A matplotlib/random_array
A matplotlib/random_array/__init__.py
A matplotlib/_sp_imports.py
A matplotlib/ma
A matplotlib/ma/__init__.py
A matplotlib/_na_imports.py
A matplotlib/_nc_imports.py
Checked out revision 3582.
cd matplotlib
rm -rf build
python setup.py install
...
error: package directory 'lib/matplotlib/numerix/mlab' does not exist
 
Nils

Nils,
I just committed 3582 which reverted numerix to 3573, so please try 
again. It works for me now.
Eric
Nils Wagner wrote:
> Hi,
> 
> I cannot install matplotlib from latest svn.
> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
> 
> Nils

On Wed, Jul 18, 2007 at 11:24:09AM -0600, Brian Granger wrote:
> At some level though, configuration is a very different thing than an
> application's runtime API. While they may be related (by exposing
> common functionality), not everything that can be configured would
> appear in a runtime API and vice-versa. Also, some events that need
> to happen when an attribute is changed at runtime can't happen at
> config time as the application might not yet be up and running yet.
Well that easy to sort out. You can put a flag to the traits handler that
simply forbids it as long as the application is not running. Something
like:
 def if_app_running(callback):
 app = get_application() # get_application could be anything that
 # returns the current application
 def modified_callback(self, *args, **kwargs):
 if app.running:
 callback(self, *args, **kwargs)
 return modified_callback
 class ConfigurationObject(HasTraits):
 prompt = String('[%i]')
 @if_app_running
 def _prompt_changed(self):
 do whatever you want here
Gaël

On 7/19/07, Darren Dale <dd...@co...> wrote:
> Damn, that is really cool. So you can generate default config files from the
> MPLConfig instance. We create a default matplotlibrc file from a template,
> setting default backend and numerix values based on what is available on the
> users system. It looks like it would be even easier with your scheme: import
> MPLConfig in setup.py, set the attributes, dump to a default config file.
Yup. If you update, I just committed the last changes I can make to
this for now. I need to switch gears (real work calls...), but this
stuff is mostly functional. It needs a solid cleanup and my quick
tests to be moved into proper doc/unit tests, but I think it's looking
reasonably good. The examples/tests part of the file shows exactly
what you are asking for.
> > In summary, I'm fairly happy with the results, and I think the benefit
> > is enough to convince me of falling in the embrace of the gods of
> > Traits. It seems John is going for Traits as well, so perhaps we can
> > use this little config setup across our systems, and even make it
> > something that others use in the future. I think there's value for
> > end users in having common, uniform configuration systems across the
> > various parts of the scientific python 'ecosystem'.
>
> I agree. It looks really elegant. What about the circular dependencies you
> mentioned in a previous email, is that still a potential problem?
Nope, gone (I think). Since the config file is pure text, it will
never pull the main project's objects in via code. One can allow a
config field to specify a file to execute *later*, once everything is
up and running, but the building of these config objects is going to
be strictly declarative via traits, so we should be OK.
Brian has more experience with those headaches than I, so he may still
spot issues with this, but I think this setup is looking very
reasonable.
Cheers,
f

Hi,
I cannot install matplotlib from latest svn.
error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Nils
 

On Thu, Jul 19, 2007 at 10:42:56PM -0500, Ken McIvor wrote:
> >= Traits =
> >I think we should make a major committment to traits and use them from
> >the ground up. Even without the UI stuff, they add plenty to make
> >them worthwhile, especially the validation and notification features.
> Code readability is also a concern to me -- the experience of reading
> mpl1.py suggests to me that newcomers might find traits a bit too
> "voodoo". I'm confident that the same thing could be achieved using
> Python properties to validate attributes. 
Well, I am a stupid noob as far as coding goes (hell, I am an
experimentalist, I work with a soldering iron and a mill, not a
computer), but I can tell you I find traited code very readable. It is
just that the API is very well done. It could have indeed been a
nightmare.
I think Python properties would be harder to read. Traits simply look
like type checking (that's prety much what it is, though), so people get
it really quickly. Besides, the manual is very well written.
But I am biased, Traits have gotten my out of a difficult moment, not
long ago, and I fell in love with them.
My 2 cents,
Gaël

Wow, lots of food for thought. Thanks John!
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
>
> = Objects that talk to the backend "primitives" =
>
> Have just a few, fairly rich obects, that the backends need to
> understand. Clear candidates are a Path, Text and Image, but despite
> their names, don't confuse these with the eponymous matplotlib
> matplotlib Artists, which are higher level than what I'm thinking of
> here (eg matplotlib.text.Text does *a lot* of layout, and this would
> be offloaded ot the backend in this conception of the Text primitive).
This sounds like a great idea. I think you should consider making 
transformations a first-class citizen as well, to improve code 
readability. Some of us have to think really hard to translate 
"[[width, 0, 0], [0, -height, height], [0, 0, 1]]" into English! ;-)
> = Where do the plot functions live? =
>
> In matplotlib, the plot functions are matplotlib.axes.Axes methods and
> I think there is consensus that this is a poor design. Where should
> these live, what should they create, etc?
I propose that the plot functions be replaced by plot classes that 
implement whatever the new Artist API ends up being. I'm not sure 
where I'd put them (grouped into modules by type?) or how they should 
be added to an Axes (add_artist()?).
> = How much of an intermediate artist layer do we need? =
>
> Do we want to create high level objects like Circle, Rectangle and
> Line, each of which manage a Path object under the hood?
Yes, but I don't think they should be subclassed from Path. I found 
that rather confusing because I read that as "Rectangle is-a Path".
> = Z-ordering, containers, etc =
>
> Peter has been doing a lot of nice work on z-order and layers for
> chaco, stuff that looks really useful for picking, interaction, etc...
> We should look at this approach, and think carefully about how this
> should be handled.
Is there somewhere in particular that I can look to see what Peter's 
been working on? Enthought's svn repositories?
> I also plan to use the SWIG agg wrapper, so this gets rid of 
> _backend_agg. If we can enhance the SWIG agg wrapper, we can also 
> do images through there, getting rid of _image.cpp. Having a fully 
> featured, python-exposed agg wrapper will be a plus in mpl and 
> beyond. But with the agg license change, I'm open to discussion of 
> other approaches.
Have you looked into Fredrik Lundh's aggdraw module? Apart from not 
yet supporting image drawing/blitting, I think it might do the 
trick. I've attached an aggdraw version your mpl1.py that I wrote as 
proof of concept. I opted to start hacking instead of installing the 
traits package, so there's just a basic demo of the renderer for now.
Since aggdraw can work natively with the Python Imaging Library we'd 
be able to support every raster format under the sun *and* save those 
images to Python strings. That would make the webapps people very 
happy.
> I want to do away with *all* GUI extension code.
Hurrah!
> This means someone needs to figure out how to get TkInter talking 
> to a python
> buffer object or a numpy array.
I think PIL's ImageTk module would do the trick for converting RGBA - 
 > PIL Image -> Tk Bitmap/PhotoImage.
> = Traits =
>
> I think we should make a major committment to traits and use them from
> the ground up. Even without the UI stuff, they add plenty to make
> them worthwhile, especially the validation and notification features.
I hate to be the first one to disagree, but here goes: traits give me 
the heebie-jeebies. I agree that matplotlib 1.0/2.0 needs to 
validate all user-settable parameters. However, I'm concerned about 
the development overhead that might result from making traits as a 
core dependency. Code readability is also a concern to me -- the 
experience of reading mpl1.py suggests to me that newcomers might 
find traits a bit too "voodoo". I'm confident that the same thing 
could be achieved using Python properties to validate attributes. 
Change notification is another matter, granted, but I think that a 
major rewrite will provide the opportunity to better design for those 
situations.
Ken

On Thursday 19 July 2007 8:02:53 pm Fernando Perez wrote:
> - Consider a file called mpl.conf:
> # Top-level
> backend = "TkAgg"
> interactive = False
>
> # Things that can only be set at init time, they become read-only
> afterwards 
> [InitOnly] 
> numerix = "numpy"
[...]
> - Then, consider the following bit of Python code:
[...]
> This purely declarative code incorporates:
>
> * The types of all parameters acceptable in the file
> * The nesting hierarchy for subobjects
> * The default values hardcoded in the app if users don't provide any
> * The valid values for those which are choices.
>
> An 'application' is defined via:
>
> class App(object):
> """A trivial 'application' class to be initialized.
> """
> def __init__(self,configClass,conf_filename):
> conf = mkConfigObj(conf_filename)
> self.rc = configClass(conf)
>
>
> mpl = App(MPLConfig,'mpl.conf')
>
> This makes the App object load the .conf file, immediately giving
> errors if any of the validation constraints implicit in the traits
> spec are not met. The resulting mpl.rc object can be printed,
> manipulated, modified (for non-read-only sections), even edited with a
> GUI (limited at the moment to WX and not really working for
> sub-sections, though that's easily fixed). For example:
>
> In [159]: mpl.rc
> Out[159]:
> # Dump of MPLConfig
>
> backend = 'TkAgg'
> interactive = False
>
> [InitOnly]
> numerix = 'numpy'
>
> [lines]
> linewidth = 2.0
> linestyle = '-'
>
> [figure]
> edgecolor = 'white'
> figsize = [6.4000000000000004, 4.7999999999999998]
> dpi = 100
> facecolor = 0.75
>
> [[subplot]]
> top = 0.90000000000000002
> right = 0.90000000000000002
> left = 0.125
> bottom = 0.10000000000000001
>
> These objects are automatically self-representable in a valid
> roundtrip format.
Damn, that is really cool. So you can generate default config files from the 
MPLConfig instance. We create a default matplotlibrc file from a template, 
setting default backend and numerix values based on what is available on the 
users system. It looks like it would be even easier with your scheme: import 
MPLConfig in setup.py, set the attributes, dump to a default config file.
[...]
> In summary, I'm fairly happy with the results, and I think the benefit
> is enough to convince me of falling in the embrace of the gods of
> Traits. It seems John is going for Traits as well, so perhaps we can
> use this little config setup across our systems, and even make it
> something that others use in the future. I think there's value for
> end users in having common, uniform configuration systems across the
> various parts of the scientific python 'ecosystem'.
I agree. It looks really elegant. What about the circular dependencies you 
mentioned in a previous email, is that still a potential problem?
Darren

On Thu, Jul 19, 2007 at 12:18:21PM -0500, John Hunter wrote:
> = Z-ordering, containers, etc =
> 
> Peter has been doing a lot of nice work on z-order and layers for
> chaco, stuff that looks really useful for picking, interaction, etc...
> We should look at this approach, and think carefully about how this
> should be handled. Paul may be a good candidate for this, since he
> has been working recently on the picking API.
I'm certainly interested in any advice on the best way to implement 
canvas objects.
	- Paul

On Thu, Jul 19, 2007 at 03:31:26PM -0700, Christopher Barker wrote:
> > In matplotlib, the plot functions are matplotlib.axes.Axes methods and
> > I think there is consensus that this is a poor design.
> 
> Well, the OO interface has always felt a bit clunky to me, but I'm not 
> sure where else plot functions could go -- I'd love to hear ideas, though.
With a few primitives (add_artist, set_property, get_property, x/y axis,
labels, grids), all of the plot types can be implemented identically
outside of the axes class. Most of them are implemented that way already,
and only need to change ax.plot to plot(self=ax). Default to gca() and
you have pylab.
> > Also, everything should be numpy enabled,
> > and the sequence-of-python-tuples approach that many of the
> > collections take should be dropped.
> 
> who hoo!
> 
> However, numpy doesn't handle "ragged" arrays well. I wonder if there's 
> a good way to implement those, so that transforms can be done 
> numpy-efficient.
Can you do it with simple vectors, and an index vector indicating where
the different objects start? The transformations can run simply
through the sets of indices without bothering about object boundaries.
The path objects can use vector slices, which IIRC, are simply views
into the vectors and don't require copying the data. It would be
easy enough to hide this in a class so that it acts like a sequence
of lines to the caller.
 - Paul

John Hunter wrote:
>>> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
>> 4X4 -- is there much cost?
> 
> The potential cost is not in the 3x3 vs 4x4, but in the extra row of
> junk data you would store in the data matrix, which is N extra values
> for plotting N points . The matrix multiplication would be 3x3 * 3xN
> vs 4x4 * 4xN , so there would be a cost in memory and performance.
I'm not sure this is the case -- there are still going to have to be
transforms which aren't 4x4 projections (e.g. polar transforms), so
presumably we keep the 2D affine transform as another case, just the one
that gets used 99% of the time. Perhaps it could even subclass the 4x4
projection transform but optimize needing 4D data on backends where this
is an optimization (all the 2D ones) and keep the 3rd and 4th dimensions
when sending to OpenGL or whereever. Or am I missing something?
My biggest mental stumbling block (which is IIUC is already solved for
mpl0, so it is really just my stumbling block) doing placements like
"OK, here are 10 million data points which need to go through this polar
transform, but also, plot this text such that the anchor is 2 pixels
above the 439th point." mpl can clearly do this by keeping a copy of the
transform before it pushes it off to the backend, but this gets tricker
when you need reference coordinates that only the backend can compute,
such as relative to rendered strings. Perhaps an explicit multipass
system is necessary? (This whole kettle of fish is actually the part of
mpl that I currently don't understand at all, so I'm probably
mischaracterizing the situation.)
Anyhow this is exciting, and I wish I had more time to jump in and help
code...

(oops, I meant to send that to the matplotlib list)
Hi,
I was looking at the transform code recently..
On Thu, July 19, 2007 7:31 pm, John Hunter wrote:
> The potential cost is not in the 3x3 vs 4x4, but in the extra row of
> junk data you would store in the data matrix, which is N extra values for
> plotting N points . The matrix multiplication would be 3x3 * 3xN vs 4x4 *
> 4xN , so there would be a cost in memory and performance.
I'm not so clear about what you are planning for the transforms and
matrices in mpl1, especially in relation to the 4x4 to 3x3 matrices.
Couldn't you just pass around 4x4 matrices, but then truncate them to 3x3
right before you apply them? If you are passing any affine transforms to
the backend, you are going to be breaking apart your matrix anyway. (agg
accepts the affine transform like tuple a,b,c,d,tx,ty)
Also, my impression is that the matrix multiplication strategy in numpy is
going to be slow if it happens a lot. I am guessing what you are going to
do is do a matrix mult once just for the nonlinear transform when show()
is called, but it will not happen for redraws (due to panning etc). When
panning, only the affine part is changed, and the backend takes care of
that efficiently (in C, for agg). Therefore the matrix mult is very rare.
Is that correct?
Allan

On 7/19/07, Eric Firing <ef...@ha...> wrote:
> Please let me know if you are still online (I know it is very late in
> Germany); otherwise I may have to revert your changes until the problems
> are fixed.
Eric, since it looks like you have not reverted these changes, I went
ahead and did so because svn remains broken. Norbert, thanks for
taking the lead on numpifying some of the modules, but as Eric said,
we plan on keeping the numerix layer for sometime since a lot of
external code depends on it. Apparently your changes broke the
numerix layer, but the rest of mpl still depended on it, so I had to
revert them. I had hoped to do an svn diff between HEAD and 3573 (the
last revision before your numerix changes) and manually remove all the
changes in the diff file to just the lib/matplotlib/numerix so the
rest of your and others work would not be lost, and then apply that
diff against 3573. Unfortunately, because you also changed many of
the numerix imports which would be broken against a working numerix, I
had to simply revert to all the python code to 3573 (src code changes
should be OK)
Also, the style we agreed (in the usual case) to use
 import numpy as npy
 npy.ones(something)
rather than
 from numpy import ones.
This is also a good idea to remind developers to run simple demos and
examples/backend_driver.py after non-trivial commits. I usually run
examples/simple_demo.py and the examples/backend_driver.py. . The
latter I don't always run to completion, but if it runs for a while I
feel OK with a commit
Thanks,
JDH

On 7/18/07, Brian Granger <ell...@gm...> wrote:
> > 3. Traits. We (Brian and I) have gone back and forth a lot on Traits,
> > and we've come very close to just making them a dependency. The only
> > real issue holding us back is that ipython so far has exactly *zero*
> > extension code, which is a plus in terms of ease of
> > installation/deployment. Having said that, as far as extension code
> > is concerned, Traits is light and clean, and nowhere near the kinds of
> > complexities that MPL deals with. But since anything is more than
> > zero, it is a bit of an issue for us. We may tip over though, I'm
> > just stating what our reasoning so far has been.
> >
> > In terms of Traits, point (2) above makes them even more attractive.
> > The delegation aspect of Traits is a very appealing way of combining
> > validation with additional action for the runtime modification of an
> > object. For example:
> >
> > ipython.color_scheme = "foo"
> >
> > If color_scheme were a Trait, the above could simply:
> >
> > a) validate that "foo" was acceptable as a value
> > b) trigger the chain of other trait updates (dependent color schemes
> > for exceptions, prompts, etc).
>
> At some level though, configuration is a very different thing than an
> application's runtime API. While they may be related (by exposing
> common functionality), not everything that can be configured would
> appear in a runtime API and vice-versa. Also, some events that need
> to happen when an attribute is changed at runtime can't happen at
> config time as the application might not yet be up and running yet.
[ Brian, I know we already talked about this, but I'm putting the full
reasoning here because I'm interested in this discussion going beyond
ipython to mpl and possibly other tools in this little 'universe' of
ours]
I should have provided more detail in my previous email, to address
your (valid) concerns. Here's how I view organizing things: objects
have:
1. an init-time-only configuration part, which after construction is read-only,
2. a part which can be set at init or runtime
3. an api for purely run-time behavior, that can't be exposed at init
time because it fundamentally needs the object to exist. This is the
'user public' api of the object instead of the 'developer public' one
(in the sense of not having _underscore prefixes).
1 and 2 can be expressed declaratively and the .conf format that
ConfigObj reads is very nice for that. 3 can only exist at runtime,
so it's a matter of having a way in the .conf file for the user to
declare a .py file that will be run AFTER object construction.
> Using Traits in the runtime API is an entirely different ballgame than
> simply using it for type validation in configuration: When using
> Traits for validation+configuration, the objects that inherit from
> HasTraits are simply bunch/dict like objects that do type validation -
> but they don't contain any application logic. The actually
> application logic is contained in classes that aren't traited
> themselves, but that consume traited config objects to configure
> themselves at startup.
>
> If traited objects are exposed in a runtime API, all of a sudden the
> application logic moves to the traited classes themselves. Then, the
> entire application (any object that needs config or has a runtime API)
> is built upon traits at its core. This is very from the previous case
> where traited classes are used as a minor implementation detail of the
> config system.
>
> I am not saying that it is bad to build an application with traits at
> its core, but only that that is very different from the path that
> ipython and matplotlib have taken thus far. Also, it makes the
> commitment level to traits much higher than if it is used merely as a
> component in the config system - which could easily be swapped out if
> desired.
As I said elsewhere, Traits is *really* small and self-contained, with
a single super-clean piece of C-only extension code that compiles
quickly and without a single warning. I'm still waiting for the
Enthought guys to help me with the metaclass hacks to fully disable
the GUI support at will, but I'm sure it's doable (I even already have
a solution, I just want a better one).
I'm honestly 90% convinced of just using Traits now. The reason is here:
svn co http://ipython.scipy.org/svn/ipython/ipython/branches/saw/sandbox
Just run the file tconfig.py there from within ipython, and start
playing for example with the mpl.rc object. There are a few things I
dislike:
1. Any traited object has a very dirty namespace out of the box. For
rc objects, this makes tab-completion a royal pain in the ass. We'll
see what the Enthought gurus suggest on this front.
2. The way I'm handling read-only name displays in the string
representation of these things is a bit ugly. But the mix of
declarative use of classes, multiple inheritance and traits'
metaclasses got me a bit confused and I couldn't find a cleaner
solution.
But I think this approach can be very nice. For those not interested
in downloading the code, the highlights are:
- Consider a file called mpl.conf:
# Top-level
backend = "TkAgg"
interactive = False
# Things that can only be set at init time, they become read-only afterwards
[InitOnly]
numerix = "numpy"
# Other sections
[lines]
linewidth = 2.0
linestyle = '-'
[figure]
figsize = [6.4,4.8] # figure size in inches
dpi = 100 # figure dots per inch
facecolor = 0.75 # figure facecolor; 0.75 is scalar gray
edgecolor = "white" # figure edgecolor
 [[subplot]]
 # The figure subplot parameters. All dimensions are fraction of the
 # figure width or height
 left = 0.125 # the left side of the subplots of the figure
 right = 0.9 # the right side of the subplots of the figure
 bottom = 0.1 # the bottom of the subplots of the figure
 top = 0.9 # the top of the subplots of the figure
This can be edited in any text editor, emacs even has a .conf major mode!
- Then, consider the following bit of Python code:
 standard_color = Trait ('black',
 {'black': (0.0, 0.0, 0.0, 1.0),
 'blue': (0.0, 0.0, 1.0, 1.0),
 'cyan': (0.0, 1.0, 1.0, 1.0),
 'green': (0.0, 1.0, 0.0, 1.0),
 'magenta': (1.0, 0.0, 1.0, 1.0),
 'orange': (0.8, 0.196, 0.196, 1.0),
 'purple': (0.69, 0.0, 1.0, 1.0),
 'red': (1.0, 0.0, 0.0, 1.0),
 'violet': (0.31, 0.184, 0.31, 1.0),
 'yellow': (1.0, 1.0, 0.0, 1.0),
 'white': (1.0, 1.0, 1.0, 1.0),
 'transparent': (1.0, 1.0, 1.0, 0.0) } )
 class MPLConfig(TConfig):
 # Valid backends, first is default
 backend = Trait('TkAgg','WXAgg','GTKAgg','QtAgg','Qt4Agg')
 interactive = Bool(False)
 class InitOnly(TConfig,ReadOnlyTConfig):
 """Things that can only be set at init time"""
 numerix = Str('numpy')
 class lines(TConfig):
 linewidth = Float(2.0)
 linestyle = Trait('-','=','^')
 class figure(TConfig):
 figsize = ListFloat([6.4,4.8]) # figure size in inches
 dpi = Int(100) # figure dots per inch
 facecolor = Float(0.75) # figure facecolor; 0.75 is scalar gray
 edgecolor = Trait('white',standard_color)
 class subplot(TConfig):
 """The figure subplot parameters. All dimensions are fraction
 of the figure width or height"""
 left = Float(0.125)
 right = Float(0.9)
 bottom = Float(0.1)
 top = Float(0.9)
This purely declarative code incorporates:
 * The types of all parameters acceptable in the file
 * The nesting hierarchy for subobjects
 * The default values hardcoded in the app if users don't provide any
 * The valid values for those which are choices.
An 'application' is defined via:
 class App(object):
 """A trivial 'application' class to be initialized.
 """
 def __init__(self,configClass,conf_filename):
 conf = mkConfigObj(conf_filename)
 self.rc = configClass(conf)
 mpl = App(MPLConfig,'mpl.conf')
This makes the App object load the .conf file, immediately giving
errors if any of the validation constraints implicit in the traits
spec are not met. The resulting mpl.rc object can be printed,
manipulated, modified (for non-read-only sections), even edited with a
GUI (limited at the moment to WX and not really working for
sub-sections, though that's easily fixed). For example:
In [159]: mpl.rc
Out[159]:
# Dump of MPLConfig
backend = 'TkAgg'
interactive = False
[InitOnly]
numerix = 'numpy'
[lines]
linewidth = 2.0
linestyle = '-'
[figure]
edgecolor = 'white'
figsize = [6.4000000000000004, 4.7999999999999998]
dpi = 100
facecolor = 0.75
 [[subplot]]
 top = 0.90000000000000002
 right = 0.90000000000000002
 left = 0.125
 bottom = 0.10000000000000001
These objects are automatically self-representable in a valid
roundtrip format. Editing works:
In [160]: mpl.rc.interactive
Out[160]: False
In [161]: mpl.rc.interactive = True
with validation:
In [162]: mpl.rc.interactive = "well"
---------------------------------------------------------------------------
TraitError Traceback (most recent call last)
/home/fperez/ipython/svn/ipython/branches/saw/sandbox/<ipython
console> in <module>()
/home/fperez/usr/opt/lib/python2.5/site-packages/enthought/traits/trait_handlers.py
in error(self, object, name, value)
 169 another trait handler to handle to validate the value.
 170 """
--> 171 raise TraitError, ( object, name, self.info(), value )
 172
 173 def arg_error ( self, method, arg_num, object, name, value ):
TraitError: The 'interactive' trait of a MPLConfig instance must be a
value of type 'bool', but a value of well was specified.
And read-only parts can't be modified:
In [163]: mpl.rc.InitOnly.numerix = "Numeric"
---------------------------------------------------------------------------
TraitError Traceback (most recent call last)
/home/fperez/ipython/svn/ipython/branches/saw/sandbox/<ipython
console> in <module>()
TraitError: Cannot modify the read only 'numerix' attribute of a
'ReadOnlyTConfig' object.
In summary, I'm fairly happy with the results, and I think the benefit
is enough to convince me of falling in the embrace of the gods of
Traits. It seems John is going for Traits as well, so perhaps we can
use this little config setup across our systems, and even make it
something that others use in the future. I think there's value for
end users in having common, uniform configuration systems across the
various parts of the scientific python 'ecosystem'.
Once we have a discussion here, I'll take this over to the ipython list as well.
Cheers,
f

On Thursday 19 July 2007 7:31:11 pm John Hunter wrote:
> On 7/19/07, Christopher Barker <Chr...@no...> wrote:
> > How many back-ends does the future hold? It seems if the GUI toolkits
> > all use *Agg, then that's only one render for all of them. Then we need:
> >
> > SVG
> > PDF
> > PS
> > Cairo would be nice, as it gives us almost all of them at once, but I
> > guess licensing keeps that a non-starter. Oh well.
>
> Not at all, we want to fully support Cairo. We just want to have some
> fully BSD compliant backends as well.
Is there much demand for BSD-compliant svg, pdf, and ps backends?

On Thursday 19 July 2007 6:31:26 pm Christopher Barker wrote:
> > There is also the question of whether
> > we want to pay up and use 4x4 from the ground up and just ignore the
> > 3rd dimension to open the door for 3D support.
>
> I say yes! 3-d really is a very often needed and requested feature.
> Sure, we can go to VTK or something for really sophisticated 3-d work,
> but being able to do the basic stuff with MPL would be wonderful.
>
> If the framework supports it cleanly internally, it's much more likely
> that the 3-d stuff will get written.
I also think we should use 4x4 affines, and ignore the third dimension. 10 
years down the line, we might look back and regret not taking advantage of 
this opportunity.

On 7/19/07, Christopher Barker <Chr...@no...> wrote:
> > This is potentially a major win, because we currently
> > move the data around on every draw.
>
> Is it that expensive to push data around? In any case, it does sound
> cleaner and more efficient not to.
It can be very expensive. Imagine you are smoothly panning or zooming
a line object with 100,000 x,y points. All you are really doing is
changing the affine. Although we've done some things to help this
case, in matplotlib we still have to create a new path object every
time in the agg backend, and then transform it. It's much cheaper
just to push the affine to the backend in this case. So interaction
with large data sets should get better.
> > Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
>
> 4X4 -- is there much cost?
The potential cost is not in the 3x3 vs 4x4, but in the extra row of
junk data you would store in the data matrix, which is N extra values
for plotting N points . The matrix multiplication would be 3x3 * 3xN
vs 4x4 * 4xN , so there would be a cost in memory and performance.
> > This approach requires the backends to be smarter, but they have to
> > handle fewer entities.
>
> How many back-ends does the future hold? It seems if the GUI toolkits
> all use *Agg, then that's only one render for all of them. Then we need:
>
> SVG
> PDF
> PS
> Cairo would be nice, as it gives us almost all of them at once, but I
> guess licensing keeps that a non-starter. Oh well.
Not at all, we want to fully support Cairo. We just want to have some
fully BSD compliant backends as well. agg 2.4 will remain BSD and I
don't have too much of a problem relying on it. We are not alone in
needing a BSD agg. I think the 4 you mentioned plus *Agg are the
ones we should target. The goal is to get all the GUIs to work with a
python buffer object or a numpy pixel buffer array -- if Agg and Cairo
can provide the same buffer or numpy format, then we would
automagically get *Agg and *Cairo across the GUIs.
JDH

Lots of god stuff John!
> There is also the question of whether
> we want to pay up and use 4x4 from the ground up and just ignore the
> 3rd dimension to open the door for 3D support. 
I say yes! 3-d really is a very often needed and requested feature. 
Sure, we can go to VTK or something for really sophisticated 3-d work, 
but being able to do the basic stuff with MPL would be wonderful.
If the framework supports it cleanly internally, it's much more likely 
that the 3-d stuff will get written.
> This is potentially a major win, because we currently
> move the data around on every draw.
Is it that expensive to push data around? In any case, it does sound 
cleaner and more efficient not to.
> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
4X4 -- is there much cost?
> This approach requires the backends to be smarter, but they have to
> handle fewer entities.
How many back-ends does the future hold? It seems if the GUI toolkits 
all use *Agg, then that's only one render for all of them. Then we need:
SVG
PDF
PS
???
Cairo would be nice, as it gives us almost all of them at once, but I 
guess licensing keeps that a non-starter. Oh well.
> In matplotlib, the plot functions are matplotlib.axes.Axes methods and
> I think there is consensus that this is a poor design.
Well, the OO interface has always felt a bit clunky to me, but I'm not 
sure where else plot functions could go -- I'd love to hear ideas, though.
> Do we want to create high level objects like Circle, Rectangle and
> Line, each of which manage a Path object under the hood?
I like that idea -- working with Paths should be saved for the gurus.
> Just having the right Path object
> will reduce the need for many of these, eg LineCollection,
> PolygonCollection, etc... 
sounds good.
> Also, everything should be numpy enabled,
> and the sequence-of-python-tuples approach that many of the
> collections take should be dropped.
who hoo!
However, numpy doesn't handle "ragged" arrays well. I wonder if there's 
a good way to implement those, so that transforms can be done 
numpy-efficient.
> = Extension code =
> 
> If we can enhance the
> SWIG agg wrapper, we can also do images through there, getting rid of
> _image.cpp. Having a fully featured, python-exposed agg wrapper will
> be a plus in mpl and beyond.
Very nice.
> But with the agg license change, I'm
> open to discussion of other approaches.
hmm GPL now. Well, maybe Cairo's LGPL isn't so bad after all!
> I want to do away with *all* GUI extension code.
yeah!
> = Traits =
> I think we should make a major committment to traits and use them from
> the ground up.
Good plan.
> = Breakage =
> 
> I think we need to be prepared to break the hell out of matplotlib.
> The API will basically be a significant rewrite. 
Well worth it.
 > pylab will still
> mostly work unchanged -- that is the beauty of pylab 
As a rule for the future though, a stable OO interface would be nice.
> Or we could forget all this wild speculation and resume our normally
> scheduled lives.
no!!
> = Chaco and Kiva =
> 
> It is a good idea for an enterprising developer to take a careful look
> at the current Chaco and Kiva
OK. I have to ask -- why aren't we all just using Chaco? I know I'm not 
because ??years ago, Enthought was not really supporting anything but 
Windows -- is that still true? Would it be a whole lot less work to 
support GTK, OS-X, ??? in Chaco than keep developing a separate lib?
Great conversation starters!
-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...

On Thursday 19 July 2007 04:05:11 pm ah...@cs... wrote:
> Somehow I accidentally deleted a line in a part I thought I hadn't touched.
>
> It's a two line change, so I'll just tell you what to change:
>
> Find the line:
> set_clipbox_rasterizer(gc.cliprect);
>
> in src/_backend_agg.cpp in the draw_lines function. (around line 1500)
>
> Right after it, add the following two lines:
> //path_t transpath(path, xytrans);
> _process_alpha_mask(gc);
It's done, svn 3579. Thank you Allan.
Darren

On Jul 19, 2007, at 3:05 PM, Bill Baxter wrote:
> Chaco may be formidable and complex, but so is the list of features
> and requirements you just posted. What about just focusing on a Pylab
> wrapper for Chaco? And working with Peter to make Chaco everything
> you envison. Or does Chaco have the same needs-a-rewrite architecture
> issues as the mpl?
There are certainly directions I'd like to take the architecture, but 
I'm not planning a rewrite anytime soon. One rewrite every 4 years 
is more than enough for me. ;)
> Just to be clear, I don't have any first hand experience with Chaco,
> other than running the demos once. The main problems with Chaco I'm
> aware of are 1) entanglement with the rest of ETS, which they're
> working on, 2) no pylab like easy-to-use interface.
(1): Other than traits (and a teensy bit of traits UI), Chaco 
requires only Kiva and Enable. Its setup.py reflects this. This has 
been the case for a while, but historically the issue has been that 
all the interdependencies at the traits UI level sucked in basically 
the rest of ETS.
(2): Chaco2.shell has some rudimentary pylab-like features, but 
obviously is nowhere near complete. There are some examples of the 
sorts of things it can do: https://svn.enthought.com/enthought/ 
browser/branches/enthought.chaco2_2.0/examples/shell. One thing to 
note about the shell is that its commands are just convenience 
functions that wrap existing Chaco containers and components, so the 
structure of the live plot that is built with, say, an imshow() 
command is similar to one that you could build by hand. This means 
that you can dynamically extend its behavior by adding new tools that 
the command-line interface doesn't know about. It also means that 
you can use the command-line interface to construct a plot (or grid 
of plots) and trivially embed that into an external application, no 
differently than if you had hand-coded to the lower, object-oriented 
layer.
-Peter

On 7/20/07, John Hunter <jd...@gm...> wrote:
> = Chaco and Kiva =
>
> It is a good idea for an enterprising developer to take a careful look
> at the current Chaco and Kiva to see if we can further integrate with
> them. I am gun shy because they seem formiddable and complex, and one
> of my major goals here is to streamline and simplify, but they are
> incredible pieces of work and we need to carefully consider them,
> especially as we integrate other parts of the enthought suite into our
> core, eg traits, increasing the possibility of synergies.
Chaco may be formidable and complex, but so is the list of features
and requirements you just posted. What about just focusing on a Pylab
wrapper for Chaco? And working with Peter to make Chaco everything
you envison. Or does Chaco have the same needs-a-rewrite architecture
issues as the mpl?
Just to be clear, I don't have any first hand experience with Chaco,
other than running the demos once. The main problems with Chaco I'm
aware of are 1) entanglement with the rest of ETS, which they're
working on, 2) no pylab like easy-to-use interface.
--bb

Somehow I accidentally deleted a line in a part I thought I hadn't touched.
It's a two line change, so I'll just tell you what to change:
Find the line:
set_clipbox_rasterizer(gc.cliprect);
in src/_backend_agg.cpp in the draw_lines function. (around line 1500)
Right after it, add the following two lines:
//path_t transpath(path, xytrans);
_process_alpha_mask(gc);
I don't know how that happened....
Allan
On Thu, July 19, 2007 3:33 pm, ah...@cs... wrote:
> That seems to have to do with the line culling agg patch I sent. I never
> thought to check with polar plots. I'll look into it.
>
> Allan
>
>
> On Thu, July 19, 2007 12:17 pm, Paul Kienzle wrote:
>
>> The polar demo in examples/polar_demo.py no longer displays the spiral
>> and axes. It worked a couple of weeks ago when I was testing the
>> contains() method.
>>
>> I downloaded a fresh build of matplotlib pulled from svn today. Tested
>> on python 2.5 OS X. Should be on the wxAgg backend, though I don't
>> know how to confirm that.
>>
>> - Paul
>>