Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
Sorry for the delayed reply -- I've been on vacation. Thanks so much for untangling this mess. It looks great. Mike On 06/02/2011 07:46 PM, Darren Dale wrote: > Folks, > > We had some minor confusion with a merge a few weeks back, which > pulled much of the master branch into the v1.0.x maintenance branch. I > created a new v1.0.x-maint branch that rolled back all of the changes > from that point on, and cherry-picked all of the changes that were > actually intended for the v1.0.x branch. > > Please use v1.0.x-maint from now on. v1.0.x has been deleted from the > repository (though I'll keep a local copy for a few weeks as a backup, > just in case). > > If you have any changes that branched from v1.0.x after May 6 2011, > please contact me off list so we can correctly apply those changes on > top of v1.0.x-maint. > > Darren > > -- > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] HTML5 Matplotlib Backend
On 06/06/2011 02:06 PM, Brian Refsdal wrote: > Hello, > > I've been following the updates to mplh5canvas for some time now, since > its debut at SciPy 2010. I am interested in working to extend > mplh5canvas into a cloud-based web service as a thesis project. I have > not found anybody whose is currently working on this path. Are there > any active projects working on this? Specifically, I am referring to > Michael Droettboom's comments of a possible web application and Simon > Ratcliffe's comments about using Flex. If anyone is interested I would > be happy to talk in person at SciPy next month. I did a little exploratory work with this at the Sage Days sprint in Seattle back in March. My (humble) assessment is that HTML 5 Canvas doesn't make much sense for any of the use cases I could dream up, and that in fact SVG is a more appropriate choice for interactive graphics. The browser support for each technology is fairly equivalent at this point, with IE9 finally getting on the SVG bandwagon. The main problem with Canvas (from the point of view of matplotlib) is that it doesn't support persistence, (without building such a layer on top in JavaScript), so if you want to update the figure, you have to send the whole thing over the wire each time. SVG, on the other hand, maintains a tree of objects that can be tweaked at any time (and the performance in the current generation of browsers is stunning). One could send all of the large data objects as SVG from matplotlib to the browser and using XML ids to maintain relationships between the client and the server. Then, do scale the data (in many common cases), it is just a matter of updating the affiine transform on that object, (as well as updating the ticks etc, but that's peanuts), which requires very little bandwidth. I have some hackish "proof of concept" code doing this kind of thing, but it's a long way from there to something that truly works. This all glosses over the path simplification stuff that matplotlib does -- the assumption here is that the browser would have access to *all* of the data, and there are probably practical limits on how big that data can be. I recently did a lot of cleanup to the SVG backend to pave the way for having persistent objects etc. -- though there is no client/server code at all in master at the moment. All of that is "to be written", perhaps by you if you're interested. Cheers, Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] HTML5 Matplotlib Backend
Hey Mike, Thanks for your informative assessment of Canvas vs SVG. Indeed it encapsulates much of the thinking and horse trading done when we decided on Canvas as a delivery technology for mplh5canvas. I particularly agree with you that sending smaller encapsulated updates is less bandwidth intensive (although not necessarily faster to re-rasterise the client display). We have also spent a lot of time tearing our hair out at the primitive drawing commands, the lack of dashed lines in particular is pretty painful. For us the plus points for Canvas came down to our perception of better future browser support, and that most of the browsers seemed to be putting a large push into Canvas performance. Coupled with the use of WebSockets, we felt an all HTML5 solution may be more universally supported in the long run. (although who can tell what the browser vendors are actually thinking :) Our initial testing showed that DOM manipulation was a surprising bottleneck in SVG animations and that, particularly as the SVG object count increased, Canvas performance (time to raster) was better. Also the rendering of the imshow inline png's was a lot quicker than the SVG equivalent in our initial testing. Obviously the vector strengths of SVG are highlighted with higher output DPI, and this is certainly an area of interest. This mail is mostly to give others a bit of background about our choice, I think it could easily have gone either way, and perhaps it should. Most of the client/server code could easily be factored out with a common API that accepts either an SVG or Canvas drawing object for display on the client side. This would give us the best of both worlds (raster and vector) in a number of situations (i.e. lower DPI / high animation rate using Canvas, high DPI with lots of interactivity using SVG etc...). Interactivity would need a tweak on the browser side (much easier to do with SVG than Canvas). As suggested, perhaps Brian Refsdal would be interested in looking at producing a more generic mplweb backend. How about an imshow hybrid, with a canvas for the bitmap and SVG axes and surrounds :) Cheers, Simon Ratcliffe / Ludwig Schwardt SKA South Africa www.ska.ac.za > My (humble) assessment is that HTML 5 Canvas doesn't make much sense for > any of the use cases I could dream up, and that in fact SVG is a more > appropriate choice for interactive graphics. The browser support for > each technology is fairly equivalent at this point, with IE9 finally > getting on the SVG bandwagon. The main problem with Canvas (from the > point of view of matplotlib) is that it doesn't support persistence, > (without building such a layer on top in JavaScript), so if you want to > update the figure, you have to send the whole thing over the wire each > time. SVG, on the other hand, maintains a tree of objects that can be > tweaked at any time (and the performance in the current generation of > browsers is stunning). One could send all of the large data objects as > SVG from matplotlib to the browser and using XML ids to maintain > relationships between the client and the server. Then, do scale the > data (in many common cases), it is just a matter of updating the affiine > transform on that object, (as well as updating the ticks etc, but that's > peanuts), which requires very little bandwidth. I have some hackish > "proof of concept" code doing this kind of thing, but it's a long way > from there to something that truly works. > > This all glosses over the path simplification stuff that matplotlib does > -- the assumption here is that the browser would have access to *all* of > the data, and there are probably practical limits on how big that data > can be. > > I recently did a lot of cleanup to the SVG backend to pave the way for > having persistent objects etc. -- though there is no client/server code > at all in master at the moment. All of that is "to be written", perhaps > by you if you're interested. > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > > -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Mat
Re: [matplotlib-devel] HTML5 Matplotlib Backend
On 06/13/2011 10:07 AM, Simon Ratcliffe wrote: > Hey Mike, > > Thanks for your informative assessment of Canvas vs SVG. Indeed it > encapsulates much of the thinking and horse trading > done when we decided on Canvas as a delivery technology for mplh5canvas. > > For us the plus points for Canvas came down to our perception of > better future browser support, and that most of the browsers seemed to > be putting > a large push into Canvas performance. Coupled with the use of > WebSockets, we felt an all HTML5 solution may be more universally > supported > in the long run. (although who can tell what the browser vendors are > actually thinking :) Yeah. I'll start implementing the "crystal ball" backend so we can answer that question ;) > Our initial testing showed that DOM manipulation was a surprising > bottleneck in SVG animations and that, particularly as the SVG object > count increased, > Canvas performance (time to raster) was better. Interesting result. I wonder if browsers differ in that respect. I've been using Firefox 4 primarily, but testing with Chrome as well, and have been nothing but impressed with SVG performance -- but I'm only doing getElementById and then tweaking attributes, not actually changing tree morphology. > Also the rendering of > the imshow inline png's was a lot quicker than the SVG equivalent in > our initial testing. Have you tried non-inline PNGs? The only need for inline PNGs is to have a self-contained SVG file. When one has a webapp server available that is no longer necessary. I suspect the encoding to/from base64 adds some overhead. > Obviously the vector strengths of SVG are highlighted with higher > output DPI, and this is certainly an area of interest. True. Of course, given that we already have a static SVG backend that works, it should be simple enough to have a "Print" button that generates SVG only when printing (much like Google Docs generates a PDF when printing). > This mail is mostly to give others a bit of background about our > choice, I think it could easily have gone either way, and perhaps it > should. Yes -- perhaps still an open question. I should probably also add: I have sort of a bias toward a smart server/dumb client approach to continue to leverage the existing matplotlib code as much as possible -- which is kind of at odds with the ideal arrangement for best interactive performance, which would be to move a bunch of logic into Javascript. I don't have anything against plotting with Javascript -- there are some great packages out there -- but then it becomes a very different beast. I think your work has that assumption behind it as well, but speaking to some folks at Sage Days, it's not always implied when people start drafting a plan to do this. Cheers, Mike > SKA South Africa > www.ska.ac.za > >> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for >> any of the use cases I could dream up, and that in fact SVG is a more >> appropriate choice for interactive graphics. The browser support for >> each technology is fairly equivalent at this point, with IE9 finally >> getting on the SVG bandwagon. The main problem with Canvas (from the >> point of view of matplotlib) is that it doesn't support persistence, >> (without building such a layer on top in JavaScript), so if you want to >> update the figure, you have to send the whole thing over the wire each >> time. SVG, on the other hand, maintains a tree of objects that can be >> tweaked at any time (and the performance in the current generation of >> browsers is stunning). One could send all of the large data objects as >> SVG from matplotlib to the browser and using XML ids to maintain >> relationships between the client and the server. Then, do scale the >> data (in many common cases), it is just a matter of updating the affiine >> transform on that object, (as well as updating the ticks etc, but that's >> peanuts), which requires very little bandwidth. I have some hackish >> "proof of concept" code doing this kind of thing, but it's a long way >> from there to something that truly works. >> >> This all glosses over the path simplification stuff that matplotlib does >> -- the assumption here is that the browser would have access to *all* of >> the data, and there are probably practical limits on how big that data >> can be. >> >> I recently did a lot of cleanup to the SVG backend to pave the way for >> having persistent objects etc. -- though there is no client/server code >> at all in master at the moment. All of that is "to be written", perhaps >> by you if you're interested. >> >> Cheers, >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> >> -- >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Im
Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?
On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom wrote: > This was recently discussed in the thread "v1.0.x branch seems confused." > > I (believe) the consensus was to get out another v1.0.x maintenance > release out in the near future (which would not support py3k, but would > still support Python 2.4), and then merge the py3 branch into master so > it starts to get some more testing before making the next major release. > > I'm just today merging master into py3 so that when we are ready to do > the merge the other way most of the hard work will have already been done. Are there features already in master that should be supported by http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?
On 06/13/2011 01:38 PM, Darren Dale wrote: > On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom wrote: >> This was recently discussed in the thread "v1.0.x branch seems confused." >> >> I (believe) the consensus was to get out another v1.0.x maintenance >> release out in the near future (which would not support py3k, but would >> still support Python 2.4), and then merge the py3 branch into master so >> it starts to get some more testing before making the next major release. >> >> I'm just today merging master into py3 so that when we are ready to do >> the merge the other way most of the hard work will have already been done. > Are there features already in master that should be supported by > making a 1.1.x maintenance branch before merging the py3 stuff back > into master. Then mpl-1.2 could be the first to support py3. That's a good question. We're now *officially* on 2.7 in my environment, so I don't have any compulsion to raise my hand here. But others may. Speak up! :) > Should we move this discussion to the mpl-dev mailing list? Sure. Cheers, Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] HTML5 Matplotlib Backend
On 06/13/2011 10:07 AM, Simon Ratcliffe wrote: > Hey Mike, > > Thanks for your informative assessment of Canvas vs SVG. Indeed it > encapsulates much of the thinking and horse trading > done when we decided on Canvas as a delivery technology for mplh5canvas. > > I particularly agree with you that sending smaller encapsulated > updates is less bandwidth intensive (although not necessarily faster > to re-rasterise the > client display). We have also spent a lot of time tearing our hair out > at the primitive drawing commands, the lack of dashed lines in > particular > is pretty painful. > > For us the plus points for Canvas came down to our perception of > better future browser support, and that most of the browsers seemed to > be putting > a large push into Canvas performance. Coupled with the use of > WebSockets, we felt an all HTML5 solution may be more universally > supported > in the long run. (although who can tell what the browser vendors are > actually thinking :) > > Our initial testing showed that DOM manipulation was a surprising > bottleneck in SVG animations and that, particularly as the SVG object > count increased, > Canvas performance (time to raster) was better. Also the rendering of > the imshow inline png's was a lot quicker than the SVG equivalent in > our initial testing. > Obviously the vector strengths of SVG are highlighted with higher > output DPI, and this is certainly an area of interest. > > This mail is mostly to give others a bit of background about our > choice, I think it could easily have gone either way, and perhaps it > should. > > Most of the client/server code could easily be factored out with a > common API that accepts either an SVG or Canvas drawing object for > display on the client side. > This would give us the best of both worlds (raster and vector) in a > number of situations (i.e. lower DPI / high animation rate using > Canvas, high DPI with lots of interactivity using SVG etc...). > Interactivity would need a tweak on the browser side (much easier to > do with SVG than Canvas). > > As suggested, perhaps Brian Refsdal would be interested in looking at > producing a more generic mplweb backend. Great! I am interested in developing some of these ideas. I particularly like the idea to keep the transport design independent of the payload. I am also looking to expand on the collaborative element in mplh5canvas, and one of my first thoughts is to move the server code to the cloud. This way all communication can travel over port 80 or 443 for maximum compatibility between networks/ISPs and the instance running matplotlib does not have to serve up pages (latency is a concern, have you found multiple ports to be superior for throughput?). I am also looking to reduce UI request contention with multiple users and develop a session space. Something akin to doodle or imgur where users can anonymously generate unique URLs to share. I have written some prototype code that separates the canvas backend from the web server and websocket server to test for latency issues, but I am open to new ideas. -Brian > > How about an imshow hybrid, with a canvas for the bitmap and SVG axes > and surrounds :) > > Cheers, > > Simon Ratcliffe / Ludwig Schwardt > > SKA South Africa > www.ska.ac.za > >> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for >> any of the use cases I could dream up, and that in fact SVG is a more >> appropriate choice for interactive graphics. The browser support for >> each technology is fairly equivalent at this point, with IE9 finally >> getting on the SVG bandwagon. The main problem with Canvas (from the >> point of view of matplotlib) is that it doesn't support persistence, >> (without building such a layer on top in JavaScript), so if you want to >> update the figure, you have to send the whole thing over the wire each >> time. SVG, on the other hand, maintains a tree of objects that can be >> tweaked at any time (and the performance in the current generation of >> browsers is stunning). One could send all of the large data objects as >> SVG from matplotlib to the browser and using XML ids to maintain >> relationships between the client and the server. Then, do scale the >> data (in many common cases), it is just a matter of updating the affiine >> transform on that object, (as well as updating the ticks etc, but that's >> peanuts), which requires very little bandwidth. I have some hackish >> "proof of concept" code doing this kind of thing, but it's a long way >> from there to something that truly works. >> >> This all glosses over the path simplification stuff that matplotlib does >> -- the assumption here is that the browser would have access to *all* of >> the data, and there are probably practical limits on how big that data >> can be. >> >> I recently did a lot of cleanup to the SVG backend to pave the way for >> having persistent objects etc. -- though there is no client/server code >> at all in master a
Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?
On 06/13/2011 07:38 PM, Darren Dale wrote: > On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom wrote: >> This was recently discussed in the thread "v1.0.x branch seems confused." >> >> I (believe) the consensus was to get out another v1.0.x maintenance >> release out in the near future (which would not support py3k, but would >> still support Python 2.4), and then merge the py3 branch into master so >> it starts to get some more testing before making the next major release. >> >> I'm just today merging master into py3 so that when we are ready to do >> the merge the other way most of the hard work will have already been done. > Are there features already in master that should be supported by > making a 1.1.x maintenance branch before merging the py3 stuff back > into master. Then mpl-1.2 could be the first to support py3. > > Should we move this discussion to the mpl-dev mailing list? > > Darren Ho I wasn't aware of an mpl-dev mailing list. Sorry. py3 is already ok with python3 *and* python2 isn't it? Maybe the website should advertise a bit on the needs to test the py3 branch. Users used to compile mpl from git should be able to produce valuable technical feedback, shoudn't they? Xavier -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Plan to merge the matplotlib-py3 branch?
On Mon, Jun 13, 2011 at 5:33 PM, Xavier Gnata wrote: > On 06/13/2011 07:38 PM, Darren Dale wrote: >> >> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom >> wrote: >>> >>> This was recently discussed in the thread "v1.0.x branch seems confused." >>> >>> I (believe) the consensus was to get out another v1.0.x maintenance >>> release out in the near future (which would not support py3k, but would >>> still support Python 2.4), and then merge the py3 branch into master so >>> it starts to get some more testing before making the next major release. >>> >>> I'm just today merging master into py3 so that when we are ready to do >>> the merge the other way most of the hard work will have already been >>> done. >> >> Are there features already in master that should be supported by >> > making a 1.1.x maintenance branch before merging the py3 stuff back >> into master. Then mpl-1.2 could be the first to support py3. >> >> Should we move this discussion to the mpl-dev mailing list? >> >> Darren > > Ho I wasn't aware of an mpl-dev mailing list. Sorry. > py3 is already ok with python3 *and* python2 isn't it? With python-2.6 and python-2.7, yes, but not with older versions. There will be some outstanding issues with python3, like certain backends that will not work because the gui toolkits have not been ported. > Maybe the website should advertise a bit on the needs to test the py3 > branch. > Users used to compile mpl from git should be able to produce valuable > technical feedback, shoudn't they? I think we should wait until we merge py3 back into the main repo. Darren -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Backend for Pyside
Hi, 1.0.3 packages are available for OS X. I'll be going on vacation next week and my work project using PySide will be winding down over the same period. It would be nice if the PySide changes could be pulled into master before then Thanks, Gerald. On 31/05/2011 5:10 PM, Gerald Storer wrote: > 1.0.3 packages for Windows and Ubuntu/Debian are available to test with. > > I'm not sure that the OS X package is ready yet. If you want to get > testing with it quicker jumping up and down on their mailing list > normally gets them out faster. > > I also added an update to formlayout.py. I've merged in Pierre's latest > version that validates the floats so an exception isn't thrown when a > user inputs an invalid number. > > Gerald. > > On 31/05/2011 4:43 PM, David Trémouilles wrote: >> The pyside bug affecting matplotlib pyside backend is now fixed >> with pyside 1.0.3 >> >> I would be nice to have the pyside option in the next matplotlib release... >> >> Regards, >> >> David >> >> Le 06/05/11 10:32, David Trémouilles a écrit : >>> Hello, >>> >>> This is not directly related to your patch but I would like to >>> report here that I still have at least one issue on MacOs >>> that prevent matplotlib to work with your pyside backend. >>> Indeed current PySide version (1.0.2) have a bug on MacOS that seems to >>> have been fixed recently: >>> http://bugs.pyside.org/show_bug.cgi?id=809 >>> But I will have to wait for next PySide release to >>> confirm your pyside patch works on MacOs. >>> Will test as soon as next pyside version is out and available on >>> macports. I do not have time nor will to test with the latest current >>> pyside head. >>> >>> Regards, >>> >>> David >>> >>> >>> >>> Le 06/05/11 03:36, Gerald Storer a écrit : Hi, I was wondering if I could get a comment on this. Its been 4 weeks since I submitted the original version and it has been more or less production ready since Monday. https://github.com/matplotlib/matplotlib/pull/80 Thanks, Gerald. On 11/04/2011 4:49 PM, Gerald Storer wrote: > Hi, > I've submitted a pull request with backend changes that (should) let > all currently supported versions of PyQt work along side PySide. I've > tested with PyQt 4.8.3 and PySide 1.0.0. > > I haven't bothered chasing down old versions of PyQt as they seem > elusive. > > Gerald. > > On 29/03/2011 3:25 AM, [email protected] wrote: >> Looking forward, supporting the Python 3 compatible PyQt API is >> likely the way to go. >> >> Le , Gerald Storer a écrit : >>> On 28/03/2011 1:10 AM, Peter Butterworth wrote: >>> >>> >>> Wouldn't it be possible to use a single backend compatible with both >>> >>> PyQt and Pyside ? >>> >>> >>> The current Qt mpl backend uses the old PyQt slots/signals API >> which PySide doesn't really support (there are some macros but they >> don't work 100% the same). From a quick glance at the IPython >> implementation it looks like they are using the new API which means >> older versions (<4.5) of PyQt won't be supported. This might be ok, I >> don't know. >>> If it isn't then, there will need to be some try...excepts around >> the place or separate back ends. If you ignore the PySide bugs I had >> to work around I've only changed ~4 lines in the main backend. >>> >>> Pierre's formlayout is also using an obsolete method that isn't >> present in PySide. I've opted to emulate it, but it would be best to >> change the code to use the alternative method available in both PyQt >> and PySide. formlayout also uses the old QString implementation of >> PyQt, PySide only supports the new implementation where QString is >> transparently convert to/from str/unicode. Setting QString = unicode >> seems to work though. >>> >>> Gerald. >>> > -- > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/list
