From tcaswell at gmail.com Fri Dec 1 10:45:41 2017 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 01 Dec 2017 15:45:41 +0000 Subject: [Matplotlib-devel] Getting MultiCursor Subplots values (coordinates) In-Reply-To: <1512057979130-0.post@n5.nabble.com> References: <1512057979130-0.post@n5.nabble.com> Message-ID: It looks like MultiCursor does not directly store that information, it just implicitly stores it in the positions of the lines. I would look at `multi.vlines` and `multi.hlines`, loop over those and extract the information you need. Tom On Thu, Nov 30, 2017 at 11:06 AM A.Brahim wrote: > I'm using this code to generate subplots with multiCursor crossing plots, > and > I want to get values (cursor coordinates) for all existing plots at the > same > time to show them in labels (on mouse motion). > > > import numpy as np > import matplotlib.pyplot as plt > from matplotlib.widgets import MultiCursor > > t = np.arange(0.0, 2.0, 0.01) > s1 = np.sin(2*np.pi*t) > s2 = np.sin(4*np.pi*t) > fig = plt.figure() > ax1 = fig.add_subplot(211) > ax1.plot(t, s1) > > > ax2 = fig.add_subplot(212, sharex=ax1) > ax2.plot(t, s2) > > multi = MultiCursor(fig.canvas, (ax1, ax2), color='r', lw=1) > plt.show() > > > > > > > > -- > Sent from: > http://matplotlib.1069221.n5.nabble.com/matplotlib-devel-f28077.html > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quantum.analyst at gmail.com Mon Dec 11 00:44:00 2017 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Mon, 11 Dec 2017 00:44:00 -0500 Subject: [Matplotlib-devel] On testing with other FreeType versions Message-ID: Hi all, Downstream in Fedora (and maybe Debian), they are running into issues with testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide has FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. Many other distros are also transitioning to these newer FreeType as well [1] and I think anaconda recently added 2.8 too. With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms [4]. This is a bit harder to paper over. I see a few ways to mitigate the problem, with varying advantages/disadvantages: 1. Bundle the older version in the Matplotlib package like we do with tests. I don't really believe this to be a viable option for downstream, but I'm just mentioning it to be thorough. There are already a few (minor) security issues in the one we test against. 2. Inject older FreeType just to run tests on the package. Again I don't like this idea. The point of running tests is to be sure that the version in a distro works *in that distro*. Testing with something a user could never install seems useless. 3. Re-create all our current and future test images with 2.8. While this is most future-proof, adding over 800 images is going to bloat the repo quite a bit. 4. Create some sort of side repo with test images for other FreeType releases. This would reduce bloat in the main repo but be somewhat more work. Thus I'd only suggest doing so for tags. I dislike the first two options as they would be repetitive across distros (unless they just stopped testing altogether), but the last two are not without work for us. Opinions? Alternative ideas? [1] https://repology.org/metapackage/freetype/versions [2] https://github.com/QuLogic/matplotlib/commit/cfdc 835923407810bd087f60332cdc8cdcb23f05 [3] https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 -- Elliott -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.lee at berkeley.edu Mon Dec 11 01:40:07 2017 From: antony.lee at berkeley.edu (Antony Lee) Date: Sun, 10 Dec 2017 22:40:07 -0800 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: Hi, 1. Sticking to testing with the old FreeType. Injecting an older FreeType version is "relatively" easy to do (the question is whether you want to do it...). Naively, one could just set LD_PRELOAD to /path/to/libfreetype.so, but that will also affect subprocesses such as imagemagick, which (IIRC) don't like that, so instead the correct way is to ensure that the Python process calls `dlopen('/path/to/libfreetype.so', RTLD_GLOBAL)` which forces symbol resolution *in this process* to first check the given path, but does not affect subprocess (alternatively, one could remove LD_PRELOAD from the environment before calling the subprocess but that seems messier). Fortunately, dlopen is "effectively" available under the name of `ctypes.CDLL` in Python. I have a proof of principle somewhere that patches the testing framework to 1) ensure that an old freetype is built (basically moving the local_freetype implemenation from setupext to the main lib), and 2) loads it as above. Another relevant issue is the manylinux wheels, which must somehow embed a libfreetype. Currently I believe this is done via static linking. This is not so great if you also want to load freetype for other reasons; for example mplcairo (which loads freetype via cairo) currently cannot work with local_freetype builds due to symbol conflicts. I believe that switching to the standard manylinux approach (which is to include the shared object in a hidden folder and set RPATH appropriately) would work better (and allow us to strip out the static linking code). 2. Switching to newer FreeTypes. I don't think committing all test images to the main repo is really a viable option: FreeType is also making new releases every once in a while and different Linuxes have different versions ( https://pkgs.org/download/freetype gives 2.8.1 (Arch, Debian Sid), 2.8 (Fedora 27, Ubuntu 17.10), 2.6.3 (Debian 9, OpenSUSE 42.3), 2.6.1 (Ubuntu 16.04 LTS) and that's only a few). I do believe that adding tooling that generates the test images to a side repo for each tag + FreeType version (say, using the FT versions of the major distros at the time of the tag) may be reasonable. 3. Side note. If #9763 (or #5414) gets accepted (new FT wrappers), they will also require a new generation of the test images: ft2font currently generates "wiggly baselines" in certain cases (see example in #5414), and try as I might (i.e. not so much) I could not reproduce them in the new wrapper :-) Antony 2017-12-10 21:44 GMT-08:00 Elliott Sales de Andrade < quantum.analyst at gmail.com>: > Hi all, > > Downstream in Fedora (and maybe Debian), they are running into issues with > testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide has > FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. > Many other distros are also transitioning to these newer FreeType as well > [1] and I think anaconda recently added 2.8 too. > > With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch > that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms > [4]. This is a bit harder to paper over. > > I see a few ways to mitigate the problem, with varying > advantages/disadvantages: > > 1. Bundle the older version in the Matplotlib package like we do with > tests. I don't really believe this to be a viable option for downstream, > but I'm just mentioning it to be thorough. There are already a few (minor) > security issues in the one we test against. > 2. Inject older FreeType just to run tests on the package. Again I don't > like this idea. The point of running tests is to be sure that the version > in a distro works *in that distro*. Testing with something a user could > never install seems useless. > 3. Re-create all our current and future test images with 2.8. While this > is most future-proof, adding over 800 images is going to bloat the repo > quite a bit. > 4. Create some sort of side repo with test images for other FreeType > releases. This would reduce bloat in the main repo but be somewhat more > work. Thus I'd only suggest doing so for tags. > > I dislike the first two options as they would be repetitive across distros > (unless they just stopped testing altogether), but the last two are not > without work for us. > > Opinions? Alternative ideas? > > [1] https://repology.org/metapackage/freetype/versions > [2] https://github.com/QuLogic/matplotlib/commit/cfdc8359234 > 07810bd087f60332cdc8cdcb23f05 > [3] https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log > [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 > > -- > Elliott > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Dec 11 11:32:15 2017 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 11 Dec 2017 16:32:15 +0000 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: There may also be an interesting machine learning problem here to use a more intelligent criteria for determining if an image has failed. By changing the freetype version we have a bunch of images that do fail pixel comparison that should not and by slightly modifying tests or shuffling the test <-> result image mapping we can generate as many do fail and should fail cases as we need. Tom On Mon, Dec 11, 2017 at 1:40 AM Antony Lee wrote: > Hi, > > 1. Sticking to testing with the old FreeType. > > Injecting an older FreeType version is "relatively" easy to do (the > question is whether you want to do it...). Naively, one could just set > LD_PRELOAD to /path/to/libfreetype.so, but that will also affect > subprocesses such as imagemagick, which (IIRC) don't like that, so instead > the correct way is to ensure that the Python process calls > `dlopen('/path/to/libfreetype.so', RTLD_GLOBAL)` which forces symbol > resolution *in this process* to first check the given path, but does not > affect subprocess (alternatively, one could remove LD_PRELOAD from the > environment before calling the subprocess but that seems messier). > Fortunately, dlopen is "effectively" available under the name of > `ctypes.CDLL` in Python. > > I have a proof of principle somewhere that patches the testing framework > to 1) ensure that an old freetype is built (basically moving the > local_freetype implemenation from setupext to the main lib), and 2) loads > it as above. > > Another relevant issue is the manylinux wheels, which must somehow embed a > libfreetype. Currently I believe this is done via static linking. This is > not so great if you also want to load freetype for other reasons; for > example mplcairo (which loads freetype via cairo) currently cannot work > with local_freetype builds due to symbol conflicts. I believe that > switching to the standard manylinux approach (which is to include the > shared object in a hidden folder and set RPATH appropriately) would work > better (and allow us to strip out the static linking code). > > 2. Switching to newer FreeTypes. > > I don't think committing all test images to the main repo is really a > viable option: FreeType is also making new releases every once in a while > and different Linuxes have different versions ( > https://pkgs.org/download/freetype gives 2.8.1 (Arch, Debian Sid), 2.8 > (Fedora 27, Ubuntu 17.10), 2.6.3 (Debian 9, OpenSUSE 42.3), 2.6.1 (Ubuntu > 16.04 LTS) and that's only a few). > > I do believe that adding tooling that generates the test images to a side > repo for each tag + FreeType version (say, using the FT versions of the > major distros at the time of the tag) may be reasonable. > > 3. Side note. > > If #9763 (or #5414) gets accepted (new FT wrappers), they will also > require a new generation of the test images: ft2font currently generates > "wiggly baselines" in certain cases (see example in #5414), and try as I > might (i.e. not so much) I could not reproduce them in the new wrapper :-) > > Antony > > 2017-12-10 21:44 GMT-08:00 Elliott Sales de Andrade < > quantum.analyst at gmail.com>: > >> Hi all, >> >> Downstream in Fedora (and maybe Debian), they are running into issues >> with testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide >> has FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next >> week. Many other distros are also transitioning to these newer FreeType as >> well [1] and I think anaconda recently added 2.8 too. >> >> With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch >> that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms >> [4]. This is a bit harder to paper over. >> >> I see a few ways to mitigate the problem, with varying >> advantages/disadvantages: >> >> 1. Bundle the older version in the Matplotlib package like we do with >> tests. I don't really believe this to be a viable option for downstream, >> but I'm just mentioning it to be thorough. There are already a few (minor) >> security issues in the one we test against. >> 2. Inject older FreeType just to run tests on the package. Again I don't >> like this idea. The point of running tests is to be sure that the version >> in a distro works *in that distro*. Testing with something a user could >> never install seems useless. >> 3. Re-create all our current and future test images with 2.8. While this >> is most future-proof, adding over 800 images is going to bloat the repo >> quite a bit. >> 4. Create some sort of side repo with test images for other FreeType >> releases. This would reduce bloat in the main repo but be somewhat more >> work. Thus I'd only suggest doing so for tags. >> >> I dislike the first two options as they would be repetitive across >> distros (unless they just stopped testing altogether), but the last two are >> not without work for us. >> >> Opinions? Alternative ideas? >> >> [1] https://repology.org/metapackage/freetype/versions >> [2] >> https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05 >> [3] >> https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log >> [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 >> >> -- >> Elliott >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Mon Dec 11 12:30:08 2017 From: morph at debian.org (Sandro Tosi) Date: Mon, 11 Dec 2017 12:30:08 -0500 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: Debian is also interested in this duscyssuib, we have a local patch to increase the RMS of several tests, but i agree with Elliot the number of failing tests is getting bigger and bigger and just bumping the threshold is not always the best way (as we risk to make the testsuite pass just to not feel bad, without actually spotting real issues). I remember a similar conversation in the past, and the idea of providing multiple sets of reference images, built with different freetype versions, and to release them as an additional tarball the downstream distribution can download and bundle up with the python code release (remember debian dont want to download stuff during the build, which is where we run the test suite). i also like a lot Thomas' idea of having AI/ML actually inspect the image and say if they are alike "enough" for the test to pass instead of a pixel-by-pixel comparison, but it may be a long time effort (GSOC maybe?) and we should also keep an eye on how long the test suite run time it will be (mpl is already long enough to build as is lol) On Mon, Dec 11, 2017 at 11:32 AM, Thomas Caswell wrote: > There may also be an interesting machine learning problem here to use a more > intelligent criteria for determining if an image has failed. > > By changing the freetype version we have a bunch of images that do fail > pixel comparison that should not and by slightly modifying tests or > shuffling the test <-> result image mapping we can generate as many do fail > and should fail cases as we need. > > Tom > > On Mon, Dec 11, 2017 at 1:40 AM Antony Lee wrote: >> >> Hi, >> >> 1. Sticking to testing with the old FreeType. >> >> Injecting an older FreeType version is "relatively" easy to do (the >> question is whether you want to do it...). Naively, one could just set >> LD_PRELOAD to /path/to/libfreetype.so, but that will also affect >> subprocesses such as imagemagick, which (IIRC) don't like that, so instead >> the correct way is to ensure that the Python process calls >> `dlopen('/path/to/libfreetype.so', RTLD_GLOBAL)` which forces symbol >> resolution *in this process* to first check the given path, but does not >> affect subprocess (alternatively, one could remove LD_PRELOAD from the >> environment before calling the subprocess but that seems messier). >> Fortunately, dlopen is "effectively" available under the name of >> `ctypes.CDLL` in Python. >> >> I have a proof of principle somewhere that patches the testing framework >> to 1) ensure that an old freetype is built (basically moving the >> local_freetype implemenation from setupext to the main lib), and 2) loads it >> as above. >> >> Another relevant issue is the manylinux wheels, which must somehow embed a >> libfreetype. Currently I believe this is done via static linking. This is >> not so great if you also want to load freetype for other reasons; for >> example mplcairo (which loads freetype via cairo) currently cannot work with >> local_freetype builds due to symbol conflicts. I believe that switching to >> the standard manylinux approach (which is to include the shared object in a >> hidden folder and set RPATH appropriately) would work better (and allow us >> to strip out the static linking code). >> >> 2. Switching to newer FreeTypes. >> >> I don't think committing all test images to the main repo is really a >> viable option: FreeType is also making new releases every once in a while >> and different Linuxes have different versions >> (https://pkgs.org/download/freetype gives 2.8.1 (Arch, Debian Sid), 2.8 >> (Fedora 27, Ubuntu 17.10), 2.6.3 (Debian 9, OpenSUSE 42.3), 2.6.1 (Ubuntu >> 16.04 LTS) and that's only a few). >> >> I do believe that adding tooling that generates the test images to a side >> repo for each tag + FreeType version (say, using the FT versions of the >> major distros at the time of the tag) may be reasonable. >> >> 3. Side note. >> >> If #9763 (or #5414) gets accepted (new FT wrappers), they will also >> require a new generation of the test images: ft2font currently generates >> "wiggly baselines" in certain cases (see example in #5414), and try as I >> might (i.e. not so much) I could not reproduce them in the new wrapper :-) >> >> Antony >> >> 2017-12-10 21:44 GMT-08:00 Elliott Sales de Andrade >> : >>> >>> Hi all, >>> >>> Downstream in Fedora (and maybe Debian), they are running into issues >>> with testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide >>> has FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. >>> Many other distros are also transitioning to these newer FreeType as well >>> [1] and I think anaconda recently added 2.8 too. >>> >>> With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch >>> that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms >>> [4]. This is a bit harder to paper over. >>> >>> I see a few ways to mitigate the problem, with varying >>> advantages/disadvantages: >>> >>> 1. Bundle the older version in the Matplotlib package like we do with >>> tests. I don't really believe this to be a viable option for downstream, but >>> I'm just mentioning it to be thorough. There are already a few (minor) >>> security issues in the one we test against. >>> 2. Inject older FreeType just to run tests on the package. Again I don't >>> like this idea. The point of running tests is to be sure that the version in >>> a distro works *in that distro*. Testing with something a user could never >>> install seems useless. >>> 3. Re-create all our current and future test images with 2.8. While this >>> is most future-proof, adding over 800 images is going to bloat the repo >>> quite a bit. >>> 4. Create some sort of side repo with test images for other FreeType >>> releases. This would reduce bloat in the main repo but be somewhat more >>> work. Thus I'd only suggest doing so for tags. >>> >>> I dislike the first two options as they would be repetitive across >>> distros (unless they just stopped testing altogether), but the last two are >>> not without work for us. >>> >>> Opinions? Alternative ideas? >>> >>> [1] https://repology.org/metapackage/freetype/versions >>> [2] >>> https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05 >>> [3] >>> https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log >>> [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 >>> >>> -- >>> Elliott >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi From jklymak at uvic.ca Mon Dec 11 12:45:23 2017 From: jklymak at uvic.ca (Jody Klymak) Date: Mon, 11 Dec 2017 09:45:23 -0800 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: <090EE41B-021C-49A9-AC6E-4AF3ACE467F1@uvic.ca> > I see a few ways to mitigate the problem, with varying advantages/disadvantages: > > 1. Bundle the older version in the Matplotlib package like we do with tests. I don't really believe this to be a viable option for downstream, but I'm just mentioning it to be thorough. There are already a few (minor) security issues in the one we test against. > 2. Inject older FreeType just to run tests on the package. Again I don't like this idea. The point of running tests is to be sure that the version in a distro works *in that distro*. Testing with something a user could never install seems useless. > 3. Re-create all our current and future test images with 2.8. While this is most future-proof, adding over 800 images is going to bloat the repo quite a bit. > 4. Create some sort of side repo with test images for other FreeType releases. This would reduce bloat in the main repo but be somewhat more work. Thus I'd only suggest doing so for tags. > > I dislike the first two options as they would be repetitive across distros (unless they just stopped testing altogether), but the last two are not without work for us. I guess something like 4 makes sense to me. You guys have more experience than I do, but? it seems testing *most* of the repo with a fixed FreeType would be fine. The point of most of the tests is to catch Matplotlib bugs, and the exact font being rendered doesn?t matter too much. Then there could be a much smaller separate repo for the tests that depend on the font being rendered, and to test that downstream distributions work. Cheers, Jody > Opinions? Alternative ideas? > > [1] https://repology.org/metapackage/freetype/versions > [2] https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05 > [3] https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log > [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 > > -- > Elliott > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -- Jody Klymak http://web.uvic.ca/~jklymak/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Dec 11 14:48:12 2017 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 11 Dec 2017 19:48:12 +0000 Subject: [Matplotlib-devel] 2017-12-11 call notes Message-ID: My self, Hannah, Eric Firing (first half), Ryan May (second half) - 2.1.1 tagged, conda-forge built, wheels + pypi + docs + announcement tonight. - back to normal time for phone call next week (3pm EST) - cluster of Tk related PRs that need to be merged. - some discussion of categorical support for scalar mappables. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From quantum.analyst at gmail.com Mon Dec 11 21:20:33 2017 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Mon, 11 Dec 2017 21:20:33 -0500 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: On 11 December 2017 at 00:44, Elliott Sales de Andrade < quantum.analyst at gmail.com> wrote: > Hi all, > > Downstream in Fedora (and maybe Debian), they are running into issues with > testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide has > FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. > Many other distros are also transitioning to these newer FreeType as well > [1] and I think anaconda recently added 2.8 too. > > With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch > that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms > [4]. This is a bit harder to paper over. > > I see a few ways to mitigate the problem, with varying > advantages/disadvantages: > > 1. Bundle the older version in the Matplotlib package like we do with > tests. I don't really believe this to be a viable option for downstream, > but I'm just mentioning it to be thorough. There are already a few (minor) > security issues in the one we test against. > 2. Inject older FreeType just to run tests on the package. Again I don't > like this idea. The point of running tests is to be sure that the version > in a distro works *in that distro*. Testing with something a user could > never install seems useless. > 3. Re-create all our current and future test images with 2.8. While this > is most future-proof, adding over 800 images is going to bloat the repo > quite a bit. > 4. Create some sort of side repo with test images for other FreeType > releases. This would reduce bloat in the main repo but be somewhat more > work. Thus I'd only suggest doing so for tags. > > One more thing I forgot to mention is ImageHash [5] which is used by Iris for image tests using the following strategy [6]: - using a perceptual 'image hash' of the outputs as the basis for checking test results. - storing the hashes of 'known accepted results' for each test in a database in the repo - storing associated reference images for each hash value in a separate public repository, allowing human-eye judgement of 'valid equivalent' results. - a new version of the 'iris/tests/idiff.py' assists in comparing proposed new 'correct' result images with the existing accepted ones. While this does reduce load in the main repo itself, it does increase the cognitive load for developers. Iris has a small core group of developers and much fewer drive-by contributions compared to Matplotlib, so I'm not sure we want to be doing this full idea. (Note also their repo is LGPL3, so please don't copy anything from there.) Using ImageHash might still be useful instead of RMS, though it may generalize things too much. I dislike the first two options as they would be repetitive across distros > (unless they just stopped testing altogether), but the last two are not > without work for us. > > Opinions? Alternative ideas? > > [1] https://repology.org/metapackage/freetype/versions > [2] https://github.com/QuLogic/matplotlib/commit/cfdc8359234 > 07810bd087f60332cdc8cdcb23f05 > [3] https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log > [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 > [5] https://pypi.python.org/pypi/ImageHash [6] https://github.com/SciTools/iris/blob/master/docs/iris/src/ developers_guide/graphics_tests.rst#graphics-testing-strategy -- Elliott -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Dec 11 22:49:06 2017 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 12 Dec 2017 03:49:06 +0000 Subject: [Matplotlib-devel] [REL] Matplotlib 2.1.1 Message-ID: Folks, Happy to announce Matplotlib 2.1.1 This is primarily a bug fix release, see https://github.com/matplotlib/matplotlib/releases/tag/v2.1.1 for details. The next planned release is a 2.2 feature release in January/February 2018. Thank you to everyone who worked on this release! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jklymak at uvic.ca Tue Dec 12 01:29:26 2017 From: jklymak at uvic.ca (Jody Klymak) Date: Mon, 11 Dec 2017 22:29:26 -0800 Subject: [Matplotlib-devel] On testing with other FreeType versions In-Reply-To: References: Message-ID: Another idea might be to make most text a unique color that then could be not included in some image diffs. Sure there may be the occasional image that uses that colour but a few missed pixels won?t matter too much. Sent from my iPhone > On Dec 11, 2017, at 6:20 PM, Elliott Sales de Andrade wrote: > >> On 11 December 2017 at 00:44, Elliott Sales de Andrade wrote: >> Hi all, >> >> Downstream in Fedora (and maybe Debian), they are running into issues with testing and text. Fedora 26 has FreeType 2.7.1 and Fedora 27 & Rawhide has FreeType 2.8. Fedora 25 uses 2.6.5, but it will be EOL in the next week. Many other distros are also transitioning to these newer FreeType as well [1] and I think anaconda recently added 2.8 too. >> >> With 2.7.1, a few tests fail (rms < 1) and it is straightforward to patch that [2]. With 2.8 though, over 800 tests fail [3] ranging up to ~80 rms [4]. This is a bit harder to paper over. >> >> I see a few ways to mitigate the problem, with varying advantages/disadvantages: >> >> 1. Bundle the older version in the Matplotlib package like we do with tests. I don't really believe this to be a viable option for downstream, but I'm just mentioning it to be thorough. There are already a few (minor) security issues in the one we test against. >> 2. Inject older FreeType just to run tests on the package. Again I don't like this idea. The point of running tests is to be sure that the version in a distro works *in that distro*. Testing with something a user could never install seems useless. >> 3. Re-create all our current and future test images with 2.8. While this is most future-proof, adding over 800 images is going to bloat the repo quite a bit. >> 4. Create some sort of side repo with test images for other FreeType releases. This would reduce bloat in the main repo but be somewhat more work. Thus I'd only suggest doing so for tags. >> > > One more thing I forgot to mention is ImageHash [5] which is used by Iris for image tests using the following strategy [6]: > using a perceptual 'image hash' of the outputs as the basis for checking test results. > storing the hashes of 'known accepted results' for each test in a database in the repo > storing associated reference images for each hash value in a separate public repository, allowing human-eye judgement of 'valid equivalent' results. > a new version of the 'iris/tests/idiff.py' assists in comparing proposed new 'correct' result images with the existing accepted ones. > While this does reduce load in the main repo itself, it does increase the cognitive load for developers. Iris has a small core group of developers and much fewer drive-by contributions compared to Matplotlib, so I'm not sure we want to be doing this full idea. (Note also their repo is LGPL3, so please don't copy anything from there.) Using ImageHash might still be useful instead of RMS, though it may generalize things too much. > >> I dislike the first two options as they would be repetitive across distros (unless they just stopped testing altogether), but the last two are not without work for us. >> >> Opinions? Alternative ideas? >> >> [1] https://repology.org/metapackage/freetype/versions >> [2] https://github.com/QuLogic/matplotlib/commit/cfdc835923407810bd087f60332cdc8cdcb23f05 >> [3] https://kojipkgs.fedoraproject.org//work/tasks/3137/23623137/build.log >> [4] https://gist.github.com/QuLogic/477055a847a44cd444a0932432acffd1 > > [5] https://pypi.python.org/pypi/ImageHash > [6] https://github.com/SciTools/iris/blob/master/docs/iris/src/developers_guide/graphics_tests.rst#graphics-testing-strategy > > -- > Elliott > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From gina at numfocus.org Fri Dec 15 12:57:20 2017 From: gina at numfocus.org (Gina Helfrich) Date: Fri, 15 Dec 2017 11:57:20 -0600 Subject: [Matplotlib-devel] NumFOCUS End-of-Year Fundraising Drive (Matplotlib fiscal sponsor) Message-ID: Hi folks, NumFOCUS, the nonprofit that provides fiscal sponsorship for Matplotlib, kicks off our end of year fundraising drive officially on Monday and would really appreciate your support! Andy Terrel, NumFOCUS Board President, has generously put up the first $5,000 donation as a matching challenge to the community. For every dollar the community donates, Andy will donate a dollar, up to $5k. Please spread the word and use this link to donate: https://www.flipcause.com/secure/cause_pdetails/Mjc2NTg= Thanks so much for your support of Matplotlib and NumFOCUS! Cheers, Gina -- Dr. Gina Helfrich Communications Director, NumFOCUS -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Wed Dec 27 16:30:00 2017 From: morph at debian.org (Sandro Tosi) Date: Wed, 27 Dec 2017 16:30:00 -0500 Subject: [Matplotlib-devel] how not to install backend_gtk{,agg} Message-ID: Hello folks! in Debian we're trying to phase out GTK2 and all its bindings, including python-gtk2 and python-glade2 it looks like those modules are only used in backend_gtk{,agg}.py, so i had a quick look on how to stop installing those backends (we already provide the Gtk3 Cairo/Agg backends anyway) Is there any better way than to comment setupext.BackendGtkAgg() and setupext.BackendGtk() from setup.py (full disclosure, i havent tried it yet if it actually works)? they seem to just check if the `gtk` module is importable, but i dont want to rely on that module not being available (as in this transition phase, it is possible other packages still depend on it, pulling it in the installed pkgs and thus enable it implicitly for mpl) thanks! From antony.lee at berkeley.edu Wed Dec 27 16:40:41 2017 From: antony.lee at berkeley.edu (Antony Lee) Date: Wed, 27 Dec 2017 13:40:41 -0800 Subject: [Matplotlib-devel] how not to install backend_gtk{,agg} In-Reply-To: References: Message-ID: I believe that setting setup.cfg accordingly is the way to go. setup.cfg.template in the source tree includes the relevant instructions. Antony 2017-12-27 13:30 GMT-08:00 Sandro Tosi : > Hello folks! > in Debian we're trying to phase out GTK2 and all its bindings, > including python-gtk2 and python-glade2 > > it looks like those modules are only used in backend_gtk{,agg}.py, so > i had a quick look on how to stop installing those backends (we > already provide the Gtk3 Cairo/Agg backends anyway) > > Is there any better way than to comment setupext.BackendGtkAgg() and > setupext.BackendGtk() from setup.py (full disclosure, i havent tried > it yet if it actually works)? they seem to just check if the `gtk` > module is importable, but i dont want to rely on that module not being > available (as in this transition phase, it is possible other packages > still depend on it, pulling it in the installed pkgs and thus enable > it implicitly for mpl) > > thanks! > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Wed Dec 27 16:45:32 2017 From: morph at debian.org (Sandro Tosi) Date: Wed, 27 Dec 2017 16:45:32 -0500 Subject: [Matplotlib-devel] how not to install backend_gtk{,agg} In-Reply-To: References: Message-ID: oh yes youre right! i'll set gtk/gtkagg to false in the gui_support section and see how that goes - thanks! On Wed, Dec 27, 2017 at 4:40 PM, Antony Lee wrote: > I believe that setting setup.cfg accordingly is the way to go. > setup.cfg.template in the source tree includes the relevant instructions. > Antony > > 2017-12-27 13:30 GMT-08:00 Sandro Tosi : >> >> Hello folks! >> in Debian we're trying to phase out GTK2 and all its bindings, >> including python-gtk2 and python-glade2 >> >> it looks like those modules are only used in backend_gtk{,agg}.py, so >> i had a quick look on how to stop installing those backends (we >> already provide the Gtk3 Cairo/Agg backends anyway) >> >> Is there any better way than to comment setupext.BackendGtkAgg() and >> setupext.BackendGtk() from setup.py (full disclosure, i havent tried >> it yet if it actually works)? they seem to just check if the `gtk` >> module is importable, but i dont want to rely on that module not being >> available (as in this transition phase, it is possible other packages >> still depend on it, pulling it in the installed pkgs and thus enable >> it implicitly for mpl) >> >> thanks! >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi