From matti.picus at gmail.com Fri Sep 2 09:24:19 2016 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 2 Sep 2016 16:24:19 +0300 Subject: [Matplotlib-devel] getting pypy to play nice with matplotlib Message-ID: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> The pypy C-API progress, where we can basically run all of numpy (on a HEAD version numpy + nightly version of pypy). That means I will start to look at passing the matplotlib test suite. My first try segfaults, due to the tkagg backend blit function which calls into tk via id(data) and id(bbox_array). That of course will not work on PyPy since the address of a random python object does not reflect anything usable in C. So my question, as someone who is new to your codebase, is how to rewrite this using cffi or the standard C-API without impacting performance? Matti From tcaswell at gmail.com Fri Sep 2 09:32:27 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 02 Sep 2016 13:32:27 +0000 Subject: [Matplotlib-devel] getting pypy to play nice with matplotlib In-Reply-To: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> References: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> Message-ID: Which branch are you working off of? Matthew Brett recently did a whole bunch of work over-hauling how that linking happens. We currently have a blanket ban on cffi so that mpl will run in locked-down environments, but I would be open to being convinced using it in a localized way inside of the tk code. How are you running the test suite? It is odd that you are hitting tk at all. Tom On Fri, Sep 2, 2016 at 9:24 AM Matti Picus wrote: > The pypy C-API progress, where we can basically run all of numpy (on a > HEAD version numpy + nightly version of pypy). > > That means I will start to look at passing the matplotlib test suite. > > My first try segfaults, due to the tkagg backend blit function which > calls into tk via id(data) and id(bbox_array). > > That of course will not work on PyPy since the address of a random > python object does not reflect anything usable in C. > > So my question, as someone who is new to your codebase, is how to > rewrite this using cffi or the standard C-API without impacting > performance? > > Matti > > _______________________________________________ > 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 matti.picus at gmail.com Fri Sep 2 09:54:07 2016 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 2 Sep 2016 16:54:07 +0300 Subject: [Matplotlib-devel] getting pypy to play nice with matplotlib In-Reply-To: References: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> Message-ID: <825f7b62-0788-9329-d30a-3ccbabfb5f52@gmail.com> I am working off of 1.5.1, should I be using HEAD? Would any of the data access API's like np.array.__array_interface__ be acceptable? I did these two calls setup.py build setup.py nosetests --verbosity=10 and got a crash in matplotlib.tests.test_artist.test_remove Is there a better way to run tests? Thanks Matti On 02/09/16 16:32, Thomas Caswell wrote: > Which branch are you working off of? Matthew Brett recently did a > whole bunch of work over-hauling how that linking happens. > > We currently have a blanket ban on cffi so that mpl will run in > locked-down environments, but I would be open to being convinced using > it in a localized way inside of the tk code. > > How are you running the test suite? It is odd that you are hitting tk > at all. > > Tom > > On Fri, Sep 2, 2016 at 9:24 AM Matti Picus > wrote: > > The pypy C-API progress, where we can basically run all of numpy (on a > HEAD version numpy + nightly version of pypy). > > That means I will start to look at passing the matplotlib test suite. > > My first try segfaults, due to the tkagg backend blit function which > calls into tk via id(data) and id(bbox_array). > > That of course will not work on PyPy since the address of a random > python object does not reflect anything usable in C. > > So my question, as someone who is new to your codebase, is how to > rewrite this using cffi or the standard C-API without impacting > performance? > > Matti > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From tcaswell at gmail.com Fri Sep 2 13:05:52 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 02 Sep 2016 17:05:52 +0000 Subject: [Matplotlib-devel] getting pypy to play nice with matplotlib In-Reply-To: <825f7b62-0788-9329-d30a-3ccbabfb5f52@gmail.com> References: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> <825f7b62-0788-9329-d30a-3ccbabfb5f52@gmail.com> Message-ID: On my phone so excuse the terse answer. Use the numpy calls if likely OK Work of of master or v2.x Look at our travis.yml file for how to run the tests. Python tests.py Tom On Fri, Sep 2, 2016, 09:54 Matti Picus wrote: > I am working off of 1.5.1, should I be using HEAD? Would any of the data > access API's like np.array.__array_interface__ be acceptable? > I did these two calls > > setup.py build > > setup.py nosetests --verbosity=10 > > and got a crash in matplotlib.tests.test_artist.test_remove > > Is there a better way to run tests? > > Thanks > Matti > > On 02/09/16 16:32, Thomas Caswell wrote: > > Which branch are you working off of? Matthew Brett recently did a > > whole bunch of work over-hauling how that linking happens. > > > > We currently have a blanket ban on cffi so that mpl will run in > > locked-down environments, but I would be open to being convinced using > > it in a localized way inside of the tk code. > > > > How are you running the test suite? It is odd that you are hitting tk > > at all. > > > > Tom > > > > On Fri, Sep 2, 2016 at 9:24 AM Matti Picus > > wrote: > > > > The pypy C-API progress, where we can basically run all of numpy (on > a > > HEAD version numpy + nightly version of pypy). > > > > That means I will start to look at passing the matplotlib test suite. > > > > My first try segfaults, due to the tkagg backend blit function which > > calls into tk via id(data) and id(bbox_array). > > > > That of course will not work on PyPy since the address of a random > > python object does not reflect anything usable in C. > > > > So my question, as someone who is new to your codebase, is how to > > rewrite this using cffi or the standard C-API without impacting > > performance? > > > > Matti > > > > _______________________________________________ > > 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 Fri Sep 2 13:18:41 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 2 Sep 2016 10:18:41 -0700 Subject: [Matplotlib-devel] getting pypy to play nice with matplotlib In-Reply-To: References: <29b654a6-7039-ce49-08c7-5a0075602156@gmail.com> <825f7b62-0788-9329-d30a-3ccbabfb5f52@gmail.com> Message-ID: On Fri, Sep 2, 2016 at 10:05 AM, Thomas Caswell wrote: > On my phone so excuse the terse answer. > > Use the numpy calls if likely OK > > Work of of master or v2.x > > Look at our travis.yml file for how to run the tests. > > Python tests.py The newer tcl / tk linking finds the relevant functions from libraries loaded by Python, at run time, rather than at compile time. This is already working for pypy over at Pillow : https://github.com/python-pillow/Pillow/pull/1932 Cheers, Matthew From tcaswell at gmail.com Sat Sep 3 22:02:06 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 04 Sep 2016 02:02:06 +0000 Subject: [Matplotlib-devel] pydata cookbook Message-ID: Folks, Andy Terrel and Katy Huff are working on a pydata cookbook and have solicited chapter proposals at https://github.com/pydata/pydata-cookbook (see the readme there for more details). The schedule for chapter proposals was Sept 1, but if anyone one on this list is interested in writing a chapter (15-20 pgs) about matplotlib, I suspect that there is still time to get it in. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Sep 5 14:28:38 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 05 Sep 2016 18:28:38 +0000 Subject: [Matplotlib-devel] Documentation help request for web frameworks Message-ID: Folks, I know that there is a use of mpl as part of django / flask / bottle / zope / ... to write figures directly to buffers and serve them to users without writing to disk (an example of this is http://scipy-cookbook.readthedocs.io/items/Matplotlib_Django.html , but I think this is better done via `fig.savefig(bytes_io_buffer, format='png')` rather than reaching in and touching the canvas directly). This seems like the sort of thing that should be easy to find in our documentation. Is anyone interested in writing up 'canonical' examples? Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Rougier at inria.fr Wed Sep 7 01:37:41 2016 From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier) Date: Wed, 7 Sep 2016 06:37:41 +0100 Subject: [Matplotlib-devel] pydata cookbook In-Reply-To: References: Message-ID: I have some material that could be adapted for the chapter. Anyone else interested in participating ? Nicolas > On 04 Sep 2016, at 03:02, Thomas Caswell wrote: > > Folks, > > Andy Terrel and Katy Huff are working on a pydata cookbook and have solicited chapter proposals at https://github.com/pydata/pydata-cookbook (see the readme there for more details). > > The schedule for chapter proposals was Sept 1, but if anyone one on this list is interested in writing a chapter (15-20 pgs) about matplotlib, I suspect that there is still time to get it in. > > Tom > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From tcaswell at gmail.com Thu Sep 8 23:13:11 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 09 Sep 2016 03:13:11 +0000 Subject: [Matplotlib-devel] matplotlib v1.5.3 Message-ID: Folks, I have backported a few critical bug-fixes tagged 1.5.3. This release contains a few critical bug fixes: eliminate fatal exceptions with Qt5.7 memory leak in the contour code keyboard interaction bug with nbagg automatic integration with the ipython event loop (if running) which fixes 'naive' integration for IPython 5+ Plan wait to collect the wheels before uploading to pypi and a wider release. I have kicked off conda-forge with 1.5.3. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Sep 9 00:05:36 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 09 Sep 2016 04:05:36 +0000 Subject: [Matplotlib-devel] mpl v2.0.0b4 Message-ID: Folks, I tagged v2.0.0b4 tonight. As with 1.5.3 will make a bigger announcement once the binaries are ready. I think we are (finally) converging. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Fri Sep 9 07:07:07 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 9 Sep 2016 12:07:07 +0100 Subject: [Matplotlib-devel] OpenGL backend efforts? Message-ID: Hi everyone, I was curious as to whether there are currently any active efforts to write a Matplotlib OpenGL backend? In the past I've seen several starts at a backend, including for example in the VisPy package, but the latter has now been removed: https://github.com/vispy/vispy/pull/1224 Is anyone aware of more recent or maintained efforts? Thanks! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlong at stsci.edu Fri Sep 9 11:43:38 2016 From: jlong at stsci.edu (Joseph Long) Date: Fri, 9 Sep 2016 15:43:38 +0000 Subject: [Matplotlib-devel] matplotlib v1.5.3 In-Reply-To: References: Message-ID: Hi Tom, Thanks for backporting these! I'm attempting to get the folks at Continuum Analytics to provide this version in 'conda', but they say the website at http://matplotlib.org shows 1.5.1 as the latest stable release. Can you clarify, and if necessary ping the appropriate web maintainer? Thanks! -- Joseph Long From jenshnielsen at gmail.com Fri Sep 9 11:49:13 2016 From: jenshnielsen at gmail.com (Jens Nielsen) Date: Fri, 09 Sep 2016 15:49:13 +0000 Subject: [Matplotlib-devel] matplotlib v1.5.3 In-Reply-To: References: Message-ID: That would be https://github.com/matplotlib/matplotlib.github.com/issues/18 The docs needs to be rebuild for 1.5.2 On Fri, 9 Sep 2016 at 16:44 Joseph Long wrote: > Hi Tom, > > Thanks for backporting these! I'm attempting to get the folks at Continuum > Analytics to provide this version in 'conda', but they say the website at > http://matplotlib.org shows 1.5.1 as the latest stable release. Can you > clarify, and if necessary ping the appropriate web maintainer? > > Thanks! > -- > Joseph Long > > _______________________________________________ > 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 Sep 9 12:04:10 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 09 Sep 2016 16:04:10 +0000 Subject: [Matplotlib-devel] matplotlib v1.5.3 In-Reply-To: References: Message-ID: I have the 1.5.3 wheels and will upload to pypi after lunch. After that i will rebuild and upload the docs. Tom On Fri, Sep 9, 2016, 11:49 Jens Nielsen wrote: > That would be > https://github.com/matplotlib/matplotlib.github.com/issues/18 > The docs needs to be rebuild for 1.5.2 > > > > On Fri, 9 Sep 2016 at 16:44 Joseph Long wrote: > >> Hi Tom, >> >> Thanks for backporting these! I'm attempting to get the folks at Continuum >> Analytics to provide this version in 'conda', but they say the website at >> http://matplotlib.org shows 1.5.1 as the latest stable release. Can you >> clarify, and if necessary ping the appropriate web maintainer? >> >> Thanks! >> -- >> Joseph Long >> >> _______________________________________________ >> 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 Sep 9 19:03:14 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 09 Sep 2016 23:03:14 +0000 Subject: [Matplotlib-devel] v1.5.3 and v2.0.0b4 Message-ID: Folks, Source + wheels for both are up on pypi and conda forge for both is built. I will get the docs updated + annoucenments out tomorrow. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sat Sep 10 22:40:53 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 11 Sep 2016 02:40:53 +0000 Subject: [Matplotlib-devel] force-pushed to matplotlib.github.io repo Message-ID: Folks, I made a mistake uploading the 1.5.3 docs, cleaned it up and then force-pushed to the matplotlib.github.io repository. If you happened to fetch or clone it in ~the last hour be aware Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Sep 15 22:44:39 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 16 Sep 2016 02:44:39 +0000 Subject: [Matplotlib-devel] waffle-bot Message-ID: Folks, We have been half-heatedly signed up for waffle.io for a while now. They suggested we try turning on wafflebot (which I thought would just take care of assigning 'needs review' to PRs under it's account instead of Mikes), but it looks like it was doing a whole bunch more. I have uninstalled it, we probably should have a discussion about what parts of it we want to use before / if we turn it back on. Sorry for the noise! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From t at too.gy Sat Sep 17 16:45:16 2016 From: t at too.gy (tgy) Date: Sat, 17 Sep 2016 13:45:16 -0700 (MST) Subject: [Matplotlib-devel] animation in SVG In-Reply-To: <1425053384790-45021.post@n5.nabble.com> References: <1425053384790-45021.post@n5.nabble.com> Message-ID: <1474145116302-47524.post@n5.nabble.com> Hi, I am very interested in SVG animations and I would like to know how your research turned out. Thanks, -- tgy -- View this message in context: http://matplotlib.1069221.n5.nabble.com/animation-in-SVG-tp45021p47524.html Sent from the matplotlib - devel mailing list archive at Nabble.com. From tcaswell at gmail.com Sun Sep 18 15:33:35 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 18 Sep 2016 19:33:35 +0000 Subject: [Matplotlib-devel] pdf docs Message-ID: Folks, Last time I tried to build the pdf docs I ran into LaTeX exceptions that I could not sort out (to be fair I did not try super hard). Not clear if the issue is a bad/missing latex setup on my machine, there is something wrong with the docs, or it is a sphinx bug. There are two issues (one on matplotlib/matplotlib one on matplotlib/devdocs) noting that the pdf docs are missing from 1.5.3, 2.0.0b4, and devdocs. Has anyone successfully built the pdf version of the docs recently? Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Sep 19 21:39:23 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 20 Sep 2016 01:39:23 +0000 Subject: [Matplotlib-devel] mpl weekly phone calls Message-ID: Folks, We have been having weekly phone calls about matplotlib Mondays at 3pm EST (which is a not awful compromise between Hawaii and England). If you are interested in joining please let me know. If people are interested, but can not make this time we will reschedule (but do that off-list). Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Sep 19 22:24:24 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 20 Sep 2016 02:24:24 +0000 Subject: [Matplotlib-devel] new github features Message-ID: Folks, Have people had a chance to look at the new review tools on github? Do we want to work these into our workflow? It looks like we can set it so that PRs can only be merged via the web UI with at least one approve review and no 'needs work' reviews if we want. My initial reaction is we should try to use the review tools, but hold on on the engineering control on merges until we have a better sense of what that would look like. Has anyone looked at the 'projects' feature yet? A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on review add a [mrg+N] to the title to help other devs find PRs that are almost ready to merge, but need another set of eyes. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Sep 19 22:32:48 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 19 Sep 2016 19:32:48 -0700 Subject: [Matplotlib-devel] new github features In-Reply-To: References: Message-ID: Hi all, One data point, it seem that some users/dev (at least on Jupyter side) are complaining that they don't get the "grouped-review-comments" by emails. So are waiting for feedback they never get until they check the PR. Still haven't figured out when this happens. I'm curious if the "Approved" review get reset after a new commit is pushed, and If so and the N reviewer is enforced, it can be annoying if someone approved with a small condition, like typo fixed or something similar. -- M On Mon, Sep 19, 2016 at 7:24 PM, Thomas Caswell wrote: > Folks, > > Have people had a chance to look at the new review tools on github? Do we > want to work these into our workflow? It looks like we can set it so that > PRs can only be merged via the web UI with at least one approve review and > no 'needs work' reviews if we want. My initial reaction is we should try > to use the review tools, but hold on on the engineering control on merges > until we have a better sense of what that would look like. > > Has anyone looked at the 'projects' feature yet? > > A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on review > add a [mrg+N] to the title to help other devs find PRs that are almost ready > to merge, but need another set of eyes. > > Tom > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From efiring at hawaii.edu Mon Sep 19 23:00:18 2016 From: efiring at hawaii.edu (Eric Firing) Date: Mon, 19 Sep 2016 17:00:18 -1000 Subject: [Matplotlib-devel] new github features In-Reply-To: References: Message-ID: <5e9d29d9-9e95-9dc4-0d23-4b02686fc87f@hawaii.edu> On 2016/09/19 4:24 PM, Thomas Caswell wrote: > Folks, > > Have people had a chance to look at the new review tools on github? Do > we want to work these into our workflow? It looks like we can set it so > that PRs can only be merged via the web UI with at least one approve > review and no 'needs work' reviews if we want. My initial reaction is > we should try to use the review tools, but hold on on the engineering > control on merges until we have a better sense of what that would look like. I'm not a fan of this new mechanism. One of the problems is that sometimes one doesn't know at the outset whether one will be doing a thorough review, or just starting to look and make a few comments. I don't much like the automated comments it generates based on the review checkbutton, either. Making this mechanism mandatory would be quite an irritant for little or no benefit, I think. Some automated operations are good. For example, if a "closes #1234" in an obvious location in a PR causes #1234 to be closed when the PR is merged, that's good. Unfortunately, I haven't figured out how this works--it seems like sometimes it does, sometimes it doesn't. Presumably I just don't know the rule github is using. So here, a better design would be a box in the PR specifically for linking in "closes" issue numbers. Thumbs-up emoji counts are not helpful; I need to look to see whose thumb it is, and then I'm still left wondering exactly what was being approved. And was it a thoughtful approval, or just a twitch? So overall, with my usual curmudgeon's hat on, covering my small brain, I favor keeping the automation simple, obvious, and fairly minimal. For everything else, let's use normal human communications, not bots. > > Has anyone looked at the 'projects' feature yet? Haven't looked. Should I? > > A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on > review add a [mrg+N] to the title to help other devs find PRs that are > almost ready to merge, but need another set of eyes. Aha! So that's what those are! The "N" is the number of eye-sets needed? I don't object to having a few conventions like that. If it ends up helping us cut down the open PR and issue counts, that would be great. Conventions are better than bots. Eric From story645 at gmail.com Tue Sep 20 12:40:03 2016 From: story645 at gmail.com (Hannah) Date: Tue, 20 Sep 2016 12:40:03 -0400 Subject: [Matplotlib-devel] new github features In-Reply-To: References: Message-ID: I think the projects board (it looks like a trello type thing) could be a good way to organize MEPs and/or new feature requests with a lot of moving pieces (like the categorical work...) On Mon, Sep 19, 2016 at 10:24 PM, Thomas Caswell wrote: > Folks, > > Have people had a chance to look at the new review tools on github? Do we > want to work these into our workflow? It looks like we can set it so that > PRs can only be merged via the web UI with at least one approve review and > no 'needs work' reviews if we want. My initial reaction is we should try > to use the review tools, but hold on on the engineering control on merges > until we have a better sense of what that would look like. > > Has anyone looked at the 'projects' feature yet? > > A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on > review add a [mrg+N] to the title to help other devs find PRs that are > almost ready to merge, but need another set of eyes. > > 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 bussonniermatthias at gmail.com Tue Sep 20 13:10:15 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Tue, 20 Sep 2016 10:10:15 -0700 Subject: [Matplotlib-devel] new github features In-Reply-To: <5e9d29d9-9e95-9dc4-0d23-4b02686fc87f@hawaii.edu> References: <5e9d29d9-9e95-9dc4-0d23-4b02686fc87f@hawaii.edu> Message-ID: Hi Eric, > Some automated operations are good. For example, if a "closes #1234" in an obvious location in a PR causes #1234 to be closed when the PR is merged, that's good. Unfortunately, I haven't figured out how this works--it seems like sometimes it does, sometimes it doesn't. Presumably I just don't know the rule github is using. So here, a better design would be a box in the PR specifically for linking in "closes" issue numbers. I can inform you on that. It has to be in one of the _commit message_, once the commit is in master the PR get closed. It is confusing as when there is a single commit, GitHub make the the default for the pull-request description, but being in the commit allows you to close issues by pushing directly on master (for project that do it). See https://help.github.com/articles/closing-issues-via-commit-messages/ Cheers, -- M On Mon, Sep 19, 2016 at 8:00 PM, Eric Firing wrote: > On 2016/09/19 4:24 PM, Thomas Caswell wrote: >> >> Folks, >> >> Have people had a chance to look at the new review tools on github? Do >> we want to work these into our workflow? It looks like we can set it so >> that PRs can only be merged via the web UI with at least one approve >> review and no 'needs work' reviews if we want. My initial reaction is >> we should try to use the review tools, but hold on on the engineering >> control on merges until we have a better sense of what that would look >> like. > > > I'm not a fan of this new mechanism. One of the problems is that sometimes > one doesn't know at the outset whether one will be doing a thorough review, > or just starting to look and make a few comments. I don't much like the > automated comments it generates based on the review checkbutton, either. > Making this mechanism mandatory would be quite an irritant for little or no > benefit, I think. > > Some automated operations are good. For example, if a "closes #1234" in an > obvious location in a PR causes #1234 to be closed when the PR is merged, > that's good. Unfortunately, I haven't figured out how this works--it seems > like sometimes it does, sometimes it doesn't. Presumably I just don't know > the rule github is using. So here, a better design would be a box in the PR > specifically for linking in "closes" issue numbers. > > Thumbs-up emoji counts are not helpful; I need to look to see whose thumb it > is, and then I'm still left wondering exactly what was being approved. And > was it a thoughtful approval, or just a twitch? > > So overall, with my usual curmudgeon's hat on, covering my small brain, I > favor keeping the automation simple, obvious, and fairly minimal. For > everything else, let's use normal human communications, not bots. > >> >> Has anyone looked at the 'projects' feature yet? > > Haven't looked. Should I? >> >> >> A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on >> review add a [mrg+N] to the title to help other devs find PRs that are >> almost ready to merge, but need another set of eyes. > > > Aha! So that's what those are! The "N" is the number of eye-sets needed? > I don't object to having a few conventions like that. If it ends up helping > us cut down the open PR and issue counts, that would be great. > Conventions are better than bots. > > Eric > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From rmay31 at gmail.com Wed Sep 21 17:14:33 2016 From: rmay31 at gmail.com (Ryan May) Date: Wed, 21 Sep 2016 15:14:33 -0600 Subject: [Matplotlib-devel] new github features In-Reply-To: References: Message-ID: Hi, In general, given the griping I've seen over time for how hard it is to do code review on GitHub Pull Requests, I think we (the open source community) owe it to GitHub to try out the new feature they rolled out to address and give them feedback--that's the only way the feature can ever meet our needs. For our (matplotlib) case, I think we get a few good gains: - line comments are batched so we can cut down on the number of notifications - Your work is saved so you can come back later and finish--and adjust when you see something later that invalidates your comment *before* commenting for all to see - Reviews are atomic items, so you can get an idea of what a specific reviewer thinks (and not lose pieces) - By having the state of Approved/Needs Changes actually tracked, there's no need to read through the entire PR to see what objections are left. (Granted, it does mean people have to come back and approve it once the changes are made) Seems like a lot to gain for little to no extra effort--having used it, I certainly fail to see any problem. The matter of turning on required reviews for protected branches is a whole other matter, though I will say you can always let admins override. Ryan On Mon, Sep 19, 2016 at 8:24 PM, Thomas Caswell wrote: > Folks, > > Have people had a chance to look at the new review tools on github? Do we > want to work these into our workflow? It looks like we can set it so that > PRs can only be merged via the web UI with at least one approve review and > no 'needs work' reviews if we want. My initial reaction is we should try > to use the review tools, but hold on on the engineering control on merges > until we have a better sense of what that would look like. > > Has anyone looked at the 'projects' feature yet? > > A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on > review add a [mrg+N] to the title to help other devs find PRs that are > almost ready to merge, but need another set of eyes. > > Tom > > _______________________________________________ > 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 rmay31 at gmail.com Wed Sep 21 17:26:57 2016 From: rmay31 at gmail.com (Ryan May) Date: Wed, 21 Sep 2016 15:26:57 -0600 Subject: [Matplotlib-devel] new github features In-Reply-To: References: Message-ID: Matthias, Regarding the emails, could this be due to notification settings? I notice that PR reviews are a separate item you have to check in the notification center. Ryan On Mon, Sep 19, 2016 at 8:32 PM, Matthias Bussonnier < bussonniermatthias at gmail.com> wrote: > Hi all, > > One data point, it seem that some users/dev (at least on Jupyter side) > are complaining that they don't get the "grouped-review-comments" by > emails. So are waiting for feedback they never get until they check > the PR. > > Still haven't figured out when this happens. > > I'm curious if the "Approved" review get reset after a new commit is > pushed, and If so and the N reviewer is enforced, it can be annoying > if someone approved with a small condition, like typo fixed or > something similar. > -- > M > > On Mon, Sep 19, 2016 at 7:24 PM, Thomas Caswell > wrote: > > Folks, > > > > Have people had a chance to look at the new review tools on github? Do > we > > want to work these into our workflow? It looks like we can set it so > that > > PRs can only be merged via the web UI with at least one approve review > and > > no 'needs work' reviews if we want. My initial reaction is we should > try > > to use the review tools, but hold on on the engineering control on merges > > until we have a better sense of what that would look like. > > > > Has anyone looked at the 'projects' feature yet? > > > > A suggestion from Nelle Varoquaux is to follow skimage/sklearn and on > review > > add a [mrg+N] to the title to help other devs find PRs that are almost > ready > > to merge, but need another set of eyes. > > > > 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 > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelle.varoquaux at gmail.com Fri Sep 30 12:32:28 2016 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Fri, 30 Sep 2016 09:32:28 -0700 Subject: [Matplotlib-devel] BIDS machine shop & matplotlib Message-ID: Hello matplotlib-devs ! As some of you may know, I am involved with St?fan van der Walt in an initiative around Berkeley campus known as the "BIDS Machine Shop". It consists of trying to bridge the gap in software development and best practises around campus by introducing undergraduates to research software development and open source communities. St?fan and I will manage students on different research projects and open source packages, including matplotlib and scikit-image. I'll be managing the matplotlib side of the machine shop, and you should see (I hope) a bunch of contributions from our students popping up on github. I am going to create a label "Machine Shop" and a project "Machine Shop" for the duration of the semester (maybe longer if this experiment is a success). I'll assign "easy fix" tickets to our students. I expect them to do peer-review before opening the PRs for broader reviews. Please, wait for the tag "need review" to be set on those PR before reviewing theme. Once they fixed these issues, I'll assign them to more complex tasks. If you have questions/suggestions, don't hesitate to chime in. Thanks, Nelle PS: we should have a website up and running soon with more details. From pmhobson at gmail.com Fri Sep 30 14:15:48 2016 From: pmhobson at gmail.com (Paul Hobson) Date: Fri, 30 Sep 2016 11:15:48 -0700 Subject: [Matplotlib-devel] BIDS machine shop & matplotlib In-Reply-To: References: Message-ID: Nelle, I think the "needs review" tag is automatically added. I might be wrong though. -p On Fri, Sep 30, 2016 at 9:32 AM, Nelle Varoquaux wrote: > Hello matplotlib-devs ! > > As some of you may know, I am involved with St?fan van der Walt in an > initiative around Berkeley campus known as the "BIDS Machine Shop". It > consists of trying to bridge the gap in software development and best > practises around campus by introducing undergraduates to research > software development and open source communities. > St?fan and I will manage students on different research projects and > open source packages, including matplotlib and scikit-image. I'll be > managing the matplotlib side of the machine shop, and you should see > (I hope) a bunch of contributions from our students popping up on > github. > > I am going to create a label "Machine Shop" and a project "Machine > Shop" for the duration of the semester (maybe longer if this > experiment is a success). I'll assign "easy fix" tickets to our > students. I expect them to do peer-review before opening the PRs for > broader reviews. Please, wait for the tag "need review" to be set on > those PR before reviewing theme. Once they fixed these issues, I'll > assign them to more complex tasks. > > If you have questions/suggestions, don't hesitate to chime in. > > Thanks, > Nelle > > PS: we should have a website up and running soon with more details. > _______________________________________________ > 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 nelle.varoquaux at gmail.com Fri Sep 30 14:20:00 2016 From: nelle.varoquaux at gmail.com (Nelle Varoquaux) Date: Fri, 30 Sep 2016 11:20:00 -0700 Subject: [Matplotlib-devel] BIDS machine shop & matplotlib In-Reply-To: References: Message-ID: On 30 September 2016 at 11:15, Paul Hobson wrote: > Nelle, > > I think the "needs review" tag is automatically added. I might be wrong > though. Yes. I plan on removing it by hand everytime one of my students open a PR not ready to be merged. It is going to be painful, but I don't see any other way? I actually think it is slightly problematic to have it added automatically. A bunch of PRs are not ready to be merged or review, and not many people remove the tag after reviewing if changes need to be applied. That means most of our PRs have this tag, so it is hard to identify the one that actually need to be reviewed. Chers, N > -p > > On Fri, Sep 30, 2016 at 9:32 AM, Nelle Varoquaux > wrote: >> >> Hello matplotlib-devs ! >> >> As some of you may know, I am involved with St?fan van der Walt in an >> initiative around Berkeley campus known as the "BIDS Machine Shop". It >> consists of trying to bridge the gap in software development and best >> practises around campus by introducing undergraduates to research >> software development and open source communities. >> St?fan and I will manage students on different research projects and >> open source packages, including matplotlib and scikit-image. I'll be >> managing the matplotlib side of the machine shop, and you should see >> (I hope) a bunch of contributions from our students popping up on >> github. >> >> I am going to create a label "Machine Shop" and a project "Machine >> Shop" for the duration of the semester (maybe longer if this >> experiment is a success). I'll assign "easy fix" tickets to our >> students. I expect them to do peer-review before opening the PRs for >> broader reviews. Please, wait for the tag "need review" to be set on >> those PR before reviewing theme. Once they fixed these issues, I'll >> assign them to more complex tasks. >> >> If you have questions/suggestions, don't hesitate to chime in. >> >> Thanks, >> Nelle >> >> PS: we should have a website up and running soon with more details. >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > From efiring at hawaii.edu Fri Sep 30 14:41:29 2016 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 30 Sep 2016 08:41:29 -1000 Subject: [Matplotlib-devel] BIDS machine shop & matplotlib In-Reply-To: References: Message-ID: On 2016/09/30 8:20 AM, Nelle Varoquaux wrote: > I actually think it is slightly problematic to have it added > automatically. A bunch of PRs are not ready to be merged or review, > and not many people remove the tag after reviewing if changes need to > be applied. That means most of our PRs have this tag, so it is hard to > identify the one that actually need to be reviewed. I agree. Automatic adding of this tag is pointless, not helpful, as far as I can see. Eric From efiring at hawaii.edu Fri Sep 30 22:51:18 2016 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 30 Sep 2016 16:51:18 -1000 Subject: [Matplotlib-devel] encoders for animations Message-ID: <94e0e688-44a8-6132-c662-6bada1c842d6@hawaii.edu> For making video files the animation module presently supports ffmpeg (the default), avconv (a fork of ffmpeg), and mencoder. Does anyone use mencoder? If so, why? And would you be seriously inconvenienced or otherwise harmed if we ended our only partially successful support of mencoder as an option in the animation module? Thank you. Eric