On 7/21/07, Darren Dale [EMAIL PROTECTED] wrote:
On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
On 7/21/07, Darren Dale [EMAIL PROTECTED] 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
Im attaching a patch
Is the patch against current SVN?
It was one version out of date. Here is a new one, against 2533
Index: mpltest.py
===
--- mpltest.py (revision 2533)
+++ mpltest.py (working copy)
@@ -5,43 +5,14 @@
import
On 7/21/07, Darren Dale [EMAIL PROTECTED] wrote:
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
Hi John,
On Sunday 22 July 2007 9:51:05 am John Hunter wrote:
On 7/21/07, Darren Dale [EMAIL PROTECTED] wrote:
2) It would be nice to be able to write a default file that has
everything commented out with the exception of backend.use and numerix.
We comment out all the parameters in the
On Sun, Jul 22, 2007 at 11:43:31AM -0400, Darren Dale wrote:
The issue of configuration has come up several times on the mailing
lists over the last few years, and Fernando's tconfig feels like the
right solution. On the other hand, I can't be too enthusiastic about
pushing for inclusion in
On 7/22/07, Darren Dale [EMAIL PROTECTED] wrote:
the other hand, I can't be too enthusiastic about pushing for inclusion in
matplotlib in the near future, because I havent been able to install traits
as a separate package. At the moment, the following command
Well, we always have
On 7/21/07, Darren Dale [EMAIL PROTECTED] 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.
I'm going to try and finish hierarchical
On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
On 7/21/07, Darren Dale [EMAIL PROTECTED] 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
On 7/19/07, Darren Dale [EMAIL PROTECTED] wrote:
Damn, that is really cool. So you can generate default config files from the
MPLConfig instance. We create a default matplotlibrc file from a template,
setting default backend and numerix values based on what is available on the
users system.
On Wed, Jul 18, 2007 at 11:24:09AM -0600, Brian Granger wrote:
At some level though, configuration is a very different thing than an
application's runtime API. While they may be related (by exposing
common functionality), not everything that can be configured would
appear in a runtime API and
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.
On 7/20/07, Fernando Perez [EMAIL PROTECTED] wrote:
However, it's not all gloom and doom: one can simply generate a config
file from the object description, edit it for ordering, and after that
keep it synced with changes to the object description fairly easily.
The current code only works in
On 7/20/07, Fernando Perez [EMAIL PROTECTED] wrote:
On 7/20/07, Darren Dale [EMAIL PROTECTED] wrote:
This should give you a very reasonable solution for what you wanted to do.
Great! I'm surprised that this was possible.
And actually easy, for once.
Im attaching a patch for the
On 7/20/07, Darren Dale [EMAIL PROTECTED] wrote:
On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote:
I also just (r2528) updated things to use a cleaner import convention:
I don't like importing things from modules *they* imported.
[...]
The point is that instead of
-from
On Thursday 19 July 2007 8:02:53 pm Fernando Perez wrote:
- Consider a file called mpl.conf:
# Top-level
backend = TkAgg
interactive = False
# Things that can only be set at init time, they become read-only
afterwards
[InitOnly]
numerix = numpy
[...]
- Then, consider the following bit
On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
On 7/16/07, Eric Firing [EMAIL PROTECTED] 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
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
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
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
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
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,
On 7/17/07, Darren Dale [EMAIL PROTECTED] 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.
Sorry for double posting. Apparently the original posting was html formatted,
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
On 7/17/07, Michael Droettboom [EMAIL PROTECTED] 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,
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
Darren Dale wrote:
I've been thinking a bit about rcParams and validation. It looks like values
are currently only validated when matplolibrc is read, during the call to
rc_params. What if we define a new class (RcParams), derived from dict, which
has as an attribute, a dict, called
On Monday 16 July 2007 7:22:37 pm you wrote:
Darren Dale wrote:
I've been thinking a bit about rcParams and validation. It looks like
values are currently only validated when matplolibrc is read, during the
call to rc_params. What if we define a new class (RcParams), derived from
dict,
On 7/16/07, Darren Dale [EMAIL PROTECTED] wrote:
John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
seem more appealing to me than properties, but I was looking for something
that could be done outside of a chainsaw branch. If we decided on traits, we
should also try
On 7/16/07, Darren Dale [EMAIL PROTECTED] wrote:
John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
seem more appealing to me than properties, but I was looking for something
that could be done outside of a chainsaw branch. If we decided on traits, we
should also try
John Hunter wrote:
[...]
Isn't there a potential problem here? The original validate funcs
support conversion from a string to a value, but you are proposing
using them here in a context where users will generally be supplying a
(possibly bogus) value, but in general not a string. So the
John Hunter wrote:
On 7/16/07, Eric Firing [EMAIL PROTECTED] wrote:
Are any real, live projects outside of enthought making major use of
traits? Or would we be the first?
Yes. Most are in the somewhat formative stages, so you may not think they count
(which is fine).
I am happy to be the
31 matches
Mail list logo
