Re: [matplotlib-devel] v1.4.3rc1
On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell wrote: > 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. Aaah dont worry about changing things :) I can reroute the tools to track GH no problem, what I need to know if that's the place where the next tarballs will be released; if so, I will update the tracking straight away. 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] Release planning/milestones
Hi all! On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell wrote: > 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). Do I understand correctly you plan to maintain 2 separate development lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ? 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] Release planning/milestones
Ah, no I mean the exact opposite! My proposal is to cut 2.0 off of what ever the current stable release is (ex, 1.4.3) and then merge that into master. The next minor release would then be 2.1 and there would be no new 1.Y releases. Tom On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi wrote: > Hi all! > > On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell > wrote: > > 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). > > Do I understand correctly you plan to maintain 2 separate development > lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ? > > 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] Release planning/milestones
On Feb 8, 2015 1:13 AM, "Thomas Caswell" wrote: > > 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. I thought there was going to be a complete overhaul of the default theme? Has that idea been abandoned? > - 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 Do either of these mean that it will be possible to use the OO interface without needing to go through pyplot? -- 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] Release planning/milestones
To overhauling all of the default colors, I think that is still in the cards, but some one who is not me needs to drive that. The goal of pulling pyplot out of backend_bases is exactly that, to be able to do everything using the OO interface in a convenient way. Tom On Sun Feb 08 2015 at 4:50:51 PM Todd wrote: > > On Feb 8, 2015 1:13 AM, "Thomas Caswell" wrote: > > > > 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. > > I thought there was going to be a complete overhaul of the default theme? > Has that idea been abandoned? > > > - 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 > > Do either of these mean that it will be possible to use the OO interface > without needing to go through pyplot? > > -- > 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
Re: [matplotlib-devel] Release planning/milestones
On 2015/02/08 12:05 PM, Thomas Caswell wrote: > The goal of pulling pyplot out of backend_bases is exactly that, to be > able to do everything using the OO interface in a convenient way. > https://github.com/matplotlib/matplotlib/pull/4082 The above PR is an illustration of one approach to making the OO interface draw like the pyplot interface does in interactive mode. There may be a better way to do it, but this way is quite simple and non-intrusive. Eric -- 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] SystemError exception calling agg's draw_path_collection()
I am experimenting with my idea for utilizing a _draworder attribute in Collection objects. Since not everything in a collection is guaranteed to be the same length or even be numpy arrays, I have to add some logic to coerce everything to numpy arrays and tile their data so that the length of their first axis match up. I also have logic to convert all objects back to their original types prior to continuing, just in case that makes any difference. However, using AGG seems to fail here: 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/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 51, in failer result = f(*args, **kwargs) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 183, in do_test figure.savefig(actual_fname, **self._savefig_kwarg) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py", line 1490, in savefig self.canvas.print_figure(*args, **kwargs) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py", line 2211, in print_figure **kwargs) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", line 525, in print_png FigureCanvasAgg.draw(self) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", line 472, in draw self.figure.draw(self.renderer) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py", line 60, in draw_wrapper draw(artist, renderer, *args, **kwargs) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py", line 1094, in draw func(*args) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py", line 273, in draw ax.draw(renderer) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py", line 370, in draw self.gridlines.draw(renderer, project=True) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py", line 203, in draw LineCollection.draw(self, renderer) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py", line 60, in draw_wrapper draw(artist, renderer, *args, **kwargs) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py", line 345, in draw self._offset_position) File "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", line 127, in draw_path_collection return self._renderer.draw_path_collection(*kl, **kw) SystemError: new style getargs format but argument is not a tuple The PDF and SVG backends aren't experiencing this problem. I have taken out the parts of my code that "broadcasted" the arrays, and the error still happens. I then took out the code that coerced everything to numpy arrays in the first place, and the error disappeared (taking that out effectively let everything pass through unaffected). Keep in mind that my code coerced everything back to their original types prior to calling the renderer, so it was merely the action of converting stuff into an array that did this. The best I can figure is that there is something wrong with the C++ code for our agg wrapper? Googling the exception message brings up various discussions of mistakes in the argument handling of C/C++ code. I haven't a clue, though, why this would be an issue. 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
Hi, On Sat, Feb 7, 2015 at 9: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. the release tarball contains __pycache__ directories and other binary files, like lib/matplotlib/backends/_backend_agg.cpython-34m.so (likely it was generated from a "live" directory, where some tests have been run). I just gave a brief look at updating the package and I noticed just some failures in the tests related to test_axes_grid1 (but it might be due to an un-clean env, I will re-run in a chroot to be sure), also any reason not to include https://github.com/matplotlib/matplotlib/commit/ba4016014cb4fb4927e36ce8ea429fed47dcb787#diff-51 ? that would fix CVE-2013-1424 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
Please ignore my test failure report. I was accidentally running an older install of matplotlib from the same branch. Ben Root On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root wrote: > 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
Re: [matplotlib-devel] SystemError exception calling agg's draw_path_collection()
I think I figured it out... the linestyles are a list of tuples. When they get coerced to a numpy array, and then coerced back to a list, you get a list of lists instead of a list of tuples! There must be some code deep down in the agg that is expecting a tuple, and choking on a list. Ben Root On Sun, Feb 8, 2015 at 5:54 PM, Benjamin Root wrote: > I am experimenting with my idea for utilizing a _draworder attribute in > Collection objects. Since not everything in a collection is guaranteed to > be the same length or even be numpy arrays, I have to add some logic to > coerce everything to numpy arrays and tile their data so that the length of > their first axis match up. > > I also have logic to convert all objects back to their original types > prior to continuing, just in case that makes any difference. > > However, using AGG seems to fail here: > > 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/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", > line 51, in failer > result = f(*args, **kwargs) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", > line 183, in do_test > figure.savefig(actual_fname, **self._savefig_kwarg) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py", > line 1490, in savefig > self.canvas.print_figure(*args, **kwargs) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backend_bases.py", > line 2211, in print_figure > **kwargs) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", > line 525, in print_png > FigureCanvasAgg.draw(self) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", > line 472, in draw > self.figure.draw(self.renderer) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py", > line 60, in draw_wrapper > draw(artist, renderer, *args, **kwargs) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/figure.py", > line 1094, in draw > func(*args) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axes3d.py", > line 273, in draw > ax.draw(renderer) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/axis3d.py", > line 370, in draw > self.gridlines.draw(renderer, project=True) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/mpl_toolkits/mplot3d/art3d.py", > line 203, in draw > LineCollection.draw(self, renderer) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/artist.py", > line 60, in draw_wrapper > draw(artist, renderer, *args, **kwargs) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/collections.py", > line 345, in draw > self._offset_position) > File > "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", > line 127, in draw_path_collection > return self._renderer.draw_path_collection(*kl, **kw) > SystemError: new style getargs format but argument is not a tuple > > The PDF and SVG backends aren't experiencing this problem. I have taken > out the parts of my code that "broadcasted" the arrays, and the error still > happens. I then took out the code that coerced everything to numpy arrays > in the first place, and the error disappeared (taking that out effectively > let everything pass through unaffected). Keep in mind that my code coerced > everything back to their original types prior to calling the renderer, so > it was merely the action of converting stuff into an array that did this. > > The best I can figure is that there is something wrong with the C++ code > for our agg wrapper? Googling the exception message brings up various > discussions of mistakes in the argument handling of C/C++ code. I haven't a > clue, though, why this would be an issue. > > 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, v
Re: [matplotlib-devel] v1.4.3rc1
Sorry about the bad tarball, I forgot to clean my git directory before generating it. Another point in favor of using the gh tarball, I can't screw it up. This is the first I have seen that CVE. That PR is not included in 1.4.3 because it completely over-hauls how the Agg rendering works (and generated a whole bunch of other bugs along the way). Mike: Is there a way to fix up the security issues reported on just the 1.4.x branch with out pulling that whole patch back? Tom On Sun Feb 08 2015 at 7:47:00 PM Benjamin Root wrote: > Please ignore my test failure report. I was accidentally running an older > install of matplotlib from the same branch. > > Ben Root > > On Sat, Feb 7, 2015 at 9:08 PM, Benjamin Root wrote: > >> 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 >>> >>> >> >
Re: [matplotlib-devel] v1.4.3rc1
> On 7 Feb 2015, at 10:18 pm, Thomas Caswell wrote:
>
> raise ValueError(msg % style)
> ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style
> library and input is not a valid URL or path. See `style.available` for list
> of available styles.
>
> Is your computer connected to the internet? Can you get to that url in any
> other way? This works on my machine and on the travis (both linux and osx
> https://travis-ci.org/MacPython/scipy-stack-osx-testing). Unfortunately the
> code currently snarfs all exceptions so this makes it hard to sort out what
> exactly is going wrong.
>
Yes, the "not found in the style library and input is not a valid URL or path”
message is not exactly
clear about that. Both with lynx and wget I am getting a warning about an
invalid ssl certificate for
that URL, so I need to explicitly override it or use ‘wget
—no-check-certificate’. Curl seems to have
some issues of its own, does not download the raw file anyway, though silently
unless given ‘-v':
> curl -v -O https://gist.github.com/adrn/6590261/raw
>
* Hostname was NOT found in DNS cache
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying 192.30.252.143...
0 00 00 0 0 0 --:--:-- 0:00:02 --:--:-- 0*
Connected to gist.github.com (192.30.252.143) port 443 (#0)
0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0*
TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *.github.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /adrn/6590261/raw HTTP/1.1
> User-Agent: curl/7.37.1
> Host: gist.github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://gist.githubusercontent.com/adrn/6590261/raw
< Connection: close
<
0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Closing connection 0
> wget https://gist.github.com/adrn/6590261/raw
>
--2015-02-09 01:38:16-- https://gist.github.com/adrn/6590261/raw
Resolving gist.github.com (gist.github.com)... 192.30.252.143
Connecting to gist.github.com (gist.github.com)|192.30.252.143|:443...
connected.
ERROR: cannot verify gist.github.com's certificate, issued by ‘/C=US/O=DigiCert
Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA’:
Unable to locally verify the issuer's authority.
To connect to gist.github.com insecurely, use `--no-check-certificate’.
I don’t know if this is only due to something peculiar with my proxy or cache
settings, but the mpl error
comes down to python2.7’s urllib rejecting this certificate
>>> from urllib2 import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
Traceback (most recent call last):
File "", line 1, in
File "/sw/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/sw/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/sw/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/sw/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/sw/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/sw/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
urllib2.URLError:
(even when using ‘http://...' in the URL), while python3.4 urllib apparently
has no problems with it:
>>> from urllib.request import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
>>> fp
>>> fp.read()
b'axes.facecolor : adeade’
MacOS X’s own /usr/bin/python (2.7.6) works as well, and Safari displays that
URL as encrypted with a trusted
certificate from DigiCert SHA2 High Assurance Server CA.
An obvious suspect would be the latter two using Mac OS X’s system ssl, which
is OpenSSL 0.9.8za, while
lynx, wget and fink python all use fink’s OpenSSL 1.0.2; on a Linux machine
with OpenSSL 1.0.1e wget and
python2.7 can resolve the URL as well (though curl doesn’t download anything
there either).
But Fink’s python3.4 is using the same OpenSSL 1.0.2 as it’s python2.7, and
accepts the certificate as well!
Anyway this is obviously not a matplotlib problem.
> On 10.10 there are a number of additional errors (I’ve checked the
> save_animation
> errors are not due to permission problems):
>
> ERROR:
> matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg', 'mp4')
> --
...
> To be clear, th
