Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint
On Sun, Apr 5, 2009 at 6:38 PM, Eric Firing wrote: > It is not always clear what should go in the 0.98.5 maintenance branch. > For example, is the _png.cpp patch by Tobias, committed by Andrew, a > bug fix or a new feature? I would have said the latter, but I can see > arguments either way. > > More generally, how long do we need to keep updating this maintenance > branch? > I have been meaning to do a release from the branch for some time, but haven't gotten it done. Charlie, if you are out there and have some time, please forge ahead. Otherwise, I will devote some time to it next week when I am back from vacation. In general, only very clear bugfixes which are unlikely to result in "surprise" breakages should go in. The _png patch, though a bug fix, has more of the feel of a feature enhancement, and given its complexity, should probably not go in to the branch unless someone makes a compelling case (though I am very excited to see it go in to the trunk). As soon as we get the branch release out, I would like to push to get a trunk release out as soon as it is ready, and all the remaining outstanding features that people are working on get put in. Then the trunk will become the branch, and the branch will be finished, either removed or allowed to linger for a while and then removed. But I think this should be the last release of this branch, one suitable for debian and other packagers who release infrequently because it should be very stable at this point. > And is there a release schedule in mind? Any prospect of more > thoroughly automating official releases and of adding svn snapshot > releases? And of following numpy's buildbot example? > > I don't think I can help with any of this; I am just casting about to > see if there might be someone on the list who is interested and can > break loose some time. We are not that far away, at least for src snapshots, os x binaries, and the docs. The windows binary would take some work, as would a linux binary, eg a debian package. I am definitely for it, but one or more of us will have to step up and push it through. JDH JDH -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint
John Hunter wrote: > In general, only very clear bugfixes which are unlikely to result in > "surprise" breakages should go in. The _png patch, though a bug fix, > has more of the feel of a feature enhancement, and given its > complexity, should probably not go in to the branch unless someone > makes a compelling case (though I am very excited to see it go in to > the trunk). > OK, I wasn't sure about it when I put it in. Shall I back it out? > We are not that far away, at least for src snapshots, os x binaries, > and the docs. The windows binary would take some work, as would a > linux binary, eg a debian package. FWIW, the Debian packagers will want to make their own .debs from the source package. Also note that the Windows binaries may take more effort than normal -- Python 2.6 is built with a different MS compiler than before. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
I read the thread about mplot3d and the work that has been done by Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. Jonathan's work seems to be great for simple 3D plotting while the mayavi mlab module is here for more "serious" rendering. I think I will concentrate my efforts on a simple GL terminal for IPython with embedded visualization capability. As for sympy (and because it uses pyglet), I guess the integration should be straight forward. Last version of the ipython GL terminal is on launchpad: https://launchpad.net/glipy Nicolas On 7 Apr, 2009, at 00:38 , Cohen-Tanugi Johann wrote: > There has been a recent thread discussing sympy interface to pyglet > in the context of matplotlib refactoring of the 3D code. See thread > named 'Updating MPlot3D to a more recent matplotlib.' > If you are porting pyglet interface to Ipython, Ondrej might be > happy to see his sympy 3D plotting routines go there as well :) > cheers, > Johann > > Nicolas Rougier wrote: >> Sure, thread about IPython integration to be continued on ipython- >> dev list... >> >> Nicolas >> >> On 3 Apr, 2009, at 19:07 , Fernando Perez wrote: >> >> >>> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier >>> wrote: >>> Sorry for that, I coded it on linux and just tested on mac. I fixed the error and upload the new version on the same link. Tell me if it's ok. >>> Great! >>> >>> Would you have any interest in having this be shipped/developed as >>> part of IPython itself? >>> >>> You are using a fair amount of internals of the ipython machinery, >>> and >>> we're getting ready for a large cleanup. Having your code shipped >>> with ipython itself would give it perhaps more exposure, as well as >>> allow it to evolve in sync with the rest of the API, since we could >>> test it as the internals change. >>> >>> I think it would be great to ship this with ipython itself, and I'm >>> sure you'd get help and contributions from the rest of the ipython >>> team as well... >>> >>> Best, >>> >>> f >>> >> >> >> -- >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
Nicolas Rougier wrote: > > I read the thread about mplot3d and the work that has been done by > Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. > Jonathan's work seems to be great for simple 3D plotting while the > mayavi mlab module is here for more "serious" rendering. I think I > will concentrate my efforts on a simple GL terminal for IPython with > embedded visualization capability. As for sympy (and because it uses > pyglet), I guess the integration should be straight forward. > > Last version of the ipython GL terminal is on launchpad: >https://launchpad.net/glipy Hi Nicolas, I haven't tried your glipy terminal, but it looks very interesting. The main issue with an OpenGL backend for MPL is simply that a naive implementation is going to look ugly when compared, pixel-by-pixel, against the Agg or cairo backends to generate bitmaps. Agg and cairo are very good at drawing anti-aliased lines, whereas one must jump through hoops to get consumer OpenGL cards to render lines well. Here's an idea -- an OpenGLAgg backend that actually uses Agg for all the rendering, but blits the results to an OpenGL texture for display. Thus, the backend would really just be glue between the existing Agg backend and pyglet. -Andrew -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
What I do generally to have "nice" OpenGL output is to render screenshots at high resolution and then use something like gimp to resize them. I agree that it is far from optimal but it's pretty decent for a scientific paper. Other solutions are vector rendering of scene (using gl2ps for example) or the texture anti-aliasing technique (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html). But, beside rendering issue, I think an OpenGL backend could be useful for experiments involving very fast rendering of large arrays. Using OpenGL texture, you can render 1000x1000 arrays with continuous update of data (on recent machines). Nicolas On 7 Apr, 2009, at 19:05 , Andrew Straw wrote: > Nicolas Rougier wrote: >> >> I read the thread about mplot3d and the work that has been done by >> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. >> Jonathan's work seems to be great for simple 3D plotting while the >> mayavi mlab module is here for more "serious" rendering. I think I >> will concentrate my efforts on a simple GL terminal for IPython with >> embedded visualization capability. As for sympy (and because it uses >> pyglet), I guess the integration should be straight forward. >> >> Last version of the ipython GL terminal is on launchpad: >> https://launchpad.net/glipy > > Hi Nicolas, I haven't tried your glipy terminal, but it looks very > interesting. > > The main issue with an OpenGL backend for MPL is simply that a naive > implementation is going to look ugly when compared, pixel-by-pixel, > against the Agg or cairo backends to generate bitmaps. Agg and cairo > are > very good at drawing anti-aliased lines, whereas one must jump through > hoops to get consumer OpenGL cards to render lines well. > > Here's an idea -- an OpenGLAgg backend that actually uses Agg for all > the rendering, but blits the results to an OpenGL texture for display. > Thus, the backend would really just be glue between the existing Agg > backend and pyglet. > > -Andrew > > -- > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
Nicolas Rougier wrote: > > What I do generally to have "nice" OpenGL output is to render > screenshots at high resolution and then use something like gimp to > resize them. I agree that it is far from optimal but it's pretty > decent for a scientific paper. Other solutions are vector rendering of > scene (using gl2ps for example) or the texture anti-aliasing technique > (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html). Yes. That is why I said a "naive" implementation. > But, beside rendering issue, I think an OpenGL backend could be useful > for experiments involving very fast rendering of large arrays. Using > OpenGL texture, you can render 1000x1000 arrays with continuous update > of data (on recent machines). Yes. I wrote a module pygarrayimage for just that: http://code.astraw.com/projects/motmot/pygarrayimage.html BTW, my ideas were meant more as "how to wedge MPL quickly into glipy with a minimum of work" rather than "a talented programmer with one year of free time to come up with the coolest scientific workflow GUI" variety. -Andrew -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint
John Hunter wrote: [...] >> And is there a release schedule in mind? Any prospect of more >> thoroughly automating official releases and of adding svn snapshot >> releases? And of following numpy's buildbot example? >> >> I don't think I can help with any of this; I am just casting about to >> see if there might be someone on the list who is interested and can >> break loose some time. > > We are not that far away, at least for src snapshots, os x binaries, > and the docs. The windows binary would take some work, as would a > linux binary, eg a debian package. I am definitely for it, but one or > more of us will have to step up and push it through. For snapshots, I think that packages are needed only for OS X and Windows. Anyone who is going to be running snapshots on linux should be able to build from a tarball or svn. (And they should be installing in /usr/local or a private location.) The only step that might be nice to make that easier would be to list the package dependencies for common distros--that is, not just in generic form, but the actual names. Eric -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
> > BTW, my ideas were meant more as "how to wedge MPL quickly into glipy > with a minimum of work" rather than "a talented programmer with one > year > of free time to come up with the coolest scientific workflow GUI" > variety. Sorry, I did not understood your proposal in the first place... That might be a good thing to try, I'll have a look at as soon as I have more free time. Nicolas -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint
On Tue, Apr 7, 2009 at 18:06, Andrew Straw wrote: > John Hunter wrote: >> We are not that far away, at least for src snapshots, os x binaries, >> and the docs. The windows binary would take some work, as would a >> linux binary, eg a debian package. > FWIW, the Debian packagers will want to make their own .debs from the > source package. I'm ready and waiting for a shiny new release to give our beloved Debian users a package to install ;) In unstable we have a "rather old" release, 0.98.3, since I was asked to not upload 0.98.5.2 to the main audience (it's now in experimental, JFTR). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
