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
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(1) |
2
(1) |
3
(3) |
4
(2) |
5
|
6
|
7
(8) |
8
|
9
|
10
(3) |
11
(2) |
12
(2) |
13
(2) |
14
(6) |
15
(1) |
16
|
17
|
18
(8) |
19
(1) |
20
(9) |
21
|
22
(6) |
23
(1) |
24
(13) |
25
(8) |
26
(5) |
27
(3) |
28
(7) |
29
(4) |
30
|
|
|
|
From: Darren D. <dar...@co...> - 2008-04-25 02:24:03
|
On Thursday 24 April 2008 09:48:18 pm John Hunter wrote: > On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote: > > Darren, > > > > It is open for discussion. Here are some factors: > > > > 1) In my experience, numpy is easy to build from source--easier than > > matplotlib. > > This is my view too -- if you rely on or can build svn mpl, I seen no > reason why you can't also rely on/build svn numpy since it is a much > easier build. If mpl builds, numpy svn is pretty much guaranteed to > build on any platform. > > If I am missing something Darren, please let me know, but in my > regular workflow, I pretty much assume I can bild svn ipython, numpy > and mpl, and hopefully scipy. I have been developing a data acquisition and analysis program for my lab, and we are actually in the process of using it it this week and next to run experiments with our visiting scientists. I've been running matplotlib from svn for as long as I can remember and hadn't anticipated trouble. I guess I just wasn't reading the dev list closely enough since I rely on the trunk for daily use. Maybe we should consider cutting a transitional prelease at some point before additional big changes are made, so those of us who have already transitioned our code to the new codebase have a reference build we can install when we run into trouble on the trunk? |
From: John H. <jd...@gm...> - 2008-04-25 01:48:24
|
On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote: > Darren, > > It is open for discussion. Here are some factors: > > 1) In my experience, numpy is easy to build from source--easier than > matplotlib. This is my view too -- if you rely on or can build svn mpl, I seen no reason why you can't also rely on/build svn numpy since it is a much easier build. If mpl builds, numpy svn is pretty much guaranteed to build on any platform. If I am missing something Darren, please let me know, but in my regular workflow, I pretty much assume I can bild svn ipython, numpy and mpl, and hopefully scipy. JDH |
From: Eric F. <ef...@ha...> - 2008-04-24 22:04:13
|
Darren Dale wrote: > On Thursday 24 April 2008 03:09:43 pm John Hunter wrote: >> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote: >>> Darren, >>> >>> In an earlier thread on matplotlib-users, when this first came up, John >>> noted that numpy svn should be required for present mpl svn, so >>> instead of fixing the attempted workaround for 1.04 I took it out and >>> instead put a numpy version check in matplotlib.__init__. >> Just to make clear my thinking on this: since the svn trunk of mpl is >> a major refactoring and will be a major point jump when we release it >> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we >> can rely on all the nice features and fixes that have gone into that >> release. > > I've been installing numpy through various package managers and now I'll need > to figure out how to configure the build on fedora, ubuntu and gentoo in > order to use svn matplotlib. Was it a mistake for me to develop my > application using the matplotlib trunk? If I go through the trouble of > configuring the build environments for numpy on these various OS's, am I > going to discover that the numpy trunk is not backward compatible and is > causing problems with other applications? I know my own difficulties are not > sufficient reason to alter the development path of our fine library, but I > think this might be a mistake. Darren, It is open for discussion. Here are some factors: 1) In my experience, numpy is easy to build from source--easier than matplotlib. 2) The numpy 1.1 release is coming soon--on the order of a week. I don't know how much that will help you. Maybe not much until distro packages catch up, which can take a long time. 3) There have been a lot of bug fixes between numpy 1.04 and 1.1. The main area of *slight* incompatibility is in the masked array package. The main practical difference is that some import forms that worked with 1.04 do not work with 1.1; e.g. you can't import ma from numpy.core because that is not where it is now, and it is sub-package, not a file. The ma internals are quite different (a masked array is now a subclass of ndarray), and the overall implementation is much improved, but functions and methods are highly compatible. Although I am sympathetic to the problems involved in making changes of this sort, I am also sympathetic to the problems of trying to keep something like mpl working with multiple versions of components like the numeric library. There were a lot of bugs and holes in the old numpy.ma. To me, it is a relief to be able to stick to the new version and forget about the limitations and quirks of the old. Ideally, it will mean that all of us can spend more time thinking about how to improve mpl and less time in duplicate testing and coming up with workarounds. Eric |
From: Gael V. <gae...@no...> - 2008-04-24 21:41:19
|
Hum, a quite common discussion (we have had it at the nipy sprint, for instance). My feeling is that you want to avoid depending on SVN versions, unless there is a huge gain. The reason is that you loose tester and potential contributors. In addition it makes it harder to get the whole stack in a consistent shape because everything becomes a moving target. My 2 cents, Gaël |
From: Darren D. <dar...@co...> - 2008-04-24 21:32:58
|
On Thursday 24 April 2008 03:09:43 pm John Hunter wrote: > On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote: > > Darren, > > > > In an earlier thread on matplotlib-users, when this first came up, John > > noted that numpy svn should be required for present mpl svn, so > > instead of fixing the attempted workaround for 1.04 I took it out and > > instead put a numpy version check in matplotlib.__init__. > > Just to make clear my thinking on this: since the svn trunk of mpl is > a major refactoring and will be a major point jump when we release it > (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we > can rely on all the nice features and fixes that have gone into that > release. I've been installing numpy through various package managers and now I'll need to figure out how to configure the build on fedora, ubuntu and gentoo in order to use svn matplotlib. Was it a mistake for me to develop my application using the matplotlib trunk? If I go through the trouble of configuring the build environments for numpy on these various OS's, am I going to discover that the numpy trunk is not backward compatible and is causing problems with other applications? I know my own difficulties are not sufficient reason to alter the development path of our fine library, but I think this might be a mistake. |
From: John H. <jd...@gm...> - 2008-04-24 20:35:36
|
On Thu, Apr 24, 2008 at 3:32 PM, Eric Firing <ef...@ha...> wrote: > Agreed. If there were a meta-class usage that was crystal-clear after a > little inspection, and that actually made the code easier to understand and > maintain, I would consider it. > > I know that when we talked in Kona I was complaining about decorators, but > they are here to stay, and as long as they are not too tricky they can be > fine. The @staticmethod form is an improvement over the non-decorator > equivalent, an assignment at the bottom of the method. I would be happy to > see Mike's commented-out @staticmethod lines uncommented, and the > corresponding assignments at the bottom of the method deleted, for example. > > Requiring 2.4 would also let us remove the subprocess module--not a big > deal, but an incremental simplification of the mpl package. All these sound like good suggestions to me... JDH |
From: Eric F. <ef...@ha...> - 2008-04-24 20:32:43
|
John Hunter wrote: > On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote: > >> On a related note, what about python >= 2.4 instead of 2.3? This is not >> something I have a strong opinion about, but I think it might also be a >> reasonable time to let 2.4 be the minimum requirement. > > I think python 2.4 is totally reasonable for the 0.98 release, though > I am still prone to avoiding certain magic like meta-classes where > possible. > > JDH Agreed. If there were a meta-class usage that was crystal-clear after a little inspection, and that actually made the code easier to understand and maintain, I would consider it. I know that when we talked in Kona I was complaining about decorators, but they are here to stay, and as long as they are not too tricky they can be fine. The @staticmethod form is an improvement over the non-decorator equivalent, an assignment at the bottom of the method. I would be happy to see Mike's commented-out @staticmethod lines uncommented, and the corresponding assignments at the bottom of the method deleted, for example. Requiring 2.4 would also let us remove the subprocess module--not a big deal, but an incremental simplification of the mpl package. Eric |
From: John H. <jd...@gm...> - 2008-04-24 20:16:46
|
On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote: > On a related note, what about python >= 2.4 instead of 2.3? This is not > something I have a strong opinion about, but I think it might also be a > reasonable time to let 2.4 be the minimum requirement. I think python 2.4 is totally reasonable for the 0.98 release, though I am still prone to avoiding certain magic like meta-classes where possible. JDH |
From: Jarrod M. <mi...@be...> - 2008-04-24 19:44:01
|
On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote: > On a related note, what about python >= 2.4 instead of 2.3? This is not > something I have a strong opinion about, but I think it might also be a > reasonable time to let 2.4 be the minimum requirement. As a point of reference, NumPy 1.2 will require python >= 2.4 and so will the SciPy 0.7 release. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ |
From: Eric F. <ef...@ha...> - 2008-04-24 19:21:55
|
John Hunter wrote: > On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote: >> Darren, >> >> In an earlier thread on matplotlib-users, when this first came up, John >> noted that numpy svn should be required for present mpl svn, so >> instead of fixing the attempted workaround for 1.04 I took it out and >> instead put a numpy version check in matplotlib.__init__. > > Just to make clear my thinking on this: since the svn trunk of mpl is > a major refactoring and will be a major point jump when we release it > (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we > can rely on all the nice features and fixes that have gone into that > release. > > JDH I agree completely! On a related note, what about python >= 2.4 instead of 2.3? This is not something I have a strong opinion about, but I think it might also be a reasonable time to let 2.4 be the minimum requirement. Eric |
From: John H. <jd...@gm...> - 2008-04-24 19:09:55
|
On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote: > Darren, > > In an earlier thread on matplotlib-users, when this first came up, John > noted that numpy svn should be required for present mpl svn, so > instead of fixing the attempted workaround for 1.04 I took it out and > instead put a numpy version check in matplotlib.__init__. Just to make clear my thinking on this: since the svn trunk of mpl is a major refactoring and will be a major point jump when we release it (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we can rely on all the nice features and fixes that have gone into that release. JDH |
From: Eric F. <ef...@ha...> - 2008-04-24 18:32:55
|
Darren, In an earlier thread on matplotlib-users, when this first came up, John noted that numpy svn should be required for present mpl svn, so instead of fixing the attempted workaround for 1.04 I took it out and instead put a numpy version check in matplotlib.__init__. Eric Darren Dale wrote: > It looks like the recent modification to transforms.py to update datalims only > when valid data are available is broken for numpy-1.04. In > tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line: > > xym = ma.masked_where(~npy.isfinite(xy), xy) > > fails with: > > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in > plot > self.add_line(line) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in > add_line > self._update_line_limits(line) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in > _update_line_limits > self.update_datalim( xydata ) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in > update_datalim > self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits) > File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line > 699, in update_from_data_xy > xym = ma.masked_where(~npy.isfinite(xy), xy) > File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in > __array_wrap__ > domain = ufunc_domain[func] > KeyError: <ufunc 'isfinite'> > > > It looks like isfinite doesnt like getting a masked array as input. Is xy > always a masked array? If so, maybe that line could look like: > > xym = ma.masked_where(~npy.isfinite(xy.data), xy) > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Eric F. <ef...@ha...> - 2008-04-24 17:19:17
|
Mike, One of your cleanups might have introduced a problem? Eric Updated to revision 5071. efiring@manini:~/programs/py/mpl/mpl_trunk$ psb ============================================================================ BUILDING MATPLOTLIB matplotlib: 0.98pre python: 2.5.1 (r251:54863, Mar 7 2008, 03:41:45) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] platform: linux2 REQUIRED DEPENDENCIES numpy: 1.1.0.dev5061 freetype2: 9.10.3 OPTIONAL BACKEND DEPENDENCIES libpng: 1.2.15beta5 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4 wxPython: 2.8.1.1 * WxAgg extension not required for wxPython >= 2.8 Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4, pygobject: 2.12.3 Qt: Qt: 3.3.7, PyQt: 3.17 Qt4: Qt: 4.2.2, PyQt4: 4.1 Cairo: 1.2.0 OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: present, version unknown pytz: 3371 OPTIONAL USETEX DEPENDENCIES dvipng: 1.9 ghostscript: 8.15.4 latex: 3.141592 pdftops: 3.00 EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES configobj: 4.4.0 enthought.traits: matplotlib will provide [Edit setup.cfg to suppress the above messages] ============================================================================ running build running build_py copying lib/matplotlib/__init__.py -> build/lib.linux-i686-2.5/matplotlib copying lib/matplotlib/mathtext.py -> build/lib.linux-i686-2.5/matplotlib copying lib/matplotlib/mlab.py -> build/lib.linux-i686-2.5/matplotlib copying lib/matplotlib/backends/backend_wx.py -> build/lib.linux-i686-2.5/matplotlib/backends copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-i686-2.5/matplotlib/mpl-data copying lib/matplotlib/mpl-data/matplotlib.conf -> build/lib.linux-i686-2.5/matplotlib/mpl-data running build_ext building 'matplotlib.ft2font' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/ft2font.cpp -o build/temp.linux-i686-2.5/src/ft2font.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/ft2font.o build/temp.linux-i686-2.5/src/mplutils.o build/temp.linux-i686-2.5/CXX/cxx_extensions.o build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o build/temp.linux-i686-2.5/CXX/cxxsupport.o build/temp.linux-i686-2.5/CXX/cxxextensions.o -L/usr/local/lib -lfreetype -lz -lstdc++ -lm -o build/lib.linux-i686-2.5/matplotlib/ft2font.so building 'matplotlib.ttconv' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/_ttconv.cpp -o build/temp.linux-i686-2.5/src/_ttconv.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c ttconv/pprdrv_tt.cpp -o build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/_ttconv.o build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o build/temp.linux-i686-2.5/ttconv/pprdrv_tt2.o build/temp.linux-i686-2.5/ttconv/ttutil.o -L/usr/local/lib -o build/lib.linux-i686-2.5/matplotlib/ttconv.so building 'matplotlib._path' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_curves.cpp -o build/temp.linux-i686-2.5/agg24/src/agg_curves.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c src/path.cpp -o build/temp.linux-i686-2.5/src/path.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/agg24/src/agg_curves.o build/temp.linux-i686-2.5/agg24/src/agg_bezier_arc.o build/temp.linux-i686-2.5/agg24/src/agg_trans_affine.o build/temp.linux-i686-2.5/agg24/src/agg_vcgen_stroke.o build/temp.linux-i686-2.5/CXX/cxx_extensions.o build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o build/temp.linux-i686-2.5/CXX/cxxsupport.o build/temp.linux-i686-2.5/CXX/cxxextensions.o build/temp.linux-i686-2.5/src/path.o -L/usr/local/lib -lpng12 -lz -lstdc++ -lm -o build/lib.linux-i686-2.5/matplotlib/_path.so building 'matplotlib.backends._backend_agg' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/_image.cpp -o build/temp.linux-i686-2.5/src/_image.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ /usr/include/libpng12/pngconf.h:317: error: expected constructor, destructor, or type conversion before ‘.’ token /usr/include/libpng12/pngconf.h:318: error: ‘__dont__’ does not name a type error: command 'gcc' failed with exit status 1 |
From: Darren D. <dar...@co...> - 2008-04-24 15:19:44
|
It looks like the recent modification to transforms.py to update datalims only when valid data are available is broken for numpy-1.04. In tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line: xym = ma.masked_where(~npy.isfinite(xy), xy) fails with: File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in plot self.add_line(line) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in add_line self._update_line_limits(line) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in _update_line_limits self.update_datalim( xydata ) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in update_datalim self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits) File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line 699, in update_from_data_xy xym = ma.masked_where(~npy.isfinite(xy), xy) File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in __array_wrap__ domain = ufunc_domain[func] KeyError: <ufunc 'isfinite'> It looks like isfinite doesnt like getting a masked array as input. Is xy always a masked array? If so, maybe that line could look like: xym = ma.masked_where(~npy.isfinite(xy.data), xy) |
From: Michael D. <md...@st...> - 2008-04-24 12:38:14
|
Paul Kienzle wrote: > Hi, > > The superscripts in mpl don't seem to be placed at the correct height for > small fonts. The y-tics on the attached plot shows this. The effect is > similar in svg and pdf backends. > Thanks. When looking up the x-height, the code was not taking the font size into account. This has been fixed on the branch and trunk. > I'm using 0.91.2 because the latest svn version gives me a KeyError for > ufunc isfinite. > Can you provide the full traceback here so we can diagnose and fix this problem? The only reference to isfinite seems to be in the PDF backend, which is working for me, and is identical in 0.91.2 and trunk in that respect. There is probably a more complex Numpy version interaction going on. Cheers, Mike > - Paul > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Paul K. <pki...@ni...> - 2008-04-23 21:17:15
|
Hi, The superscripts in mpl don't seem to be placed at the correct height for small fonts. The y-tics on the attached plot shows this. The effect is similar in svg and pdf backends. I'm using 0.91.2 because the latest svn version gives me a KeyError for ufunc isfinite. - Paul |
From: Carl W. <cw...@cw...> - 2008-04-22 20:26:30
|
On Tue, 22 Apr 2008 15:41:26 -0400, Michael Droettboom wrote: > My concern with subpixel rendering has always been that it's fine for > interactive use, but for producing plots that may end up on someone > else's screen or on a printer, it can actually make matters much worse. Naturally. As such, cairo lets you explicitly choose what you want to draw by setting one of the following values in your font options: CAIRO_ANTIALIAS_NONE: Use a bilevel alpha mask. CAIRO_ANTIALIAS_GRAY: Perform single-color antialiasing (using shades of gray for black text on a white background, for example). CAIRO_ANTIALIAS_SUBPIXEL: Perform antialiasing by taking advantage of the order of subpixel elements on devices such as LCD panels And most importantly, the default value is as follows: CAIRO_ANTIALIAS_DEFAULT: Use the default antialiasing for the subsystem and target device So, (excepting bugs), you should really have to go out of your way to get cairo to do the wrong thing here. -Carl |
From: Michael D. <md...@st...> - 2008-04-22 19:41:48
|
My concern with subpixel rendering has always been that it's fine for interactive use, but for producing plots that may end up on someone else's screen or on a printer, it can actually make matters much worse. Agg (well freetype really) could do subpixel font rendering as well, but I deliberately stayed away from it last time I looked at fonts. We could have some mechanism to determine whether the render is intended for a GUI or a file, but that would have to be dealt with carefully so as not to introduce more backend selection and context related problems. Cheers, Mike Darren Dale wrote: > On Tuesday 22 April 2008 02:54:09 pm Eric Firing wrote: > >> In case any devels are interested in making more backends work on the >> trunk: >> >> Running examples/backend_driver.py yields quite a few svg plots that are >> incorrect, with things like colorbars missing their colors. >> >> The cairo backend does better, but also needs a little work. Cairo is >> looking more interesting with the latest release; the notes say that eps >> output is now supported. >> > > Also, sibpixel rendering of fonts is supported in the new Cairo. On an LCD > monitor, fonts look sharper with Cairo than they do with AGG. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Darren D. <dar...@co...> - 2008-04-22 19:07:18
|
On Tuesday 22 April 2008 02:54:09 pm Eric Firing wrote: > In case any devels are interested in making more backends work on the > trunk: > > Running examples/backend_driver.py yields quite a few svg plots that are > incorrect, with things like colorbars missing their colors. > > The cairo backend does better, but also needs a little work. Cairo is > looking more interesting with the latest release; the notes say that eps > output is now supported. Also, sibpixel rendering of fonts is supported in the new Cairo. On an LCD monitor, fonts look sharper with Cairo than they do with AGG. |
From: Eric F. <ef...@ha...> - 2008-04-22 18:54:34
|
In case any devels are interested in making more backends work on the trunk: Running examples/backend_driver.py yields quite a few svg plots that are incorrect, with things like colorbars missing their colors. The cairo backend does better, but also needs a little work. Cairo is looking more interesting with the latest release; the notes say that eps output is now supported. Eric |
From: Eric F. <ef...@ha...> - 2008-04-22 18:29:31
|
This is inherent; mpl 0.90.1 is permanently incompatible with numpy 1.1, short of each user making the change suggested below. The earliest mpl that should work with numpy 1.1 is 0.91.2. The change in masked array module is a major reason why numpy is getting a version bump to 1.1.0 instead of 1.0.5. Eric Michael Droettboom wrote: > I will forward it to the matplotlib-devel mailing list on your behalf. > > Cheers, > Mike > > lorenzo bolla wrote: >> Hello, >> >> the latest svn numpy version 1.1.0.dev5061 does not work with >> matplotlib 0.90.1 (version shipped with enthought distribution), >> unless a change in >> Python25/Lib/site-packages/matplotlib-0.90.1.0003-py2.5-win32.egg/matplotlib/numerix/ma/__init__.py >> is done: >> >> $ diff __init__.py.orig __init__.py >> 12c12 >> < from numpy.core.ma <http://numpy.core.ma> import * >> --- >>> from numpy.ma <http://numpy.ma> import * >> Maybe this should be forwarded to the pylab mailing list, but I'm not >> subscribed there... >> >> L. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Numpy-discussion mailing list >> Num...@sc... >> http://projects.scipy.org/mailman/listinfo/numpy-discussion >> > |
From: Michael D. <md...@st...> - 2008-04-22 14:25:24
|
I will forward it to the matplotlib-devel mailing list on your behalf. Cheers, Mike lorenzo bolla wrote: > Hello, > > the latest svn numpy version 1.1.0.dev5061 does not work with > matplotlib 0.90.1 (version shipped with enthought distribution), > unless a change in > Python25/Lib/site-packages/matplotlib-0.90.1.0003-py2.5-win32.egg/matplotlib/numerix/ma/__init__.py > is done: > > $ diff __init__.py.orig __init__.py > 12c12 > < from numpy.core.ma <http://numpy.core.ma> import * > --- > > from numpy.ma <http://numpy.ma> import * > > Maybe this should be forwarded to the pylab mailing list, but I'm not > subscribed there... > > L. > > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Num...@sc... > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Eric F. <ef...@ha...> - 2008-04-20 22:46:04
|
Stéfan, OK, I see some differences now, and it looks like it is related to antialiasing and the rendering of patch boundaries. I have run into this sort of thing before, where depending on how patch edges are handled, and depending on the particular renderer and viewer combination, antialiasing can make the result better or worse. To make things even more confusing, a combination that looks good with alpha=1 can look bad with alpha<1. Linewidth of 1 is a bit drastic, and can significantly shift the perceived boundaries. Maybe a smaller value would be adequate. I played with all this a long time ago before settling on linewidth of zero with antialiasing turned on, which seemed to be a good compromise. Either I was wrong, or the Agg rendering is different in Agg 2.4. One of the strange things here is that even when I set the antialiased kwarg to False, I still seem to be getting antialiasing. The lack of effect of the antialiasing kwarg on my system looks like a definite bug that requires investigation. To be continued, but not right now. Eric Stéfan van der Walt wrote: > On 20/04/2008, Eric Firing <ef...@ha...> wrote: >> I don't see any contour lines; I see only the boundaries between patches. >> In other words, the plot looks the way I would expect it to. This is with >> evince or gv on a linux machine. (Both fail when trying to blow up the plot >> to 400%, but work at 200%.) > > Attached is the script that generates the contour plot I'm interested > in. A PNG cropped from the PS onscreen is at > > http://mentat.za.net/refer/contour_zoom.png > > It's small, but the line should be clearly visible. > >> My sense is that there is an optical illusion effect making the boundaries >> look somewhat line-like, but it doesn't sound like this is what you are >> talking about, so I am baffled. > > Could be -- maybe an interpolation effect? Odd thing is that the > lines are differently coloured. In fact, I can get *only* the lines > to render by commenting out certain lines in contour.py. > >> Do you see the problem if you run contourf_demo.py and use the gui to >> generate png, pdf, and ps files from figure 1? I still can't see any sign >> of it anywhere. > > I see contour lines, as shown here: > > http://mentat.za.net/refer/contour_demo.png > >> Would you send a png file generated with and without your workaround, >> please? That should get around any differences in postscript interpreters. > > They are here: > > http://mentat.za.net/refer/contours_without_patch.png > http://mentat.za.net/refer/contours_with_patch.png > >> It sounds like you are seeing something fairly subtle that I am having a >> hard time seeing, and that is new with the transforms branch. > > I don't want to waste your time further with this problem, so if you > think the above png's look fine then I'll just use my workaround. It > might be a problem very specific to my setup. > > Thanks for your time, > Stéfan |
From: S. v. d. W. <st...@su...> - 2008-04-20 21:45:17
|
And the attachment... On 20/04/2008, Eric Firing <ef...@ha...> wrote: |
From: S. v. d. W. <st...@su...> - 2008-04-20 21:44:24
|
On 20/04/2008, Eric Firing <ef...@ha...> wrote: > I don't see any contour lines; I see only the boundaries between patches. > In other words, the plot looks the way I would expect it to. This is with > evince or gv on a linux machine. (Both fail when trying to blow up the plot > to 400%, but work at 200%.) Attached is the script that generates the contour plot I'm interested in. A PNG cropped from the PS onscreen is at http://mentat.za.net/refer/contour_zoom.png It's small, but the line should be clearly visible. > My sense is that there is an optical illusion effect making the boundaries > look somewhat line-like, but it doesn't sound like this is what you are > talking about, so I am baffled. Could be -- maybe an interpolation effect? Odd thing is that the lines are differently coloured. In fact, I can get *only* the lines to render by commenting out certain lines in contour.py. > Do you see the problem if you run contourf_demo.py and use the gui to > generate png, pdf, and ps files from figure 1? I still can't see any sign > of it anywhere. I see contour lines, as shown here: http://mentat.za.net/refer/contour_demo.png > Would you send a png file generated with and without your workaround, > please? That should get around any differences in postscript interpreters. They are here: http://mentat.za.net/refer/contours_without_patch.png http://mentat.za.net/refer/contours_with_patch.png > It sounds like you are seeing something fairly subtle that I am having a > hard time seeing, and that is new with the transforms branch. I don't want to waste your time further with this problem, so if you think the above png's look fine then I'll just use my workaround. It might be a problem very specific to my setup. Thanks for your time, Stéfan |