As some of you probably know, I've been working on a fairly major refactoring of matplotlib. It's now getting to the point where I think more people may want to check it out and kick the tires. It is definitely not ready for real work -- I guarantee the first thing you try will break ;) However, it is passing the vast majority of examples in examples/ (with some major exceptions). The only working backends are Agg and all Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been attempted, and I'm certain is broken. There's a very good chance that external tools like basemap will not work at all. If you care about any of these missing things, you may not want to try the branch yet, or better yet, you may want to check out the branch and get those things working ;) Or, please let me know if the changes make any of those things much harder to do, so the design can be refined while we still have the chance ;) There are more details about the changes in CHANGELOG and API_CHANGES. PASSED_DEMOS contains my own notes about what is currently working. The SVN URL is: https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transforms Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote: > As some of you probably know, I've been working on a fairly major > refactoring of matplotlib. It's now getting to the point where I think > more people may want to check it out and kick the tires. It is > definitely not ready for real work -- I guarantee the first thing you > try will break ;) > > However, it is passing the vast majority of examples in examples/ (with > some major exceptions). The only working backends are Agg and all > Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been > attempted, and I'm certain is broken. There's a very good chance that > external tools like basemap will not work at all. If you care about any > of these missing things, you may not want to try the branch yet, or > better yet, you may want to check out the branch and get those things > working ;) Or, please let me know if the changes make any of those > things much harder to do, so the design can be refined while we still > have the chance ;) > > There are more details about the changes in CHANGELOG and API_CHANGES. > PASSED_DEMOS contains my own notes about what is currently working. > > The SVN URL is: > > > https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transfor >ms I'm looking forward to trying it out. Maybe we can consider switching to the traited config package after the potential merge. I have been running with it for quite a long time, and haven't had any issues. Now that traits can be installed without any additional dependencies, and enthought has been working on playing well with debs and rpms, we could consider making traits an external dependency. I think it should be external, because that will make it easier to generate default config files at compile time. We could also benefit from a reorganization of the src directory tree, one that would not touch the actual api. I think I will have some free evenings and weekends for these projects starting Dec 4. Darren
Darren Dale wrote: > > Maybe we can consider switching to the traited config package after the > potential merge. I have been running with it for quite a long time, and > haven't had any issues. Now that traits can be installed without any > additional dependencies, and enthought has been working on playing well with > debs and rpms, we could consider making traits an external dependency. I > think it should be external, because that will make it easier to generate > default config files at compile time. We could also benefit from a > reorganization of the src directory tree, one that would not touch the actual > api. I think I will have some free evenings and weekends for these projects > starting Dec 4. Darren, When I go to the enthought web site, the most recent traits release I see is 1.1, from August 2006. That doesn't make me optimistic about traits as an external dependency any time soon. Eric
On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > When I go to the enthought web site, the most recent traits release I > see is 1.1, from August 2006. That doesn't make me optimistic about > traits as an external dependency any time soon. That's because the website is unmaintained. There have been two releases lately. One during scipy, and one mainly bug fix and small improvements, last week. This shows that enthought is really bad at communicating there work, something that I have come to realize, and that is a major prolblem. The software it self is pretty good, it just lacks packaging (I have more and more doubts about eggs), good release plans, and testing with different uses than enthought's. Gael
On 10/29/07, Darren Dale <dar...@co...> wrote: > Maybe we can consider switching to the traited config package after the > potential merge. I have been running with it for quite a long time, and I think it would be a good time to do the switch. Michael's changes do not change much of the API, but there are a number of places where there will be changes, and so it is a good idea to get as many of these things in at once. I think a good way to proceed will be to treat this as a pre-pre 1.0 release (0.98?), with widely advertised changes, so people will expect some pain in the upgrade. The only other major thing I want to see overhauled before 1.0 is the axis treatment, so people can add an arbitrary number of x and y axis instances with different scaling and placement. I am also mostly in agreement with Eric that I am hesitant to rely on traits as an external dependency. When I first started testing traits this summer and did the install on my powerbook, the install was anything but painless. The team on the enthought-dev mailing lists was awesome in their support, but it took a lot of support for me to get everything working right, and I was at least 10 times more motivated, and probably more competent, than the typical user. When there is a single tarball or command that works on almost all platforms, and continues to do so for six months or so, I am amenable to making it an external dependency, which is the approach enthought prefers and which has its own advantages . Darren, how much work would it take to get traits 3.0 into our install pipline? Proposed timeline: * get out a release of the current trunk, and make a branch for bug fix releases * merge Michael's branch into the trunk with emails to the lists and posts to the site that svn is bleeding edge, and this time we mean it, with instructions on how to use the oldline branch for people who need up to the minute bug fixes in the old branch * bring enthought traits 3.0 into our build pipeline * turn on traited config, and deprecate the old config. * add traited properties for the artists. * release 0.98 sometime early next year. We probably want to consult with the ipython folks to see what their plans are vis-a-vis traits and config to see if there is any duplication of effort we can avoid.
On Tuesday 30 October 2007 11:07:32 am you wrote: > On 10/29/07, Darren Dale <dar...@co...> wrote: > > Maybe we can consider switching to the traited config package after the > > potential merge. I have been running with it for quite a long time, and > > I think it would be a good time to do the switch. Michael's changes > do not change much of the API, but there are a number of places where > there will be changes, and so it is a good idea to get as many of > these things in at once. I think a good way to proceed will be to > treat this as a pre-pre 1.0 release (0.98?), with widely advertised > changes, so people will expect some pain in the upgrade. The only > other major thing I want to see overhauled before 1.0 is the axis > treatment, so people can add an arbitrary number of x and y axis > instances with different scaling and placement. > > I am also mostly in agreement with Eric that I am hesitant to rely on > traits as an external dependency. When I first started testing traits > this summer and did the install on my powerbook, the install was > anything but painless. The team on the enthought-dev mailing lists > was awesome in their support, but it took a lot of support for me to > get everything working right, and I was at least 10 times more > motivated, and probably more competent, than the typical user. When > there is a single tarball or command that works on almost all > platforms, and continues to do so for six months or so, I am amenable > to making it an external dependency, which is the approach enthought > prefers and which has its own advantages . Darren, how much work > would it take to get traits 3.0 into our install pipline? I think that part should be pretty easy. The hard part is writing the default config file during development and then updating it at build time depending on the available backends, etc. Solving that problem would be easy with an external traits, but with an internal package, I don't think we will have access to the machinery of tconfig until "setup.py install" has been run, is that correct? I'll come up with some kind of workaround. > Proposed timeline: > > * get out a release of the current trunk, and make a branch for bug > fix releases > > * merge Michael's branch into the trunk with emails to the lists and > posts to the site that svn is bleeding edge, and this time we mean it, > with instructions on how to use the oldline branch for people who need > up to the minute bug fixes in the old branch I think we should consider an mpl1 branch and a temporary dev mailing list for that branch, like they did with py3k. It would be less disruptive to the many users who already run svn-mpl. Then when people complain that mpl-0.98 is broken, we can tell them they asked for it :) > * bring enthought traits 3.0 into our build pipeline > > * turn on traited config, and deprecate the old config. > > * add traited properties for the artists. At this point, we should start using the traited config object directly, and add deprecation warnings in the rcParams wrapper. > * release 0.98 sometime early next year. > > We probably want to consult with the ipython folks to see what their > plans are vis-a-vis traits and config to see if there is any > duplication of effort we can avoid. Darren
On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote: > As some of you probably know, I've been working on a fairly major > refactoring of matplotlib. It's now getting to the point where I think > more people may want to check it out and kick the tires. It is > definitely not ready for real work -- I guarantee the first thing you > try will break ;) The first thing I tried was to enable the new config package and run backend_driver. I'm impressed, I saw only one error that doesnt occur in the trunk: driving mri_with_eeg.py Traceback (most recent call last): File "_tmp_mri_with_eeg.py", line 13, in <module> from matplotlib.transforms import get_bbox_transform, Point, Value, Bbox,\ ImportError: cannot import name get_bbox_transform backend_driver was a little slow to run on the transforms branch: Backend Agg took 2.94 minutes to complete template ratio 1.527, template residual 1.015 Backend PS took 1.80 minutes to complete template ratio 0.933, template residual -0.129 Backend Template took 1.92 minutes to complete template ratio 1.000, template residual 0.000 Backend PDF took 2.17 minutes to complete template ratio 1.129, template residual 0.248 Backend SVG took 2.08 minutes to complete template ratio 1.082, template residual 0.158 as compared to the trunk: Backend Agg took 1.53 minutes to complete template ratio 1.628, template residual 0.589 Backend PS took 1.34 minutes to complete template ratio 1.426, template residual 0.399 Backend Template took 0.94 minutes to complete template ratio 1.000, template residual 0.000 Backend PDF took 1.62 minutes to complete template ratio 1.726, template residual 0.680 Backend SVG took 1.45 minutes to complete template ratio 1.548, template residual 0.514 > However, it is passing the vast majority of examples in examples/ (with > some major exceptions). The only working backends are Agg and all > Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been > attempted, and I'm certain is broken. There's a very good chance that > external tools like basemap will not work at all. If you care about any > of these missing things, you may not want to try the branch yet, or > better yet, you may want to check out the branch and get those things > working ;) Or, please let me know if the changes make any of those > things much harder to do, so the design can be refined while we still > have the chance ;)
On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote: > > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > >> When I go to the enthought web site, the most recent traits release I > >> see is 1.1, from August 2006. That doesn't make me optimistic about > >> traits as an external dependency any time soon. > > That's because the website is unmaintained. There have been two releases > > lately. One during scipy, and one mainly bug fix and small improvements, > > last week. > > This shows that enthought is really bad at communicating there work, > > something that I have come to realize, and that is a major prolblem. > > The software it self is pretty good, it just lacks packaging (I have more > > and more doubts about eggs), good release plans, and testing with > > different uses than enthought's. > During the last Scipy conference, Fernando Perez and (I think) Dave > Peterson tracked down the source of a performance hit when we use our new > config package, which uses traits. They determined it was an issue with > setuptools. Do you know what is enthought's current thinking about using > setuptools? Their official thinking is to stick to it, and to improve it. But I have started release tarball that require setuptools only to build, but not at run-time. They are being used to package traits, traitsUI and mayavi2 in Debian. I would be happy to guive more info about that, but I am currently travelling, and my internet access is very poor. Beta versions of tarballs are on http://code.enthought.com/downloads/source . I will make cleaner tarballs of the release that was done last week when I get back home. These tarballscan be used for eg packaging, or integrating the dependency, as Fernando does in ipython. Cheers, Gael
On Wednesday 31 October 2007 12:07:12 pm Gael Varoquaux wrote: > On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote: > > > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote: > > >> When I go to the enthought web site, the most recent traits release I > > >> see is 1.1, from August 2006. That doesn't make me optimistic about > > >> traits as an external dependency any time soon. > > > > > > That's because the website is unmaintained. There have been two > > > releases lately. One during scipy, and one mainly bug fix and small > > > improvements, last week. > > > > > > This shows that enthought is really bad at communicating there work, > > > something that I have come to realize, and that is a major prolblem. > > > > > > The software it self is pretty good, it just lacks packaging (I have > > > more and more doubts about eggs), good release plans, and testing with > > > different uses than enthought's. > > > > During the last Scipy conference, Fernando Perez and (I think) Dave > > Peterson tracked down the source of a performance hit when we use our new > > config package, which uses traits. They determined it was an issue with > > setuptools. Do you know what is enthought's current thinking about using > > setuptools? > > Their official thinking is to stick to it, and to improve it. But I have > started release tarball that require setuptools only to build, but not at > run-time. They are being used to package traits, traitsUI and mayavi2 in > Debian. I would be happy to guive more info about that, but I am > currently travelling, and my internet access is very poor. > > Beta versions of tarballs are on > http://code.enthought.com/downloads/source . I will make cleaner tarballs > of the release that was done last week when I get back home. These > tarballscan be used for eg packaging, or integrating the dependency, as > Fernando does in ipython. This is just what we are looking for. Please let me know when the new tarballs are available. Darren
On Wed, Oct 31, 2007 at 01:55:09PM -0400, Darren Dale wrote: > > Beta versions of tarballs are on > > http://code.enthought.com/downloads/source . I will make cleaner tarballs > > of the release that was done last week when I get back home. These > > tarballscan be used for eg packaging, or integrating the dependency, as > > Fernando does in ipython. > This is just what we are looking for. Please let me know when the new > tarballs are available. I forgot to let you know :->. I made a new release on Saturday. Its a traits 2 release, not a traits 3, but eventhough this is not the latest and greatest, this is what I use on a day to day basis, and it is a well tested and solid release. Gaël