You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: John H. <jdh...@ac...> - 2004-09-25 14:45:56
|
>>>>> "Ingo" =3D=3D Ingo L=FCtkebohle <ilu...@gm...> writes: Ingo> Hi, a patch to compile the agg2 subdir with gcc 3.4 is on Ingo> sourceforge. Ingo> Background: The stricter template member-access checks in Ingo> gcc 3.4 break compilation of some agg2 headers. The problem Ingo> occurs when a class derives from a templatized class and Ingo> access members of the base class. Previously, the name of Ingo> the member was sufficient. Now, access to members of the Ingo> base class has to be qualified with "this". Ingo> [I sent this mail earlier, with the patch attached, but it Ingo> never arrived. Maybe mailman didn't like the attachment. Ingo> Sorry of you get duplicates.]. Sorry for the patch troubles. matplotlib cvs has already upgraded to agg22, which among other things is fixed to handle gcc 3.4. I don't have access to gcc 3.4 currently, so am unable to test matplotlib compilation with agg22 with that version. Could you give it a try and let me know? Thanks! JDH |
From: <ilu...@gm...> - 2004-09-25 12:12:39
|
Hi, a patch to compile the agg2 subdir with gcc 3.4 is on sourceforge. Background: The stricter template member-access checks in gcc 3.4 break compilation of some agg2 headers. The problem occurs when a class derives from a templatized class and access members of the base class. Previously, the name of the member was sufficient. Now, access to members of the base class has to be qualified with "this". [I sent this mail earlier, with the patch attached, but it never arrived. Maybe mailman didn't like the attachment. Sorry of you get duplicates.]. Ingo |
From: John H. <jdh...@ac...> - 2004-09-24 22:55:11
|
>>>>> "thane" == <th...@ma...> writes: thane> I've got an alpha version of a .NET backend up and running thane> for matplotlib (http://matplotlib.sourceforge.net/ ). It thane> was just intended to be "proof-of-concept" code, but it thane> works. I'm certainly interested. I don't know a lot about .Net. Is your backend an image backend or GUI one? If the latter, are you using agg for rendering ala tkagg, gtkagg, etc, or native .Net drawing? Inquiring minds want to know. thane> This back end is targeted for anyone using PythonNet (see thane> http://www.zope.org/Members/Brian/PythonNet/index_html ). thane> It should also be compatible with IronPython (see thane> http://ironpython.com/) once the standard libraries and thane> Numarray (or Numeric) are available for the IronPython thane> release. thane> If there is any interest, please respond to this post and thane> I'll go through the trouble of adding it to the project (at thane> this point I don't know how to do this, so any guidance thane> here would be appreciated). The standard procedure for submitting a backend is to send it to the dev list, where I and other matplotlib developers can take it for a test drive and submit feedback. I'd be happy to give it a try. If you have any extra instructions for .Net dummies, please send them along with the code. Cheers! JDH thane> --Thane thane> Thane Plummer, Ph.D. thane> CEO Magna Capital, LLC thane> (520) 760-4957 thane> (520) 405-2277 (cell) thane> <mailto:th...@ma...> th...@ma... thane> <http://www.magna-capital.com> www.magna-capital.com |
From: <th...@ma...> - 2004-09-24 21:22:22
|
I've got an alpha version of a .NET backend up and running for matplotlib (http://matplotlib.sourceforge.net/ ). It was just intended to be "proof-of-concept" code, but it works. This back end is targeted for anyone using PythonNet (see http://www.zope.org/Members/Brian/PythonNet/index_html ). It should also be compatible with IronPython (see http://ironpython.com/) once the standard libraries and Numarray (or Numeric) are available for the IronPython release. If there is any interest, please respond to this post and I'll go through the trouble of adding it to the project (at this point I don't know how to do this, so any guidance here would be appreciated). --Thane Thane Plummer, Ph.D. CEO Magna Capital, LLC (520) 760-4957 (520) 405-2277 (cell) <mailto:th...@ma...> th...@ma... <http://www.magna-capital.com> www.magna-capital.com |
From: Perry G. <pe...@st...> - 2004-09-24 16:51:53
|
On Sep 24, 2004, at 10:59 AM, John Hunter wrote: > > The other core features that would be nice to have but aren't > absolutely critical are polar and contour. I believe the stsci folks > are working on contour. > Off and on, but indeed we are working on implementing contour plots. Perry |
From: John H. <jdh...@ac...> - 2004-09-24 15:48:22
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> My argument is that most other software I've looked at does Steve> this and it seems to work OK. I guess the reasons are that Steve> - it makes software packages smaller - you only need to Steve> directly download one copy of a package and do not Steve> indirectly download multiple copies of the same package. - Steve> you can end up with multiple versions of a package. And Steve> later you may try to recall - which package x did I use to Steve> install package y? - the software package that includes Steve> other packages needs to make sure it keeps up to date with Steve> with the included packages and does not install old Steve> versions. Hi Steve, Those are reasonable arguments. I'm still convinced that it is better to err on the side of simplifying the install, though. matplotlib has been distributing some of it's prereqs for some time (agg, pyparsing) and not others (Numeric/numarray, freetype, libpng). I try to balance the likelihood the user already has the package on their system, the additional ease/complexity of installation and coding, and package size. On balance, I decided to add pytz and dateutil to the matplotlib src distro - I won't however, overwrite existing installs. In the past we've included things (fontutils, ttfquery) that were eventually removed because we found or wrote better replacements. So the matplotlib package size tends to fluctuate up and down a bit. Currently, with src, fonts, icons, examples, example data, and add-on packages, the src dist comes to 1.6M. I can live with that. Steve> As a way to encourage more users how about working towards Steve> moving from the development status of version 0.62.4 "4 - Steve> Beta" to 1.0.0 "5 - Production/Stable". What's the Steve> criteria for this step? My understanding is that it does Steve> not mean that all desired features are implemented or Steve> complete, it just means that the software is stable, and Steve> matplotlib seems to be pretty stable already. I'm amenable. Do you know of instances where people aren't using matplotlib due to it's version number or development status flag? My working plan is to be mostly 2D feature complete for 1.0, but I am not wed to this. As you say, 1.0 really just implies some stability rather than feature set. The only thing off the top of my head that must be added before 1.0 is a Users Guide - I should be done with this already, but alas... Should be done in a month (I said that last month) I also think it would also be nice to have a more streamlined, sophisticated configure process. The other core features that would be nice to have but aren't absolutely critical are polar and contour. I believe the stsci folks are working on contour. As for stability, there will probably be a significant refactoring of the renderer drawing API at some point. But I don't think this precludes a 1.0 release. As long as the matlab interface and OO Figure/Axes/Text/Line/Patch interface is stable, and it largely is discussed on the user's list), then I don't think it would break any existing code to refactor the drawing model down the road. As far as I know, noone is directly using the renderer API, and I've never advertised it. JDH |
From: John H. <jdh...@ac...> - 2004-09-22 13:03:51
|
>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes: Patrik> Here's a proposed patch for the caching problem in Patrik> text.py. (I'm sending it before someone actually adds Patrik> matplotlib.text.Text.cached = {} to, e.g., Patrik> matlab.close(). Oh, the horror :-) What happened when you put it there? It's not clear to me where to me where that misplaced zero is coming from. Since the two figures are identical in size, I would think the cached location of '0' from the first iteration of the loop would be suitable for the second iteration. Do you understand how this is failing? The main reason for the cache was for efficiency in animated plots. Eg, if you are just updating the data in a plot and then redrawing, you don't want to do all the number crunching for text layout. With rotated text and matrix operations to get the layout right, this can get expensive. I read over your patch. I wonder if a simpler and cleaner solution might just be to move the cached into the __init__ method. Ie, make it instance specific. This would still provide the cache efficiency for animated plots, but should fix the problem you encountered. It might also be less mind-bending than the solution you posted, at least at this hour of the morning :-) But I *would* like to understand how the current situation is failing. I note that it does not occur if you replace figure(1) with figure(i+1). JDH |
From: Patrik S. <pat...@ne...> - 2004-09-22 12:49:23
|
Here's a proposed patch for the caching problem in text.py. (I'm sending it before someone actually adds matplotlib.text.Text.cached = {} to, e.g., matlab.close(). Oh, the horror :-) -- Patrik |
From: Patrik S. <pat...@ne...> - 2004-09-22 08:06:56
|
Hi there, matplotlib.text.Text._get_layout(self, renderer) caches its return value in the dictionary matplotlib.text.Text.cached. Since it is never emptied, it causes problems when one creates many figures. Below, t0.png is ok but t1.png has the vertical tick label 0 in the wrong place. import matplotlib matplotlib.use('Agg') from matplotlib.matlab import * y = [[100, 250], [10, 25]] for i in range(2): figure(1) bar([0,1], y[i]) savefig('t%d.png' % i) # Uncomment to fix #matplotlib.text.Text.cached = {} close('all') -- Patrik |
From: Andrew S. <str...@as...> - 2004-09-22 04:40:15
|
John Hunter wrote: >>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes: >>>>>> >>>>>> > > Steve> My view is that a software package should not distribute > Steve> and install its own dependencies. I think matplotlib > Steve> should have a list of dependencies (Python 2.2+, Numeric or > Steve> numarray, ...) which it requires before it attempts an > Steve> install, and a list of optional dependencies (pytz, > Steve> dateutil, ...) which matplotlib supports if it finds they > Steve> are already installed. > >What's your argument for this? > >My motivation to include them is mainly to simplify the install >process, to have some control over versioning, and to simplify the >coding process. > I agree with JDH on this one. Including extra pure-Python packages is not likely to cause (m)any problems: 1) on systems where people do lots of "python setup.py install" the definitive list of installed packages is the contents of site-packages 2) on systems with real package managers (e.g. Debian), this is for the package maintainer to worry about. those extra packages should be made package-level dependencies and not in the matplotlib.deb itself. (this assumes people on these systems are using the package manager. if not, see point #1) 3) on Windows, you want to double click something that just works. (In fact, by this reasoning, there's nothing against including mixed C/Python packages, either.) |
From: Steve C. <ste...@ya...> - 2004-09-22 04:08:24
|
On Tue, 2004-09-21 at 19:44, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> My view is that a software package should not distribute > Steve> and install its own dependencies. I think matplotlib > Steve> should have a list of dependencies (Python 2.2+, Numeric or > Steve> numarray, ...) which it requires before it attempts an > Steve> install, and a list of optional dependencies (pytz, > Steve> dateutil, ...) which matplotlib supports if it finds they > Steve> are already installed. > > What's your argument for this? My argument is that most other software I've looked at does this and it seems to work OK. I guess the reasons are that - it makes software packages smaller - you only need to directly download one copy of a package and do not indirectly download multiple copies of the same package. - you can end up with multiple versions of a package. And later you may try to recall - which package x did I use to install package y? - the software package that includes other packages needs to make sure it keeps up to date with with the included packages and does not install old versions. > My motivation to include them is mainly to simplify the install > process, to have some control over versioning, and to simplify the > coding process. Since these are pure python packages, they present no Yes, this is an advantage of including everything, and a disadvantage for minimal packages. > Does your opinion change for the win32 installer? In that case, we > also include freetype, libpng, zlib. I guarantee the numbers of win32 > users would drop significantly if they had to install these extra > packages. Neither dateutil nor pytz distribute a win32 installer. > dateutil doesn't include a zip file (only a tar.bz file). So win32 > users would first have to get bunzip2, and then tar, figure out how to > use them, install, etc, just to get matplotlib date support. Win32 could be a special case. As a way to encourage more users how about working towards moving from the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 - Production/Stable". What's the criteria for this step? My understanding is that it does not mean that all desired features are implemented or complete, it just means that the software is stable, and matplotlib seems to be pretty stable already. Regards, Steve |
From: Darren D. <dd...@co...> - 2004-09-21 12:39:43
|
On Tuesday 21 September 2004 11:54 am, Steve Chaplin wrote: > My view is that a software package should not distribute and install its > own dependencies. > I think matplotlib should have a list of dependencies (Python 2.2+, > Numeric or numarray, ...) which it requires before it attempts an > install, and a list of optional dependencies (pytz, dateutil, ...) which > matplotlib supports if it finds they are already installed. I second that. -- Darren Dale |
From: John H. <jdh...@ac...> - 2004-09-21 12:33:29
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> My view is that a software package should not distribute Steve> and install its own dependencies. I think matplotlib Steve> should have a list of dependencies (Python 2.2+, Numeric or Steve> numarray, ...) which it requires before it attempts an Steve> install, and a list of optional dependencies (pytz, Steve> dateutil, ...) which matplotlib supports if it finds they Steve> are already installed. What's your argument for this? My motivation to include them is mainly to simplify the install process, to have some control over versioning, and to simplify the coding process. Since these are pure python packages, they present no extra installation overhead for matplotlib and the only downside I see is potential package bloat. Both of these packages combined add 200k to the src distro. The coding burden is reduced, if for example I know pytz is included, because I don't have to do a lot of conditional stuff throughout the code where that module is used. Does your opinion change for the win32 installer? In that case, we also include freetype, libpng, zlib. I guarantee the numbers of win32 users would drop significantly if they had to install these extra packages. Neither dateutil nor pytz distribute a win32 installer. dateutil doesn't include a zip file (only a tar.bz file). So win32 users would first have to get bunzip2, and then tar, figure out how to use them, install, etc, just to get matplotlib date support. Basically, my goal is to maximize the likelihood that someone can use matplotlib even if they haven't RTFM. I wish they would read the install instructions and dependencies, but I think that is only about half of the users. If we can set it up so that most things work out of the box on a standard python setup - and I think having Numeric/numarray) is fairly standard for most potential matplotlib users. On a related note, Todd just added a fix in CVS that autodetects numerix at build time and builds in Numeric and/or numarray. It would probably be a good idea to have an rc template and write the actual rc file depending on what the autodetect finds in setup.py. Eg, if setup finds Tkinter and numarray but not pygtk and Numeric, there's not much sense in using the default backend : GTKAgg and numerix : Numeric in rc. Paul did something like this for the license, so that the license file was automatically built with the correct version number at build time. JDH |
From: Steve C. <ste...@ya...> - 2004-09-21 11:56:00
|
My view is that a software package should not distribute and install its own dependencies. I think matplotlib should have a list of dependencies (Python 2.2+, Numeric or numarray, ...) which it requires before it attempts an install, and a list of optional dependencies (pytz, dateutil, ...) which matplotlib supports if it finds they are already installed. Regards, Steve |
From: John H. <jdh...@ac...> - 2004-09-20 17:49:05
|
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> Should I assume that the installed packages would have the Paul> same structure, i.e. lib/python2.3/site-packages/matplotlib/ Paul> ? If yes, then I see no problem with this proposal. Yes, the install paths would be unaffected. JDH |
From: Paul B. <ba...@st...> - 2004-09-20 17:41:47
|
John Hunter wrote: >Many new users have been bitten by trying to run matplotlib from the >matplotlib src dir, only to get an inscrutable error about not being >able to find some extension code, as described in this FAQ >http://matplotlib.sourceforge.net/faq.html#WRONGDIR. > >Recently, I've added pytz and dateutil for improved timezone and date >ticking to the src distro. I want to conditionally install these >packages with matplotlib, only if the user hasn't installed them >already. So in setup.py, I do for example > >try: import dateutil >except ImportError: > packages.append('dateutil') > > >But I was bitten by the same bug. Because dateutil was in the >matplotlib root dir, it was imported successfully and not installed. > >My proposal is to move all the python library code into a lib subdir, >which currently would look like > > lib\matplotlib > lib\pytz > lib\dateutil > >and use package_dir = {'': 'lib'} in setup.py, which would fix both >problems. > >Of course, I'll have to submit an admin request to sourceforge just to >get the old dirs purged. Sure would be nice if CVS supported basic >rename and delete operations on directories. > >Comments, suggestions, objections... > > Should I assume that the installed packages would have the same structure, i.e. lib/python2.3/site-packages/matplotlib/ ? If yes, then I see no problem with this proposal. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218 |
From: John H. <jdh...@ac...> - 2004-09-20 15:30:49
|
Many new users have been bitten by trying to run matplotlib from the matplotlib src dir, only to get an inscrutable error about not being able to find some extension code, as described in this FAQ http://matplotlib.sourceforge.net/faq.html#WRONGDIR. Recently, I've added pytz and dateutil for improved timezone and date ticking to the src distro. I want to conditionally install these packages with matplotlib, only if the user hasn't installed them already. So in setup.py, I do for example try: import dateutil except ImportError: packages.append('dateutil') But I was bitten by the same bug. Because dateutil was in the matplotlib root dir, it was imported successfully and not installed. My proposal is to move all the python library code into a lib subdir, which currently would look like lib\matplotlib lib\pytz lib\dateutil and use package_dir = {'': 'lib'} in setup.py, which would fix both problems. Of course, I'll have to submit an admin request to sourceforge just to get the old dirs purged. Sure would be nice if CVS supported basic rename and delete operations on directories. Comments, suggestions, objections... JDH |
From: Christopher H. <ha...@ca...> - 2004-09-03 07:38:48
|
Hi, I think I might have noticed an off by one bug in the pcolor and pcolor_classic functions. To replicate the problem: from matplotlib.matlab import * import Numeric pcolor(Numeric.transpose(rand(2,2))) ** Note that although this is a 2x2 matrix the pcolor plot is rendered with only 1 square. This problem scales. The dimensions of the pcolor plots are always 1 less than they should be. Changing line 1306 in axes.py (I'm running the debian package ver. 0.61.0-2) from: X, Y = meshgrid(arange(numCols), arange(numRows) ) to: X, Y = meshgrid(arange(numCols+1), arange(numRows+1) ) And I think similar change can fix pcolor_classic too. This fixes the off-by-one problem when plotting arrays. I haven't thoroughly tested this, but I think it works in all cases. --chris. PS. Thanks for the nice work on matplotlib. ---------------------- Christopher Hart Caltech Biology |
From: Stefan K. <pon...@ya...> - 2004-09-01 17:38:00
|
In the generated documentation ( the doc string ) for scatter, 'octagon' is mispelled 'octogon'. S __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: John H. <jdh...@ac...> - 2004-08-27 03:39:13
|
>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes: Abraham> Thanks for the tip on variable expansion. I'll add it in Abraham> to my current code. Hi Abraham, Just wanted to let you know I haven't dropped off the face of the planet. With SciPy looming and other deadlines, I haven't had a chance to look into your code in any detail. I'll be away all of next week, so it will be some time until I get a chance to take a look. Keep plugging away (pun intended) and hopefully we can put together something nice in the near term. I think your hybrid solution of using a plain text key/val pair format for rc, and user customizable python for toolbar config, is a good one. JDH |
From: Fernando P. <Fer...@co...> - 2004-08-22 08:07:45
|
Abraham Schneider wrote: > I completely agree. I recently changed the code to allow a path to be > specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax > .. something to think about. However, if people have a .matplotlibrc > file in their home directory, it should make it so people aren't mucking > up things with the plugins.. I'll have to check the behavior of > find_module to see what it does with '~' and such. You can expand the user-given string by doing: user_dirlist = os.path.expanduser(os.path.expandvars(user_path)).split(':') This gives you a list of directories to search, with user ~names and $VARIABLES expanded out. This approach worked fine for mayavi. Best, f |
From: Fernando P. <Fer...@co...> - 2004-08-22 08:01:08
|
Abraham Schneider wrote: > I do like the idea, and I was actually going to suggest something > similiar earlier on, but thought it wise at the time not to rock the > boat too much.. I am currently using this technique for my own code and > it's working out extremely well. The biggest problem with this approach, > is that I'm guessing the average user doesn't want to trawl through > python code to change a setting, or worry why Matplotlib doesn't work > because of some strange error message. > > Because of this, I think it might make the most sense to partition the > rc file. For common settings, keep the current RC format, but then allow > python code to be executed for other settings. > > A simple approach for this might be to add in directives to the RC > language like: > > @import('file.rc') > > or > > @import('file.py') > > Depending on the file type (i.e. ends in 'rc' or ends in 'py'), the file > could be parsed properly (either executed with 'execfile' with a given > namespace, or operate on rcParams). -1, too complicated to code and maintain, IMHO. And @foo looks poised to become valid python syntax, in case you've missed the recent firestorms on c.l.py and python-dev. In my view, matplotlib (and similarly ipython) are already tools for people coding in python to begin with. So they can deal with python syntax, otherwise they wouldn't be using them. Simplified syntaxes may make sense for configuring end-user programs, but for that we already have ConfigParser in the stdlib. We have better things to do than reinventing half-working implementations of toy languages, and users will always end up needing an if statement, a looping construct, a system access function, etc. Might as well just give them all of python and be done with it, I think. The approach I have in mind for ipython is simply making sure that any exceptions generated during the execution of this file are presented very clearly to the user, with full source details and a clear message wrapping them going to stderr. This will indicate not only the exception but the fact that it is occurring in the user's config file and that ipython (or matplotlib) can't proceed further until this is fixed. IPython comes with a better exception formatter than the default (ultraTB, essentially a console port of cgitb); matplotlib is welcome to use it. Best, f |
From: Fernando P. <Fer...@co...> - 2004-08-22 07:48:11
|
John Hunter wrote: >>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes: > > > Fernando> 2. From some of your syntax struggles, I'm starting to > Fernando> wonder whether it would be best to turn the > Fernando> .matplotlibrc file into a proper python one. I followed > Fernando> the same approach with ipython of having a custom > Fernando> syntax, and now I regret it. It appears easier > Fernando> initially, but in the long term it's clunky (at least > Fernando> for ipython). For ipython's next major revision, I plan > Fernando> on dumping its own rc format and allowing users to > Fernando> define their configuration using plain python syntax. > Fernando> Just some thoughts. > > I had the same thought this morning - you start with a simple config > file, key/value pairs, but as you add features you find yourself > writing a little primitive mini-language. Why ham-string yourself, > when you already have an elegant, simple, powerful language available > - python! There are a few technical issues with this problem, some of which I've partly thought about. This will be one of my first things to do once I'm done with matplotlib support in ipython, as part of the rewrite. Perhaps we could share some of the work for this problem with a light module for handling python config files with proper namespace control and recursive inclusion (important for handling global defaults modified by local project fine-tuning). Best, f |
From: Abraham S. <ab...@cn...> - 2004-08-22 04:11:49
|
Fernando Perez wrote: > > > 1. I think plugin support is a fantastic idea, but I hope it can be > made user-extensible in local paths. I recently modified mayavi > (available in current CVS) precisely in this manner, and I think it's > a very useful thing. In lab settings where users are not allowed to > write to system directories, it becomes very important that they can > add their own plugins in local paths. This also allows you to keep > your personal extensions alive as matplotlib versions are upgraded, > since your directories are untouched. > > What I did for mayavi was to add a search-path option to mayavi, made > of colon-separated dirs with ~user/$VAR support. Any such dir gets > added to mayavi's search path for user-defined filters and modules > (the equivalent of plugins), and you can load a user module just like > you can load a builtin: > > load_module('Glyphs') -> loads mayavi's Glyphs module > load_module('User.Glyphs') -> loads a user-defined Glyphs module from > the search path. > > I think it's important that it's a _path_ and not a single directory, > because this allows a research group to maintain shared extensions > suited for their purposes, and individual users to add personal > modifications which don't fit group projects. I completely agree. I recently changed the code to allow a path to be specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax .. something to think about. However, if people have a .matplotlibrc file in their home directory, it should make it so people aren't mucking up things with the plugins.. I'll have to check the behavior of find_module to see what it does with '~' and such. I like the idea of 'load_module'. Currently all the plugins in the directories are loaded automatically. There is a certain nicety, though, to automatically having it load all the plugins found in a particular directory. Less cumbersome for most users. Abe |
From: Abraham S. <ab...@cn...> - 2004-08-22 03:43:45
|
I do like the idea, and I was actually going to suggest something similiar earlier on, but thought it wise at the time not to rock the boat too much.. I am currently using this technique for my own code and it's working out extremely well. The biggest problem with this approach, is that I'm guessing the average user doesn't want to trawl through python code to change a setting, or worry why Matplotlib doesn't work because of some strange error message. Because of this, I think it might make the most sense to partition the rc file. For common settings, keep the current RC format, but then allow python code to be executed for other settings. A simple approach for this might be to add in directives to the RC language like: @import('file.rc') or @import('file.py') Depending on the file type (i.e. ends in 'rc' or ends in 'py'), the file could be parsed properly (either executed with 'execfile' with a given namespace, or operate on rcParams). This could also support other features such as verbosity: @verbose moderate That said, I think the current syntax for adding widgets and connecting them isn't too bad. I think it's worth experimenting with to see which is easier to use. Abe John Hunter wrote: >>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes: >>>>>> >>>>>> > > Fernando> 2. From some of your syntax struggles, I'm starting to > Fernando> wonder whether it would be best to turn the > Fernando> .matplotlibrc file into a proper python one. I followed > Fernando> the same approach with ipython of having a custom > Fernando> syntax, and now I regret it. It appears easier > Fernando> initially, but in the long term it's clunky (at least > Fernando> for ipython). For ipython's next major revision, I plan > Fernando> on dumping its own rc format and allowing users to > Fernando> define their configuration using plain python syntax. > Fernando> Just some thoughts. > >I had the same thought this morning - you start with a simple config >file, key/value pairs, but as you add features you find yourself >writing a little primitive mini-language. Why ham-string yourself, >when you already have an elegant, simple, powerful language available >- python! > >When I get some more time tomorrow I'll take a close look at Abraham's >code, and whether it might make more sense to move this section, or >the who rc file, into python. That Abraham was able to factor out / >modularize most of the toolbar code will certainly pave the way. > >Abraham, had you given this approach any thought in the midst of your >work? > >Thanks! >JDH > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |