matplotlib-devel Mailing List for matplotlib (Page 4)

On Tuesday 24 July 2007 5:49:27 pm Fernando Perez wrote:
> On 7/24/07, Darren Dale <dd...@co...> wrote:
> > creating RecursiveConfManager with no_mplrc.conf, which does not exist
> > calling RecursiveConfigManagers write() method
> > Here are the contents of no_mplrc.conf:
> >
> >
> > I might have expected to see the MPLConfig defaults
>
> Nope. The point is that a top-level file may well start empty,
> without even an 'include' statement at all, and as the user changes
> things (via the cmd line or edit_traits()), ONLY those changes will be
> written in. 
Ah! (Smacks self on forehead) 
> This way, users don't carry a lot of declaration of 
> internal defaults that may potentially change as MPL evolves; this
> minimizes the chances for config errors appearing in the future when
> they upgrade.
>
> > Backend now changed to: Cairo
> > calling RecursiveConfigManagers write() method
> > Here are the new contents of no_mplrc.conf:
> >
> >
> > in this test, dsd finds that no_mplrc.conf is empty after both writes
> > I suggest that tconfig should either write to the file, or raise an
> > error when the file does not exist
> > removing no_mplrc.conf
>
> Fixed. See note on file creation at end.
Great!
> > ------------------------------------------------------------------------
> >
> > moving mplrc.conf to mplrc.conf.off
> > copying mplrc2.conf to mplrc2_copy.conf
> > loading config from mplrc2_copy.conf, which includes mplrc.conf-
> > but mplrc.conf does not exist
> > here are the contents of mplrc2_copy.conf, as loaded
> >
> > # A hierarchical configuration
> > include = 'mplrc.conf'
> >
> > Backend now changed to: Cairo
> > writing to file
> > Here are the new contents of mplrc2_copy.conf:
> >
> > # A hierarchical configuration
> > include = 'mplrc.conf'
> >
> > I might have expected to see the backend.use here
> > maybe an error should be raised when a config file includes another
> > config file that does not exist
> > moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf
>
> Fixed, now raises IOError.
Great!
> I implemented this policy:
>
> 1. Creating a TConfigManager(FooConfig,'missingfile.conf') will work
> fine, and 'missingfile.conf' will be created empty.
>
> 2. Creating TCM(C,'OKfile.conf') where OKfile.conf has
>
> include = 'missingfile.conf'
>
> conks out with IOError.
>
> My rationale is that creating top-level empty files is a common and
> reasonable need, but that having invalid include statements should
> raise an error right away, so people know immediately that their files
> have gone stale.
>
> It seems to me that this system does everything John and I discussed
> over the phone on Sat, and that others have mentioned here.
> Basically, MPL could install at startup time a simple matplotlib.conf
> file that reads:
>
> # MPL config file. For configuration details, try exloring
> # pylab.rc
> # If you are using WX or IPython with -wthread, you can try
> # pylab.rc.edit_traits()
> # for a GUI.
> # This file:
> # /path/to/full/copy/of/mpl/internal/mpl.conf
> # is an auto-generated file with the complete current internal defaults.
> # Feel free to copy pieces you need from it if you prefer.
> # Note that you can create hierarchies of config files by using
> # include = '/path/to/base.conf'
> # For more details on MPL's config system, see
> # http://matplotlib.sf.net/great/information/page.html
>
> ### EOF
>
> That's it. Exactly zero actual data in the default file, just some
> information to get people going. This file will only grow what people
> actually change, thus minimizing the chances for problems that pop
> like dandelions as upgrades happen.
>
> In addition, even users who don't run with WX* backends could always
> just start ipython -wthread to tweak their config, save it, and then
> go back to using whatever they normally work with in production. WX
> would only be needed for the traits GUI to open, not for any of MPL
> itself.
>
> Comments, feedback?
Thank you for all you have already done, Fernando.
I tried adding a bogus key to mplrc.conf (top level, bogus = 1), and ran the 
mpltest.py script from IPython. The result is posted at the end of this 
message. Would it be possible to provide some more context for bad sections 
or keys? Like the section in which the key is located, the line number, or a 
list of acceptable keys for that section? I think it will be necessary for 
the error to relay the absolute path and file that failed, especially with 
nested configs. We could catch that error, and point to the default conf that 
ships with matplotlib, but a little additional information from tconfig would 
be helpful.
It might be nice to be able to deprecate keys as matplotlib or ipython 
evolves. Even with our current system, when we give a helpful message that a 
key is no longer valid, we will sometimes get questions on the mailing lists 
asking how to fix the problem. Raising an error for unrecognized keys might 
be too extreme. Maybe TConfig should have a raiseOnKeyError option, so that 
bad values can be reported with a warning instead, and the end user can get 
up and running without fixing it right away. 
Darren
<class 'tconfig.TConfigInvalidKeyError'> Traceback (most recent call last)
/home/darren/src/ipython1/sandbox/tconfig/mpltest.py in <module>()
 10
 11 mconf = 'mplrc.conf'
---> 12 mplconf = TConfigManager(MPLConfig, mconf, filePriority=True)
 13 mplconf.tconf.backend.use = 'Qt4Agg'
 14 mplconf.write()
/home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self, 
configClass, configFilename, filePriority)
 539
 540 if filePriority:
--> 541 self.tconf = 
configClass(self.fconfCombined,monitor=monitor)
 542 else:
 543 # Push defaults onto file object
/home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self, config, 
parent, monitor)
 369 invalid_scalars = cf_scalars - my_scalars
 370 if invalid_scalars:
--> 371 raise TConfigInvalidKeyError("Invalid keys: %s" % 
invalid_scalars)
 372
 373 # ... and sections
<class 'tconfig.TConfigInvalidKeyError'>: Invalid keys: set(['bogus'])
WARNING: Failure executing file: <mpltest.py>

Peter Wang wrote:
> On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
>> OK. I have to ask -- why aren't we all just using Chaco? 
> Most of ETS is being developed, tested, and run on Windows, Mac, and 
> Linux every day.
Ah, great to know -- that was decidedly not the case the last time I 
took a good look at Chaco.
> Long ago we factored out Chaco's 
> underlying drawing layer into a package called Kiva.
That was there from the beginning if I recall, which is great.
 > Kiva's PS, PDF, SVG, and GL backends
> could all use a little love, but they were functioning at one point 
> in time.
Sorry to play devil's advocate here, but the question remains -- MPL 
developers (John, primarily, I suppose):
Why not dump MPL1, and work on a nice pylab-like front end to Chaco, 
while giving the "love" to the Kiva PS, PDF, SVG back-ends (and add GTK 
-- if it's not there)?
Most users, like me, just want something that does the job for us. I 
know I'm going to take a look at Chaco again.
Add the skills of the MPL team to Chaco, and it could really shine!
-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 7/24/07, Darren Dale <dd...@co...> wrote:
> Hi Fernando,
>
> On Tuesday 24 July 2007 1:34:47 pm Fernando Perez wrote:
> > Just so we save time, would you mind just coding up the failure as a test?
>
> It is attached. Here is the output on my machine:
Great, thanks. Please update. My comments are inlined now:
>
> copying mplrc.conf to mplrc_copy.conf
> loading from mplrc_copy.conf
> Backend loaded from file: Qt4Agg
> Backend now changed to Cairo in tconfig object
> writing file
> reloading from mplrc_copy.conf
> Backend reloaded from file: Cairo
> It should be Cairo
> deleting mplrc_copy.conf
This one is OK.
>--------------------------------------------------------------------------------
>
> creating RecursiveConfManager with no_mplrc.conf, which does not exist
> calling RecursiveConfigManagers write() method
> Here are the contents of no_mplrc.conf:
>
>
> I might have expected to see the MPLConfig defaults
Nope. The point is that a top-level file may well start empty,
without even an 'include' statement at all, and as the user changes
things (via the cmd line or edit_traits()), ONLY those changes will be
written in. This way, users don't carry a lot of declaration of
internal defaults that may potentially change as MPL evolves; this
minimizes the chances for config errors appearing in the future when
they upgrade.
> Backend now changed to: Cairo
> calling RecursiveConfigManagers write() method
> Here are the new contents of no_mplrc.conf:
>
>
> in this test, dsd finds that no_mplrc.conf is empty after both writes
> I suggest that tconfig should either write to the file, or raise an
> error when the file does not exist
> removing no_mplrc.conf
Fixed. See note on file creation at end.
> ------------------------------------------------------------------------
>
> moving mplrc.conf to mplrc.conf.off
> copying mplrc2.conf to mplrc2_copy.conf
> loading config from mplrc2_copy.conf, which includes mplrc.conf-
> but mplrc.conf does not exist
> here are the contents of mplrc2_copy.conf, as loaded
>
> # A hierarchical configuration
> include = 'mplrc.conf'
>
> Backend now changed to: Cairo
> writing to file
> Here are the new contents of mplrc2_copy.conf:
>
> # A hierarchical configuration
> include = 'mplrc.conf'
>
> I might have expected to see the backend.use here
> maybe an error should be raised when a config file includes another
> config file that does not exist
> moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf
Fixed, now raises IOError.
> --------------------------------------------------------------------------
I implemented this policy:
1. Creating a TConfigManager(FooConfig,'missingfile.conf') will work
fine, and 'missingfile.conf' will be created empty.
2. Creating TCM(C,'OKfile.conf') where OKfile.conf has
include = 'missingfile.conf'
conks out with IOError.
My rationale is that creating top-level empty files is a common and
reasonable need, but that having invalid include statements should
raise an error right away, so people know immediately that their files
have gone stale.
It seems to me that this system does everything John and I discussed
over the phone on Sat, and that others have mentioned here.
Basically, MPL could install at startup time a simple matplotlib.conf
file that reads:
# MPL config file. For configuration details, try exloring
# pylab.rc
# If you are using WX or IPython with -wthread, you can try
# pylab.rc.edit_traits()
# for a GUI.
# This file:
# /path/to/full/copy/of/mpl/internal/mpl.conf
# is an auto-generated file with the complete current internal defaults.
# Feel free to copy pieces you need from it if you prefer.
# Note that you can create hierarchies of config files by using
# include = '/path/to/base.conf'
# For more details on MPL's config system, see
# http://matplotlib.sf.net/great/information/page.html
### EOF
That's it. Exactly zero actual data in the default file, just some
information to get people going. This file will only grow what people
actually change, thus minimizing the chances for problems that pop
like dandelions as upgrades happen.
In addition, even users who don't run with WX* backends could always
just start ipython -wthread to tweak their config, save it, and then
go back to using whatever they normally work with in production. WX
would only be needed for the traits GUI to open, not for any of MPL
itself.
Comments, feedback?
Cheers,
f

On Jul 24, 2007, at 10:46 AM, Gael Varoquaux wrote:
>
> AFAIK chaco is based on this approach.
Not as such. Chaco uses traits for its high-level plot objects but 
the rendering system, Kiva, does not appear to use traits all.
mpl1.py is using traits to maintain pre-calculated affine 
transformation matrices and graphics styles for each plot object. I 
believe this approach is confusing and results in rendering code that 
is hard to understand and optimize.
> It makes a very nice API to use in interactive programs.
I agree that an attribute-based API would much nicer for the high- 
level plot objects like Figure and Axes. However, I don't think 
traits are a technical necessity to accomplish that goal.
> As far as understanding and optimizing it would be nice to see if 
> Peter Wang has something to say about this.
It would be great to learn how Chaco/Kiva caches the things that I 
think of as "canvas primitives", like native AGG paths. I'd also be 
interested in learning how the transformation model is implemented in 
Chaco.
Ken

Hi Fernando,
On Tuesday 24 July 2007 1:34:47 pm Fernando Perez wrote:
> Just so we save time, would you mind just coding up the failure as a test?
It is attached. Here is the output on my machine:
copying mplrc.conf to mplrc_copy.conf
loading from mplrc_copy.conf
Backend loaded from file: Qt4Agg
Backend now changed to Cairo in tconfig object
writing file
reloading from mplrc_copy.conf
Backend reloaded from file: Cairo
It should be Cairo
deleting mplrc_copy.conf
--------------------------------------------------------------------------------
creating RecursiveConfManager with no_mplrc.conf, which does not exist
calling RecursiveConfigManagers write() method
Here are the contents of no_mplrc.conf:
I might have expected to see the MPLConfig defaults
Backend now changed to: Cairo
calling RecursiveConfigManagers write() method
Here are the new contents of no_mplrc.conf:
in this test, dsd finds that no_mplrc.conf is empty after both writes
I suggest that tconfig should either write to the file, or raise an
 error when the file does not exist
removing no_mplrc.conf
--------------------------------------------------------------------------------
moving mplrc.conf to mplrc.conf.off
copying mplrc2.conf to mplrc2_copy.conf
loading config from mplrc2_copy.conf, which includes mplrc.conf-
 but mplrc.conf does not exist
here are the contents of mplrc2_copy.conf, as loaded
# A hierarchical configuration
include = 'mplrc.conf'
Backend now changed to: Cairo
writing to file
Here are the new contents of mplrc2_copy.conf:
# A hierarchical configuration
include = 'mplrc.conf'
I might have expected to see the backend.use here
maybe an error should be raised when a config file includes another
 config file that does not exist
moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf
--------------------------------------------------------------------------------

On 7/24/07, Darren Dale <dd...@co...> wrote:
> On Tuesday 24 July 2007 11:29:22 am Fernando Perez wrote:
> > Bummer. It's nice to see that GUI for the whole of MPL running ;)
>
> I know, I really wanted to see this. Are you using traits from
> http://code.enthought.com/enstaller/eggs/source/unstable? I think it has
> something to do with my wx, maybe I am out of date, using wx-2.6.3.3:
Mmh, dunno what the problem may be. I think I'm using a fairly old
source install (of enthought), before eggs. All my machines are
running Feisty.
> > > > You can then save changes via
> > > >
> > > > mplconf2.write()
> > >
> > > The mpltest.py script expects there to be an mplrc2.conf file, but it
> > > isnt in svn. So the script creates an empty mplrc2_copy.conf file, linked
> > > with a default MPLConfig, but if I change some properties of
> > > mplconf2.tconf, and then do mplconf2.write(), the mplrc2_copy.conf file
> > > remains blank.
> >
> > Are you sure? I just ran the test removing the mplrc.conf file from
> > my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
> > after editing the tconf object and calling write(), I *do* get the
> > changes I make written to it. I can't reproduce your problem...
>
> I updated from svn. If mplrc.conf and mplrc2.conf are both present, I can run
> mpltest.py, change mplconf2.tconf.backend.use, call mplconf2.write(), and get
> a mplrc2_copy.conf that contains:
>
> # A hierarchical configuration
> include = 'mplrc.conf'
> [backend]
> use = 'WxAgg'
>
> if I delete mplrc.conf, and repeat the exercise, I get a blank mplrc.conf, and
> an mplrc2_copy.conf that contains:
>
> # A hierarchical configuration
> include = 'mplrc.conf'
>
> If I delete mplrc2.conf, and I make sure that mplrc2_copy.conf has also been
> deleted, the exercise yields a blank mplrc2_copy.conf.
Just so we save time, would you mind just coding up the failure as a test?
Something like (assuming it's inside mpltest.py, so the imports are done):
def test():
 ###
 if blah:
 raise Error('this is what I don't want')
test()
That way we know *exactly* what each other is trying to say. Maybe
I'm just tired (I am), but I'm not quite understanding the problem
you're seeing or the behavior you'd like/expect.
> tconf2File works nicely. One comment, it is not indented like the files that
> are created by tconf.write(), where sections are indented and subsections are
> double-indented.
Fixed to match the behavior of ConfigObj.write(), please update SVN.
Cheers,
f

T24gNy8xNi8wNywgRWRpbiBTYWxrb3ZpYyA8ZWRpbi5zYWxrb3ZpY0BnbWFpbC5jb20+IHdyb3Rl
Ogo+IEhpIGFsbCwKPgo+IEEgbmV3IG1hdHBsb3RsaWItY2hlY2tpbnMgbWFpbGluZyBsaXN0IGhh
cyBiZWVuIGNyZWF0ZWQgZm9yIFNWTiBjb21taXQKPiBub3RpZmljYXRpb24uCj4KPiBZb3UgY2Fu
IHN1YnNjcmliZSB0byBpdCBieSB2aXNpdGluZzoKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdl
Lm5ldC9saXN0cy9saXN0aW5mby9tYXRwbG90bGliLWNoZWNraW5zCgpGb2xsb3dpbmcgSm91bmkg
Sy4gU2VwcMOkbmVuJ3Mgc3VnZ2VzdGlvbiwgSSBhc2tlZCB0aGUgR21hbmUgYWRtaW5zIHRvCmFk
ZCB0aGUgY2hlY2tpbnMgbGlzdCB0byBHbWFuZSdzIGFyY2hpdmUuICBUaGV5IGFkZGVkIGl0IHVu
ZGVyOgpnbWFuZS5jb21wLnB5dGhvbi5tYXRwbG90bGliLnNjbQoKU2VlOgpodHRwOi8vZGlyLmdt
YW5lLm9yZy9nbWFuZS5jb21wLnB5dGhvbi5tYXRwbG90bGliLnNjbQpmb3IgbW9yZSBpbmZvLgoK
RWRpbgo=

On Tuesday 24 July 2007 11:29:22 am Fernando Perez wrote:
> On 7/24/07, Darren Dale <dd...@co...> wrote:
> > On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
> > > Hi all,
> > >
> > > if anyone is still following, please update the tconfig work. Run
> > >
> > > ipython -wthread
> > > %run mpltest.py
> > > mplconf2.tconf.edit_traits()
> > >
> > > Edit to your heart's content.
> >
> > I can't get edit_traits() working on my machine, but I can do it with the
> > command line.
>
> Bummer. It's nice to see that GUI for the whole of MPL running ;)
I know, I really wanted to see this. Are you using traits from 
http://code.enthought.com/enstaller/eggs/source/unstable? I think it has 
something to do with my wx, maybe I am out of date, using wx-2.6.3.3:
/usr/lib/python2.5/site-packages/enthought.traits.ui.wx-2.0b2.dev_r12984-py2.5.egg/enthought/traits/ui/wx/ui_panel.py 
in create_label(self, item, ui, desc, parent, sizer, suffix, pad_side)
 1000 control.help = item.get_help( ui )
 1001 sizer.Add( control, 0, self.label_flags | 
wx.ALIGN_CENTER_VERTICAL |
-> 1002 pad_side, self.label_pad )
 1003 if desc != '':
 1004 control.SetToolTipString( 'Specifies ' + desc )
/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py in Add(*args, 
**kwargs)
 11709 Appends a child item to the sizer.
 11710 """
> 11711 return _core_.Sizer_Add(*args, **kwargs)
 11712
 11713 def Insert(*args, **kwargs):
<type 'exceptions.TypeError'>: wx.Window, wx.Sizer, wx.Size, or (w,h) expected 
for item
> > > You can then save changes via
> > >
> > > mplconf2.write()
> >
> > The mpltest.py script expects there to be an mplrc2.conf file, but it
> > isnt in svn. So the script creates an empty mplrc2_copy.conf file, linked
> > with a default MPLConfig, but if I change some properties of
> > mplconf2.tconf, and then do mplconf2.write(), the mplrc2_copy.conf file
> > remains blank.
>
> Are you sure? I just ran the test removing the mplrc.conf file from
> my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
> after editing the tconf object and calling write(), I *do* get the
> changes I make written to it. I can't reproduce your problem...
I updated from svn. If mplrc.conf and mplrc2.conf are both present, I can run 
mpltest.py, change mplconf2.tconf.backend.use, call mplconf2.write(), and get 
a mplrc2_copy.conf that contains:
# A hierarchical configuration
include = 'mplrc.conf'
[backend]
 use = 'WxAgg'
if I delete mplrc.conf, and repeat the exercise, I get a blank mplrc.conf, and 
an mplrc2_copy.conf that contains:
# A hierarchical configuration
include = 'mplrc.conf'
If I delete mplrc2.conf, and I make sure that mplrc2_copy.conf has also been 
deleted, the exercise yields a blank mplrc2_copy.conf.
tconf2File works nicely. One comment, it is not indented like the files that 
are created by tconf.write(), where sections are indented and subsections are 
double-indented.
> > If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my
> > tconf properties, call write(), and those changes do get updated in
> > mplrc2_copy.conf.
> >
> > > ps - the auto-generated file now has all class docstrings as comments
> > > as well as traits handlers info. It should be a pretty good start for
> > > a manually tweaked one.
> >
> > I have not been able to auto-generate a default file. As above, the file
> > is blank after writing.
>
> How are you trying to generate it? Does the printout on-screen at
> least write a full config for you?
It does. I was creating a RecursiveConfigManager with a string pointing to a 
file that does not exist, and then calling that manager's write() method.
Darren

On Tuesday 24 July 2007 12:05:15 pm Darren Dale wrote:
> On Tuesday 24 July 2007 9:38:43 am Nils Wagner wrote:
> > Hi all,
> >
> > Is there a way to suppress the warning
> >
> > /usr/local/lib64/python2.5/site-packages/matplotlib/texmanager.py:137:
> > UserWarning: No LaTeX-compatible font found for the sans-serif font
> > family in rcParams. Using default.
> > warnings.warn('No LaTeX-compatible font found for the %s font family
> > in rcParams. Using default.' % ff)
>
> I'm working on it...
Its fixed in svn 3608.

On Tuesday 24 July 2007 9:38:43 am Nils Wagner wrote:
> Hi all,
>
> Is there a way to suppress the warning
>
> /usr/local/lib64/python2.5/site-packages/matplotlib/texmanager.py:137:
> UserWarning: No LaTeX-compatible font found for the sans-serif font
> family in rcParams. Using default.
> warnings.warn('No LaTeX-compatible font found for the %s font family
> in rcParams. Using default.' % ff)
I'm working on it...

On Tue, Jul 24, 2007 at 10:31:05AM -0500, Ken McIvor wrote:
> In retrospect, I should've been clearer about my objection to using 
> traits in mpl1. I don't have any problem with enthought.traits in an 
> abstract sense -- it seems like an excellent solution to the problems 
> of attribute validation and change notification. My concerns regard 
> building a backend rendering system that uses change notifications to 
> maintain graphics state. I believe this approach makes the rendering 
> system harder to understand and optimize.
AFAIK chaco is based on this approach. It makes a very nice API to use in
interactive programs. As far as understanding and optimizing it would be
nice to see if Peter Wang has something to say about this.
Gaël

On Jul 23, 2007, at 7:18 PM, Peter Wang wrote:
> On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
>>
>> 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.
>
> This is a true statement. In fact, the first version of traits
> basically used properties to implement a lot of the validation and
> notification. Eventually for power and speed, we moved to using a
> metaclass with a C extension.
>
> I think the code readability question comes down to "is it easier for
> someone to learn some basic things about traits, or is it easier for
> them to decipher the massive jumble of property setters and getters
> I've wired up"? I think that the amount of duplicated code that has
> to written using simple python properties is non-trivial.
In retrospect, I should've been clearer about my objection to using 
traits in mpl1. I don't have any problem with enthought.traits in an 
abstract sense -- it seems like an excellent solution to the problems 
of attribute validation and change notification. My concerns regard 
building a backend rendering system that uses change notifications to 
maintain graphics state. I believe this approach makes the rendering 
system harder to understand and optimize.
Since my original comment about traits I have been working hard to 
put my money where my mouth is. Attached is an experimental 
rendering system with an alternative transform architecture that does 
not require attribute change notification. Please let me know what 
you think, everybody.
Ken

On 7/24/07, Darren Dale <dd...@co...> wrote:
> On Tuesday 24 July 2007 7:57:37 am John Hunter wrote:
> > On 7/24/07, Fernando Perez <fpe...@gm...> wrote:
> > > Hi all,
> > >
> > > if anyone is still following, please update the tconfig work. Run
> > >
> > > ipython -wthread
> > > %run mpltest.py
> > > mplconf2.tconf.edit_traits()
> > >
> > > Edit to your heart's content.
> >
> > I am not running in wthred, but I think there may be an import problem
> > somewhere
>
> Line 347 in tconfig.py, change TraitError to T.TraitError
Fixed in SVN, sorry. That's why the last ToDo item on this before
considering it really semi-done is to turn the test scripts into real
doc/unit tests that also exercise the exception-generation codepaths.
Otherwise crap like this creeps in...
Cheers,
f

On 7/24/07, Darren Dale <dd...@co...> wrote:
> On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
> > Hi all,
> >
> > if anyone is still following, please update the tconfig work. Run
> >
> > ipython -wthread
> > %run mpltest.py
> > mplconf2.tconf.edit_traits()
> >
> > Edit to your heart's content.
>
> I can't get edit_traits() working on my machine, but I can do it with the
> command line.
Bummer. It's nice to see that GUI for the whole of MPL running ;)
> > You can then save changes via
> >
> > mplconf2.write()
>
> The mpltest.py script expects there to be an mplrc2.conf file, but it isnt in
> svn. So the script creates an empty mplrc2_copy.conf file, linked with a
> default MPLConfig, but if I change some properties of mplconf2.tconf, and
> then do mplconf2.write(), the mplrc2_copy.conf file remains blank.
Are you sure? I just ran the test removing the mplrc.conf file from
my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
after editing the tconf object and calling write(), I *do* get the
changes I make written to it. I can't reproduce your problem...
> If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my tconf
> properties, call write(), and those changes do get updated in
> mplrc2_copy.conf.
>
> > ps - the auto-generated file now has all class docstrings as comments
> > as well as traits handlers info. It should be a pretty good start for
> > a manually tweaked one.
>
> I have not been able to auto-generate a default file. As above, the file is
> blank after writing.
How are you trying to generate it? Does the printout on-screen at
least write a full config for you?
Please update and try again, I added a little utility called
tconf2File() to wrap this writing process; there's a small subtlety
that I might not have been clear about before (one has to write the
str() form of the tconf object to get the class docstring extraction).
>
> > pps - I'm done with this, for a while. I've sunk *way* too much time into
> > it.
>
> Thank you Fernando. I'll have a look at the issues I reported when I get a
> chance.
Thanks.
Cheers,
f

Replying to this, even though I replied to a later message to 
enthought-dev, since this one is also cc'd to matplotlib-devel....
Darren Dale wrote:
> On Sunday 22 July 2007 02:10:50 pm John Hunter wrote:
> 
>> On 7/22/07, Dave Peterson <dpe...@en...> wrote:
>> 
>>> Just uploaded a new source tarball that I believe should have this fixed
>>> so that you don't need to install enthought.resource. Basically, I
>>> 
>> Bingo, I am now getting a working install with
>>
>> sudo easy_install -f
>> http://code.enthought.com/enstaller/eggs/source/unstable
>> "enthought.traits < 3.0a"
>>
>> which brings in only etsconfig, util and traits. Thanks for tracking this
>> down.
>> 
>
> I just ran that command myself (9:45 EST, July 23), and it installed:
>
> enthought.debug-2.0b2.dev_r12984-py2.5.egg/
> enthought.developer-2.0b2.dev_r12984-py2.5.egg/
> enthought.envisage-2.0b2.dev_r12984-py2.5.egg/
> enthought.etsconfig-2.0b1.dev_r12883-py2.5.egg/
> enthought.help-2.0b2.dev_r12984-py2.5.egg/
> enthought.io-2.0b1.dev_r12810-py2.5.egg/
> enthought.logger-2.0b2.dev_r12984-py2.5.egg/
> enthought.naming-2.0b2.dev_r12810-py2.5.egg/
> enthought.plugins.text_editor-2.0b2.dev_r12984-py2.5.egg/
> enthought.pyface-2.0b2.dev_r12984-py2.5.egg/
> enthought.resource-2.0b1.dev_r12810-py2.5.egg/
> enthought.sweet_pickle-2.0b2.dev_r12810-py2.5.egg/
> enthought.traits-2.0b2.dev_r12984-py2.5-linux-x86_64.egg/
> enthought.traits.ui.wx-2.0b2.dev_r12984-py2.5.egg/
> enthought.type_manager-2.0b1.dev_r12810-py2.5.egg/
> enthought.units-2.0b2.dev_r12984-py2.5.egg/
> enthought.util-2.0b2.dev_r12981-py2.5.egg/
> 
:-( I validated that this is indeed the current state of things as a 
result of my adding in extras to the dependencies that previously 
existed. Looks like we'll have to delay our release to spend more time 
minimizing these dependencies.
-- Dave

Hi all,
Is there a way to suppress the warning
/usr/local/lib64/python2.5/site-packages/matplotlib/texmanager.py:137:
UserWarning: No LaTeX-compatible font found for the sans-serif font
family in rcParams. Using default.
 warnings.warn('No LaTeX-compatible font found for the %s font family
in rcParams. Using default.' % ff)
Nils
 

On Tuesday 24 July 2007 7:57:37 am John Hunter wrote:
> On 7/24/07, Fernando Perez <fpe...@gm...> wrote:
> > Hi all,
> >
> > if anyone is still following, please update the tconfig work. Run
> >
> > ipython -wthread
> > %run mpltest.py
> > mplconf2.tconf.edit_traits()
> >
> > Edit to your heart's content.
>
> I am not running in wthred, but I think there may be an import problem
> somewhere
Line 347 in tconfig.py, change TraitError to T.TraitError

On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
> Hi all,
>
> if anyone is still following, please update the tconfig work. Run
>
> ipython -wthread
> %run mpltest.py
> mplconf2.tconf.edit_traits()
>
> Edit to your heart's content.
I can't get edit_traits() working on my machine, but I can do it with the 
command line.
> You can then save changes via
>
> mplconf2.write()
The mpltest.py script expects there to be an mplrc2.conf file, but it isnt in 
svn. So the script creates an empty mplrc2_copy.conf file, linked with a 
default MPLConfig, but if I change some properties of mplconf2.tconf, and 
then do mplconf2.write(), the mplrc2_copy.conf file remains blank. 
If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my tconf 
properties, call write(), and those changes do get updated in 
mplrc2_copy.conf.
> ps - the auto-generated file now has all class docstrings as comments
> as well as traits handlers info. It should be a pretty good start for
> a manually tweaked one.
I have not been able to auto-generate a default file. As above, the file is 
blank after writing.
> pps - I'm done with this, for a while. I've sunk *way* too much time into
> it.
Thank you Fernando. I'll have a look at the issues I reported when I get a 
chance.
Darren

On 7/24/07, Fernando Perez <fpe...@gm...> wrote:
> Hi all,
>
> if anyone is still following, please update the tconfig work. Run
>
> ipython -wthread
> %run mpltest.py
> mplconf2.tconf.edit_traits()
>
> Edit to your heart's content.
I am not running in wthred, but I think there may be an import problem somewhere
In [3]: run mpltest.py
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/Users/jdhunter/tmp/sandbox/tconfig/mpltest.py in <module>()
 10
 11 mconf = 'mplrc.conf'
---> 12 mplconf = RecursiveConfigManager(MPLConfig, mconf, filePriority=True)
 13 mplconf.tconf.backend.use = 'Qt4Agg'
 14 mplconf.write()
/Users/jdhunter/tmp/sandbox/tconfig/tconfig.py in __init__(self,
configClass, configFilename, filePriority)
 442
 443 if filePriority:
--> 444 self.tconf = configClass(self.fconfCombined,monitor=monitor)
 445 else:
 446 # Push defaults onto file object
/Users/jdhunter/tmp/sandbox/tconfig/tconfig.py in __init__(self,
config, parent, monitor)
 345 getattr(self,k)
 346 scal = getattr(self,k)
--> 347 except TraitError,e:
 348 t = self.__class_traits__[k]
 349 msg = "Bad key,value pair given: %s -> %s\n" % (k,config[k])
NameError: global name 'TraitError' is not defined
WARNING: Failure executing file: <mpltest.py>
> pps - I'm done with this, for a while. I've sunk *way* too much time into it.
We've heard that before :-)

Hi all,
if anyone is still following, please update the tconfig work. Run
ipython -wthread
%run mpltest.py
mplconf2.tconf.edit_traits()
Edit to your heart's content.
You can then save changes via
mplconf2.write()
Cheers,
f
ps - the auto-generated file now has all class docstrings as comments
as well as traits handlers info. It should be a pretty good start for
a manually tweaked one.
pps - I'm done with this, for a while. I've sunk *way* too much time into it.

On 7/21/07, Darren Dale <dd...@co...> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <dd...@co...> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know to avoid duplicating
> > > effort.
> >
> > Excellent! Ping me if you have any problems.
>
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try your trick of modifying a well formatted file in place. Very nice!
You may want to update before touching the code further. I moved some
(not all, I didn't finish it and only meant to do enough to
illustrate) of the comments you had in mpl.conf into the class
docstrings. The TConfig __repr__ method now automatically adds these
(as comments), so that auto-generated config files, if done purely
from the TConfig class description, are still readable and possibly
even useful. You can run mpltest.py to see what I mean, I made it
just print out a purely default config at the end.
Cheers,
f

On Jul 19, 2007, at 10:42 PM, Ken McIvor 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.
>
> Is there somewhere in particular that I can look to see what 
> Peter's been working on? Enthought's svn repositories?
I would recommend grabbing the eggs:
https://svn.enthought.com/enthought/wiki/InstallWithEggs
After installing the eggs, you can grab the chaco2 examples from SVN:
svn co https://svn.enthought.com/svn/enthought/branches/ 
enthought.chaco2_2.0/examples
Let me know if you have any problems!
>> = 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.
This is a true statement. In fact, the first version of traits 
basically used properties to implement a lot of the validation and 
notification. Eventually for power and speed, we moved to using a 
metaclass with a C extension.
I think the code readability question comes down to "is it easier for 
someone to learn some basic things about traits, or is it easier for 
them to decipher the massive jumble of property setters and getters 
I've wired up"? I think that the amount of duplicated code that has 
to written using simple python properties is non-trivial. Of course, 
this being Python, people are going to be tempted to write some code 
to generate code or at least do some simple metaprogramming when they 
are faced with writing their 50th setter/getter. This then leads to 
the problem of documenting and testing the code-generating functions, 
and newcomers will have to learn about those and what they mean and 
what their side effects are. With traits, there is at least a well- 
tested and documented design that has been through the ringer a few 
times.
> Change notification is another matter, granted, but I think that a 
> major rewrite will provide the opportunity to better design for 
> those situations.
I actually think that change notification, more so than validation, 
is the killer feature of traits. After you write enough code with 
objects that communicate via notifications, you start really thinking 
of your running program as a little ecosystem of live objects, and 
it's an entirely different mental model for design and 
implementation. It's especially reinforced if you use Traits UI to 
bring up dialogs to interact with these live objects, or use IPython 
to start twiddling them as they're running, and you can see things 
change realtime, automagically.
Just my (slight biased) $.02. :)
-Peter

On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
>> 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.
Pad with NaNs?
>> = 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?
Most of ETS is being developed, tested, and run on Windows, Mac, and 
Linux every day. We now have eggs for windows and mac and some 
flavors of linux (fedora, ubuntu). Long ago we factored out Chaco's 
underlying drawing layer into a package called Kiva. Kiva has Agg- 
based backends for wxWindows on X11 and Win32, and a native Quartz 
backend for wxWindows on OS X. There is also a PIL-based non- 
interactive raster backend. Kiva's PS, PDF, SVG, and GL backends 
could all use a little love, but they were functioning at one point 
in time.
-Peter

On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> = Data copying =
>
> Push the data to the backend only once, or only when required. Update
> the transforms in the backend, but do not push transformed data on
> every draw. This is potentially a major win, because we currently
> move the data around on every draw.
Does the backend keep a copy of the untransformed data around, so 
that it can easily create new transformed data when its transform is 
updated? If so, is there a coherent mechanism for invalidating a 
piece of data that is being graphed in multiple plots? If not, then 
how does hittesting determine the correct index into the data (since, 
presumably, hittesting will require the exact transform in the backend)?
> = Transformations =
>
> Support a normal transformation architecture. The current draft
> implementation assumes one nonlinear transformation, which happens at
> a high layer, and all transformations after that are affines. In the
> mpl1 draft, there are three affines: the transformation from view
> limits -> axes units (AxesCoords.affineview), the transformation from
> axes units to normalized figure units (AxesCoords.affineaxes), and the
> transformation from normalized figure units to display
> (Renderer.affinerenderer)
>
> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
I admit the temptation of having basic 3D support, but the problem is 
that it really doesn't scale well in software. Even the simple blits 
that we do in Chaco start to hit their limits on big, high-res LCDs 
that are getting cheaper every day. The approach that I think we're 
going to have to take in Chaco is to only let 3D be available when 
using the OpenGL backend, and to restrict the Agg-based backends to 
be 2D only.
Of course, I'm thinking about all this from an interactive 
standpoint, so if speed is not a concern, then there's no reason not 
to build in 3D support from the get-go.
> How do transformations (linear and nonlinear) play with Axis features
> (ticking and gridding). The ideal is a framework in which ticking,
> gridding and labeling work intelligently with arbitrary, user
> supplied, transformations. What is the proper transformation API?
This is something we've been puzzling over for Chaco as well. Dave 
Kammeyer pointed out long ago that the problem with trying to write a 
generic axis/grid renderer while supporting arbitrary transformations 
is that straight lines become curves under arbitrary transforms. The 
basic idea is that the backend (or GraphicsContext, in the Chaco 
world) needs to provide transformation-aware implementations of 
line_to() that automatically convert line segments into bezier curves 
while at the same time providing drawing methods that are guaranteed 
to be "straight" or aligned with screen coordinates. This way, you 
can get curved axes in a hyperbolic space "for free", while your 
ticks stay perfectly straight and the label text is screen-aligned. 
(Of course, to be perfectly accurate, you would need to handle polar 
coordinates in a special way anyway.)
> = 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).
> Each of these will carry their metadata, eg a path will carry its
> stroke color, facecolor, linewidth, etc..., and Text will carry its
> font size, color, etc.... We may need some optimizations down the
> road, but we should start small. For now, let's call these objects
> "primitives".
>
> = 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? Probably,
> for user convenience and general compability with matplotlib. By
> using traits properly here, many current matplotlib Arists will be
> thin interfaces around one or more primitives.
I included these two together because I think they both concern a 
very fundamental matter, which is the drawing model. If you are 
going to create higher-level "primitives" which encapsulate state 
(e.g. color, dash style, line width), then you are moving 
significantly away from the model of a Canvas as just a place to dump 
pixels/vector drawing commands, and more towards the model of Canvas 
as a container of stateful objects. But as soon as you do this, a 
whole host of questions pop up... Are the Circle, Rectangle, etc. in 
the "intermediate artist layer" objects in their own right, with 
parameters like 'radius', 'position', etc., or are they just 
convenience functions to create more low-level primitives on the 
Canvas? If the former, then you have suddenly have a hierarchical 
Canvas. If the latter, then is there any structure to how these 
primitives are held in the Canvas? Even if they are just held in a 
simple list, are they drawn in the same order as they appear in that 
list? If they were inserted by a single Circle or Rectangle 
intermediate artist, is there any way to ensure that they maintain 
coherency when re-ordering that draw order?
Also, if you have a list of these primitives, it seems natural to 
hittest against them for picking and interaction. Does this also 
happen in the same order that they appear in the list? Is there a 
straightforward way to make them process events in a different 
order? If you have lots of these little primitives, are there 
optimizations you can design in so that you don't have to hittest 
thousands of little primitives on each mouse_move event?
> = 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?
Well, you can probably guess my answer to this question. :) It seems 
to me that if you're going to have a drawing model that supports 
stateful graphics on a canvas, plot renderers should just be 
glorified graphics that live on the canvas, no different from a 
Circle or a Rectangle or whatnot. In this case, the plot functions 
then just become convenience functions that create these graphics and 
stick them on a canvas.
> I think the whole matplotlib.collections module is poorly designed,
> and should be chucked wholesale, in favor of faster, more elegant,
> optimizations and special cases. Just having the right Path object
> will reduce the need for many of these, eg LineCollection,
> PolygonCollection, etc... Also, everything should be numpy enabled,
> and the sequence-of-python-tuples approach that many of the
> collections take should be dropped. Obviously some of the more useful
> things there, like quad meshes, need to be ported and retained.
In Chaco we can get interactive speeds just by having a few fast 
drawing calls at the Kiva layer: lines(), line_set(), 
draw_marker_at_points(). These were quite easy to implement in both 
the Agg and Quartz backends. We've talked about introducing another 
set of drawing commands that allow passing in a "style index" with 
every point, so that we can speed up our colormapped scatter plots 
and eventually do colormapped lines and such.
> = 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 think that you should really consider integrating the event 
propagation model with the drawing model. The Chaco model of 
"containers of graphical components" is pretty straightforward and 
even though we've implemented it in pure python, it is responsive 
enough for interactivity. The nice thing about it is that there's 
nothing in the container/component model that is intrinsically 
related to plotting, so you can use it to build simple widgets that 
play nicely with the rest of your plot because they use the same 
event propagation and component drawing model. I can put together 
some more thorough documentation on all this, if folks are interested.
> 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.
How exactly are you guys wrapping Agg? I guess I need to take a look 
at that stuff in more detail... Kiva has been fairly stable, even 
though we don't do much maintenance on it, and the DisplayPDF drawing 
model has worked out fairly well. After Robert put together the 
Quartz backend for it, we can nicely verify that our Agg-based 
implementation of DisplayPDF is fairly good, since our plots render 
the same on Windows and Mac. If we had just put in a little more 
effort on optimization for Linux and cleaning up some outdated cruft, 
I think it would be in really good shape. Additionally, Phil 
Thompson is going to be working on porting Kiva and Enable to Qt. 
Kiva's Agg backend is based on Agg 2.4, which is still BSD.
> The major missing piece in ft2font, which is a pretty elaborate CXX
> module. Michael may want to consider alternatives, including looking
> at the agg support for freetype, and the kiva/chaco approach.
Unfortunately, Chaco's font handling isn't anything to write home 
about.. I think the world is crying out for a nice Python library for 
font lookup and font metrics.
> = 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.
> With the UI (wx only) , they are a major win for many GUI developers.
> Compare the logic for sharing an x-axis using matplotlib transforms
> with Axes.sharex with the approach used in mpl1.py with sync_trait-ed
> affines.
Once you start using trait events and notifications extensively, you 
won't want to go back. :) It encourages a very componentized model 
of development that is both a world apart from normal OOP while at 
the same time feeling very natural.
> = Axis handling =
>
> The whole concept of the Axes object needs to be rethought, in light
> of the fact that we need to support multiple axis objects on one Axes.
> The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
> and we hack two y-axis support (examples/two_scales.py) with some
> transform shenanigans via twinx and multiple Axes where one is hidden,
> but the approach is not scalable and is unwieldy.
>
> This will require a fair amount of thought, but we should aim for
> supporting an arbitrary number of axis obects, presumably associated
> with individual artists or primitives.
> ...
> The other important featiure for axis support is that, for the most
> part, they should be arbitrarily placeable (eg a "detached" axis).
I think you should consider separating the two concerns that are 
being overloaded onto the Axis object: (1) an axis represents a range 
in data space that controls the transforms/mappings between data and 
screen space, and (2) an axis is a visual component that needs to be 
rendered at a particular place on the screen and receives events from 
the user (e.g. double-clicking to set its parameters).
If you create a separate DataRange object, then you can use it to 
drive one or more Transforms as well as multiple Axis objects. This 
is basically how Chaco gets synchronized axes for "free". The actual 
graphical Axis objects can render themselves however they want to, 
and their actual layout on the screen (on opposite sides of a plot, 
piled up in a stack on the left or right, etc.) is determined by a 
layout mechanism that is completely orthogonal to the issues of 
mapping. This also allows for "detached" axes and such.
> = 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.
I really glad to read this, because I think there are clearly a lot 
of common problems that we all have to solve. At its core, Chaco is 
not *that* complex - it's just rather poorly documented, and that is 
no one's fault but mine. The structure, however, is really pretty 
straightforward. Its container/component model is not much more 
complicated than what a minimal solution to some of the problems I've 
outlined in previous paragraphs would entail.
I guess the key question I would ask is this: What is the vision, or 
driving purpose, behind mpl1? Is it to develop a better backend 
architecture for pylab, or something more? I ask this because some 
of the designs you have proposed for various pieces of mpl1 look very 
much like they are trying to solve the same problems that we're 
trying to solve in Chaco; if you really are quite prepared to "break 
the hell out of matplotlib", I think that now would be a really good 
time for collaboration. :)
-Peter

On 7/21/07, Darren Dale <dd...@co...> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <dd...@co...> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know to avoid duplicating
> > > effort.
> >
> > Excellent! Ping me if you have any problems.
>
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try your trick of modifying a well formatted file in place. Very nice!
Thanks, I added your more recent version. I also changed the base
class to HasStrictTraits, so that junk can't be added to the instance
post-creation via rc.junk='foo'.
There is also more support for recursive inclusion. Unfortunately I
didn't finish everything (I took a break on Sunday) and right now I
can't work on this, so it may not quite do everything you want it to.
But let's try to pinpoint what's still missing, and I'll find some
time this week in the evenings to finish it up while the logic is
still in my head.
cheers,
f