Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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'] = 2
--
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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/17/07, Darren Dale <[EMAIL PROTECTED]> 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'] = 2 I prefer controllerConfig.listenForEnginesOn.ip = '127.0.0.1' controllerConfig.listenForEnginesOn.port = 2 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] negative log transforms
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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Tuesday 17 July 2007 11:22:29 am John Hunter wrote: > 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. 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] negative log transforms
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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 [EMAIL PROTECTED] - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] negative log transforms
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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, 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Steeling some of you colormaps
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Steeling some of you colormaps
On 7/17/07, Gael Varoquaux <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 <[EMAIL PROTECTED]> wrote: > On 7/17/07, Darren Dale <[EMAIL PROTECTED]> 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'] = 2 > > I prefer > > controllerConfig.listenForEnginesOn.ip = '127.0.0.1' > controllerConfig.listenForEnginesOn.port = 2 > > 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 ju
Re: [matplotlib-devel] [Enthought-dev] Good feedback on traits
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Good feedback on traits
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Good feedback on traits
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Good feedback on traits
On Wed, Jul 18, 2007 at 01:49:19AM -0500, Robert Kern wrote: > 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. Well if _you_ say this, than I'll trust you. Especially since there are some really nifty features in Traits 3. Cheers, Gaël - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
