From matthew.brett at gmail.com Tue May 3 16:47:20 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 May 2016 16:47:20 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel wrote: >> I tested it with: >> >> import matplotlib >> matplotlib.use('PyQt5') > > Typo, this was supposed to read: > > matplotlib.use('Qt5Agg') Meanwhile, I tried removing (patchelf --remove-needed) the requirements of _tkagg.so on the vendored libtk, libtcl, and added back the requirement (patch --add-needed) on general `libtk.so' and 'libtcl.so'. This removed the segfault and allowed me to display `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are using is relatively stable across versions 8.4 (on the docker image) and 8.6 (on Debian sid). Worth experimenting with this - or too much of a hack? Is there a way to add libraries to ignore, in `auditwheel repair` ? Cheers, Matthew From njs at pobox.com Wed May 4 05:30:09 2016 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 4 May 2016 02:30:09 -0700 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Wed, May 4, 2016 at 12:40 AM, Olivier Grisel wrote: > 2016-05-03 22:47 GMT+02:00 Matthew Brett : >> On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel wrote: >>>> I tested it with: >>>> >>>> import matplotlib >>>> matplotlib.use('PyQt5') >>> >>> Typo, this was supposed to read: >>> >>> matplotlib.use('Qt5Agg') >> >> Meanwhile, I tried removing (patchelf --remove-needed) the >> requirements of _tkagg.so on the vendored libtk, libtcl, and added >> back the requirement (patch --add-needed) on general `libtk.so' and >> 'libtcl.so'. This removed the segfault and allowed me to display >> `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are >> using is relatively stable across versions 8.4 (on the docker image) >> and 8.6 (on Debian sid). >> >> Worth experimenting with this - or too much of a hack? >> >> Is there a way to add libraries to ignore, in `auditwheel repair` ? > > It sounds reasonable to add this feature as a CLI option to me. > > Also maybe we could decide to amend PEP 513 to add libtk.so and > libtcl.so to the system provided white-list as they are direct > dependencies for Python via tkinter which is part of the standard > library. I believe that they're optional dependencies, i.e. if you build python on a system that's missing TCL/TK then it just disables those modules? They might be available-in-fact on every system we care about, I don't know -- but unfortunately we can't assume that they're available-in-principle :-/. (It looks like Debian at least splits tk off into its own python-tk package.) -n -- Nathaniel J. Smith -- https://vorpus.org From ben.v.root at gmail.com Wed May 4 09:28:40 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Wed, 4 May 2016 09:28:40 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Yes, Tcl/Tk is technically optional, but it is usually included. However, I am not entirely convinced that restricted environments like google app engine would really benefit from having tkagg available. These sort of environments are intended to be headless environments, anyway, so having AGG available is sufficient. My concern is about making it easier for everyone else, even if it will take some time to get there. Who would be best to head up the submission of the patch to Tkinter? On Wed, May 4, 2016 at 5:30 AM, Nathaniel Smith wrote: > On Wed, May 4, 2016 at 12:40 AM, Olivier Grisel > wrote: > > 2016-05-03 22:47 GMT+02:00 Matthew Brett : > >> On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel < > olivier.grisel at ensta.org> wrote: > >>>> I tested it with: > >>>> > >>>> import matplotlib > >>>> matplotlib.use('PyQt5') > >>> > >>> Typo, this was supposed to read: > >>> > >>> matplotlib.use('Qt5Agg') > >> > >> Meanwhile, I tried removing (patchelf --remove-needed) the > >> requirements of _tkagg.so on the vendored libtk, libtcl, and added > >> back the requirement (patch --add-needed) on general `libtk.so' and > >> 'libtcl.so'. This removed the segfault and allowed me to display > >> `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > >> using is relatively stable across versions 8.4 (on the docker image) > >> and 8.6 (on Debian sid). > >> > >> Worth experimenting with this - or too much of a hack? > >> > >> Is there a way to add libraries to ignore, in `auditwheel repair` ? > > > > It sounds reasonable to add this feature as a CLI option to me. > > > > Also maybe we could decide to amend PEP 513 to add libtk.so and > > libtcl.so to the system provided white-list as they are direct > > dependencies for Python via tkinter which is part of the standard > > library. > > I believe that they're optional dependencies, i.e. if you build python > on a system that's missing TCL/TK then it just disables those modules? > They might be available-in-fact on every system we care about, I don't > know -- but unfortunately we can't assume that they're > available-in-principle :-/. > > (It looks like Debian at least splits tk off into its own python-tk > package.) > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > 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 isaac.gerg at gergltd.com Fri May 6 13:34:28 2016 From: isaac.gerg at gergltd.com (Isaac Gerg) Date: Fri, 6 May 2016 13:34:28 -0400 Subject: [Matplotlib-devel] Issue with suptitle In-Reply-To: References: Message-ID: Calling fig.canvas.draw() had no effect. On Sat, Mar 19, 2016 at 11:53 PM, Antony Lee wrote: > re: centering: You may want to check the discussion there: > https://github.com/matplotlib/matplotlib/issues/5463 > Briefly, adding a call to `fig.canvas.draw()` before creating the colorbar > can improve the situation a bit. > > (sorry for the double posting, I had to delete the images). > > 2016-03-10 13:51 GMT-08:00 Isaac Gerg : > >> Hi, >> >> I am currently writing a test suite by which you input your matplotlibrc >> file and it generates you a set of commonly used plots so you can examine >> the aesthetics of your config. >> >> I am having 2 issues, >> 1. How do I make SupTitle centered in matplotlibrc? >> 2. How do I make the points larger on the scatter plot? >> >> See attached pictures. >> >> I'm happy to share the code if someone wants it. >> >> Isaac >> >> _______________________________________________ >> 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 May 9 21:58:29 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 10 May 2016 01:58:29 +0000 Subject: [Matplotlib-devel] Near term release schedule Message-ID: Hey folks, The current plan for near term release is to by the end of the month tag: - a 2.0 beta (v2.0.0b1) - a 1.5.2rc1 1.5.2 will be the last release in the 1.x series. We anticipate that the 2.0 release cycle will be long to give people enough time to try out the new defaults. If you have any cycles to devote to either code review or bug squashing on the outstanding issues on either the 2.0 or 1.5.2 milestones please do! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon May 9 23:18:56 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 10 May 2016 03:18:56 +0000 Subject: [Matplotlib-devel] Long term release schedule Message-ID: Folks, Compared to the short term schedule this maybe be a bit for contentious as it puts dropping Py2 on our road map. This has been discussed by my self, Mike Droettboom, Eric Firing and Jens Nielsen. As I am sure you are all aware, upstream cpython is planning to drop support for python 2.7 in 2020 which leaves us in the scientific community to sort out how to manage this transition. There seems to be momentum for the transition and we have reached the point where the discussion is not _if_ we drop python 2 support but _when_. The Jupyter/IPython team is working to build a community wide consensus [0] on moving to python3 for feature releases before 2020. This text is still under development, but text has been consistent in spirit. Instead if my attempting to summarize, please go read ;) We propose the following long term schedule for mpl: 2016-09/10 : 2.1 what we have on master is probably good enough for a release already but target - traitlets - the gui overhaul if we miss them, tag in late september anyway 2017-07 : 2.2 LTS - last feature release with 2.7 support - critical bug fixes on mpl 2.2.x branch until 2020 - solicit a dedicated py2.7 maintainer 2018-07 : 3.0 - only support py3.4+ - chance to break functional API if we want This is less aggressive of a schedule than IPython (they have a planned py3 only release at the beginning of 2017) and gives us ample time to address any unexpected issues in the transition. This plan is not with out risks (ex as master picks up python3 only code it will diverge from 2.2.x making back-porting bug fixes harder), however continuing to support python 2.7 forever has it's own. If we have users that can not (or will not) switch from py2 we are going to need those users to step up and support the continued maintenance of a 2.7 compatible branch. My personal thinking on this has been greatly influenced by Nick Coghlan [1], the continued support of deprecated versions of python for commercial use can not fall on a small group of volunteers. As a project we have a couple of decisions to make: 1. If we adopt this as our time line (and if not what time line do we use) 2. If we add mpl + our time line to https://python3statement.github.io/ Tom [0] https://python3statement.github.io/ [1] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Tue May 10 00:03:16 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 9 May 2016 21:03:16 -0700 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: Hey Thomas, Some comment inline, On Mon, May 9, 2016 at 8:18 PM, Thomas Caswell wrote: > Folks, > > Compared to the short term schedule this maybe be a bit for contentious as > it puts dropping Py2 on our road map. This has been discussed by my self, > Mike Droettboom, Eric Firing and Jens Nielsen. > > As I am sure you are all aware, upstream cpython is planning to drop support > for python 2.7 in 2020 which leaves us in the scientific community to sort > out how to manage this transition. There seems to be momentum for the > transition and we have reached the point where the discussion is not _if_ we > drop python 2 support but _when_. > > The Jupyter/IPython team is working to build a community wide consensus [0] > on moving to python3 for feature releases before 2020. This text is still > under development, but text has been consistent in spirit. Instead if my > attempting to summarize, please go read ;) > > We propose the following long term schedule for mpl: > > 2016-09/10 : 2.1 > what we have on master is probably good enough for a release already but > target > - traitlets > - the gui overhaul > if we miss them, tag in late september anyway > > 2017-07 : 2.2 LTS > - last feature release with 2.7 support > - critical bug fixes on mpl 2.2.x branch until 2020 > - solicit a dedicated py2.7 maintainer > > 2018-07 : 3.0 > - only support py3.4+ I wouldn't commit now to which version of Py3 you will support, It seem to me that upgrade of python 3 minor version seem to be a much more accepted process than fro Py2, and 2018 is 2,5 years down the road, so by that time you might decide to do 3.5+ only, who knows. > - chance to break functional API if we want > > This is less aggressive of a schedule than IPython (they have a planned py3 > only release at the beginning of 2017) and gives us ample time to address > any unexpected issues in the transition. > We are always 3 to 6 month behind schedule, but here is the more detailed roadmap [3] > This plan is not with out risks (ex as master picks up python3 only code it > will diverge from 2.2.x making back-porting bug fixes harder), however > continuing to support python 2.7 forever has it's own. > > If we have users that can not (or will not) switch from py2 we are going to > need those users to step up and support the continued maintenance of a 2.7 > compatible branch. My personal thinking on this has been greatly influenced > by Nick Coghlan [1], the continued support of deprecated versions of python > for commercial use can not fall on a small group of volunteers. I want to emphasize that if you would be interested in commercial support by that time (regardless of the project), it would be good to speak soon-ish, so that companies like continuum/enthought... can start planning for providing this support. > As a project we have a couple of decisions to make: > > 1. If we adopt this as our time line (and if not what time line do we use) > 2. If we add mpl + our time line to https://python3statement.github.io/ > > > [0] https://python3statement.github.io/ > [1] > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html Thanks, -- M [3] https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md From matthew.brett at gmail.com Tue May 10 11:59:04 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 11:59:04 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Tue, May 3, 2016 at 4:47 PM, Matthew Brett wrote: > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel wrote: >>> I tested it with: >>> >>> import matplotlib >>> matplotlib.use('PyQt5') >> >> Typo, this was supposed to read: >> >> matplotlib.use('Qt5Agg') > > Meanwhile, I tried removing (patchelf --remove-needed) the > requirements of _tkagg.so on the vendored libtk, libtcl, and added > back the requirement (patch --add-needed) on general `libtk.so' and > 'libtcl.so'. This removed the segfault and allowed me to display > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > using is relatively stable across versions 8.4 (on the docker image) > and 8.6 (on Debian sid). > > Worth experimenting with this - or too much of a hack? I have experimented with this. It does seem that we can get away with using the system tcl / tk libraries as installed, at least on a couple of Debian systems I have. Now there's a new problem, to do with linux library namespaces. We need the _tkagg.so file to use the same libraries as the Python Tkinter package at run time. There can be more than one tcl / tk version installed on a given system, so, as things stand, we'd need to inspect the Tkinter extension modules to see what they are using, and then work out a way to use those libraries at run time. Here are the questions for the experts out there: * Can anyone think of a way of using the symbol namespace of the tkinter extension modules directly, to pick up the symbols we need rather than re-importing the libraries? * If we do discover which libraries Tkinter is using, what would be a good way of pulling in these libraries at run-time? Cheers, Matthew From njs at pobox.com Tue May 10 16:13:28 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 10 May 2016 13:13:28 -0700 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On May 10, 2016 09:00, "Matthew Brett" wrote: > > Hi, > > On Tue, May 3, 2016 at 4:47 PM, Matthew Brett wrote: > > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel wrote: > >>> I tested it with: > >>> > >>> import matplotlib > >>> matplotlib.use('PyQt5') > >> > >> Typo, this was supposed to read: > >> > >> matplotlib.use('Qt5Agg') > > > > Meanwhile, I tried removing (patchelf --remove-needed) the > > requirements of _tkagg.so on the vendored libtk, libtcl, and added > > back the requirement (patch --add-needed) on general `libtk.so' and > > 'libtcl.so'. This removed the segfault and allowed me to display > > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > > using is relatively stable across versions 8.4 (on the docker image) > > and 8.6 (on Debian sid). > > > > Worth experimenting with this - or too much of a hack? > > I have experimented with this. It does seem that we can get away with > using the system tcl / tk libraries as installed, at least on a couple > of Debian systems I have. > > Now there's a new problem, to do with linux library namespaces. We > need the _tkagg.so file to use the same libraries as the Python > Tkinter package at run time. There can be more than one tcl / tk > version installed on a given system, so, as things stand, we'd need to > inspect the Tkinter extension modules to see what they are using, and > then work out a way to use those libraries at run time. Here are the > questions for the experts out there: > > * Can anyone think of a way of using the symbol namespace of the > tkinter extension modules directly, to pick up the symbols we need > rather than re-importing the libraries? It would be a bit of a weird hack, but we could have _tkagg.so "link" against the tkinter extension module. The idea would be that we don't care about the symbols that the tkinter extension exports, but we'd take advantage on the fact the on ELF, linking against one .so automatically gives you not just its symbols, but also the symbols of all the libraries that it links against, transitively. This would probably look like: _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls this module) Before loading _tkagg.so, we use Python level introspection figure out where tkinter.so lives We add its directory to LD_LIBRARY_PATH we import _tkagg.so We take its directory back off of LD_LIBRARY_PATH Very weird, but I can't see why it wouldn't work, and probably more reliable than anything where we try to reimplement the dynamic loader's search logic ourselves. > * If we do discover which libraries Tkinter is using, what would be a > good way of pulling in these libraries at run-time? > > Cheers, > > Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue May 10 17:26:19 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 17:26:19 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Tue, May 10, 2016 at 4:13 PM, Nathaniel Smith wrote: > On May 10, 2016 09:00, "Matthew Brett" wrote: >> >> Hi, >> >> On Tue, May 3, 2016 at 4:47 PM, Matthew Brett >> wrote: >> > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel >> > wrote: >> >>> I tested it with: >> >>> >> >>> import matplotlib >> >>> matplotlib.use('PyQt5') >> >> >> >> Typo, this was supposed to read: >> >> >> >> matplotlib.use('Qt5Agg') >> > >> > Meanwhile, I tried removing (patchelf --remove-needed) the >> > requirements of _tkagg.so on the vendored libtk, libtcl, and added >> > back the requirement (patch --add-needed) on general `libtk.so' and >> > 'libtcl.so'. This removed the segfault and allowed me to display >> > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are >> > using is relatively stable across versions 8.4 (on the docker image) >> > and 8.6 (on Debian sid). >> > >> > Worth experimenting with this - or too much of a hack? >> >> I have experimented with this. It does seem that we can get away with >> using the system tcl / tk libraries as installed, at least on a couple >> of Debian systems I have. >> >> Now there's a new problem, to do with linux library namespaces. We >> need the _tkagg.so file to use the same libraries as the Python >> Tkinter package at run time. There can be more than one tcl / tk >> version installed on a given system, so, as things stand, we'd need to >> inspect the Tkinter extension modules to see what they are using, and >> then work out a way to use those libraries at run time. Here are the >> questions for the experts out there: >> >> * Can anyone think of a way of using the symbol namespace of the >> tkinter extension modules directly, to pick up the symbols we need >> rather than re-importing the libraries? > > It would be a bit of a weird hack, but we could have _tkagg.so "link" > against the tkinter extension module. The idea would be that we don't care > about the symbols that the tkinter extension exports, but we'd take > advantage on the fact the on ELF, linking against one .so automatically > gives you not just its symbols, but also the symbols of all the libraries > that it links against, transitively. > > This would probably look like: > > _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls > this module) > > Before loading _tkagg.so, we use Python level introspection figure out where > tkinter.so lives > > We add its directory to LD_LIBRARY_PATH > > we import _tkagg.so > > We take its directory back off of LD_LIBRARY_PATH > > Very weird, but I can't see why it wouldn't work, and probably more reliable > than anything where we try to reimplement the dynamic loader's search logic > ourselves. Nice - yes - it does work in a first-pass test - I'll look into automating that. Cheers, Matthew From matthew.brett at gmail.com Tue May 10 17:52:08 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 17:52:08 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 5:26 PM, Matthew Brett wrote: > Hi, > > On Tue, May 10, 2016 at 4:13 PM, Nathaniel Smith wrote: >> On May 10, 2016 09:00, "Matthew Brett" wrote: >>> >>> Hi, >>> >>> On Tue, May 3, 2016 at 4:47 PM, Matthew Brett >>> wrote: >>> > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel >>> > wrote: >>> >>> I tested it with: >>> >>> >>> >>> import matplotlib >>> >>> matplotlib.use('PyQt5') >>> >> >>> >> Typo, this was supposed to read: >>> >> >>> >> matplotlib.use('Qt5Agg') >>> > >>> > Meanwhile, I tried removing (patchelf --remove-needed) the >>> > requirements of _tkagg.so on the vendored libtk, libtcl, and added >>> > back the requirement (patch --add-needed) on general `libtk.so' and >>> > 'libtcl.so'. This removed the segfault and allowed me to display >>> > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are >>> > using is relatively stable across versions 8.4 (on the docker image) >>> > and 8.6 (on Debian sid). >>> > >>> > Worth experimenting with this - or too much of a hack? >>> >>> I have experimented with this. It does seem that we can get away with >>> using the system tcl / tk libraries as installed, at least on a couple >>> of Debian systems I have. >>> >>> Now there's a new problem, to do with linux library namespaces. We >>> need the _tkagg.so file to use the same libraries as the Python >>> Tkinter package at run time. There can be more than one tcl / tk >>> version installed on a given system, so, as things stand, we'd need to >>> inspect the Tkinter extension modules to see what they are using, and >>> then work out a way to use those libraries at run time. Here are the >>> questions for the experts out there: >>> >>> * Can anyone think of a way of using the symbol namespace of the >>> tkinter extension modules directly, to pick up the symbols we need >>> rather than re-importing the libraries? >> >> It would be a bit of a weird hack, but we could have _tkagg.so "link" >> against the tkinter extension module. The idea would be that we don't care >> about the symbols that the tkinter extension exports, but we'd take >> advantage on the fact the on ELF, linking against one .so automatically >> gives you not just its symbols, but also the symbols of all the libraries >> that it links against, transitively. >> >> This would probably look like: >> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls >> this module) >> >> Before loading _tkagg.so, we use Python level introspection figure out where >> tkinter.so lives >> >> We add its directory to LD_LIBRARY_PATH >> >> we import _tkagg.so >> >> We take its directory back off of LD_LIBRARY_PATH >> >> Very weird, but I can't see why it wouldn't work, and probably more reliable >> than anything where we try to reimplement the dynamic loader's search logic >> ourselves. > > Nice - yes - it does work in a first-pass test - I'll look into automating that. Ah - except I do not believe it is possible to change the linker path for Python modules, within the Python process: http://www.gossamer-threads.com/lists/python/python/393770#393770 Ugh. Matthew From njs at pobox.com Tue May 10 18:38:59 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 10 May 2016 15:38:59 -0700 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida wrote: > On 10 May 2016 at 18:52, Matthew Brett wrote: >> >> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >> wrote: >> >> [...] >> >> >> >> This would probably look like: >> >> >> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >> >> calls >> >> this module) >> >> >> >> Before loading _tkagg.so, we use Python level introspection figure out >> >> where >> >> tkinter.so lives >> >> >> >> We add its directory to LD_LIBRARY_PATH >> >> >> >> we import _tkagg.so >> >> >> >> We take its directory back off of LD_LIBRARY_PATH >> >> >> >> Very weird, but I can't see why it wouldn't work, and probably more >> >> reliable >> >> than anything where we try to reimplement the dynamic loader's search >> >> logic >> >> ourselves. >> > >> > Nice - yes - it does work in a first-pass test - I'll look into >> > automating that. >> >> Ah - except I do not believe it is possible to change the linker path >> for Python modules, within the Python process: >> >> http://www.gossamer-threads.com/lists/python/python/393770#393770 Doh :-( > I was about to point that out... > > On the other hand, if there is a `Tkinter` module that Python can import, > just importing it will make the symbols needed the `_tkagg` module > available, assuming Python calls `dlopen()` on import with RTLD_GLOBAL[1]. > > [1] http://man7.org/linux/man-pages/man3/dlopen.3.html > But it doesn't use RTLD_GLOBAL. You can make it with sys.setdlopenflags, but this then dumps a bunch of symbols into *every* Python extension module's namespace, which is pretty risky... -n -- Nathaniel J. Smith -- https://vorpus.org From matthew.brett at gmail.com Wed May 11 09:58:51 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 11 May 2016 09:58:51 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida > wrote: >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>> wrote: >>> >> [...] >>> >> >>> >> This would probably look like: >>> >> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>> >> calls >>> >> this module) >>> >> >>> >> Before loading _tkagg.so, we use Python level introspection figure out >>> >> where >>> >> tkinter.so lives >>> >> >>> >> We add its directory to LD_LIBRARY_PATH >>> >> >>> >> we import _tkagg.so >>> >> >>> >> We take its directory back off of LD_LIBRARY_PATH >>> >> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>> >> reliable >>> >> than anything where we try to reimplement the dynamic loader's search >>> >> logic >>> >> ourselves. >>> > >>> > Nice - yes - it does work in a first-pass test - I'll look into >>> > automating that. >>> >>> Ah - except I do not believe it is possible to change the linker path >>> for Python modules, within the Python process: >>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 > > Doh :-( Any other suggestions? I guess this will be a problem for the external library PEP? Matthew From njs at pobox.com Wed May 11 19:26:37 2016 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 11 May 2016 16:26:37 -0700 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Wed, May 11, 2016 at 6:58 AM, Matthew Brett wrote: > On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >> wrote: >>> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>> >>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>> wrote: >>>> >> [...] >>>> >> >>>> >> This would probably look like: >>>> >> >>>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>>> >> calls >>>> >> this module) >>>> >> >>>> >> Before loading _tkagg.so, we use Python level introspection figure out >>>> >> where >>>> >> tkinter.so lives >>>> >> >>>> >> We add its directory to LD_LIBRARY_PATH >>>> >> >>>> >> we import _tkagg.so >>>> >> >>>> >> We take its directory back off of LD_LIBRARY_PATH >>>> >> >>>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>> >> reliable >>>> >> than anything where we try to reimplement the dynamic loader's search >>>> >> logic >>>> >> ourselves. >>>> > >>>> > Nice - yes - it does work in a first-pass test - I'll look into >>>> > automating that. >>>> >>>> Ah - except I do not believe it is possible to change the linker path >>>> for Python modules, within the Python process: >>>> >>>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >> >> Doh :-( > > Any other suggestions? One option is to just drop tk support from the wheels, and stick with Qt or GTK. Super annoying because it would mean we need to sort out the Qt-or-GTK wheel situation too, but I guess we have to do that anyway, and this would just move it up the priority list? Barring that, I guess the plan of converting _tkagg.so to ctypes is the only option. I assume the matplotlib devs are very motivated to get linux wheels -- maybe we can convince them to implement this? :-) > I guess this will be a problem for the external library PEP? (It's not a PEP) For the external library proposal on Linux it's annoying but I think we're okay -- instead of adjusting LD_LIBRARY_PATH we can fall back to using the "preload trick", like on Windows. Basically exploiting our old friend this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19884 :-). And on Windows I know we can use the preload trick, so that's okay. What I'm really worried about now is OS X -- we need at least one of these to work: {runtime changes to DYLD_LIBRARY_PATH, the preloading trick}. Do they? If not then we have a serious problem :-/ -n -- Nathaniel J. Smith -- https://vorpus.org From dr369 at nau.edu Thu May 12 15:13:43 2016 From: dr369 at nau.edu (plotalot) Date: Thu, 12 May 2016 12:13:43 -0700 (MST) Subject: [Matplotlib-devel] PSD Scaling (matplotlib version 1.4.X versus 1.5.X) Message-ID: <1463080423584-47064.post@n5.nabble.com> Hello, I noticed an inconsistency with the pyplot.psd function when upgrading from matplotlib version 1.4.0 to 1.5.3 I have written some code (below) that will show what I'm talking about when run with the different matplotlib versions. In 1.4.0, the line "PX2 /= fft_size" was needed, but gives the wrong answer (P_ave is not equal to 1, and Pxw.max() is -36dB instead of 0dB) if it is included when using 1.5.3 I am mainly concerned with knowing if this change was intentional; will it behave like this from now on (no longer needing division by fft_size)? import matplotlib.pyplot as plt import matplotlib.mlab as mlab import numpy as np fft_size = 4096 fs = 2500.00 gram_lines = 100; t = np.arange(1.0,gram_lines*fft_size,1.0); t = t / fs; del_f = fs/fft_size; base_freq = 10.0 # in Hz bin_err = 0.0 f = (int(base_freq / del_f) + bin_err) * del_f # ensure f is in center of Fourier band A = np.sqrt(2.0); # if the amplitude is sqrt(2) then the total power = 1.0 linear and 0.0 in dB dat = A * np.sin(2 * np.pi * f * t); (Px2, F) = plt.psd(dat, NFFT = fft_size, Fs=fs, Fc=0, detrend=mlab.detrend_none, window=mlab.window_none, noverlap=0, pad_to = None, sides='onesided', scale_by_freq = False); Px2 /= fft_size; #comment this line out if using 1.5.1?? P_ave = sum(Px2); Px2 = 10.0*np.log10(Px2); #print results to compare actual with expected print "Sum of psd Px2 = %f, This should equal 1.0." %P_ave print "Max psd Px2 = %f dB. This should equal 0.0 dB if freq is a multiple of freq resolution.\n" %(Px2.max()) -- View this message in context: http://matplotlib.1069221.n5.nabble.com/PSD-Scaling-matplotlib-version-1-4-X-versus-1-5-X-tp47064.html Sent from the matplotlib - devel mailing list archive at Nabble.com. From matthew.brett at gmail.com Thu May 12 16:28:10 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 12 May 2016 16:28:10 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Wed, May 11, 2016 at 7:26 PM, Nathaniel Smith wrote: > On Wed, May 11, 2016 at 6:58 AM, Matthew Brett wrote: >> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>> wrote: >>>> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>>> >>>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>>> wrote: >>>>> >> [...] >>>>> >> >>>>> >> This would probably look like: >>>>> >> >>>>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>>>> >> calls >>>>> >> this module) >>>>> >> >>>>> >> Before loading _tkagg.so, we use Python level introspection figure out >>>>> >> where >>>>> >> tkinter.so lives >>>>> >> >>>>> >> We add its directory to LD_LIBRARY_PATH >>>>> >> >>>>> >> we import _tkagg.so >>>>> >> >>>>> >> We take its directory back off of LD_LIBRARY_PATH >>>>> >> >>>>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>>> >> reliable >>>>> >> than anything where we try to reimplement the dynamic loader's search >>>>> >> logic >>>>> >> ourselves. >>>>> > >>>>> > Nice - yes - it does work in a first-pass test - I'll look into >>>>> > automating that. >>>>> >>>>> Ah - except I do not believe it is possible to change the linker path >>>>> for Python modules, within the Python process: >>>>> >>>>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>> >>> Doh :-( >> >> Any other suggestions? > > One option is to just drop tk support from the wheels, and stick with > Qt or GTK. Super annoying because it would mean we need to sort out > the Qt-or-GTK wheel situation too, but I guess we have to do that > anyway, and this would just move it up the priority list? > > Barring that, I guess the plan of converting _tkagg.so to ctypes is > the only option. > > I assume the matplotlib devs are very motivated to get linux wheels -- > maybe we can convince them to implement this? :-) > >> I guess this will be a problem for the external library PEP? > > (It's not a PEP) > > For the external library proposal on Linux it's annoying but I think > we're okay -- instead of adjusting LD_LIBRARY_PATH we can fall back to > using the "preload trick", like on Windows. Basically exploiting our > old friend this bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=19884 > :-). > > And on Windows I know we can use the preload trick, so that's okay. > > What I'm really worried about now is OS X -- we need at least one of > these to work: {runtime changes to DYLD_LIBRARY_PATH, the preloading > trick}. Do they? If not then we have a serious problem :-/ Sorry - writing in haste - but I believe that OSX does have preload trick. There's something called the "install name" : http://matthew-brett.github.io/docosx/mac_runtime_link.html#the-install-name - this is the name the library declares. I believe (but I am not sure) that once a library is loaded with a given "install name" then no further libraries with the same required install name get loaded... Cheers, Matthew From tcaswell at gmail.com Sat May 14 13:41:09 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 14 May 2016 17:41:09 +0000 Subject: [Matplotlib-devel] PSD Scaling (matplotlib version 1.4.X versus 1.5.X) In-Reply-To: <1463080423584-47064.post@n5.nabble.com> References: <1463080423584-47064.post@n5.nabble.com> Message-ID: I suspect that this is related to https://github.com/matplotlib/matplotlib/issues/4328 which was fixed by https://github.com/matplotlib/matplotlib/pull/4593 and was an intentional change. Tom On Thu, May 12, 2016 at 3:13 PM plotalot wrote: > Hello, > > I noticed an inconsistency with the pyplot.psd function when upgrading > from matplotlib version 1.4.0 to 1.5.3 > > I have written some code (below) that will show what I'm talking about > when run with the different matplotlib versions. In 1.4.0, the line "PX2 > /= fft_size" was needed, but gives the wrong answer (P_ave is not equal > to 1, and Pxw.max() is -36dB instead of 0dB) if it is included when > using 1.5.3 > > I am mainly concerned with knowing if this change was intentional; will > it behave like this from now on (no longer needing division by fft_size)? > > import matplotlib.pyplot as plt > import matplotlib.mlab as mlab > import numpy as np > > fft_size = 4096 > fs = 2500.00 > > gram_lines = 100; > t = np.arange(1.0,gram_lines*fft_size,1.0); > t = t / fs; > del_f = fs/fft_size; > base_freq = 10.0 # in Hz > bin_err = 0.0 > f = (int(base_freq / del_f) + bin_err) * del_f # ensure f is in center > of Fourier band > A = np.sqrt(2.0); # if the amplitude is sqrt(2) then the total power = > 1.0 linear and 0.0 in dB > dat = A * np.sin(2 * np.pi * f * t); > > (Px2, F) = plt.psd(dat, NFFT = fft_size, Fs=fs, Fc=0, > detrend=mlab.detrend_none, window=mlab.window_none, noverlap=0, pad_to = > None, sides='onesided', scale_by_freq = False); > Px2 /= fft_size; #comment this line out if using 1.5.1?? > P_ave = sum(Px2); > Px2 = 10.0*np.log10(Px2); > > #print results to compare actual with expected > print "Sum of psd Px2 = %f, This should equal 1.0." %P_ave > print "Max psd Px2 = %f dB. This should equal 0.0 dB if freq is a > multiple of freq resolution.\n" %(Px2.max()) > > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/PSD-Scaling-matplotlib-version-1-4-X-versus-1-5-X-tp47064.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > _______________________________________________ > 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 Sat May 14 14:15:38 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 14 May 2016 18:15:38 +0000 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: Hey all, Any feed back on this? Not sure if silence means you all agree or disagree so badly that no one can compose a polite email ;). Tom On Tue, May 10, 2016 at 12:03 AM Matthias Bussonnier < bussonniermatthias at gmail.com> wrote: > Hey Thomas, > > Some comment inline, > > On Mon, May 9, 2016 at 8:18 PM, Thomas Caswell wrote: > > Folks, > > > > Compared to the short term schedule this maybe be a bit for contentious > as > > it puts dropping Py2 on our road map. This has been discussed by my > self, > > Mike Droettboom, Eric Firing and Jens Nielsen. > > > > As I am sure you are all aware, upstream cpython is planning to drop > support > > for python 2.7 in 2020 which leaves us in the scientific community to > sort > > out how to manage this transition. There seems to be momentum for the > > transition and we have reached the point where the discussion is not > _if_ we > > drop python 2 support but _when_. > > > > The Jupyter/IPython team is working to build a community wide consensus > [0] > > on moving to python3 for feature releases before 2020. This text is > still > > under development, but text has been consistent in spirit. Instead if > my > > attempting to summarize, please go read ;) > > > > We propose the following long term schedule for mpl: > > > > 2016-09/10 : 2.1 > > what we have on master is probably good enough for a release already > but > > target > > - traitlets > > - the gui overhaul > > if we miss them, tag in late september anyway > > > > 2017-07 : 2.2 LTS > > - last feature release with 2.7 support > > - critical bug fixes on mpl 2.2.x branch until 2020 > > - solicit a dedicated py2.7 maintainer > > > > 2018-07 : 3.0 > > - only support py3.4+ > > I wouldn't commit now to which version of Py3 you will support, It > seem to me that upgrade > of python 3 minor version seem to be a much more accepted process than fro > Py2, > and 2018 is 2,5 years down the road, so by that time you might decide > to do 3.5+ only, who knows. > > > - chance to break functional API if we want > > > > This is less aggressive of a schedule than IPython (they have a planned > py3 > > only release at the beginning of 2017) and gives us ample time to address > > any unexpected issues in the transition. > > > > We are always 3 to 6 month behind schedule, but here is the more > detailed roadmap [3] > > > This plan is not with out risks (ex as master picks up python3 only code > it > > will diverge from 2.2.x making back-porting bug fixes harder), however > > continuing to support python 2.7 forever has it's own. > > > > If we have users that can not (or will not) switch from py2 we are going > to > > need those users to step up and support the continued maintenance of a > 2.7 > > compatible branch. My personal thinking on this has been greatly > influenced > > by Nick Coghlan [1], the continued support of deprecated versions of > python > > for commercial use can not fall on a small group of volunteers. > > I want to emphasize that if you would be interested in commercial > support by that time > (regardless of the project), it would be good to speak soon-ish, so > that companies like > continuum/enthought... can start planning for providing this support. > > > > As a project we have a couple of decisions to make: > > > > 1. If we adopt this as our time line (and if not what time line do we > use) > > 2. If we add mpl + our time line to https://python3statement.github.io/ > > > > > > [0] https://python3statement.github.io/ > > [1] > > > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > > Thanks, > -- > M > > [3] > https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmay31 at gmail.com Sun May 15 13:16:22 2016 From: rmay31 at gmail.com (Ryan May) Date: Sun, 15 May 2016 11:16:22 -0600 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: It's a general +1 from me but: 1) I tend to move on aggressively 2) I'm sure there are consequences I haven't considered. Ryan On Sat, May 14, 2016 at 12:15 PM, Thomas Caswell wrote: > Hey all, > > Any feed back on this? > > Not sure if silence means you all agree or disagree so badly that no one > can compose a polite email ;). > > Tom > > On Tue, May 10, 2016 at 12:03 AM Matthias Bussonnier < > bussonniermatthias at gmail.com> wrote: > >> Hey Thomas, >> >> Some comment inline, >> >> On Mon, May 9, 2016 at 8:18 PM, Thomas Caswell >> wrote: >> > Folks, >> > >> > Compared to the short term schedule this maybe be a bit for contentious >> as >> > it puts dropping Py2 on our road map. This has been discussed by my >> self, >> > Mike Droettboom, Eric Firing and Jens Nielsen. >> > >> > As I am sure you are all aware, upstream cpython is planning to drop >> support >> > for python 2.7 in 2020 which leaves us in the scientific community to >> sort >> > out how to manage this transition. There seems to be momentum for the >> > transition and we have reached the point where the discussion is not >> _if_ we >> > drop python 2 support but _when_. >> > >> > The Jupyter/IPython team is working to build a community wide consensus >> [0] >> > on moving to python3 for feature releases before 2020. This text is >> still >> > under development, but text has been consistent in spirit. Instead if >> my >> > attempting to summarize, please go read ;) >> > >> > We propose the following long term schedule for mpl: >> > >> > 2016-09/10 : 2.1 >> > what we have on master is probably good enough for a release already >> but >> > target >> > - traitlets >> > - the gui overhaul >> > if we miss them, tag in late september anyway >> > >> > 2017-07 : 2.2 LTS >> > - last feature release with 2.7 support >> > - critical bug fixes on mpl 2.2.x branch until 2020 >> > - solicit a dedicated py2.7 maintainer >> > >> > 2018-07 : 3.0 >> > - only support py3.4+ >> >> I wouldn't commit now to which version of Py3 you will support, It >> seem to me that upgrade >> of python 3 minor version seem to be a much more accepted process than >> fro Py2, >> and 2018 is 2,5 years down the road, so by that time you might decide >> to do 3.5+ only, who knows. >> >> > - chance to break functional API if we want >> > >> > This is less aggressive of a schedule than IPython (they have a planned >> py3 >> > only release at the beginning of 2017) and gives us ample time to >> address >> > any unexpected issues in the transition. >> > >> >> We are always 3 to 6 month behind schedule, but here is the more >> detailed roadmap [3] >> >> > This plan is not with out risks (ex as master picks up python3 only >> code it >> > will diverge from 2.2.x making back-porting bug fixes harder), however >> > continuing to support python 2.7 forever has it's own. >> > >> > If we have users that can not (or will not) switch from py2 we are >> going to >> > need those users to step up and support the continued maintenance of a >> 2.7 >> > compatible branch. My personal thinking on this has been greatly >> influenced >> > by Nick Coghlan [1], the continued support of deprecated versions of >> python >> > for commercial use can not fall on a small group of volunteers. >> >> I want to emphasize that if you would be interested in commercial >> support by that time >> (regardless of the project), it would be good to speak soon-ish, so >> that companies like >> continuum/enthought... can start planning for providing this support. >> >> >> > As a project we have a couple of decisions to make: >> > >> > 1. If we adopt this as our time line (and if not what time line do we >> use) >> > 2. If we add mpl + our time line to >> https://python3statement.github.io/ >> > >> > >> > [0] https://python3statement.github.io/ >> > [1] >> > >> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html >> >> Thanks, >> -- >> M >> >> [3] >> https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabien.maussion at gmail.com Sun May 15 16:45:32 2016 From: fabien.maussion at gmail.com (Fabien) Date: Sun, 15 May 2016 22:45:32 +0200 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: On 05/14/2016 08:15 PM, Thomas Caswell wrote: > > Not sure if silence means you all agree or disagree so badly that no one > can compose a polite email ;). I totally agree, but I think that my opinion is not very useful in that case ;-) What would be more interesting to read are arguments against this initiative. But I believe that once the major projects (mpl, jupyter, ipython, pandas...) have made the first step, others will undoubtedly follow. Fabien From ben.v.root at gmail.com Mon May 16 10:44:41 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 16 May 2016 10:44:41 -0400 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: I think this timeline is reasonable, and it is especially important that we express this now, so that various members of the python community can use these statements as evidence to their management that it is time to begin the transition process in their enterprise. In my company, one of the things holding us back is the amount of code that has little if any unit tests. For the codebases that do have decent coverage, our usage of CI is spotty. So, we target a particular platform and we never get much opportunity to automatically test other platforms to ensure that our changes aren't py3k-breaking. What is changing is that GitLab is improving its CI interface, so -- hopefully -- it'll get better soon. If it doesn't, then I guess I'll become the resident py2.7 supporter... Ben Root On Sun, May 15, 2016 at 4:45 PM, Fabien wrote: > On 05/14/2016 08:15 PM, Thomas Caswell wrote: > >> >> Not sure if silence means you all agree or disagree so badly that no one >> can compose a polite email ;). >> > > I totally agree, but I think that my opinion is not very useful in that > case ;-) > > What would be more interesting to read are arguments against this > initiative. But I believe that once the major projects (mpl, jupyter, > ipython, pandas...) have made the first step, others will undoubtedly > follow. > > Fabien > > > > > > > _______________________________________________ > 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 fabien.maussion at gmail.com Mon May 16 12:25:10 2016 From: fabien.maussion at gmail.com (Fabien) Date: Mon, 16 May 2016 18:25:10 +0200 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: On 05/16/2016 04:44 PM, Benjamin Root wrote: > > In my company, one of the things holding us back is the amount of code > that has little if any unit tests. For the codebases that do have decent > coverage, our usage of CI is spotty. So, we target a particular platform > and we never get much opportunity to automatically test other platforms > to ensure that our changes aren't py3k-breaking. What is changing is > that GitLab is improving its CI interface, so -- hopefully -- it'll get > better soon. > > If it doesn't, then I guess I'll become the resident py2.7 supporter... I think that what you describe is what most users will say, and this makes sense. However, does the codebase you mention (the one with hardly any tests, etc.) really depend on the very-last-update of the dependencies? After 2020 it will still be possible to run py2 programs... From bussonniermatthias at gmail.com Mon May 16 13:42:19 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 16 May 2016 10:42:19 -0700 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: On Sun, May 15, 2016 at 1:45 PM, Fabien wrote: > > What would be more interesting to read are arguments against this > initiative. But I believe that once the major projects (mpl, jupyter, > ipython, pandas...) have made the first step, others will undoubtedly > follow. Devil's advocate: You will piss of some people that will either stop contributing, or fork MPL, and get an indefinite number of bug report from people stuck on the last version supporting 2.7. I suspect you will have two wave of people pissed: When you switch master to 3+ only, and when you **release** a 3+ only version. You'll have **some** packaging pain, as you need to publish a `tar.gz` and `zip` that pip should not even **try** to install on Python 2. As for undoubtedly following, I would not be so sure. I can see pandas and numpy be one of the last projects dropping support. Especially numpy which is at the base of most of the SciPy Stack. Though, having **their dependents** being python 3 only will likely make their decision much easier. Will mercurial ever migrate to Py3... I'm not sure, but we can argue it's not in the Scientific stack. -- M From nathan12343 at gmail.com Mon May 16 13:51:56 2016 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Mon, 16 May 2016 12:51:56 -0500 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: On Mon, May 16, 2016 at 12:42 PM, Matthias Bussonnier < bussonniermatthias at gmail.com> wrote: > On Sun, May 15, 2016 at 1:45 PM, Fabien wrote: > > > > > What would be more interesting to read are arguments against this > > initiative. But I believe that once the major projects (mpl, jupyter, > > ipython, pandas...) have made the first step, others will undoubtedly > > follow. > > Devil's advocate: You will piss of some people that will either stop > contributing, or fork MPL, and get an indefinite > number of bug report from people stuck on the last version supporting > 2.7. Another concern: if I depend on matplotlib and don't want to drop python2 support (but also don't want to drop support for newer matplotlib versions), that means I need to simultaneously support the last py2 matplotlib through the latest and greatest matplotlib version on py3. It would be nice if some thought could be expended for the breaking changes you're planning on matplotlib 3.0 so that compatibility across matplotlib versions can be attained without a huge amount of trouble. > I suspect you will have two wave of people pissed: > When you switch master to 3+ only, and when you **release** a 3+ only > version. > You'll have **some** packaging pain, as you need to publish a `tar.gz` > and `zip` that pip should not even **try** to install on Python 2. > > As for undoubtedly following, I would not be so sure. I can see pandas > and numpy be one of the last projects dropping support. > Especially numpy which is at the base of most of the SciPy Stack. > > Though, having **their dependents** being python 3 only will likely > make their decision much easier. > > Will mercurial ever migrate to Py3... I'm not sure, but we can argue > it's not in the Scientific stack. > This is being actively worked on. In any case, even if mercuroal doesn't move to python3, you can very easily have a separate python2 installation. You can even do this with conda and just symlink the hg executable into your python3 environment. > -- > M > _______________________________________________ > 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 olivier.grisel at ensta.org Mon May 2 16:21:33 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Mon, 2 May 2016 22:21:33 +0200 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Note that PyQt5 developers have released binary wheels for all the supported platforms (windows, OSX and Linux via manylinux1): pip install --upgrade PyQt5 https://pypi.io/project/PyQt5 (the legacy pypi index is broken at the moment). I tested it with: import matplotlib matplotlib.use('PyQt5') and it seems to work as expected. That does not solve the tkinter issue but at least provides an alternative (if you accept the terms of the GPL v3 license). -- Olivier From droberts at spawar.navy.mil Mon May 2 17:54:35 2016 From: droberts at spawar.navy.mil (Dan Roberts) Date: Mon, 2 May 2016 14:54:35 -0700 Subject: [Matplotlib-devel] FW: PSD Scaling (matplotlib version 1.4.X versus 1.5.X) In-Reply-To: <57193E9E.8060706@spawar.navy.mil> References: <57193E9E.8060706@spawar.navy.mil> Message-ID: <011a01d1a4bd$39b5b940$ad212bc0$@spawar.navy.mil> -----Original Message----- From: Dan Roberts [mailto:droberts at spawar.navy.mil] Sent: Thursday, April 21, 2016 1:57 PM To: matplotlib-users at python.org Subject: PSD Scaling (matplotlib version 1.4.X versus 1.5.X) Hello, I noticed an inconsistency with the pyplot.psd function when upgrading from matplotlib version 1.4.0 to 1.5.3 I have written some code (below) that will show what I'm talking about when run with the different matplotlib versions. In 1.4.0, the line "PX2 /= fft_size" was needed, but gives the wrong answer (P_ave is not equal to 1, and Pxw.max() is -36dB instead of 0dB) if it is included when using 1.5.3 I am mainly concerned with knowing if this change was intentional; will it behave like this from now on (no longer needing division by fft_size)? import matplotlib.pyplot as plt import matplotlib.mlab as mlab import numpy as np fft_size = 4096 fs = 2500.00 gram_lines = 100; t = np.arange(1.0,gram_lines*fft_size,1.0); t = t / fs; del_f = fs/fft_size; base_freq = 10.0 # in Hz bin_err = 0.0 f = (int(base_freq / del_f) + bin_err) * del_f # ensure f is in center of Fourier band A = np.sqrt(2.0); # if the amplitude is sqrt(2) then the total power = 1.0 linear and 0.0 in dB dat = A * np.sin(2 * np.pi * f * t); (Px2, F) = plt.psd(dat, NFFT = fft_size, Fs=fs, Fc=0, detrend=mlab.detrend_none, window=mlab.window_none, noverlap=0, pad_to = None, sides='onesided', scale_by_freq = False); Px2 /= fft_size; #comment this line out if using 1.5.1?? P_ave = sum(Px2); Px2 = 10.0*np.log10(Px2); #print results to compare actual with expected print "Sum of psd Px2 = %f, This should equal 1.0." %P_ave print "Max psd Px2 = %f dB. This should equal 0.0 dB if freq is a multiple of freq resolution.\n" %(Px2.max()) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5424 bytes Desc: not available URL: From vishal.goundar at gmail.com Tue May 3 01:34:04 2016 From: vishal.goundar at gmail.com (vishal) Date: Mon, 2 May 2016 22:34:04 -0700 (MST) Subject: [Matplotlib-devel] Please I am getting error message when running this code in Python. Message-ID: <1462253644031-47047.post@n5.nabble.com> >>> import numpy as np import matplotlib.pyplot as plt mu, sigma = 100, 15 x = mu + sigma * np.random.randn(10000) # the histogram of the data n, bins, patches = plt.hist(x, 50, normed=1, facecolor='g', alpha=0.75) plt.xlabel('Smarts') plt.ylabel('Probability') plt.title('Histogram of IQ') plt.text(60, .025, r'$\mu=100,\ \sigma=15$') plt.axis([40, 160, 0, 0.03]) plt.grid(True) plt.show() SyntaxError: multiple statements found while compiling a single statement -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Please-I-am-getting-error-message-when-running-this-code-in-Python-tp47047.html Sent from the matplotlib - devel mailing list archive at Nabble.com. From vishal.goundar at gmail.com Tue May 3 02:01:29 2016 From: vishal.goundar at gmail.com (vishal) Date: Mon, 2 May 2016 23:01:29 -0700 (MST) Subject: [Matplotlib-devel] New to the list, MEPS, and plot serialization questions In-Reply-To: References: Message-ID: <1462255289957-47048.post@n5.nabble.com> Hi Jay, I am no way near to achieving this. Please help me. What am I doing wrong? >>> import numpy as np import matplotlib.pyplot as plt x = np.linspace(0, 1) y = np.sin(4 * np.pi * x) * np.exp(-5 * x) plt.fill(x, y, 'r') plt.grid(True) plt.show() SyntaxError: multiple statements found while compiling a single statement -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-devel-New-to-the-list-MEPS-and-plot-serialization-questions-tp47033p47048.html Sent from the matplotlib - devel mailing list archive at Nabble.com. From olivier.grisel at ensta.org Tue May 3 05:35:51 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Tue, 3 May 2016 11:35:51 +0200 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: > I tested it with: > > import matplotlib > matplotlib.use('PyQt5') Typo, this was supposed to read: matplotlib.use('Qt5Agg') -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel From olivier.grisel at ensta.org Wed May 4 03:40:17 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Wed, 4 May 2016 09:40:17 +0200 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: 2016-05-03 22:47 GMT+02:00 Matthew Brett : > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel wrote: >>> I tested it with: >>> >>> import matplotlib >>> matplotlib.use('PyQt5') >> >> Typo, this was supposed to read: >> >> matplotlib.use('Qt5Agg') > > Meanwhile, I tried removing (patchelf --remove-needed) the > requirements of _tkagg.so on the vendored libtk, libtcl, and added > back the requirement (patch --add-needed) on general `libtk.so' and > 'libtcl.so'. This removed the segfault and allowed me to display > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > using is relatively stable across versions 8.4 (on the docker image) > and 8.6 (on Debian sid). > > Worth experimenting with this - or too much of a hack? > > Is there a way to add libraries to ignore, in `auditwheel repair` ? It sounds reasonable to add this feature as a CLI option to me. Also maybe we could decide to amend PEP 513 to add libtk.so and libtcl.so to the system provided white-list as they are direct dependencies for Python via tkinter which is part of the standard library. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel From leorochael at gmail.com Tue May 10 18:09:13 2016 From: leorochael at gmail.com (Leonardo Rochael Almeida) Date: Tue, 10 May 2016 19:09:13 -0300 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On 10 May 2016 at 18:52, Matthew Brett wrote: > On Tue, May 10, 2016 at 5:26 PM, Matthew Brett > wrote: > >> [...] > >> > >> This would probably look like: > >> > >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python > calls > >> this module) > >> > >> Before loading _tkagg.so, we use Python level introspection figure out > where > >> tkinter.so lives > >> > >> We add its directory to LD_LIBRARY_PATH > >> > >> we import _tkagg.so > >> > >> We take its directory back off of LD_LIBRARY_PATH > >> > >> Very weird, but I can't see why it wouldn't work, and probably more > reliable > >> than anything where we try to reimplement the dynamic loader's search > logic > >> ourselves. > > > > Nice - yes - it does work in a first-pass test - I'll look into > automating that. > > Ah - except I do not believe it is possible to change the linker path > for Python modules, within the Python process: > > http://www.gossamer-threads.com/lists/python/python/393770#393770 I was about to point that out... On the other hand, if there is a `Tkinter` module that Python can import, just importing it will make the symbols needed the `_tkagg` module available, assuming Python calls `dlopen()` on import with RTLD_GLOBAL[1]. [1] http://man7.org/linux/man-pages/man3/dlopen.3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From leorochael at gmail.com Wed May 11 14:26:24 2016 From: leorochael at gmail.com (Leonardo Rochael Almeida) Date: Wed, 11 May 2016 15:26:24 -0300 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On 11 May 2016 at 10:58, Matthew Brett wrote: > On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: > > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida > > wrote: > >> On 10 May 2016 at 18:52, Matthew Brett wrote: > >>> > >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett < > matthew.brett at gmail.com> > >>> wrote: > >>> >> [...] > >>> >> > >>> >> This would probably look like: > >>> >> > >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever > Python > >>> >> calls > >>> >> this module) > >>> >> > >>> >> Before loading _tkagg.so, we use Python level introspection figure > out > >>> >> where > >>> >> tkinter.so lives > >>> >> > >>> >> We add its directory to LD_LIBRARY_PATH > >>> >> > >>> >> we import _tkagg.so > >>> >> > >>> >> We take its directory back off of LD_LIBRARY_PATH > >>> >> > >>> >> Very weird, but I can't see why it wouldn't work, and probably more > >>> >> reliable > >>> >> than anything where we try to reimplement the dynamic loader's > search > >>> >> logic > >>> >> ourselves. > >>> > > >>> > Nice - yes - it does work in a first-pass test - I'll look into > >>> > automating that. > >>> > >>> Ah - except I do not believe it is possible to change the linker path > >>> for Python modules, within the Python process: > >>> > >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 > > > > Doh :-( > > Any other suggestions? > Calling `patchelf` at runtime with the result of introspecting the `_tkinter.so` module? :-) On a more serious note, even though it would be dangerous to call `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: - ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) - ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed (but not re-added). We would be dumping only libtcl/tk's symbols in the namespace of other python extension modules. > I guess this will be a problem for the external library PEP? > Likely, yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon May 16 14:09:32 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 16 May 2016 18:09:32 +0000 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: I think it is fair to expect that the 3.x series only adds functionality, but does not remove any APIs. Part of this exercise is to really sort out what the 2.7 demand really is. If someone shows up and commits to backporting all new features from 3.x to 2.x I would not be opposed. Tom On Mon, May 16, 2016 at 1:54 PM Nathan Goldbaum wrote: > On Mon, May 16, 2016 at 12:42 PM, Matthias Bussonnier < > bussonniermatthias at gmail.com> wrote: > >> On Sun, May 15, 2016 at 1:45 PM, Fabien >> wrote: >> >> > >> > What would be more interesting to read are arguments against this >> > initiative. But I believe that once the major projects (mpl, jupyter, >> > ipython, pandas...) have made the first step, others will undoubtedly >> > follow. >> >> Devil's advocate: You will piss of some people that will either stop >> contributing, or fork MPL, and get an indefinite >> number of bug report from people stuck on the last version supporting >> 2.7. > > > > Another concern: if I depend on matplotlib and don't want to drop python2 > support (but also don't want to drop support for newer matplotlib > versions), that means I need to simultaneously support the last py2 > matplotlib through the latest and greatest matplotlib version on py3. It > would be nice if some thought could be expended for the breaking changes > you're planning on matplotlib 3.0 so that compatibility across matplotlib > versions can be attained without a huge amount of trouble. > > >> I suspect you will have two wave of people pissed: >> When you switch master to 3+ only, and when you **release** a 3+ only >> version. >> You'll have **some** packaging pain, as you need to publish a `tar.gz` >> and `zip` that pip should not even **try** to install on Python 2. >> >> As for undoubtedly following, I would not be so sure. I can see pandas >> and numpy be one of the last projects dropping support. >> Especially numpy which is at the base of most of the SciPy Stack. >> >> Though, having **their dependents** being python 3 only will likely >> make their decision much easier. >> >> Will mercurial ever migrate to Py3... I'm not sure, but we can argue >> it's not in the Scientific stack. >> > > This is being actively worked on. > > In any case, even if mercuroal doesn't move to python3, you can very > easily have a separate python2 installation. You can even do this with > conda and just symlink the hg executable into your python3 environment. > > >> -- >> M >> _______________________________________________ >> 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 bussonniermatthias at gmail.com Mon May 16 14:14:28 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 16 May 2016 11:14:28 -0700 Subject: [Matplotlib-devel] Long term release schedule In-Reply-To: References: Message-ID: Hey, On Mon, May 16, 2016 at 10:51 AM, Nathan Goldbaum wrote: > Another concern: if I depend on matplotlib and don't want to drop python2 > support (but also don't want to drop support for newer matplotlib versions), > that means I need to simultaneously support the last py2 matplotlib through > the latest and greatest matplotlib version on py3. It would be nice if some > thought could be expended for the breaking changes you're planning on > matplotlib 3.0 so that compatibility across matplotlib versions can be > attained without a huge amount of trouble. > As a data point, we don't planned to break the API for IPython 6.0 more than usual. Though there are some things (liek completion) were we'd really like to break API/provide a new one. Though there are some things that will be hard to impossible to backport. As Thomas said, if someone[user or company] come up and want to backport all the things or provide shims, we'll likely not say no, but there is few chance we actually publish that under the 'IPython' package name. >> >> I suspect you will have two wave of people pissed: >> When you switch master to 3+ only, and when you **release** a 3+ only >> version. >> You'll have **some** packaging pain, as you need to publish a `tar.gz` >> and `zip` that pip should not even **try** to install on Python 2. >> >> As for undoubtedly following, I would not be so sure. I can see pandas >> and numpy be one of the last projects dropping support. >> Especially numpy which is at the base of most of the SciPy Stack. >> >> Though, having **their dependents** being python 3 only will likely >> make their decision much easier. >> >> Will mercurial ever migrate to Py3... I'm not sure, but we can argue >> it's not in the Scientific stack. > > > This is being actively worked on. Ah, I didn't knew that, but this comment was mostly meant as a joke as Mercurial was IIUC known to have often been against migrating its codebase to Python 3. And yes, I know I can link the executable. -- M From ben.v.root at gmail.com Mon May 16 14:29:35 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 16 May 2016 14:29:35 -0400 Subject: [Matplotlib-devel] Please I am getting error message when running this code in Python. In-Reply-To: <1462253644031-47047.post@n5.nabble.com> References: <1462253644031-47047.post@n5.nabble.com> Message-ID: I suspect it is the extra backslash there in the plt.text() call. On Tue, May 3, 2016 at 1:34 AM, vishal wrote: > >>> import numpy as np > import matplotlib.pyplot as plt > > mu, sigma = 100, 15 > x = mu + sigma * np.random.randn(10000) > > # the histogram of the data > n, bins, patches = plt.hist(x, 50, normed=1, facecolor='g', alpha=0.75) > > > plt.xlabel('Smarts') > plt.ylabel('Probability') > plt.title('Histogram of IQ') > plt.text(60, .025, r'$\mu=100,\ \sigma=15$') > plt.axis([40, 160, 0, 0.03]) > plt.grid(True) > plt.show() > SyntaxError: multiple statements found while compiling a single statement > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/Please-I-am-getting-error-message-when-running-this-code-in-Python-tp47047.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > _______________________________________________ > 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 rmay31 at gmail.com Mon May 16 14:42:37 2016 From: rmay31 at gmail.com (Ryan May) Date: Mon, 16 May 2016 12:42:37 -0600 Subject: [Matplotlib-devel] Please I am getting error message when running this code in Python. In-Reply-To: References: <1462253644031-47047.post@n5.nabble.com> Message-ID: It looks to me almost like the code's been pasted into a Python interpreter session and it's not picking up the newlines. Ryan On Mon, May 16, 2016 at 12:29 PM, Benjamin Root wrote: > I suspect it is the extra backslash there in the plt.text() call. > > On Tue, May 3, 2016 at 1:34 AM, vishal wrote: > >> >>> import numpy as np >> import matplotlib.pyplot as plt >> >> mu, sigma = 100, 15 >> x = mu + sigma * np.random.randn(10000) >> >> # the histogram of the data >> n, bins, patches = plt.hist(x, 50, normed=1, facecolor='g', alpha=0.75) >> >> >> plt.xlabel('Smarts') >> plt.ylabel('Probability') >> plt.title('Histogram of IQ') >> plt.text(60, .025, r'$\mu=100,\ \sigma=15$') >> plt.axis([40, 160, 0, 0.03]) >> plt.grid(True) >> plt.show() >> SyntaxError: multiple statements found while compiling a single statement >> >> >> >> -- >> View this message in context: >> http://matplotlib.1069221.n5.nabble.com/Please-I-am-getting-error-message-when-running-this-code-in-Python-tp47047.html >> Sent from the matplotlib - devel mailing list archive at Nabble.com. >> _______________________________________________ >> 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 > > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon May 16 14:50:19 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 16 May 2016 14:50:19 -0400 Subject: [Matplotlib-devel] Please I am getting error message when running this code in Python. In-Reply-To: References: <1462253644031-47047.post@n5.nabble.com> Message-ID: heh, yeah, I didn't notice that. The SyntaxError would be raised by the interpretor, not tex parser. Solution, use IPython, not IDLE. On Mon, May 16, 2016 at 2:42 PM, Ryan May wrote: > It looks to me almost like the code's been pasted into a Python > interpreter session and it's not picking up the newlines. > > Ryan > > On Mon, May 16, 2016 at 12:29 PM, Benjamin Root > wrote: > >> I suspect it is the extra backslash there in the plt.text() call. >> >> On Tue, May 3, 2016 at 1:34 AM, vishal wrote: >> >>> >>> import numpy as np >>> import matplotlib.pyplot as plt >>> >>> mu, sigma = 100, 15 >>> x = mu + sigma * np.random.randn(10000) >>> >>> # the histogram of the data >>> n, bins, patches = plt.hist(x, 50, normed=1, facecolor='g', alpha=0.75) >>> >>> >>> plt.xlabel('Smarts') >>> plt.ylabel('Probability') >>> plt.title('Histogram of IQ') >>> plt.text(60, .025, r'$\mu=100,\ \sigma=15$') >>> plt.axis([40, 160, 0, 0.03]) >>> plt.grid(True) >>> plt.show() >>> SyntaxError: multiple statements found while compiling a single statement >>> >>> >>> >>> -- >>> View this message in context: >>> http://matplotlib.1069221.n5.nabble.com/Please-I-am-getting-error-message-when-running-this-code-in-Python-tp47047.html >>> Sent from the matplotlib - devel mailing list archive at Nabble.com. >>> _______________________________________________ >>> 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 >> >> > > > -- > Ryan May > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon May 16 14:53:44 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 16 May 2016 18:53:44 +0000 Subject: [Matplotlib-devel] Offer of additions to subplots In-Reply-To: <920E7B99-B2D7-41F3-A7FB-A3721ECDF637@gmail.com> References: <920E7B99-B2D7-41F3-A7FB-A3721ECDF637@gmail.com> Message-ID: We have a number of other cases where we mix types on input. I have also wanted `squeeze='flatten'` on a few occasions and am +1 on the first idea I am a bit more hesitant on the second, it might be crossing the line into making the API too clever/flexible for its own good. Tom On Mon, May 16, 2016 at 2:06 PM Christopher Field < christophertfield at gmail.com> wrote: > I love pyplot.subplots and use it to create almost all of my > graphs. I have implemented code for two subplots enhancements. Because I > have never contributed to an open source project, I wanted to clear the > additions before I put in the effort to learn how to make a contribution > and implement all of the supporting documentation and samples. > > I found that was often writing > Fig, ax = plt.subplots( N, M, squeeze=False ) > ax = ax.flatten() or ax=ax.ravel() > My addition provides a squeeze=?flatten? option, which always > returns a 1D numpy array. This is useful under three situations. First, > there is a 2D arrangement of plots that are to be populated by indexing in > a single loop. Second, there is a 1D arrangement of plots of variable > number which, if squeeze=True, might return a single axis or a numpy array. > Third, there is a 2D arrangement of plots that you wish to access with a > single subscript. > Does providing squeeze with bool or string values violate any > rules? > What is the clearest string to use? I have considered ?flatten?, > ?flat?, ?ravel?, and ?1d?. > > The second enhancement permits sharing axis between different > figures. It extends the sharex and sharey arguments to accept either an > axis instance (in which case all of the new plots share the same x or y > limits), or 1D or 2D numpy arrays of axis instances (in which case > rows/columns are shared or each plot shares with the corresponding plot > passed in. > > Should I invest the effort required to submit these? Is there a > time frame in which these additions would be more or less welcome? > > Thank you, > Christopher Field > > > > _______________________________________________ > 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 Tue May 17 11:23:08 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 17 May 2016 15:23:08 +0000 Subject: [Matplotlib-devel] May 2016 release plans Message-ID: Hey folks, We are closing in on a v2.0.0beta release. As part of this we finished off almost all of the isses tagged as v1.5.2 and will not be adding anymore issues to that list after tomorrow. The plan is to tag a v1.5.2rc1 this upcoming weekend (May 21 or 22). If there are any last minute issues, please speak up. Please focus any development time you have in the next few weeks on dealing with the outstanding 2.0 issues! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue May 17 14:43:11 2016 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 17 May 2016 08:43:11 -1000 Subject: [Matplotlib-devel] legend defaults for 2.0 Message-ID: For anyone interested in default settings for 2.0, please see https://github.com/matplotlib/matplotlib/pull/6424. We have a brief window of opportunity to settle on the new defaults. The legend defaults have not yet been reviewed in detail. As with all of the default settings, the question is not "what looks good on my fancy plot for publication X", but what will make a good *default*. This means it should work well in a wide variety of situations; it should be "good enough" in many cases, and "terrible" in few. Relatively simple and common cases are weighted more highly than complex cases for which customization is inevitable anyway. The goal is to convey information effectively and in a visually pleasing manner. Eric From matthew.brett at gmail.com Tue May 17 16:23:07 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 17 May 2016 16:23:07 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida wrote: > On 11 May 2016 at 10:58, Matthew Brett wrote: >> >> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >> > wrote: >> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >> >>> >> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >> >>> >> >>> wrote: >> >>> >> [...] >> >>> >> >> >>> >> This would probably look like: >> >>> >> >> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >> >>> >> Python >> >>> >> calls >> >>> >> this module) >> >>> >> >> >>> >> Before loading _tkagg.so, we use Python level introspection figure >> >>> >> out >> >>> >> where >> >>> >> tkinter.so lives >> >>> >> >> >>> >> We add its directory to LD_LIBRARY_PATH >> >>> >> >> >>> >> we import _tkagg.so >> >>> >> >> >>> >> We take its directory back off of LD_LIBRARY_PATH >> >>> >> >> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >> >>> >> reliable >> >>> >> than anything where we try to reimplement the dynamic loader's >> >>> >> search >> >>> >> logic >> >>> >> ourselves. >> >>> > >> >>> > Nice - yes - it does work in a first-pass test - I'll look into >> >>> > automating that. >> >>> >> >>> Ah - except I do not believe it is possible to change the linker path >> >>> for Python modules, within the Python process: >> >>> >> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >> > >> > Doh :-( >> >> Any other suggestions? > > > Calling `patchelf` at runtime with the result of introspecting the > `_tkinter.so` module? :-) > > On a more serious note, even though it would be dangerous to call > `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: > > ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) > ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) > > before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed > (but not re-added). > > We would be dumping only libtcl/tk's symbols in the namespace of other > python extension modules. I have implemented dlopen dynamic loading of the TCL / Tk functions from the Python tkinter extension module here : https://github.com/matplotlib/matplotlib/pull/6442 It appears to work. I'd love any feedback y'all can offer. Cheers, Matthew From macdems at gmail.com Wed May 18 03:40:48 2016 From: macdems at gmail.com (Maciek Dems) Date: Wed, 18 May 2016 09:40:48 +0200 Subject: [Matplotlib-devel] legend defaults for 2.0 In-Reply-To: References: Message-ID: <1463557248.5221.22.camel@gmail.com> Hello, How difficult it would be to add an option to replace a legend with labels directly next to the plot with some intelligent automatic positioning? Regards, Maciek -------- Oryginalna wiadomo?? --------Od: Eric Firing Do: matplotlib development list Temat: [Matplotlib-devel] legend defaults for 2.0 Data: Tue, 17 May 2016 08:43:11 -1000 For anyone interested in default settings for 2.0, please see https://github.com/matplotlib/matplotlib/pull/6424.??We have a brief window of opportunity to settle on the new defaults. The legend defaults have not yet been reviewed in detail. As with all of the default settings, the question is not "what looks good on my fancy plot for publication X", but what will make a good *default*. This means it should work well in a wide variety of situations; it should be "good enough" in many cases, and "terrible" in few. Relatively simple and common cases are weighted more highly than complex cases for which customization is inevitable anyway. The goal is to convey information effectively and in a visually pleasing manner. Eric _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel at python.org https://mail.python.org/mailman/listinfo/matplotlib-devel -- Maciek Dems http://dems.art.pl/ From efiring at hawaii.edu Wed May 18 12:19:25 2016 From: efiring at hawaii.edu (Eric Firing) Date: Wed, 18 May 2016 06:19:25 -1000 Subject: [Matplotlib-devel] legend defaults for 2.0 In-Reply-To: <1463557248.5221.22.camel@gmail.com> References: <1463557248.5221.22.camel@gmail.com> Message-ID: <7261fcfc-a47a-5f66-0a59-a1ae9701612d@hawaii.edu> On 2016/05/17 9:40 PM, Maciek Dems wrote: > Hello, > > How difficult it would be to add an option to replace a legend with > labels directly next to the plot with some intelligent automatic > positioning? > > Regards, > Maciek You mean directly labeling each curve, as one would do manually with annotations? This is similar to what the contour labeling algorithm does, but probably even harder to do well enough to be useful. Eric From macdems at gmail.com Wed May 18 17:12:24 2016 From: macdems at gmail.com (Maciek Dems) Date: Wed, 18 May 2016 23:12:24 +0200 Subject: [Matplotlib-devel] legend defaults for 2.0 In-Reply-To: <7261fcfc-a47a-5f66-0a59-a1ae9701612d@hawaii.edu> References: <1463557248.5221.22.camel@gmail.com> <7261fcfc-a47a-5f66-0a59-a1ae9701612d@hawaii.edu> Message-ID: <1463605944.19728.4.camel@gmail.com> > You mean directly labeling each curve, as one would do manually with? > annotations???This is similar to what the contour labeling algorithm? > does, but probably even harder to do well enough to be useful. Yes, this is exactly what I mean. Very often such approach is better than using the legend. Maciek --? Maciek Dems http://dems.art.pl/ From pmhobson at gmail.com Wed May 18 17:32:06 2016 From: pmhobson at gmail.com (Paul Hobson) Date: Wed, 18 May 2016 14:32:06 -0700 Subject: [Matplotlib-devel] PyCon Portland 2016 Message-ID: Hey folks, Curious if anyone will be in Portland for PyCon. I won't be attending the conference proper, but I'm a Portland local and would like to 1) buy a round for any MPL-dev attending and 2) participate in any MPL or scipy-ish sprint that might be happening. -paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Thu May 19 09:41:58 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Thu, 19 May 2016 09:41:58 -0400 Subject: [Matplotlib-devel] legend defaults for 2.0 In-Reply-To: <1463605944.19728.4.camel@gmail.com> References: <1463557248.5221.22.camel@gmail.com> <7261fcfc-a47a-5f66-0a59-a1ae9701612d@hawaii.edu> <1463605944.19728.4.camel@gmail.com> Message-ID: Could you put in a feature request for a clabel-like function for labeling lines? That is a neat idea, and maybe someone might work on it as a summer project? On Wed, May 18, 2016 at 5:12 PM, Maciek Dems wrote: > > You mean directly labeling each curve, as one would do manually with > > annotations? This is similar to what the contour labeling algorithm > > does, but probably even harder to do well enough to be useful. > > Yes, this is exactly what I mean. Very often such approach is better > than using the legend. > > Maciek > > -- > Maciek Dems http://dems.art.pl/ > > > _______________________________________________ > 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 Fri May 20 13:31:19 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 20 May 2016 17:31:19 +0000 Subject: [Matplotlib-devel] long term schedule Message-ID: Hey folks, For the feed back I think the consensus is go with the proprosed schedule, but commit to not breaking any APIs in 3.0. 2016-09/10 : 2.1 what we have on master is probably good enough for a release already but target - traitlets - the gui overhaul if we miss them, tag in late september anyway 2017-07 : 2.2 LTS - last feature release with 2.7 support - critical bug fixes on mpl 2.2.x branch until 2020 - solicit a dedicated py2.7 maintainer 2018-07 : 3.0 - only support py3.4+ - do not break back-compatible API There has been no protest to publishing this on the pyhon3 statement web page (and this is already public) so I will ask them to include us in the list. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Fri May 20 14:18:15 2016 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 20 May 2016 18:18:15 +0000 (UTC) Subject: [Matplotlib-devel] long term schedule In-Reply-To: References: Message-ID: <206149573.9728190.1463768295858.JavaMail.yahoo@mail.yahoo.com> How does "not breaking any APIs" influence the deprecation and removal timeline for the gui overhaul?? I thought perhaps deprecate in 2.2 and remove in 3.0?? Or does such a timeline go too fast? From: Thomas Caswell To: matplotlib development list Sent: Friday, 20 May 2016, 19:31 Subject: [Matplotlib-devel] long term schedule Hey folks, For the feed back I think the consensus is go with the proprosed schedule, but commit to not breaking any APIs in 3.0. 2016-09/10 : 2.1? what we have on master is probably good enough for a release already buttarget? - traitlets? - the gui overhaul? if we miss them, tag in late september anyway 2017-07 : 2.2 LTS?- last feature release with 2.7 support?- critical bug fixes on mpl 2.2.x branch until 2020?- solicit a dedicated py2.7 maintainer 2018-07 : 3.0? - only support py3.4+? - do not break back-compatible API There has been no protest to publishing this on the pyhon3 statement web page (and this is already public) so I will ask them to include us in the list. Tom _______________________________________________ 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 efiring at hawaii.edu Fri May 20 14:32:17 2016 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 20 May 2016 08:32:17 -1000 Subject: [Matplotlib-devel] long term schedule In-Reply-To: <206149573.9728190.1463768295858.JavaMail.yahoo@mail.yahoo.com> References: <206149573.9728190.1463768295858.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1c686063-a6fe-b08f-36c6-0eb8386a0671@hawaii.edu> On 2016/05/20 8:18 AM, OceanWolf via Matplotlib-devel wrote: > How does "not breaking any APIs" influence the deprecation and removal > timeline for the gui overhaul? I thought perhaps deprecate in 2.2 and > remove in 3.0? Or does such a timeline go too fast? > Along the same lines, I think this might be too much of a straitjacket. This is a vague sense of unease--I don't have a specific example. It just seems like having to keep *everything* 100% intact until a 4.0 release in 2019 or 2020 might be going too far. This is especially so since "API" is not so well defined. Does every attribute lacking a leading underscore have to be maintained for several more years? Maybe "API" needs a qualifier, like "major API". Eric From tcaswell at gmail.com Fri May 20 16:40:54 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 20 May 2016 20:40:54 +0000 Subject: [Matplotlib-devel] long term schedule In-Reply-To: <1c686063-a6fe-b08f-36c6-0eb8386a0671@hawaii.edu> References: <206149573.9728190.1463768295858.JavaMail.yahoo@mail.yahoo.com> <1c686063-a6fe-b08f-36c6-0eb8386a0671@hawaii.edu> Message-ID: I should have said "no more api breakage than normal between point releases". We do not want to get in to a situation where major down stream packages that is mpl (yt, skimage, pandas, etc) pin a maximum matplotlib version. Tom On Fri, May 20, 2016, 14:32 Eric Firing wrote: > On 2016/05/20 8:18 AM, OceanWolf via Matplotlib-devel wrote: > > How does "not breaking any APIs" influence the deprecation and removal > > timeline for the gui overhaul? I thought perhaps deprecate in 2.2 and > > remove in 3.0? Or does such a timeline go too fast? > > > Along the same lines, I think this might be too much of a straitjacket. > This is a vague sense of unease--I don't have a specific example. It > just seems like having to keep *everything* 100% intact until a 4.0 > release in 2019 or 2020 might be going too far. This is especially so > since "API" is not so well defined. Does every attribute lacking a > leading underscore have to be maintained for several more years? Maybe > "API" needs a qualifier, like "major API". > > Eric > > _______________________________________________ > 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 mail at danieldasilva.org Fri May 20 17:06:39 2016 From: mail at danieldasilva.org (Daniel da Silva) Date: Fri, 20 May 2016 21:06:39 +0000 Subject: [Matplotlib-devel] Offer of additions to subplots In-Reply-To: References: <920E7B99-B2D7-41F3-A7FB-A3721ECDF637@gmail.com> Message-ID: I'm +1 on the addition of `squeeze='flatten'` as well. As a matter of fact I found 5 instances of `axes = axes.flatten()` I've written in the past six months, and even more cases where I didn't think of flatten() and used a combination of floor division and modulus to achieve 2D indeces. With regard two axis sharing, can you expand on the API you are proposing? There seems to be some functionality for this as answered on StackOverflow . > I am a bit more hesitant on the second, it might be crossing the line into making the API too clever/flexible for its own good. I'd have to look at the code to agree/disagree with you; but I wouldn't be surprised if somewhere along the line someone made the assumption that axes would only be owned by a single figure/subplot. Christopher, do all the unit tests pass with this patch? Overall, axis sharing sounds a lot like linkaxes() in Matlab . If axis *sharing* doesn't work, maybe axis *synchronization* could. Daniel On Mon, May 16, 2016 at 2:54 PM Thomas Caswell wrote: > We have a number of other cases where we mix types on input. I have also > wanted `squeeze='flatten'` on a few occasions and am +1 on the first idea > > I am a bit more hesitant on the second, it might be crossing the line into > making the API too clever/flexible for its own good. > > Tom > > On Mon, May 16, 2016 at 2:06 PM Christopher Field < > christophertfield at gmail.com> wrote: > >> I love pyplot.subplots and use it to create almost all of my >> graphs. I have implemented code for two subplots enhancements. Because I >> have never contributed to an open source project, I wanted to clear the >> additions before I put in the effort to learn how to make a contribution >> and implement all of the supporting documentation and samples. >> >> I found that was often writing >> Fig, ax = plt.subplots( N, M, squeeze=False ) >> ax = ax.flatten() or ax=ax.ravel() >> My addition provides a squeeze=?flatten? option, which always >> returns a 1D numpy array. This is useful under three situations. First, >> there is a 2D arrangement of plots that are to be populated by indexing in >> a single loop. Second, there is a 1D arrangement of plots of variable >> number which, if squeeze=True, might return a single axis or a numpy array. >> Third, there is a 2D arrangement of plots that you wish to access with a >> single subscript. >> Does providing squeeze with bool or string values violate any >> rules? >> What is the clearest string to use? I have considered ?flatten?, >> ?flat?, ?ravel?, and ?1d?. >> >> The second enhancement permits sharing axis between different >> figures. It extends the sharex and sharey arguments to accept either an >> axis instance (in which case all of the new plots share the same x or y >> limits), or 1D or 2D numpy arrays of axis instances (in which case >> rows/columns are shared or each plot shares with the corresponding plot >> passed in. >> >> Should I invest the effort required to submit these? Is there a >> time frame in which these additions would be more or less welcome? >> >> Thank you, >> Christopher Field >> >> >> >> _______________________________________________ >> 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 tcaswell at gmail.com Sun May 22 19:14:46 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 22 May 2016 23:14:46 +0000 Subject: [Matplotlib-devel] v1.5.2rc1 tagged Message-ID: Folks, I have tagged a rc for 1.5.2, please check it out and kick the tires. Once the conda-forge PR is merged I will make a wider announcement to the user list. If things go well the plan is to next weekend tag a 1.5.2 final and a 2.0.0b1 Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon May 23 10:38:42 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 23 May 2016 10:38:42 -0400 Subject: [Matplotlib-devel] Offer of additions to subplots In-Reply-To: References: <920E7B99-B2D7-41F3-A7FB-A3721ECDF637@gmail.com> Message-ID: Yes, matlab's linkaxes() is the same as our axis sharing. I would be hesitant to create a new and similar concept of "synchronization", though. On Fri, May 20, 2016 at 5:06 PM, Daniel da Silva wrote: > I'm +1 on the addition of `squeeze='flatten'` as well. As a matter of fact > I found 5 instances of `axes = axes.flatten()` I've written in the past six > months, and even more cases where I didn't think of flatten() and used a > combination of floor division and modulus to achieve 2D indeces. > > With regard two axis sharing, can you expand on the API you are proposing? > There seems to be some functionality for this as answered on StackOverflow > > . > > > I am a bit more hesitant on the second, it might be crossing the line > into making the API too clever/flexible for its own good. > I'd have to look at the code to agree/disagree with you; but I wouldn't be > surprised if somewhere along the line someone made the assumption that axes > would only be owned by a single figure/subplot. Christopher, do all the > unit tests pass with this patch? > > Overall, axis sharing sounds a lot like linkaxes() in Matlab > . If axis > *sharing* doesn't work, maybe axis *synchronization* could. > > Daniel > > > > On Mon, May 16, 2016 at 2:54 PM Thomas Caswell wrote: > >> We have a number of other cases where we mix types on input. I have also >> wanted `squeeze='flatten'` on a few occasions and am +1 on the first idea >> >> I am a bit more hesitant on the second, it might be crossing the line >> into making the API too clever/flexible for its own good. >> >> Tom >> >> On Mon, May 16, 2016 at 2:06 PM Christopher Field < >> christophertfield at gmail.com> wrote: >> >>> I love pyplot.subplots and use it to create almost all of my >>> graphs. I have implemented code for two subplots enhancements. Because I >>> have never contributed to an open source project, I wanted to clear the >>> additions before I put in the effort to learn how to make a contribution >>> and implement all of the supporting documentation and samples. >>> >>> I found that was often writing >>> Fig, ax = plt.subplots( N, M, squeeze=False ) >>> ax = ax.flatten() or ax=ax.ravel() >>> My addition provides a squeeze=?flatten? option, which always >>> returns a 1D numpy array. This is useful under three situations. First, >>> there is a 2D arrangement of plots that are to be populated by indexing in >>> a single loop. Second, there is a 1D arrangement of plots of variable >>> number which, if squeeze=True, might return a single axis or a numpy array. >>> Third, there is a 2D arrangement of plots that you wish to access with a >>> single subscript. >>> Does providing squeeze with bool or string values violate any >>> rules? >>> What is the clearest string to use? I have considered ?flatten?, >>> ?flat?, ?ravel?, and ?1d?. >>> >>> The second enhancement permits sharing axis between different >>> figures. It extends the sharex and sharey arguments to accept either an >>> axis instance (in which case all of the new plots share the same x or y >>> limits), or 1D or 2D numpy arrays of axis instances (in which case >>> rows/columns are shared or each plot shares with the corresponding plot >>> passed in. >>> >>> Should I invest the effort required to submit these? Is there a >>> time frame in which these additions would be more or less welcome? >>> >>> Thank you, >>> Christopher Field >>> >>> >>> >>> _______________________________________________ >>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon May 23 12:53:05 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 23 May 2016 12:53:05 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: > Hi, > > On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida > wrote: >> On 11 May 2016 at 10:58, Matthew Brett wrote: >>> >>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>> > wrote: >>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>> >>> >>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>> >>> >>> >>> wrote: >>> >>> >> [...] >>> >>> >> >>> >>> >> This would probably look like: >>> >>> >> >>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>> >>> >> Python >>> >>> >> calls >>> >>> >> this module) >>> >>> >> >>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>> >>> >> out >>> >>> >> where >>> >>> >> tkinter.so lives >>> >>> >> >>> >>> >> We add its directory to LD_LIBRARY_PATH >>> >>> >> >>> >>> >> we import _tkagg.so >>> >>> >> >>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>> >>> >> >>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>> >>> >> reliable >>> >>> >> than anything where we try to reimplement the dynamic loader's >>> >>> >> search >>> >>> >> logic >>> >>> >> ourselves. >>> >>> > >>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>> >>> > automating that. >>> >>> >>> >>> Ah - except I do not believe it is possible to change the linker path >>> >>> for Python modules, within the Python process: >>> >>> >>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>> > >>> > Doh :-( >>> >>> Any other suggestions? >> >> >> Calling `patchelf` at runtime with the result of introspecting the >> `_tkinter.so` module? :-) >> >> On a more serious note, even though it would be dangerous to call >> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >> >> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >> >> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >> (but not re-added). >> >> We would be dumping only libtcl/tk's symbols in the namespace of other >> python extension modules. > > I have implemented dlopen dynamic loading of the TCL / Tk functions > from the Python tkinter extension module here : > https://github.com/matplotlib/matplotlib/pull/6442 > > It appears to work. I'd love any feedback y'all can offer. I patched matplotlib 1.5.1 with a version of the PR at [1] to build the wheels using the script at [2] and travis-ci repo build at [3]. The built wheels are up at http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ for testing. They work for me, for example doing tkagg animations. Cheers, Matthew [1] https://github.com/matplotlib/matplotlib/pull/6442 [2] https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh [3] https://travis-ci.org/matthew-brett/manylinux-builds/builds/132304156 From matthew.brett at gmail.com Mon May 23 15:37:54 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 23 May 2016 15:37:54 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 12:53 PM, Matthew Brett wrote: > On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: >> Hi, >> >> On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida >> wrote: >>> On 11 May 2016 at 10:58, Matthew Brett wrote: >>>> >>>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>>> > wrote: >>>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>> >>> >>>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>> >>> >>>> >>> wrote: >>>> >>> >> [...] >>>> >>> >> >>>> >>> >> This would probably look like: >>>> >>> >> >>>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>>> >>> >> Python >>>> >>> >> calls >>>> >>> >> this module) >>>> >>> >> >>>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>>> >>> >> out >>>> >>> >> where >>>> >>> >> tkinter.so lives >>>> >>> >> >>>> >>> >> We add its directory to LD_LIBRARY_PATH >>>> >>> >> >>>> >>> >> we import _tkagg.so >>>> >>> >> >>>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>>> >>> >> >>>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>> >>> >> reliable >>>> >>> >> than anything where we try to reimplement the dynamic loader's >>>> >>> >> search >>>> >>> >> logic >>>> >>> >> ourselves. >>>> >>> > >>>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>>> >>> > automating that. >>>> >>> >>>> >>> Ah - except I do not believe it is possible to change the linker path >>>> >>> for Python modules, within the Python process: >>>> >>> >>>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>>> > >>>> > Doh :-( >>>> >>>> Any other suggestions? >>> >>> >>> Calling `patchelf` at runtime with the result of introspecting the >>> `_tkinter.so` module? :-) >>> >>> On a more serious note, even though it would be dangerous to call >>> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >>> >>> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >>> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >>> >>> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >>> (but not re-added). >>> >>> We would be dumping only libtcl/tk's symbols in the namespace of other >>> python extension modules. >> >> I have implemented dlopen dynamic loading of the TCL / Tk functions >> from the Python tkinter extension module here : >> https://github.com/matplotlib/matplotlib/pull/6442 >> >> It appears to work. I'd love any feedback y'all can offer. > > I patched matplotlib 1.5.1 with a version of the PR at [1] to build > the wheels using the script at [2] and travis-ci repo build at [3]. > > The built wheels are up at > http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ > for testing. > > They work for me, for example doing tkagg animations. Travis testing of these wheels, and some errors, reported at https://github.com/matplotlib/matplotlib/issues/6469 Cheers, Matthew From matthew.brett at gmail.com Tue May 24 11:28:23 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 24 May 2016 11:28:23 -0400 Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 3:37 PM, Matthew Brett wrote: > On Mon, May 23, 2016 at 12:53 PM, Matthew Brett wrote: >> On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: >>> Hi, >>> >>> On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida >>> wrote: >>>> On 11 May 2016 at 10:58, Matthew Brett wrote: >>>>> >>>>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>>>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>>>> > wrote: >>>>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>>> >>> >>>>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>>> >>> >>>>> >>> wrote: >>>>> >>> >> [...] >>>>> >>> >> >>>>> >>> >> This would probably look like: >>>>> >>> >> >>>>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>>>> >>> >> Python >>>>> >>> >> calls >>>>> >>> >> this module) >>>>> >>> >> >>>>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>>>> >>> >> out >>>>> >>> >> where >>>>> >>> >> tkinter.so lives >>>>> >>> >> >>>>> >>> >> We add its directory to LD_LIBRARY_PATH >>>>> >>> >> >>>>> >>> >> we import _tkagg.so >>>>> >>> >> >>>>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>>>> >>> >> >>>>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>>> >>> >> reliable >>>>> >>> >> than anything where we try to reimplement the dynamic loader's >>>>> >>> >> search >>>>> >>> >> logic >>>>> >>> >> ourselves. >>>>> >>> > >>>>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>>>> >>> > automating that. >>>>> >>> >>>>> >>> Ah - except I do not believe it is possible to change the linker path >>>>> >>> for Python modules, within the Python process: >>>>> >>> >>>>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>>>> > >>>>> > Doh :-( >>>>> >>>>> Any other suggestions? >>>> >>>> >>>> Calling `patchelf` at runtime with the result of introspecting the >>>> `_tkinter.so` module? :-) >>>> >>>> On a more serious note, even though it would be dangerous to call >>>> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >>>> >>>> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >>>> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >>>> >>>> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >>>> (but not re-added). >>>> >>>> We would be dumping only libtcl/tk's symbols in the namespace of other >>>> python extension modules. >>> >>> I have implemented dlopen dynamic loading of the TCL / Tk functions >>> from the Python tkinter extension module here : >>> https://github.com/matplotlib/matplotlib/pull/6442 >>> >>> It appears to work. I'd love any feedback y'all can offer. >> >> I patched matplotlib 1.5.1 with a version of the PR at [1] to build >> the wheels using the script at [2] and travis-ci repo build at [3]. >> >> The built wheels are up at >> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ >> for testing. >> >> They work for me, for example doing tkagg animations. > > Travis testing of these wheels, and some errors, reported at > https://github.com/matplotlib/matplotlib/issues/6469 Thanks Olivier for testing. Thomas Caswell gave me the pointers I needed to fix the test failures, tests now passing at : https://travis-ci.org/matthew-brett/manylinux-testing/builds/132577898 I think these wheels are now ready to ship - MPL issue at : https://github.com/matplotlib/matplotlib/issues/6473 Cheers, Matthew From pierre.haessig at crans.org Thu May 26 07:44:09 2016 From: pierre.haessig at crans.org (Pierre Haessig) Date: Thu, 26 May 2016 13:44:09 +0200 Subject: [Matplotlib-devel] markers disappear using 'seaborn-notebook' style in v1.5 Message-ID: <5746E189.5040105@crans.org> Hi, I just noticed an issue with markers using the 'seaborn-notebook' style in v1.5. Usual markers like '+' and 'x' are invisible. It comes from the line 13 in the stylesheet: lines.markeredgewidth: 0 https://github.com/matplotlib/matplotlib/blob/v1.5.1/lib/matplotlib/mpl-data/stylelib/seaborn-notebook.mplstyle#L13 Is this intentional or just a typo ? Should I send a (one line) PR ? I also made a notebook with plots while investigating the issue: https://gist.github.com/pierre-haessig/7bcceb99257da94a04525011cb2e81c3 It seems that other seeborn styles are not affected. best, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu May 26 08:07:06 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 26 May 2016 12:07:06 +0000 Subject: [Matplotlib-devel] markers disappear using 'seaborn-notebook' style in v1.5 In-Reply-To: <5746E189.5040105@crans.org> References: <5746E189.5040105@crans.org> Message-ID: Exactly which version of 1.5 are you using and how did you install it? I thought we fixed that bug (see https://github.com/matplotlib/matplotlib/issues/5156 and included links). Tom On Thu, May 26, 2016, 07:54 Pierre Haessig wrote: > Hi, > > I just noticed an issue with markers using the 'seaborn-notebook' style in > v1.5. Usual markers like '+' and 'x' are invisible. It comes from the line > 13 in the stylesheet: > > lines.markeredgewidth: 0 > > > https://github.com/matplotlib/matplotlib/blob/v1.5.1/lib/matplotlib/mpl-data/stylelib/seaborn-notebook.mplstyle#L13 > > Is this intentional or just a typo ? Should I send a (one line) PR ? > > I also made a notebook with plots while investigating the issue: > https://gist.github.com/pierre-haessig/7bcceb99257da94a04525011cb2e81c3 > It seems that other seeborn styles are not affected. > > best, > Pierre > _______________________________________________ > 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 mwaskom at stanford.edu Thu May 26 10:57:31 2016 From: mwaskom at stanford.edu (Michael Waskom) Date: Thu, 26 May 2016 07:57:31 -0700 Subject: [Matplotlib-devel] markers disappear using 'seaborn-notebook' style in v1.5 In-Reply-To: References: <5746E189.5040105@crans.org> Message-ID: I think this is a slightly different issue than #5156, and is described here: https://github.com/matplotlib/matplotlib/issues/4679 On Thu, May 26, 2016 at 5:07 AM, Thomas Caswell wrote: > Exactly which version of 1.5 are you using and how did you install it? I > thought we fixed that bug (see > https://github.com/matplotlib/matplotlib/issues/5156 and included links). > > Tom > > On Thu, May 26, 2016, 07:54 Pierre Haessig > wrote: > >> Hi, >> >> I just noticed an issue with markers using the 'seaborn-notebook' style >> in v1.5. Usual markers like '+' and 'x' are invisible. It comes from the >> line 13 in the stylesheet: >> >> lines.markeredgewidth: 0 >> >> >> https://github.com/matplotlib/matplotlib/blob/v1.5.1/lib/matplotlib/mpl-data/stylelib/seaborn-notebook.mplstyle#L13 >> >> Is this intentional or just a typo ? Should I send a (one line) PR ? >> >> I also made a notebook with plots while investigating the issue: >> https://gist.github.com/pierre-haessig/7bcceb99257da94a04525011cb2e81c3 >> It seems that other seeborn styles are not affected. >> >> best, >> Pierre >> _______________________________________________ >> 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 pierre.haessig at crans.org Thu May 26 12:15:20 2016 From: pierre.haessig at crans.org (Pierre Haessig) Date: Thu, 26 May 2016 18:15:20 +0200 Subject: [Matplotlib-devel] markers disappear using 'seaborn-notebook' style in v1.5 In-Reply-To: References: <5746E189.5040105@crans.org> Message-ID: <57472118.3030204@crans.org> Hi Thomas, Le 26/05/2016 14:07, Thomas Caswell a ?crit : > > Exactly which version of 1.5 are you using and how did you install it? > I thought we fixed that bug (see > https://github.com/matplotlib/matplotlib/issues/5156 and included links). > I'm using 1.5.1 from Anaconda (version "np110py27_0"). I'll test the clean env tomorrow. Now, looking at the plot embedded in the discussion, I must add that not all markers disappears. Those like "d" or "o" with a solid fill are still there. Only 'x' and '+' disappear. Also, the "fix" to use lines.markeredgewidth: 1 has the negative side effect that "d" or "o" are now plotted with an ugly black border... Pierre From tcaswell at gmail.com Thu May 26 22:44:01 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 27 May 2016 02:44:01 +0000 Subject: [Matplotlib-devel] REL: v1.5.2rc2 Message-ID: Hey folks, I just tagged rc2. This includes a some-what aggressive backport of the reworking of how we link into Tk to decouple from the exact version of tk we are compiled against (https://github.com/matplotlib/matplotlib/pull/6442) As such, please try to build this on your your systems and verify that mpl builds and works correctly with the tkagg backend. A major motivation for including this in the 1.5.2 release is that we can now release wheels for all of the major platforms. Much of the credit for this should go to the tireless Matthew Brett. The new rc (and the old one) should be available (assuming the CI passes) for conda via conda install -c conda-forge/channel/rc matplotlib Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.haessig at crans.org Fri May 27 03:41:22 2016 From: pierre.haessig at crans.org (Pierre Haessig) Date: Fri, 27 May 2016 09:41:22 +0200 Subject: [Matplotlib-devel] markers disappear using 'seaborn-notebook' style in v1.5 In-Reply-To: References: <5746E189.5040105@crans.org> Message-ID: <5747FA22.9050100@crans.org> Le 26/05/2016 16:57, Michael Waskom a ?crit : > I think this is a slightly different issue than #5156, and is > described here: https://github.com/matplotlib/matplotlib/issues/4679 Yes, this is it ! I agree with your July 2015 comment: > it would be better to have some *differentiation* between > the width of the edge around a solid marker, which is purely aesthetic, and >the weight of the line that is used to draw a line-art marker, which isn't. best, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tcaswell at gmail.com Fri May 27 22:30:41 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 28 May 2016 02:30:41 +0000 Subject: [Matplotlib-devel] final 2.0b1 work Message-ID: Folks, If you have anytime over the (US) holiday weekend, please look at anything in https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 I would like to tag a beta Sunday or Monday. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Sat May 28 13:00:26 2016 From: ellisonbg at gmail.com (Brian Granger) Date: Sat, 28 May 2016 10:00:26 -0700 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: Message-ID: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Could you generate the full gallery with the 2.0 style for review? Sent from my iPhone > On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: > > Folks, > > If you have anytime over the (US) holiday weekend, please look at anything in > > https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 > > I would like to tag a beta Sunday or Monday. > > Tom > _______________________________________________ > 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 Sat May 28 13:13:38 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 28 May 2016 17:13:38 +0000 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: The docs at matplotlib.org/devdocs are from master but are close style wise. I will push up a full 2.0b1 doc build when we tag. Tom On Sat, May 28, 2016, 13:00 Brian Granger wrote: > Could you generate the full gallery with the 2.0 style for review? > > Sent from my iPhone > > On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: > > Folks, > > If you have anytime over the (US) holiday weekend, please look at anything > in > > > https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 > > I would like to tag a beta Sunday or Monday. > > Tom > > _______________________________________________ > 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 isaac.gerg at gergltd.com Sat May 28 13:53:07 2016 From: isaac.gerg at gergltd.com (Isaac Gerg) Date: Sat, 28 May 2016 13:53:07 -0400 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: I have a script I use which makes several generic plots to test everything. Do you gents need it? I can clean it up and put it on github if you want it. On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell wrote: > The docs at matplotlib.org/devdocs are from master but are close style > wise. > > I will push up a full 2.0b1 doc build when we tag. > > Tom > > On Sat, May 28, 2016, 13:00 Brian Granger wrote: > >> Could you generate the full gallery with the 2.0 style for review? >> >> Sent from my iPhone >> >> On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: >> >> Folks, >> >> If you have anytime over the (US) holiday weekend, please look at >> anything in >> >> >> https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 >> >> I would like to tag a beta Sunday or Monday. >> >> Tom >> >> _______________________________________________ >> 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 tcaswell at gmail.com Sat May 28 13:58:09 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 28 May 2016 17:58:09 +0000 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: We already have one 'unified' example PR https://github.com/matplotlib/matplotlib/pull/6476 but I think this is a case of the more the better. The use case of mpl are so wide I think if you asked 10 people for 'generic' plots you would get 11 different answers. Tom On Sat, May 28, 2016 at 1:53 PM Isaac Gerg wrote: > I have a script I use which makes several generic plots to test > everything. Do you gents need it? I can clean it up and put it on github > if you want it. > > On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell > wrote: > >> The docs at matplotlib.org/devdocs are from master but are close style >> wise. >> >> I will push up a full 2.0b1 doc build when we tag. >> >> Tom >> >> On Sat, May 28, 2016, 13:00 Brian Granger wrote: >> >>> Could you generate the full gallery with the 2.0 style for review? >>> >>> Sent from my iPhone >>> >>> On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: >>> >>> Folks, >>> >>> If you have anytime over the (US) holiday weekend, please look at >>> anything in >>> >>> >>> https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 >>> >>> I would like to tag a beta Sunday or Monday. >>> >>> Tom >>> >>> _______________________________________________ >>> 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 ellisonbg at gmail.com Sat May 28 14:21:25 2016 From: ellisonbg at gmail.com (Brian Granger) Date: Sat, 28 May 2016 11:21:25 -0700 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: Which branch has the most up to date 2.0b code? On Sat, May 28, 2016 at 10:58 AM, Thomas Caswell wrote: > We already have one 'unified' example PR > https://github.com/matplotlib/matplotlib/pull/6476 but I think this is a > case of the more the better. The use case of mpl are so wide I think if you > asked 10 people for 'generic' plots you would get 11 different answers. > > Tom > > On Sat, May 28, 2016 at 1:53 PM Isaac Gerg wrote: >> >> I have a script I use which makes several generic plots to test >> everything. Do you gents need it? I can clean it up and put it on github if >> you want it. >> >> On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell >> wrote: >>> >>> The docs at matplotlib.org/devdocs are from master but are close style >>> wise. >>> >>> I will push up a full 2.0b1 doc build when we tag. >>> >>> Tom >>> >>> >>> On Sat, May 28, 2016, 13:00 Brian Granger wrote: >>>> >>>> Could you generate the full gallery with the 2.0 style for review? >>>> >>>> Sent from my iPhone >>>> >>>> On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: >>>> >>>> Folks, >>>> >>>> If you have anytime over the (US) holiday weekend, please look at >>>> anything in >>>> >>>> >>>> https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 >>>> >>>> I would like to tag a beta Sunday or Monday. >>>> >>>> Tom >>>> >>>> _______________________________________________ >>>> 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 >>> >> > -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Sat May 28 14:22:27 2016 From: ellisonbg at gmail.com (Brian Granger) Date: Sat, 28 May 2016 11:22:27 -0700 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: Isaac, that would be helpful, could you post that? On Sat, May 28, 2016 at 11:21 AM, Brian Granger wrote: > Which branch has the most up to date 2.0b code? > > On Sat, May 28, 2016 at 10:58 AM, Thomas Caswell wrote: >> We already have one 'unified' example PR >> https://github.com/matplotlib/matplotlib/pull/6476 but I think this is a >> case of the more the better. The use case of mpl are so wide I think if you >> asked 10 people for 'generic' plots you would get 11 different answers. >> >> Tom >> >> On Sat, May 28, 2016 at 1:53 PM Isaac Gerg wrote: >>> >>> I have a script I use which makes several generic plots to test >>> everything. Do you gents need it? I can clean it up and put it on github if >>> you want it. >>> >>> On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell >>> wrote: >>>> >>>> The docs at matplotlib.org/devdocs are from master but are close style >>>> wise. >>>> >>>> I will push up a full 2.0b1 doc build when we tag. >>>> >>>> Tom >>>> >>>> >>>> On Sat, May 28, 2016, 13:00 Brian Granger wrote: >>>>> >>>>> Could you generate the full gallery with the 2.0 style for review? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On May 27, 2016, at 7:30 PM, Thomas Caswell wrote: >>>>> >>>>> Folks, >>>>> >>>>> If you have anytime over the (US) holiday weekend, please look at >>>>> anything in >>>>> >>>>> >>>>> https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 >>>>> >>>>> I would like to tag a beta Sunday or Monday. >>>>> >>>>> Tom >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> > > > > -- > Brian E. Granger > Associate Professor of Physics and Data Science > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgranger at calpoly.edu and ellisonbg at gmail.com -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger at calpoly.edu and ellisonbg at gmail.com From tcaswell at gmail.com Sat May 28 14:23:42 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 28 May 2016 18:23:42 +0000 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: The beta will be cut off of v2.x Tom On Sat, May 28, 2016, 14:22 Brian Granger wrote: > Isaac, that would be helpful, could you post that? > > On Sat, May 28, 2016 at 11:21 AM, Brian Granger > wrote: > > Which branch has the most up to date 2.0b code? > > > > On Sat, May 28, 2016 at 10:58 AM, Thomas Caswell > wrote: > >> We already have one 'unified' example PR > >> https://github.com/matplotlib/matplotlib/pull/6476 but I think this is > a > >> case of the more the better. The use case of mpl are so wide I think > if you > >> asked 10 people for 'generic' plots you would get 11 different answers. > >> > >> Tom > >> > >> On Sat, May 28, 2016 at 1:53 PM Isaac Gerg > wrote: > >>> > >>> I have a script I use which makes several generic plots to test > >>> everything. Do you gents need it? I can clean it up and put it on > github if > >>> you want it. > >>> > >>> On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell > >>> wrote: > >>>> > >>>> The docs at matplotlib.org/devdocs are from master but are close > style > >>>> wise. > >>>> > >>>> I will push up a full 2.0b1 doc build when we tag. > >>>> > >>>> Tom > >>>> > >>>> > >>>> On Sat, May 28, 2016, 13:00 Brian Granger > wrote: > >>>>> > >>>>> Could you generate the full gallery with the 2.0 style for review? > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On May 27, 2016, at 7:30 PM, Thomas Caswell > wrote: > >>>>> > >>>>> Folks, > >>>>> > >>>>> If you have anytime over the (US) holiday weekend, please look at > >>>>> anything in > >>>>> > >>>>> > >>>>> > https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 > >>>>> > >>>>> I would like to tag a beta Sunday or Monday. > >>>>> > >>>>> Tom > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >> > > > > > > > > -- > > Brian E. Granger > > Associate Professor of Physics and Data Science > > Cal Poly State University, San Luis Obispo > > @ellisonbg on Twitter and GitHub > > bgranger at calpoly.edu and ellisonbg at gmail.com > > > > -- > Brian E. Granger > Associate Professor of Physics and Data Science > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgranger at calpoly.edu and ellisonbg at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Sat May 28 14:24:28 2016 From: ellisonbg at gmail.com (Brian Granger) Date: Sat, 28 May 2016 11:24:28 -0700 Subject: [Matplotlib-devel] final 2.0b1 work In-Reply-To: References: <5F0386ED-F9B3-4633-BAF5-FC129AAEC77F@gmail.com> Message-ID: OK great, I will try to do a design review this weekend... On Sat, May 28, 2016 at 11:23 AM, Thomas Caswell wrote: > The beta will be cut off of v2.x > > Tom > > > On Sat, May 28, 2016, 14:22 Brian Granger wrote: >> >> Isaac, that would be helpful, could you post that? >> >> On Sat, May 28, 2016 at 11:21 AM, Brian Granger >> wrote: >> > Which branch has the most up to date 2.0b code? >> > >> > On Sat, May 28, 2016 at 10:58 AM, Thomas Caswell >> > wrote: >> >> We already have one 'unified' example PR >> >> https://github.com/matplotlib/matplotlib/pull/6476 but I think this is >> >> a >> >> case of the more the better. The use case of mpl are so wide I think >> >> if you >> >> asked 10 people for 'generic' plots you would get 11 different answers. >> >> >> >> Tom >> >> >> >> On Sat, May 28, 2016 at 1:53 PM Isaac Gerg >> >> wrote: >> >>> >> >>> I have a script I use which makes several generic plots to test >> >>> everything. Do you gents need it? I can clean it up and put it on >> >>> github if >> >>> you want it. >> >>> >> >>> On Sat, May 28, 2016 at 1:13 PM, Thomas Caswell >> >>> wrote: >> >>>> >> >>>> The docs at matplotlib.org/devdocs are from master but are close >> >>>> style >> >>>> wise. >> >>>> >> >>>> I will push up a full 2.0b1 doc build when we tag. >> >>>> >> >>>> Tom >> >>>> >> >>>> >> >>>> On Sat, May 28, 2016, 13:00 Brian Granger >> >>>> wrote: >> >>>>> >> >>>>> Could you generate the full gallery with the 2.0 style for review? >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>> On May 27, 2016, at 7:30 PM, Thomas Caswell >> >>>>> wrote: >> >>>>> >> >>>>> Folks, >> >>>>> >> >>>>> If you have anytime over the (US) holiday weekend, please look at >> >>>>> anything in >> >>>>> >> >>>>> >> >>>>> >> >>>>> https://github.com/matplotlib/matplotlib/issues?q=is%3Aopen+milestone%3A%222.0+%28style+change+major+release%29%22+label%3A%22default+changes%22 >> >>>>> >> >>>>> I would like to tag a beta Sunday or Monday. >> >>>>> >> >>>>> Tom >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >> >> > >> > >> > >> > -- >> > Brian E. Granger >> > Associate Professor of Physics and Data Science >> > Cal Poly State University, San Luis Obispo >> > @ellisonbg on Twitter and GitHub >> > bgranger at calpoly.edu and ellisonbg at gmail.com >> >> >> >> -- >> Brian E. Granger >> Associate Professor of Physics and Data Science >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgranger at calpoly.edu and ellisonbg at gmail.com -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger at calpoly.edu and ellisonbg at gmail.com From matthew.brett at gmail.com Mon May 30 15:09:02 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 30 May 2016 12:09:02 -0700 Subject: [Matplotlib-devel] Should we add manylinux wheels for previous versions of matplotlib? Message-ID: Hi, As y'all probably know, we can now build reasonable manylinux wheels for matplotlib. For the upcoming 1.5.2 there is a firm plan to ship manylinux wheels. I also proposed putting up wheels for the current (1.5.1) and older versions - see [1]. My argument for doing this, is that it's relatively common for people to want to check that their code is compatible with older versions of matplotlib, especially using continuous integration testing on services like travis - and that putting wheels up on pypi would make this much easier to do. For example, there are now historical manylinux wheels up of numpy, scipy and cython up on pypi. Thomas C worried that this might cause problems. Numpy did get one complaint about the historical wheels (see [2]). We numpiers decided to continue providing the old numpy wheels on the basis that the person's use-case was unusual, and it was easy for him to solve the problem in a clean way by forcing a source install with the `--no-binary` flag to pip. So - the benefits of providing matplotlib wheels for old versions are easier installation of old versions for testing, or from pip requirements files that name specific versions. The risks are that someone with a more complex CI setup might run into problems we haven't yet thought of. Any thoughts / votes on this? Best, Matthew [1] https://github.com/matplotlib/matplotlib/issues/6473 [2] https://github.com/numpy/numpy/issues/7570 From tcaswell at gmail.com Mon May 30 16:44:11 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 30 May 2016 20:44:11 +0000 Subject: [Matplotlib-devel] REL: v1.5.2rc2 In-Reply-To: References: Message-ID: How long does that tend to take to run? We should probably hold off on a 1.5.2 final until we hear back. Tom On Mon, May 30, 2016 at 4:34 PM Sandro Tosi wrote: > Hey Thomas & mpl developer, > I just pushed 1.5.2rc2 to debian, let's see if some of the weirdest > archs complain - I will report here if they do > > On Fri, May 27, 2016 at 3:44 AM, Thomas Caswell > wrote: > > Hey folks, > > > > I just tagged rc2. > > > > This includes a some-what aggressive backport of the reworking of how we > > link into Tk to decouple from the exact version of tk we are compiled > > against (https://github.com/matplotlib/matplotlib/pull/6442) > > > > As such, please try to build this on your your systems and verify that > mpl > > builds and works correctly with the tkagg backend. > > > > A major motivation for including this in the 1.5.2 release is that we can > > now release wheels for all of the major platforms. Much of the credit > for > > this should go to the tireless Matthew Brett. > > > > The new rc (and the old one) should be available (assuming the CI passes) > > for conda via > > > > conda install -c conda-forge/channel/rc matplotlib > > > > Tom > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Mon May 30 16:34:06 2016 From: morph at debian.org (Sandro Tosi) Date: Mon, 30 May 2016 21:34:06 +0100 Subject: [Matplotlib-devel] REL: v1.5.2rc2 In-Reply-To: References: Message-ID: Hey Thomas & mpl developer, I just pushed 1.5.2rc2 to debian, let's see if some of the weirdest archs complain - I will report here if they do On Fri, May 27, 2016 at 3:44 AM, Thomas Caswell wrote: > Hey folks, > > I just tagged rc2. > > This includes a some-what aggressive backport of the reworking of how we > link into Tk to decouple from the exact version of tk we are compiled > against (https://github.com/matplotlib/matplotlib/pull/6442) > > As such, please try to build this on your your systems and verify that mpl > builds and works correctly with the tkagg backend. > > A major motivation for including this in the 1.5.2 release is that we can > now release wheels for all of the major platforms. Much of the credit for > this should go to the tireless Matthew Brett. > > The new rc (and the old one) should be available (assuming the CI passes) > for conda via > > conda install -c conda-forge/channel/rc matplotlib > > Tom > > _______________________________________________ > 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 njs at pobox.com Mon May 30 19:47:51 2016 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 30 May 2016 16:47:51 -0700 Subject: [Matplotlib-devel] Should we add manylinux wheels for previous versions of matplotlib? In-Reply-To: References: Message-ID: Just to check, I assume that these wheels would need a backport of: https://github.com/matplotlib/matplotlib/pull/6442 ? -n On Mon, May 30, 2016 at 12:09 PM, Matthew Brett wrote: > Hi, > > As y'all probably know, we can now build reasonable manylinux wheels > for matplotlib. > > For the upcoming 1.5.2 there is a firm plan to ship manylinux wheels. > > I also proposed putting up wheels for the current (1.5.1) and older > versions - see [1]. > > My argument for doing this, is that it's relatively common for people > to want to check that their code is compatible with older versions of > matplotlib, especially using continuous integration testing on > services like travis - and that putting wheels up on pypi would make > this much easier to do. For example, there are now historical > manylinux wheels up of numpy, scipy and cython up on pypi. > > Thomas C worried that this might cause problems. Numpy did get one > complaint about the historical wheels (see [2]). We numpiers decided > to continue providing the old numpy wheels on the basis that the > person's use-case was unusual, and it was easy for him to solve the > problem in a clean way by forcing a source install with the > `--no-binary` flag to pip. > > So - the benefits of providing matplotlib wheels for old versions are > easier installation of old versions for testing, or from pip > requirements files that name specific versions. The risks are that > someone with a more complex CI setup might run into problems we > haven't yet thought of. > > Any thoughts / votes on this? > > Best, > > Matthew > > > [1] https://github.com/matplotlib/matplotlib/issues/6473 > [2] https://github.com/numpy/numpy/issues/7570 > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -- Nathaniel J. Smith -- https://vorpus.org From matthew.brett at gmail.com Mon May 30 20:08:41 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 30 May 2016 17:08:41 -0700 Subject: [Matplotlib-devel] Should we add manylinux wheels for previous versions of matplotlib? In-Reply-To: References: Message-ID: On Mon, May 30, 2016 at 4:47 PM, Nathaniel Smith wrote: > Just to check, I assume that these wheels would need a backport of: > https://github.com/matplotlib/matplotlib/pull/6442 > ? Yes, that's already done over at : https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh . Matthew From matthew.brett at gmail.com Mon May 30 21:28:51 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 30 May 2016 18:28:51 -0700 Subject: [Matplotlib-devel] REL: v1.5.2rc2 In-Reply-To: References: Message-ID: Hi, On Thu, May 26, 2016 at 7:44 PM, Thomas Caswell wrote: > Hey folks, > > I just tagged rc2. > > This includes a some-what aggressive backport of the reworking of how we > link into Tk to decouple from the exact version of tk we are compiled > against (https://github.com/matplotlib/matplotlib/pull/6442) > > As such, please try to build this on your your systems and verify that mpl > builds and works correctly with the tkagg backend. > > A major motivation for including this in the 1.5.2 release is that we can > now release wheels for all of the major platforms. Much of the credit for > this should go to the tireless Matthew Brett. > > The new rc (and the old one) should be available (assuming the CI passes) > for conda via > > conda install -c conda-forge/channel/rc matplotlib Y'all can test the new manylinux wheels with: python -m pip install --upgrade pip # upgrade to latest pip pip install -f https://nipy.bic.berkeley.edu/manylinux --pre matplotlib In particular, I'd love to know whether this works for you: >>> import matplotlib >>> matplotlib.use('tkagg') >>> import matplotlib.pyplot as plt >>> plt.plot(range(10)) >>> plt.show() Cheers, Matthew From tcaswell at gmail.com Tue May 31 00:01:52 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 31 May 2016 04:01:52 +0000 Subject: [Matplotlib-devel] matplotlib v2.0.0b1 Message-ID: Folks, We tagged the first beta for v2.0.0 tonight. Please check out the new defaults! This is tagged as a beta because we anticipate a longer than normal release cycle. The style changes are substantial and we want to make sure that we have not crippled any common use cases. The target for the final release around scipy. A build of the docs is available at http://matplotlib.org/2.0.0b1 Preview conda packages are available via conda install -c conda-forge/label/rc -c conda-forge matplotlib pre-release packages should be on pypi tomorrow. Brief release notes: This previews the new default style and many bug-fixes. A full list of the style changes will be collected for the final release. In addition to the style change this release includes: - overhaul of font handling/text rendering to be faster and clearer - many new rcParams - Agg based OSX backend - optionally deterministic SVGs - complete re-write of image handling code - simplified color conversion - specify colors in the global property cycle via `'C0'`, `'C1'`... `'C9'` - use the global property cycle more places (bar, stem, scatter) There is a 'classic' style sheet which reproduces the 1.Y defaults: import matplotlib.style as mstyle mstyle.use('classic') A big thank you to everyone who worked on this release. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From morph at debian.org Tue May 31 01:17:11 2016 From: morph at debian.org (Sandro Tosi) Date: Tue, 31 May 2016 06:17:11 +0100 Subject: [Matplotlib-devel] REL: v1.5.2rc2 In-Reply-To: References: Message-ID: on almost all architectures, it has already built or building right now (you can see its progress at https://buildd.debian.org/status/package.php?p=matplotlib) so I expect within today we'll have most (if not all) of the archs will be done On Mon, May 30, 2016 at 9:44 PM, Thomas Caswell wrote: > How long does that tend to take to run? We should probably hold off on a > 1.5.2 final until we hear back. > > Tom > > On Mon, May 30, 2016 at 4:34 PM Sandro Tosi wrote: >> >> Hey Thomas & mpl developer, >> I just pushed 1.5.2rc2 to debian, let's see if some of the weirdest >> archs complain - I will report here if they do >> >> On Fri, May 27, 2016 at 3:44 AM, Thomas Caswell >> wrote: >> > Hey folks, >> > >> > I just tagged rc2. >> > >> > This includes a some-what aggressive backport of the reworking of how we >> > link into Tk to decouple from the exact version of tk we are compiled >> > against (https://github.com/matplotlib/matplotlib/pull/6442) >> > >> > As such, please try to build this on your your systems and verify that >> > mpl >> > builds and works correctly with the tkagg backend. >> > >> > A major motivation for including this in the 1.5.2 release is that we >> > can >> > now release wheels for all of the major platforms. Much of the credit >> > for >> > this should go to the tireless Matthew Brett. >> > >> > The new rc (and the old one) should be available (assuming the CI >> > passes) >> > for conda via >> > >> > conda install -c conda-forge/channel/rc matplotlib >> > >> > Tom >> > >> > _______________________________________________ >> > 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 -- 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 ndbecker2 at gmail.com Tue May 31 07:13:08 2016 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 31 May 2016 07:13:08 -0400 Subject: [Matplotlib-devel] matplotlib v2.0.0b1 References: Message-ID: Thomas Caswell wrote: > conda install -c conda-forge/label/rc -c conda-forge matplotlib seems to work. Where can I find info on new features/changelog? http://matplotlib.org/2.0.0b1/users/whats_new.html Does not seem to be updated From tcaswell at gmail.com Tue May 31 07:16:58 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 31 May 2016 11:16:58 +0000 Subject: [Matplotlib-devel] matplotlib v2.0.0b1 In-Reply-To: References: Message-ID: The full release notes have not been compiled yet. https://github.com/matplotlib/matplotlib/tree/v2.x/doc/users/whats_new is the components that will go into it. For the style changes, look a a diff of rcsetup.py from 1.5.1 -> 2.0.0b1 Tom On Tue, May 31, 2016 at 7:13 AM Neal Becker wrote: > Thomas Caswell wrote: > > > conda install -c conda-forge/label/rc -c conda-forge matplotlib > > seems to work. > > Where can I find info on new features/changelog? > http://matplotlib.org/2.0.0b1/users/whats_new.html > Does not seem to be updated > > _______________________________________________ > 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 matthew.brett at gmail.com Tue May 31 16:06:13 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 31 May 2016 13:06:13 -0700 Subject: [Matplotlib-devel] [Matplotlib-announce] matplotlib v2.0.0b1 In-Reply-To: References: Message-ID: On Mon, May 30, 2016 at 9:01 PM, Thomas Caswell wrote: > Folks, > > We tagged the first beta for v2.0.0 tonight. Please check out the new > defaults! > > This is tagged as a beta because we anticipate a longer than normal release > cycle. The style changes are substantial and we want to make sure that we > have not crippled any common use cases. The target for the final release > around scipy. You should now be able to get this release on OSX or Linux with: python -m pip install --upgrade pip # upgrade pip to latest pip install --pre matplotlib Cheers, Matthew From nathan12343 at gmail.com Tue May 31 18:51:55 2016 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Tue, 31 May 2016 17:51:55 -0500 Subject: [Matplotlib-devel] Setting the mathtext font via the object oriented API? Message-ID: Hi all, This is in reference to an issue I opened today: https://github.com/matplotlib/matplotlib/issues/6514#issuecomment-222833315 Is there a way to tell the mathtext renderer to use the computer modern font that used to be the default? I know I can do this via the mathtext.fontset rcparam, but this is in the context of a library that depends on matplotlib, so I'd prefer a way to do this without overriding any rcparams a user has set already. For non-mathtext text, this is easy, I just need to set the FontProperties instance associated with the Text object. However, there doesn't seem to be a way to do something similar for mathtext. Thanks for your help, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue May 31 19:59:50 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 31 May 2016 23:59:50 +0000 Subject: [Matplotlib-devel] [Matplotlib-users] matplotlib v2.0.0b1 In-Reply-To: References: Message-ID: python -m pip install --upgrade pip # upgrade pip to latest pip install --pre matplotlib Should now work on all platforms. Tom On Tue, May 31, 2016 at 6:31 PM Skip Montanaro wrote: > > A build of the docs is available at http://matplotlib.org/2.0.0b1 > > Thanks. Is there a "What's New" page in the docs? Or maybe an upgrade > guide which identifies incompatibilities with 1.5? > > Skip Montanaro > who still remembers John Hunter's interview presentation at TradeLink, > lo these many years ago... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Tue May 31 22:12:56 2016 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Tue, 31 May 2016 21:12:56 -0500 Subject: [Matplotlib-devel] Setting the mathtext font via the object oriented API? In-Reply-To: References: Message-ID: I think I'm going to work around this by wrapping the places where we draw matplotlib figures with context managers for the classic style, making use of matplotlib.style.context. We only draw figures in a few places, so it's a lot less invasive to use the context manager than I originally feared. Specifying the style exactly should also make it easier for us to avoid issues due to people's local matplotlib settings. As far as I can see, the font used for mathtext rendering can only be controlled by the mathtext.fontset rcparam (see the function MathTextParser.parse). Since I liked the old default - computer modern - I never noticed that it wasn't possible to control it via the object oriented API. I'm going to close the issue I linked to in the OP and instead open a feature request issue asking for a way to control the font of mathtext without messing with the rcparam system. Maybe it would also make sense for the font chosen for mathtext to try to match the font given by the FontProperties instance - for example, switching to a serif font if the FontProperties for the Text instance correspond to a serif font. On Tue, May 31, 2016 at 5:51 PM, Nathan Goldbaum wrote: > Hi all, > > This is in reference to an issue I opened today: > > https://github.com/matplotlib/matplotlib/issues/6514#issuecomment-222833315 > > Is there a way to tell the mathtext renderer to use the computer modern > font that used to be the default? I know I can do this via the > mathtext.fontset rcparam, but this is in the context of a library that > depends on matplotlib, so I'd prefer a way to do this without overriding > any rcparams a user has set already. > > For non-mathtext text, this is easy, I just need to set the FontProperties > instance associated with the Text object. However, there doesn't seem to be > a way to do something similar for mathtext. > > Thanks for your help, > > Nathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue May 31 22:26:55 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 01 Jun 2016 02:26:55 +0000 Subject: [Matplotlib-devel] Setting the mathtext font via the object oriented API? In-Reply-To: References: Message-ID: I am not sure that this was an intentional change. In either case, the ability to control this not via rcparams is clearly a good idea. Tom On Tue, May 31, 2016, 22:13 Nathan Goldbaum wrote: > I think I'm going to work around this by wrapping the places where we draw > matplotlib figures with context managers for the classic style, making use > of matplotlib.style.context. We only draw figures in a few places, so it's > a lot less invasive to use the context manager than I originally feared. > Specifying the style exactly should also make it easier for us to avoid > issues due to people's local matplotlib settings. > > As far as I can see, the font used for mathtext rendering can only be > controlled by the mathtext.fontset rcparam (see the function > MathTextParser.parse). Since I liked the old default - computer modern - I > never noticed that it wasn't possible to control it via the object oriented > API. > > I'm going to close the issue I linked to in the OP and instead open a > feature request issue asking for a way to control the font of mathtext > without messing with the rcparam system. Maybe it would also make sense for > the font chosen for mathtext to try to match the font given by the > FontProperties instance - for example, switching to a serif font if the > FontProperties for the Text instance correspond to a serif font. > > On Tue, May 31, 2016 at 5:51 PM, Nathan Goldbaum > wrote: > >> Hi all, >> >> This is in reference to an issue I opened today: >> >> >> https://github.com/matplotlib/matplotlib/issues/6514#issuecomment-222833315 >> >> Is there a way to tell the mathtext renderer to use the computer modern >> font that used to be the default? I know I can do this via the >> mathtext.fontset rcparam, but this is in the context of a library that >> depends on matplotlib, so I'd prefer a way to do this without overriding >> any rcparams a user has set already. >> >> For non-mathtext text, this is easy, I just need to set the >> FontProperties instance associated with the Text object. However, there >> doesn't seem to be a way to do something similar for mathtext. >> >> Thanks for your help, >> >> Nathan >> > > _______________________________________________ > 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: