[matplotlib-devel] rcparams/traits
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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Fernando Perez <[EMAIL PROTECTED]> 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 () 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: > pps - I'm done with this, for a while. I've sunk *way* too much time into it. We've heard that before :-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On Tuesday 24 July 2007 7:57:37 am John Hunter wrote: > On 7/24/07, Fernando Perez <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] texmanager.py:137
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
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] rcParams and validation
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 <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: > On Tuesday 24 July 2007 7:57:37 am John Hunter wrote: > > On 7/24/07, Fernando Perez <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
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 #!/usr/bin/env python # Name: mpl1_displaypdf.py # Purpose: Experimental rendering system using DisplayPDF's drawing model # Author: Ken McIvor <[EMAIL PROTECTED]> # # Copyright 2007 Illinois Institute of Technology # # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # "Software"), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # # The above copyright notice and this permission notice shall be # included in all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL ILLINOIS INSTITUTE OF TECHNOLOGY BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # # Except as contained in this notice, the name of Illinois Institute # of Technology shall not be used in advertising or otherwise to promote # the sale, use or other dealings in this Software without prior written # authorization from Illinois Institute of Technology. # # Derived from code Copyright 2007 John D. Hunter and released under the # license agreement for matplotlib 0.90.1 """ An experimental rendering system inspired by John Hunter's mpl1.py. This system uses a Renderer to draw series of Primitive plot objects on a Canvas implementing some of DisplayPDFs' drawing model and graphics state. The current transformation matrix is an affine transformation matrix are stored in PDF's form: a b 0 c d 0 e f 1 A Render uses the Canvas's DisplayPDF operations to draw Primitives on the Canvas. The Renderer draws in units of 1/72 of an inch with a scaling specified in dots-per-inch. Primitives may be modified at any time and may be shared between Renderers. A Canvas may have more than one Renderer associated with them. A Renderer may be associated with more than one Canvas during its lifetime. The Group primitives (Group, CanvasScaledGroup, and ScaledView) work like matlab's 'hgtransform' plot objects. The CanvasScaledGroup renderer works like an mpl1 FigurePane. """ from matplotlib import agg import numpy as npy def affine_identity(): """ a b 0 c d 0 e f 1 """ affine = npy.zeros((3,3), npy.float_) affine[0,0] = affine[1,1,] = affine[2,2] = 1 return affine def affine_from_values(a, b, c, d, e, f): affine = npy.zeros((3,3), npy.float_) affine[:,0] = a, c, e affine[:,1] = b, d, f affine[2,2] = 1 return affine def affine_from_rotation(angle): return affine_rotate(affine_identity(), angle) def affine_from_scale(sx, sy): return affine_scale(affine_identity(), sx, sy) def affine_from_translation(tx, ty): return affine_tra
Re: [matplotlib-devel] mpl1 draft
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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] texmanager.py:137
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...
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] texmanager.py:137
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.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On Tuesday 24 July 2007 11:29:22 am Fernando Perez wrote: > On 7/24/07, Darren Dale <[EMAIL PROTECTED]> 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 | -> 1002pad_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): : 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New matplotlib-checkins mailing list
On 7/16/07, Edin Salkovic <[EMAIL PROTECTED]> wrote: > Hi all, > > A new matplotlib-checkins mailing list has been created for SVN commit > notification. > > You can subscribe to it by visiting: > https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins Following Jouni K. Seppänen's suggestion, I asked the Gmane admins to add the checkins list to Gmane's archive. They added it under: gmane.comp.python.matplotlib.scm See: http://dir.gmane.org/gmane.comp.python.matplotlib.scm for more info. Edin - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> 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
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
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 mpltest2.py Description: application/python - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mpl1 + chaco
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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On Tuesday 24 July 2007 5:49:27 pm Fernando Perez wrote: > On 7/24/07, Darren Dale <[EMAIL PROTECTED]> 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 TConfi
Re: [matplotlib-devel] mpl1 + chaco
On Tuesday 24 July 2007 6:43:03 pm Chris Barker wrote: > 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! I could quickly find myself out of my depth on this topic, so I'll just make a couple quick points. I need to create plots for qt4 projects at my lab, and I have grown really accustomed to the quality of mpl's eps output when usetex is enabled. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: > Thank you for all you have already done, Fernando. My pleasure. I hope this will be useful for all of us, and that we can offer to users unified mechanisms for dealing with the various pieces of the 'scientific python toolkit' puzzle. > 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. I can't pull line number information from ConfigObj: http://www.voidspace.org.uk/python/configobj.html#todo (see last line), but now the exception message reads: TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf' Contains the following invalid keys: ['bogus'] The valid keys for this section are: ['maskedarray', 'datapath', 'numerix', 'timezone', 'toolbar', 'interactive'] and similarly for invalid sections. At least with the filename and the list of bad/good values, people should be able to fend for themselves. If not, let them use matlab :) Please update and let me know what happens. > 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. As I told John, you can already do that: when you deprecate a Key, simply change it from class Foo(TConfig): somekey = T.Int to somekey = DeprecatedKey where DeprecatedKey is a Trait you declare, whose handler/validator provides the necessary information to the user, sends warnings, it can even set the proper value in the new form of that information if it makes sense, etc. Use the Traits, Luke :) Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
Darren Dale wrote: > I need to create plots for qt4 projects at my lab, and I > have grown really accustomed to the quality of mpl's eps So we need QT and EPS. > output when usetex is enabled. Ah! and some good math implementation -- What does Chaco do for that? I know I took part in a discussion about it on a Chaco list a few years back -- at the time I argued that you're never going to do as well at TeX. These aren't deal-breakers so far -- it sounds like Kiva has at least rudimentary QT support -- and I imagine a MPL usetex-like approach could be applied to Chaco too (though I'd rather see the DVI parsed and rendered by Kiva...) -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote: > On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: [...] > > Would it be possible to provide some more context for bad > > sections or keys? [...] > now the exception message reads: > > > TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf' > Contains the following invalid keys: ['bogus'] > The valid keys for this section are: ['maskedarray', 'datapath', > 'numerix', 'timezone', 'toolbar', 'interactive'] > > and similarly for invalid sections. At least with the filename and > the list of bad/good values, people should be able to fend for > themselves. If not, let them use matlab :) :) That should be plenty of information. One comment: if you load mplrc2.conf, which includes an mplrc.conf with a bogus key, the error indicates the bad key is in mplrc2.conf. Is that a concern? > Please update and let me know what happens. > > > It might be nice to be able to deprecate keys [...] > when you deprecate a Key, simply change it from > > class Foo(TConfig): > somekey = T.Int > > to > > somekey = DeprecatedKey > > where DeprecatedKey is a Trait you declare, whose handler/validator > provides the necessary information to the user, sends warnings, it can > even set the proper value in the new form of that information if it > makes sense, etc. Great! > > 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. This seemed an important point to me at first. But with well-documented, auto-generated examples, creating minimal examples or stubs in users .matplotlib or .ipython dirs, and a good mechanism for key deprecation, now I dont think it will be a big deal to raise errors on bad keys. It should be extremely rare. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
On Jul 24, 2007, at 7:31 PM, Chris Barker wrote: >> output when usetex is enabled. > > Ah! and some good math implementation -- What does Chaco do for > that? I > know I took part in a discussion about it on a Chaco list a few years > back -- at the time I argued that you're never going to do as well > at TeX. We've also had this discussion internally a bit. It usually concludes with us wishing that someone would just port jsmath to Python, or implement Knuth's TeX layout rules in Python. :) Currently Chaco2 doesn't have a math markup mechanism, but it was fairly trivial for me to port mpl's mathtext to Chaco1. I didn't bother moving that to Chaco2 because I really wanted to figure out a way to do "real" TeX layout that would still fit into the interactive model. -Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcparams/traits
On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: > On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote: > :) That should be plenty of information. One comment: if you load mplrc2.conf, > which includes an mplrc.conf with a bogus key, the error indicates the bad > key is in mplrc2.conf. Is that a concern? It may be a concern to you, I suppose :) Kidding aside, it's not totally trivial to implement the other solution, which is why I didn't do it (or at least I couldn't think of a really simple way to do it). In a sense the message is at least correct, in that it gives the correct origin for the problem, but users will have to track the inclusion chain themselves. I'm sure we'll find more issues with complicated recursive setups as we use this for 'real', and in the process we might find a nice solution for this as well. For now, it will stay as is (at least until you send me a patch that fixes it :) > > Please update and let me know what happens. > > > > > It might be nice to be able to deprecate keys > [...] > > when you deprecate a Key, simply change it from > > > > class Foo(TConfig): > > somekey = T.Int > > > > to > > > > somekey = DeprecatedKey > > > > where DeprecatedKey is a Trait you declare, whose handler/validator > > provides the necessary information to the user, sends warnings, it can > > even set the proper value in the new form of that information if it > > makes sense, etc. > > Great! Glad you're happy. Traits are a really cool system. > > > 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. > > This seemed an important point to me at first. But with well-documented, > auto-generated examples, creating minimal examples or stubs in > users .matplotlib or .ipython dirs, and a good mechanism for key deprecation, > now I dont think it will be a big deal to raise errors on bad keys. It should > be extremely rare. OK. I guess it's now up to you guys (a collective MPL-dev you) to decide if you want to use this system or not. We'll slowly try to replace the ipython config with this, which I'm sure will uncover yet a few more problems. But overall I'm quite happy with what we've got, and I think the system is flexible enough that we should be able to solve whatever remains. Thanks for all your feedback and patience with testing! Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote: > > output when usetex is enabled. > Ah! and some good math implementation -- What does Chaco do for that? I > know I took part in a discussion about it on a Chaco list a few years > back -- at the time I argued that you're never going to do as well at TeX. Well I want TeX. I want to be able to do my TeX hacks on my figures. And I do believe there is a lot of work to be done before you can do better than TeX. My 2 cents, Gaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
On 7/25/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote: > > > output when usetex is enabled. > > > Ah! and some good math implementation -- What does Chaco do for that? I > > know I took part in a discussion about it on a Chaco list a few years > > back -- at the time I argued that you're never going to do as well at TeX. > > Well I want TeX. I want to be able to do my TeX hacks on my figures. And > I do believe there is a lot of work to be done before you can do better > than TeX. What kind of TeX hacks do you want to use on figures? My TeX hacks include mostly things like using negative vspace to squeeze more text into a 6-page paper. --bb - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
Peter Wang wrote: >> Ah! and some good math implementation -- What does Chaco do for >> that? > We've also had this discussion internally a bit. It usually > concludes with us wishing that someone would just port jsmath to > Python, or implement Knuth's TeX layout rules in Python. :) It looks like jsmath uses the TeX layout rules, so those are the same thing. If you can do it in JS, you sure should be able to do it in Python! > Currently Chaco2 doesn't have a math markup mechanism, but it was > fairly trivial for me to port mpl's mathtext to Chaco1. I didn't > bother moving that to Chaco2 because I really wanted to figure out a > way to do "real" TeX layout that would still fit into the interactive > model. That would be nice. I agree, the Math-as-bitmap approach really isn't the way to go, but it does work OK in the meantime! -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
On 7/25/07, Chris Barker <[EMAIL PROTECTED]> wrote: > Peter Wang wrote: > > We've also had this discussion internally a bit. It usually > > concludes with us wishing that someone would just port jsmath to > > Python, or implement Knuth's TeX layout rules in Python. :) > > It looks like jsmath uses the TeX layout rules, so those are the same > thing. If you can do it in JS, you sure should be able to do it in Python! I took a look at examples on the jsmath webpage, and it looks like the square-root placement is glitchy (Firefox on WinXP). If it really is TeX's rules I wonder what the problem is. Maybe fonts on my end? --bb - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
On Wed, Jul 25, 2007 at 03:25:36PM +0900, Bill Baxter wrote:
> > Well I want TeX. I want to be able to do my TeX hacks on my figures. And
> > I do believe there is a lot of work to be done before you can do better
> > than TeX.
> What kind of TeX hacks do you want to use on figures? My TeX hacks
> include mostly things like using negative vspace to squeeze more text
> into a 6-page paper.
"""
\begin{minipage}{3cm}
Multi line \\ tick marker
\end{minipage}
$ x\,e^{x} \underset{x \rightarrow 0}{\thicksim} x $
% That one probably does not run without \usepackage{amsmath} in the preamble
Velocity [{\small m$\cdot$s$^{-1}$}]
\begin{eqarray}
\Phi(v_z) & = &
\int_{z=0}^l
\int_{v_r=0}^{v_c}
\underbrace{v_r \,n \,B_T(v_r, v_z)}_{\text{\parbox{17ex}{\tiny
flux per surface element}}}
\;\times
\underbrace{
\begin{cases}
1 \text{~\small if $z/v_z<\tau$} \\
0 \text{~\small elsewhere}
\end{cases}
\!\!\!\!\!\!
}_{\text{Capture condition}}
\times \;
\underbrace{2 \pi v_r dv_r}_{\text{\parbox{7ex}{\tiny
polar coord.}}} \,
\underbrace{2\pi\, r_c}_{\text{\parbox{11ex}{\tiny 2D-MOT perimeter}}}
dz
\\
& = & 4\pi^2\,v_c^3\, r_c \; n \,
(\pi v_\text{max}^2)^{-\slantfrac{3}{2}}
e^{-v_z^2 /v_\text{max}^2} \big(
e^{-\Gamma_\text{coll} \tau} - e^{-\Gamma_\text{coll} l/ v_z}
\big)
\frac{v_z}{\Gamma_\text{coll}}
\end{eqnarray}
"""
And many more. As you can see this is mainly advanced math with sometimes
some ugly solutions (the parboxes in the underbraces, hum...), but it
works it LaTeX, and I am happy to have this familiar language at hand
when doing figures.
Gaël
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
