Re: [matplotlib-devel] v1.4.3rc1
Hi Thomas, On Mon, Feb 2, 2015 at 5:37 AM, Thomas Caswell wrote: > Evening all, > > I have tagged the first release candidate for v1.4.3 > (https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1). ... > Please kick the tires and give it a try! If there are no major issues, the > plan is to target 1.4.3 for next weekend. could you also release a tarball on SF, so I can start updating the debian package and give it a spin on our distro? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
Sandro, Can you use the tarball from github ( https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?) Tom On Sat Feb 07 2015 at 4:01:01 PM Sandro Tosi wrote: > Hi Thomas, > > On Mon, Feb 2, 2015 at 5:37 AM, Thomas Caswell wrote: > > Evening all, > > > > I have tagged the first release candidate for v1.4.3 > > (https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1). > ... > > Please kick the tires and give it a try! If there are no major issues, > the > > plan is to target 1.4.3 for next weekend. > > could you also release a tarball on SF, so I can start updating the > debian package and give it a spin on our distro? > > Cheers, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell wrote: > Sandro, > > Can you use the tarball from github > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?) Sure I can, but since all the previous release (even RC) were done one SF, we have our tools to monitor and download new releases pointing to SF: do you plan to switch to GH for releasing tarballs too? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
Sandro, Well, creating the tarball on GH is a lot easier for us as it happens automatically! I don't want to unilaterally change policy so I will create the files on SF. If you want to tracking GH for debian instead of SF I don't think that would be a bad idea, but I don't know how much of a hassle that would be for you. Tom On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi wrote: > On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell wrote: > > Sandro, > > > > Can you use the tarball from github > > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?) > > Sure I can, but since all the previous release (even RC) were done one > SF, we have our tools to monitor and download new releases pointing to > SF: do you plan to switch to GH for releasing tarballs too? > > Cheers, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Release planning/milestones
Hey all, To start with, the 2.0 release is pending a choice of new default color map. I think that when we pick that we should cut 2.0 off of the last release and then the next minor release turns into 2.1. If we want to do other breaking changes we will just do a 3.0 when that happens. It makes sense to me to bundle default color changes as one set of breaking changes and code API changes as another. Eric made the case in an issue that we should not continue the 1.4.x series and start working 1.5.0, which fits well with aiming for a 6month scheduled release cycle (minor release in July, bug-fix release in February). To this end, I have clean out and close the 1.4.x milestone (most of issues just got moved 1.5.0) and created a 1.5.0 milestone. I set a target for 1.5.0 to be released at scipy as that seems like a reasonable thing to. Targeting just after SciPy also makes sense so we have a clear list of things to work on at the sprints. Thoughts? My internal list of what we should try to get in for 1.5.0 are: - visitor pattern on all artists + recreating figure from it's visited artists. This gets us a) proper serialization of our figures instead of going through pickles and b) makes interoperability with plotly/b3/bokeh easier - pyplot overhaul (use decorators, provide decorators as part of public API) - navigation by events (PR #3652 + MEP22) - making OO interface easier to use interactively (if interactive, auto-redraw at sensible time) - pull the pyplot state machine out of backend_bases and expose the figure_manager classes - overhaul the website Anything else people think should be on the list or any protests to this list? Tom -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] MEP: _zdraworder attribute for Collections
Digging through mplot3d (again), I have come to realize that a lot of its code in art3d.py could be simplified if we had a way to tell collection objects in what order to draw their elements. My proposal is fairly straight-forward. All collections would have an internal _zdraworder attribute that can be anything that can index a numpy array: slice(), array of indices, whatever. The draw() methods will then iterate over their elements returned by indexing with _zdraworder. This will help keep the bookkeeping to a minimum, because everything should be sliced/indexed the same way: offsets, verts, facecolors, etc. The default value will be slice(None), so nothing will change for regular collections. With this, mplot3d can greatly simplify its logic and semantics by focusing on projecting and setting the _zdraworder by running np.argsort() on the projected depth of the elements. Another advantage is that methods like get_facecolors() and set_facecolors() can round-trip in mplot3d (right now, get_facecolors() has to return a z-sorted version of the colors for drawing). For now, I imagine keeping this a private attribute, but I could see some really fancy tricks in the future such as using boolean indexing to mark some elements as visible/invisible, and doing some neat tricks for animations. Thoughts? Ben Root -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP: _zdraworder attribute for Collections
Looking at collections.py, it looks like TriMesh might also benefit from this, as it has specialized code for masking out triangles and determining the order of the triangle elements. Ben Root On Sat, Feb 7, 2015 at 7:18 PM, Benjamin Root wrote: > Digging through mplot3d (again), I have come to realize that a lot of its > code in art3d.py could be simplified if we had a way to tell collection > objects in what order to draw their elements. > > My proposal is fairly straight-forward. All collections would have an > internal _zdraworder attribute that can be anything that can index a numpy > array: slice(), array of indices, whatever. The draw() methods will then > iterate over their elements returned by indexing with _zdraworder. This > will help keep the bookkeeping to a minimum, because everything should be > sliced/indexed the same way: offsets, verts, facecolors, etc. > > The default value will be slice(None), so nothing will change for regular > collections. > > With this, mplot3d can greatly simplify its logic and semantics by > focusing on projecting and setting the _zdraworder by running np.argsort() > on the projected depth of the elements. Another advantage is that methods > like get_facecolors() and set_facecolors() can round-trip in mplot3d (right > now, get_facecolors() has to return a z-sorted version of the colors for > drawing). > > For now, I imagine keeping this a private attribute, but I could see some > really fancy tricks in the future such as using boolean indexing to mark > some elements as visible/invisible, and doing some neat tricks for > animations. > > Thoughts? > Ben Root > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
I am getting some test failures here and on master in the collections module. == FAIL: __main__.test_regularpolycollection_rotate.test -- Traceback (most recent call last): File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 51, in failer result = f(*args, **kwargs) File "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 196, in do_test '(RMS %(rms).3f)'%err) ImageComparisonFailure: images not close: /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png vs. /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png (RMS 54.618) == FAIL: __main__.test_regularpolycollection_scale.test -- Traceback (most recent call last): File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 51, in failer result = f(*args, **kwargs) File "/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 196, in do_test '(RMS %(rms).3f)'%err) ImageComparisonFailure: images not close: /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png vs. /home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png (RMS 120.828) -- Ran 54 tests in 15.149s FAILED (failures=2) The squares in the first test are larger than they should be. I have some other errors, but they seem to other be floating point errors, or issues with fonts. Ben Root On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell wrote: > Sandro, > > Well, creating the tarball on GH is a lot easier for us as it happens > automatically! I don't want to unilaterally change policy so I will create > the files on SF. > > If you want to tracking GH for debian instead of SF I don't think that > would be a bad idea, but I don't know how much of a hassle that would be > for you. > > Tom > > On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi wrote: > >> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell >> wrote: >> > Sandro, >> > >> > Can you use the tarball from github >> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?) >> >> Sure I can, but since all the previous release (even RC) were done one >> SF, we have our tools to monitor and download new releases pointing to >> SF: do you plan to switch to GH for releasing tarballs too? >> >> Cheers, >> -- >> Sandro Tosi (aka morph, morpheus, matrixhasu) >> My website: http://matrixhasu.altervista.org/ >> Me at Debian: http://wiki.debian.org/SandroTosi >> > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
