matplotlib-devel Mailing List for matplotlib (Page 11)

Gael Varoquaux wrote:
> On Tue, Jul 17, 2007 at 04:54:49PM -1000, Eric Firing wrote:
>> The 2.0 branch is not new enough, though; we need the trunk. 
> 
> Nonononono. Believe me. Unless you want to live on the bleeding edge. All
> the QA is done on the branches. The trunk is for active developement
> (some active developement happens in the branches, like for mayavi2, so
> far). It is not even garantied to work (it does, most of the time).
Well, I do suggest that matplotlib start using Traits 3 rather than Traits 2.
Otherwise, they will need to switch later. Also, we've tried to minimize the
dependencies for Traits 3, but less so for Traits 2.
Another way to put Eric's suggestion is, "We need Traits 3," rather than, "We
should always use the trunk." matplotlib might want to aim for a released
version of Traits 3.
>> (I tried the 2.0 branch, but it turned out to depend on enthought.util,
>> which depended on enthought.somethingelse... so I stopped. Also it was
>> using numerix; it is not numpified.)
> 
> Traits depend on enthought.etsconfig and enthought.util. Once traits is
> on pypi, these dependencies should install automatically. I am wondering
> if there is a possibility of shipping a "fat" egg, that provides the
> dependancies, just in case the user does not have internet access, and
> that first checks pypi before using the local dependencies.
> 
> I am very surprised about the comment on traits numpification. I just
> tried out my local copy, and it is clearly numpified. I didn't do
> anything special to instal it, just built from source. What makes you
> think the branches are not numpified ?
The Array trait has been updated in Traits 3 to use numpy idioms (dtypes instead
of typecodes, mostly). Traits 2 happily uses numpy for the Array trait, but
you're stuck using icky typecodes that you need to import from numpy.oldnumeric.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Tue, Jul 17, 2007 at 04:54:49PM -1000, Eric Firing wrote:
> The 2.0 branch is not new enough, though; we need the trunk. 
Nonononono. Believe me. Unless you want to live on the bleeding edge. All
the QA is done on the branches. The trunk is for active developement
(some active developement happens in the branches, like for mayavi2, so
far). It is not even garantied to work (it does, most of the time).
> (I tried the 2.0 branch, but it turned out to depend on enthought.util,
> which depended on enthought.somethingelse... so I stopped. Also it was
> using numerix; it is not numpified.)
Traits depend on enthought.etsconfig and enthought.util. Once traits is
on pypi, these dependencies should install automatically. I am wondering
if there is a possibility of shipping a "fat" egg, that provides the
dependancies, just in case the user does not have internet access, and
that first checks pypi before using the local dependencies.
I am very surprised about the comment on traits numpification. I just
tried out my local copy, and it is clearly numpified. I didn't do
anything special to instal it, just built from source. What makes you
think the branches are not numpified ?
Cheers,
Gaël

Bryce Hendrix wrote:
> John, you're trying to check out the code from Trac, not svn :) Try this 
> URL
> 
> https://svn.enthought.com/svn/enthought/branches/enthought.traits_2.0
I just did this. There is still an authentication problem, but manually 
accepting the cert makes it work.
The 2.0 branch is not new enough, though; we need the trunk. (I tried 
the 2.0 branch, but it turned out to depend on enthought.util, which 
depended on enthought.somethingelse... so I stopped. Also it was using 
numerix; it is not numpified.)
Then I checked out the trunk:
https://svn.enthought.com/svn/enthought/trunk/enthought.traits/
ran "python setup.py build", "python setup.py install --prefix=/usr/local".
No glitches so far; but when I tried to run tests from the tests 
directory, it failed. It was looking for ui components, even for non-ui 
tests. So I commented out the ui parts of api.py, and that seems to 
have done the trick.
Eric

Hi all,
this is an important discussion also for us (ipython), so I'll go in
some detail into things. It would be great if out of this we got
something that both ipython and matplotlib could reuse for the long
haul, though I'm not sure (in a sense, ipython has some nastier
requirements that mpl may not need to worry about).
On 7/17/07, John Hunter <jd...@gm...> wrote:
> On 7/17/07, Darren Dale <dd...@co...> wrote:
>
> > I'm really impressed with how readable and well organized the code is in
> > ipython1. It looks like their approach to configuration has been carefully
> > considered. Any chance we can follow their lead? It looks like it would be a
>
> I haven't looked at it closely, but I am willing to trust Fernando on
> this for the most part. I know he has put a lot of thought into it,
> and it's something we've talked about for years.
Thanks for the compliments. We have put much thought into it, and
Brian deserves all the implementation credit. But as you'll see in a
moment, all is not quite well; hopefully after this discussion and
feedback from you guys we'll find a good solution so we can (finally!)
consider this problem fixed and move on to other things.
> I am not too fond of the dictionary usage here:
>
> controllerConfig.listenForEnginesOn['ip'] = '127.0.0.1'
> controllerConfig.listenForEnginesOn['port'] = 20000
>
> I prefer
>
> controllerConfig.listenForEnginesOn.ip = '127.0.0.1'
> controllerConfig.listenForEnginesOn.port = 20000
>
> Since dicts and attrs are intimately linked, eg with something like
> Bunch, this should be a minor tweak. Fernando, why did you prefer
> dict semantics. And are you happy with the state of your config
> system in ipython1
Let's not worry about this for now: I agree with you, but it's an
implementation detail that is trivial to fix with a light wrapper,
which already basically exists in IPython.ipstruct. The real problems
lie elsewhere.
Brian and I spent a lot of time discussing this today, and here's the
summary of the whole thing. Again, some of these issues may not
affect mpl nearly as seriously as they do ipython.
Having config files be pure python has some nice benefits:
- familiar syntax for users
- the ability for users to put in complex logic when declaring their
configuration (like make decisions based on OS, hostname, etc).
- If developers want, wrapping the underlying objects in something
like Traits provides automatically validation mechanisms for
configuration, which is important.
The security issue is for *me* moot: ipython is a full-access Python
system where people are *expected* to run code. So I don't care about
letting them run real code at config time. But for other projects,
the story is completely different, obviously. I suspect MPL falls
into ipython's category here though.
So what is the problem? The main one is that we have a real difficult
time with circular import dependencies and init-time logic.
Basically, you need these configuration objects to exist at startup
for other objects to be built, but the configuration *itself* may need
to import various things if it is to work as real Python code. In
IPython (the dev branches), for example, the user-visible system is
assembled out of multiple objects, which themselves need to build
their own internal sub-objects. Some of these simply require value
parameters at init time, but in some cases even which *class* to use
is tweakable at init time (for example, so users can choose amongst
various classes that implement different network transport protocols
but with identical API as far as IPython goes).
While in any one case one can probably disentangle the various
dependency chains that arise, it's a major pain to have to deal with
this constantly. The fact that the problem is a recurring one is to
us an indicator of a design problem that we should address
differently.
There are other issues as well, besides circular imports:
A. Initialization time modification of live objects: while config
objects are obviously meant to be built *before* the 'real' objects
(who in term use the config ones to assemble themselves), there are
cases where one would like to deal with the 'real thing'. For
example, in today's IPython (not the dev branch, but the one y'all
run) you can add things like magics at init time. This is only
possible because when the rc file is parsed, the real object is
already up and alive as __IPYTHON__ (also visible via ipapi.get() ).
Obviously this is a hack, and a cleaner design would probably separate
the declaration of code objects (say magics) that are meant to be fed
into the live instance as part of the construction of the config
object, and then would have the real ipython load up its tweaks 100%
from this config object. But since ipython is also meant to be
*runtime* modifiable, it feels natural to let users access such an API
for their own tweaks, yet there is a conflict with doing this purely
on a config object that is basically just a fancy 'data bag'.
B. Automatic creation of default config files. With pure python, this
is just hard to do, since you'd be in the business of auto-generating
valid code from the structure of an object. For a pure 'class
Bunch:pass' type thing this may not be *too* hard, as long as all
values allowed are such that eval(repr(foo))==foo, which isn't really
always the case.
C. Complexity: even for Brian, who wrote the config code, it's hard to
figure out where all the details go, since declaring new flags
typically ends up requiring fishing inside the config classes
themselves. A more plain-text, purely declarative file would
summarize these things in a way that would probably be easier for both
developers and end users.
Given all this, we are currently looking at going back to a mixture of
text-based config and real code, as a two-stage process. The
ConfigObj library:
http://www.voidspace.org.uk/python/configobj.html
looks like a nice, self-contained step above hand-parsing rc files or
Python's rather primitive ConfigParser module. It has a lot of good
features, is mature and is small enough that one can ship it inside
the project (license is BSD).
Our current plan is something along these lines:
1. Expose for all configuration objects the part that is really just a
key=value API over ConfigObj. This would dispense with all the
circular import problems, and let users specify the most common things
they want to tweak with a really simple syntax (that of .ini files).
We would then load these and build all necessary objects.
2. Make sure that the part of any given object that we mean to expose
for *runtime* modification (say adding magics to a running ipython,
for example) is easily available. This would let users modify or
extend those aspects of the system that can't just be easily declared
as simple key=value settings. The mechanism for this would simply be
to have a filename in each object's ConfigObj session like:
[SomeObject]
post_init_file = "my_post_init.py"
This file would be run via execfile() *once SomeObject* were
guaranteed to be up and running. This would then allow users to have
code that manipulates SomeObject programatically, via its runtime API.
All this conversation brings us to...
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).
All of this can obviously be done with python properties, but before I
write Traits again, poorly (I'm no David Morrill) I'd rather ride
Enthought's back.
This approach via Traits (or something like them) also ensures that
the work done in ensuring the consitency/robustness of an object's
*runtime* configuration API becomes automatically useful to users, and
it simplifies the init-time config API, since it gives us the option
to defer more complicated tasks to runtime.
So this is a summary of where we stand. It's surprising that the
'simple question' of configuring an application can turn out to be
such a can of worms, but for us it has proven to be. Input/ideas from
you all would be very welcome, as it's quite likely we've missed
possible solutions.
I'd love to get out of this discussion some ideas, clarity and
ultimately a plan for how to proceed in the long haul. If in addition
this means that ipython, mpl and others end up uniformizing further
our approach to this problem, even better! Having our end users find
familiar configuration mechanisms across their various libraries would
only be a good thing in the long run.
Cheers,
Brian and f.
ps - I debated on having this discussion on ipython-dev, but for now
I'm going to not cross-post. The MPL team is attentive to the issue
now, so I'd rather collect your wisdom here, and I'll take it upon
myself to summarize our conclusions on ipython-dev later. I just want
to avoid list cross-posting.

On 7/17/07, Gael Varoquaux <gae...@no...> wrote:
> I have written a small script that uses pylab to retrieve the data for
> the MPL colormaps. I am thinking of checking in both the script, and the
> resulting data in Mayavi2 (FBSD licenced). Can I do such a thing
> (stealing colormaps ?).
You are welcome to do this, but you might be better served stealing
our colormapping infrastructure and data directly (_cm.py, cm.py and
colors.py) rather than trying to extract it via pylab.
Some of our colormap data is borrowed from other sources (colorbrewer,
yorick). They have BSD compatible licenses, but have some
restrictions that you distribute their licenses. matplotlib does so
in the licenses subdir of the svn repo. Search _cm.py for "license"
for more details.
JDH

I have written a small script that uses pylab to retrieve the data for
the MPL colormaps. I am thinking of checking in both the script, and the
resulting data in Mayavi2 (FBSD licenced). Can I do such a thing
(stealing colormaps ?).
Cheers

On 7/17/07, Michael Droettboom <md...@st...> wrote:
> TraitsUI seems really cool, but there are a couple of reasons I think
> that should probably be considered lower priority. For one, it would
> need to be generalized and ported (backend-ed) for all of matplotlib's
> many gui backends. Also, I wonder how it fits into matplotlib's
> paradigm as somewhere in between interactive and noninteractive
> plotting. You would almost certainly want to tweak traits with the UI
> and then save that back out as Python code, but code generators almost
> never generate code that a human being would want to edit.
I recently saw a 'technical demo' of Matlab at my university, done by
their people. I have to admit that the only thing that left me truly
impressed was the quality of their code generator for interactively
modified plots. The demo person did a fair amount of non-trivial
tweaking of a plot via their GUI, and then he hit 'save as code'. He
then opened the generated code, which was a nice function definition
with the arrays being plotted as input parameters (hence reusable
right away), was very readable overall.
I certainly thought that having such functionality would be great for
mpl/python, since it really does look extremely useful. But this was
a sales demo, perhaps others who use matlab regularly (I don't) have
a different opinion of that functionality when used in day to day
production work.
Cheers,
f

On Tue, Jul 17, 2007 at 11:54:19AM -0400, Perry Greenfield wrote:
> This is exactly the sort of thing that I thought a transform approach 
> would make easier to do. So if it isn't urgent, waiting probably 
> would be better. (by the way, we see exactly the same sort of log 
> scale you propose in one of our older (non-python) packages. So there 
> is a call for this sort of thing.
This is not an urgent project. I'm going to finish work on the canvas
objects first, and use them for a couple of applications such as a 2D mesh 
slicer and a multiple peak fitter. It will be a couple of months before
we need to address log scales.
I wonder if it is worth refactoring the code with the idea of allowing
transforms to be implemented in Python+Numpy. It will mean redoing
data structures so that vertices for things like line collections and
tic marks are stored in dense arrays which can be transformed en masse
rather than point by point. I haven't looked closely enough to see how
ambitious this proposal would be.
 - Paul

Sorry for double posting. Apparently the original posting was html formatte=
d,=20
and looked nonsensical. Hopefully this one is more clear:
On Tuesday 17 July 2007 02:31:02 pm Darren Dale wrote:
> On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> > Speaking of branches, we may need to seriously consider a branch here,
> > mpl1.
>
> I vote for a branch. Maybe we could consider an alternative directory
> layout in a branch, the current layout is a bit entropic. For the sake of
> discussion:
>
> mpl/
> =A0 =A0 configfiles/
> =A0 =A0 doc/
> =A0 =A0 =A0 =A0 examples/
> =A0 =A0 =A0 =A0 users_guide/
> =A0 =A0 matplotlib/
> =A0 =A0 =A0 =A0 api/
> =A0 =A0 =A0 =A0 backends/
> =A0 =A0 =A0 =A0 config/
> =A0 =A0 =A0 =A0 mpl-data/
> =A0 =A0 =A0 =A0 test/
> =A0 =A0 =A0 =A0 text/
> =A0 =A0 =A0 =A0 =A0 =A0 afm
> =A0 =A0 =A0 =A0 =A0 =A0 dviread
> =A0 =A0 =A0 =A0 =A0 =A0 fontmanager
> =A0 =A0 =A0 =A0 =A0 =A0 mathtext
> =A0 =A0 =A0 =A0 =A0 =A0 texmanager
> =A0 =A0 =A0 =A0 =A0 =A0 text
> =A0 =A0 =A0 =A0 tools/
> =A0 =A0 =A0 =A0 =A0 =A0 cbook
> =A0 =A0 =A0 =A0 =A0 =A0 dates
> =A0 =A0 =A0 =A0 =A0 =A0 numerix
> =A0 =A0 =A0 =A0 =A0 =A0 transforms
> =A0 =A0 =A0 =A0 =A0 =A0 units
> =A0 =A0 =A0 =A0 axes.py
> =A0 =A0 =A0 =A0 figure.py
> =A0 =A0 =A0 =A0 etc.py
> =A0 =A0 external/ # or installed seperately
> =A0 =A0 =A0 =A0 agg/
> =A0 =A0 =A0 =A0 dateutil/
> =A0 =A0 =A0 =A0 enthought/
> =A0 =A0 =A0 =A0 pyparsing.py
> =A0 =A0 =A0 =A0 pytz/
> =A0 =A0 =A0 =A0 subprocess/
> =A0 =A0 =A0 =A0 ttconv/
> =A0 =A0 =A0 =A0 pylab.py # is that cheating?
> =A0 =A0 license/
> =A0 =A0 sandbox/
>
> I would move code out of CXX, src, and swig, and into the more relevant
> directories, unless it is really necessary to keep it bundled like this. I
> have often had to hunt for _transforms, for example.

On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> Speaking of branches, we may need to seriously consider a branch here,
> mpl1.
I vote for a branch. Maybe we could consider an alternative directory layout in a branch, the current layout is a bit entropic. For the sake of discussion:
mpl/
 configfiles/
 doc/
 examples/
 users_guide/
 matplotlib/
 api/
 backends/
 config/
 mpl-data/
 test/
 text/
 afm
 dviread
 fontmanager
 mathtext
 texmanager
 text
 tools/
 cbook
 dates
 numerix
 transforms
 units
 axes.py
 figure.py
 etc.py
 external/ # or installed seperately
 agg/
 dateutil/
 enthought/
 pyparsing.py
 pytz/
 subprocess/
 ttconv/
 pylab.py # is that cheating?
 license/
 sandbox/
I would move code out of CXX, src, and swig, and into the more relevant directories, unless it is really necessary to keep it bundled like this. I have often had to hunt for _transforms, for example.

Christopher Barker wrote:
> I have thought about the safety issue. One idea I've had (though I never 
> bothered with it) was to strip the input files of "import" lines first. 
> You could do a whole lot less if you couldn't import any arbitrary modules.
Disallowing import statements won't help with that. There are simply too many
ways to get around it. See Brett Cannon's paper on securing Python:
 http://www.cs.ubc.ca/%7Edrifty/papers/python_security.pdf
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Darren Dale wrote:
> John, Eric, have you had a look at the way IPython1 handles config files? 
> Here's a taste:
> In ipython's scheme, the config files 
> are loaded using execfile, I wonder if that might appear unsafe to anyone? 
This is, of course, terribly unsafe, but does anyone have a use case 
where that matters? I don't. I use python files for config all the time, 
and I love it! They are very readable, and I don't have to write a 
parser or document the syntax myself. I usually use import, rather than 
execfile, though I couldn't tell you why.
I have thought about the safety issue. One idea I've had (though I never 
bothered with it) was to strip the input files of "import" lines first. 
You could do a whole lot less if you couldn't import any arbitrary modules.
> I think it would be better to break a
> bunch of stuff all at once for a 1.0 release, than to break things
> incrementally with successive releases
+1
-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...

This is exactly the sort of thing that I thought a transform approach 
would make easier to do. So if it isn't urgent, waiting probably 
would be better. (by the way, we see exactly the same sort of log 
scale you propose in one of our older (non-python) packages. So there 
is a call for this sort of thing.
Perry
On Jul 17, 2007, at 10:36 AM, Paul Kienzle wrote:
> On Tue, Jul 17, 2007 at 08:33:47AM -0500, John Hunter wrote:
>> Speaking of branches, we may need to seriously consider a branch 
>> here,
>> mpl1. The changes here may involve breaking a fair amount of code,
>> which I don't mind doing to get it right, but I'm somewhat 
>> inclined to
>> branch off here for matplotlib1.0, with the goal of using traits,
>> fixing axis handling (eg multiple y-axis with arbitrary placement),
>> and rewriting the transforms.
>
> On the topic of transforms, I would like to be able to do dynamic 
> range
> compression on a decaying oscillatory signal. Think of it as a 
> logarithmic
> axis which supports negative numbers. AFAICT, the current transform
> infrastructure does not allow me to add this as a third party package.
>
> The axis would look something like:
>
> 	|- 10**2
> 	|
> 	|- 10**1
> 	|
> 	|- 10**0
> 	|
> 	|- 10**-1
> 	|
> 	|- 0
> 	|
> 	|- -10**-1
> 	|
> 	|- -10**0
>
> As well as a max and min parameter, there would have to be a cutoff
> parameter. For auto axes, choose a cutoff which allows a reasonable
> number of decades to be displayed (I'm guessing reasonable is seven).
>
> The transform would be something like the following:
>
> if (x[i] > cut) newx[i] = log10(x[i]) - log10cut;
> else if (x[i] < -cut) newx[i] = log10cut - log10(-x[i]);
> else newx[i] = 0.;
>
> with inverse:
>
> if (x[i] < 0) newx[i] = -pow(10.0, log10cut - x[i]);
> else if (x[i] > 0) newx[i] = pow(10.0, x[i] - log10cut);
> else x[i] = 0.
>
> Even extending the current LOG10 support would present a challenge of
> how to get the cut value into the transform.
>
> Suggestions how I can implement this in the current architecture, or
> should I wait for the new transforms code?
>
> 	- Paul
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tuesday 17 July 2007 11:22:29 am John Hunter wrote:
> On 7/17/07, Darren Dale <dd...@co...> wrote:
> > I'd like to add the dict-based validation scheme for 0.91. It should be
> > quick, and then I can focus on traits and a new config scheme, in an mpl1
> > branch if we decide that is best.
>
> Sounds like a good plan.
As of svn 3552, rc parameters are validated. Validation occurs in the rcParams 
dict itself, so settings are validated whether loaded from matplotlibrc, or 
with the rc() function, or by directly accessing rcParams itself.
Validation may uncover some hidden bugs. conoutf_demo.py had an argument 
hold='on', which wouldnt work before now because 'on' was not a valid boolean 
(it is a valid boolean now). But backend_driver runs without errors, but I 
wonder if there will be some hidden problems. For example, polar_demo.py 
runs, but polar() is not plotting lines.
Darren

On 7/17/07, Darren Dale <dd...@co...> wrote:
> I'd like to add the dict-based validation scheme for 0.91. It should be quick,
> and then I can focus on traits and a new config scheme, in an mpl1 branch if
> we decide that is best.
Sounds like a good plan.

On Tue, Jul 17, 2007 at 08:33:47AM -0500, John Hunter wrote:
> Speaking of branches, we may need to seriously consider a branch here,
> mpl1. The changes here may involve breaking a fair amount of code,
> which I don't mind doing to get it right, but I'm somewhat inclined to
> branch off here for matplotlib1.0, with the goal of using traits,
> fixing axis handling (eg multiple y-axis with arbitrary placement),
> and rewriting the transforms.
On the topic of transforms, I would like to be able to do dynamic range
compression on a decaying oscillatory signal. Think of it as a logarithmic
axis which supports negative numbers. AFAICT, the current transform 
infrastructure does not allow me to add this as a third party package.
The axis would look something like:
	|- 10**2
	|
	|- 10**1
	|
	|- 10**0
	|
	|- 10**-1
	|
	|- 0
	|
	|- -10**-1
	|
	|- -10**0
As well as a max and min parameter, there would have to be a cutoff 
parameter. For auto axes, choose a cutoff which allows a reasonable 
number of decades to be displayed (I'm guessing reasonable is seven).
The transform would be something like the following:
 if (x[i] > cut) newx[i] = log10(x[i]) - log10cut;
 else if (x[i] < -cut) newx[i] = log10cut - log10(-x[i]);
 else newx[i] = 0.;
with inverse:
 if (x[i] < 0) newx[i] = -pow(10.0, log10cut - x[i]);
 else if (x[i] > 0) newx[i] = pow(10.0, x[i] - log10cut);
 else x[i] = 0.
Even extending the current LOG10 support would present a challenge of 
how to get the cut value into the transform.
Suggestions how I can implement this in the current architecture, or
should I wait for the new transforms code?
	- Paul

On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> We should also consider getting out a 0.91 release as soon as we can
> finish the numpification, because Michael has done a lot of good work.
> So much to do....
I'd like to add the dict-based validation scheme for 0.91. It should be quick, 
and then I can focus on traits and a new config scheme, in an mpl1 branch if 
we decide that is best.

On 7/17/07, Darren Dale <dd...@co...> wrote:
> I'm really impressed with how readable and well organized the code is in
> ipython1. It looks like their approach to configuration has been carefully
> considered. Any chance we can follow their lead? It looks like it would be a
I haven't looked at it closely, but I am willing to trust Fernando on
this for the most part. I know he has put a lot of thought into it,
and it's something we've talked about for years.
I am not too fond of the dictionary usage here:
controllerConfig.listenForEnginesOn['ip'] = '127.0.0.1'
controllerConfig.listenForEnginesOn['port'] = 20000
I prefer
controllerConfig.listenForEnginesOn.ip = '127.0.0.1'
controllerConfig.listenForEnginesOn.port = 20000
Since dicts and attrs are intimately linked, eg with something like
Bunch, this should be a minor tweak. Fernando, why did you prefer
dict semantics. And are you happy with the state of your config
system in ipython1
Speaking of branches, we may need to seriously consider a branch here,
mpl1. The changes here may involve breaking a fair amount of code,
which I don't mind doing to get it right, but I'm somewhat inclined to
branch off here for matplotlib1.0, with the goal of using traits,
fixing axis handling (eg multiple y-axis with arbitrary placement),
and rewriting the transforms. I think it would be better to break a
bunch of stuff all at once for a 1.0 release, than to break things
incrementally with successive releases. here are significant pieces
of matplotlib code -- I've written some of them in past lives and I
won't be porting them to mpl1 - and we should probably try to
maintain a stable and bugfixed release of our current tree as we begin
to hack it.
We should also consider getting out a 0.91 release as soon as we can
finish the numpification, because Michael has done a lot of good work.
 So much to do....

On Tuesday 17 July 2007 09:15:15 am Darren Dale wrote:
> I'm really impressed with how readable and well organized the code is in
> ipython1. It looks like their approach to configuration has been carefully
> considered. Any chance we can follow their lead? It looks like it would be
> a good fit: we would define the config settings (and defaults) with traits
> somewhere like config.objects, import them in the rc file to be customized.
> I don't think we could automatically generate rc files with the ipython
> scheme, but thats probably not too important.
I should clarify that. I think we could still generate rc files from the 
template, modifying the backend based on what toolkits are installed on the 
user's system. There was a comment in the rcdefaults code mentioning the 
possibility of generating the template from the defaultParams dict. That 
might be tricky.
Darren

On Tuesday 17 July 2007 08:01:41 am Michael Droettboom wrote:
> Gael Varoquaux wrote:
> > On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> >> I am happy to be the first at this point -- enthought has done a lot
> >> to support traits. Traits has one of the most impressive pieces of
> >> technical documentation in the scientific python community.
> >
> > I am very happy to hear this. I have been using traits for lab work, and
> > it has been an absolute pleasure (ask Fernando, he has heard me express
> > my satisfaction over and over). I have converted a friend, here, in
> > France to traits for some software his company is developing, and every
> > body has been amazed at the results.
>
> I am happy to see this thread as well. In a conversation with Perry
> Greenfield here yesterday, we both agreed that adding traits to
> matplotlib would be a good thing to devote some of our resources to. If
> this thread has already fired others up, don't let us stop you, but
> let's coordinate efforts if possible. The motivation from an STScI
> point of view is how it may make reworking the transforms system easier
> and more powerful. It's also good to hear the positive reports about
> enthought Traits.
>
> I think the proposed roadmap makes sense: to start simple with rcParams
> and Artist and broaden out from there. I also see there being (at
> least) two phases in how it is applied: first for data validation, and
> second taking advantage of "trait notification" where appropriate.
I will start working on this today. I am a little surprised by how much 
interest has grown since the last time it came up on the mailing list.
John, Eric, have you had a look at the way IPython1 handles config files? 
Here's a taste:
------------ configfiles/ipcontroller.py --------------
from ipython1.config.api import getConfigObject
controllerConfig = getConfigObject('controller')
# Now we can configure the controller
controllerConfig.listenForEnginesOn['ip'] = '127.0.0.1'
controllerConfig.listenForEnginesOn['port'] = 20000
--------------------------------------------------------------
and then
-------- ipython1/scripts/ipcontroller.py ----------
[...]
def main():
[...]
 config.updateConfigWithFile('ipcontrollerrc.py', options.ipythondir)
[...]
--------------------------------------------------------------
I'm really impressed with how readable and well organized the code is in 
ipython1. It looks like their approach to configuration has been carefully 
considered. Any chance we can follow their lead? It looks like it would be a 
good fit: we would define the config settings (and defaults) with traits 
somewhere like config.objects, import them in the rc file to be customized. I 
don't think we could automatically generate rc files with the ipython scheme, 
but thats probably not too important. In ipython's scheme, the config files 
are loaded using execfile, I wonder if that might appear unsafe to anyone? 
Fernando, did you have any concerns about using execfile?
Darren

On Tue, Jul 17, 2007 at 08:01:41AM -0400, Michael Droettboom wrote:
> TraitsUI seems really cool, but there are a couple of reasons I think 
> that should probably be considered lower priority. For one, it would 
> need to be generalized and ported (backend-ed) for all of matplotlib's 
> many gui backends. Also, I wonder how it fits into matplotlib's 
> paradigm as somewhere in between interactive and noninteractive 
> plotting. You would almost certainly want to tweak traits with the UI 
> and then save that back out as Python code, but code generators almost 
> never generate code that a human being would want to edit.
I was only mentionning TraitsUI as an option when integrating matplotlib
into something larger, as a plotting engine (think something like
http://sourceforge.net/projects/qme-dev, for instance, or some domain
specific application).
Of course I also have in mind an IDE, written in WxPython (most probably
using enthought's envisage framework), with Ipython1 as the commandline
engine, and MPL as the plotting engine. So far this is pure sci-fi,
because we don't have the resources to write it, but it is nice if pieces
start falling together.
Gaël

Gael Varoquaux wrote:
> On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> 
>> I am happy to be the first at this point -- enthought has done a lot
>> to support traits. Traits has one of the most impressive pieces of
>> technical documentation in the scientific python community.
>> 
>
> I am very happy to hear this. I have been using traits for lab work, and
> it has been an absolute pleasure (ask Fernando, he has heard me express
> my satisfaction over and over). I have converted a friend, here, in
> France to traits for some software his company is developing, and every
> body has been amazed at the results.
> 
I am happy to see this thread as well. In a conversation with Perry 
Greenfield here yesterday, we both agreed that adding traits to 
matplotlib would be a good thing to devote some of our resources to. If 
this thread has already fired others up, don't let us stop you, but 
let's coordinate efforts if possible. The motivation from an STScI 
point of view is how it may make reworking the transforms system easier 
and more powerful. It's also good to hear the positive reports about 
enthought Traits.
I think the proposed roadmap makes sense: to start simple with rcParams 
and Artist and broaden out from there. I also see there being (at 
least) two phases in how it is applied: first for data validation, and 
second taking advantage of "trait notification" where appropriate.
TraitsUI seems really cool, but there are a couple of reasons I think 
that should probably be considered lower priority. For one, it would 
need to be generalized and ported (backend-ed) for all of matplotlib's 
many gui backends. Also, I wonder how it fits into matplotlib's 
paradigm as somewhere in between interactive and noninteractive 
plotting. You would almost certainly want to tweak traits with the UI 
and then save that back out as Python code, but code generators almost 
never generate code that a human being would want to edit.
Cheers,
Mike

On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> On 7/16/07, Eric Firing <ef...@ha...> wrote:
> > Are any real, live projects outside of enthought making major use of
> > traits? Or would we be the first?
> I am happy to be the first at this point -- enthought has done a lot
> to support traits. Traits has one of the most impressive pieces of
> technical documentation in the scientific python community. The
> enthought mailing list has become quite active of late, and they are
> clearly supporting their OS code. They actively promote their product
> and want a large user community -- we can provide synergy there. It
> has lived in our src tree for over a year and still "just compiles".
> In fact, I am amenable too, though not committed to, requiring
> traits as an *external* package rather than an included package, both
> to encourage users into the ETS suite and to encourage enthought to
> support us via their traits package. I'd be happy to hear from
> enthought here on their preferences. With the whole Numeric, numarray
> and numpy thing behind us, I'm looking for a whole new set of
> compilation issues to tackle :-)
I am very happy to hear this. I have been using traits for lab work, and
it has been an absolute pleasure (ask Fernando, he has heard me express
my satisfaction over and over). I have converted a friend, here, in
France to traits for some software his company is developing, and every
body has been amazed at the results.
Traits come with added benefits than validation:
* Traits handlers, they allow nice event driven programming in a light
way. Think of it this way: you have a mappable artist, its colormap is a
traits, you have a handler triggered when you change this colormap that
automatically redraw the axes. If you use this pattern heavily, the
drawing package becomes much nicer to use we integrating in an
interactive program.
* TraitsUI. Once everything is traited, and each artist has its
properties discribed by traits, you edit these properties graphically,
traits can create automatically dialogs for them
(see http://code.enthought.com/traits/ for an example with screenshots).
Now this is Wx only, so far, so it would be very limited. However
graphical edition of figures and artists is a feature my colleagues ask
often, and having traits would make it one step closer.
My 2 cents,
Gaël

On Mon, Jul 16, 2007 at 08:38:17AM -0500, John Hunter wrote:
> On 7/15/07, Paul Kienzle <pki...@ni...> wrote:
> > Hi,
> >
> > I don't see an obvious way to remove a line from an axes object.
> >
> > Shall I add remove_child(h) which searches through all the lists
> > of containers and removes the one that I don't want?
> 
> That's one way to do it, but you might consider something along the
> lines -- every time someone adds an Artist anywhere in the figure,
> they add an entry into a Figure remove dictionary that maps the artist
> to a function to remove it
> 
> class Figure:
> def register_remove(self, artist, func):
> 'register a function to remove an artist'
> self.removemap[artist] = func
> self.lastArtist = artist # this can be used to handle Gael's request
> 
> def remove_artist(self, artist):
> 'remove the artist'
> func = self.removemap.get(artist, None)
> if func is None: return
> func() # poof, it's gone
> del self.removemap(artist)
> 
> def remove_last(self):
> 'remove the most recently registered artist'
> self.remove_artist(self.lastArtist)
> self.lastArtist = None
> class Axes:
> def add_line(self, line):
> self.figure.register_remove(line, lambda x: self.lines.remove(line))
> self.lines.append(line)
I'm not to keen on yet another registry, especially since it will have to
be maintained when, e.g., cla() is called.
How about storing the remove function with the artist itself? Then it
would just be h.remove() rather than fig.remove_artist(h).
BTW, I can't think of a use case for 'remove last' from an applications
standpoint. Maybe it would be useful to someone entering plot commands 
from the console, but even then it is a poor substitute for 'undo'.
> Then the user won't need to know whether the artist is stored by the
> Axes, Axis, XTick, etc... This is likely more efficient and easier to
> implement than recursively searching....
On the topic of efficiency, every tick line (1,2) grid line (1,2) and 
every tick label (1,2) has an artist associated with it. Is there any
reason not to represent this as one or two line collections and a text
collection? Our application has multiple panels in a wxAUI interface,
and graph rendering is slow even on tiny data sets.
	- Paul

Robert Kern wrote:
[...]
> We've split up the main "enthought" package such that Traits can be installed
> separately as "enthoguht.traits". I think we'd prefer depending on it externally
> now that we've spent so much effort to make that feasible.
When do you expect to make a release?
Eric