matplotlib-devel Mailing List for matplotlib (Page 5)

Hi Ben and Joe,
I will be there for the tutorials doing the shell part of software
carpentry but I am available to help you with the matplotlib tutorial if
you can use any additional help
Jens
tir. 31. mar. 2015 kl. 17.07 skrev Jens Nielsen <jen...@gm...>:
> Hi
>
> I am expecting to be at Scipy but I have already volunteered to help out
> with the Software carpentry tutorials.
> I have the impression that they might have more helpers than needed in
> which case I would be happy to help with the Matplotlib tutorials.
>
> Jens
>
>
>
> tir. 31. mar. 2015 kl. 16.45 skrev Benjamin Root <ben...@ou...>:
>
>> Joe, it would be great to have you as a co-presenter.
>>
>> Nelle, I am guessing I should contact Krystyn to update my proposal to
>> include Joe?
>>
>> Ben
>>
>> On Mon, Mar 30, 2015 at 8:45 PM, Joe Kington <jof...@gm...>
>> wrote:
>>
>>> High praise, coming from you guys. Thanks! :)
>>> -Joe
>>>
>>> On Mon, Mar 30, 2015 at 6:53 PM, Paul Hobson <pmh...@gm...> wrote:
>>>
>>>> Joe,
>>>>
>>>> You should introduce yourself as "that guy who did that paw detection
>>>> post that saved that one guy's research".
>>>> -P
>>>>
>>>> —
>>>> Sent from Mailbox <https://www.dropbox.com/mailbox>
>>>>
>>>>
>>>> On Mon, Mar 30, 2015 at 4:52 PM, Thomas Caswell <tca...@gm...>
>>>> wrote:
>>>>
>>>>> +1 from me. I suspect many people got their start learning mpl from
>>>>> you on SO ;)
>>>>>
>>>>> Tom
>>>>>
>>>>> On Mon, Mar 30, 2015 at 7:17 PM Joe Kington <jof...@gm...>
>>>>> wrote:
>>>>>
>>>>>> If you don't mind a "non-core" person doing the tutorial, I'll be
>>>>>> there this year, and I'd be happy to be Ben's backup for teaching it.
>>>>>> Cheers!
>>>>>> -Joe
>>>>>>
>>>>>> On Sun, Mar 29, 2015 at 9:17 PM, Thomas Caswell <tca...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Ben,
>>>>>>>
>>>>>>> Have you sorted out if you can make scipy this year and does anyone
>>>>>>> want to be back up on teaching the tutorial?
>>>>>>>
>>>>>>> It seems a shame to not have a mpl tutorial available.
>>>>>>>
>>>>>>> I am probably going to submit a 'state of the library' talk and do
>>>>>>> not want to do both.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> On Thu, Mar 26, 2015 at 5:06 PM Michael Droettboom <md...@st...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This sounds great. Unfortunately, I can't attend Scipy this year
>>>>>>>> due to a family commitment, but would be more than happy to help put
>>>>>>>> together and review materials beforehand.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/26/2015 10:59 AM, Thomas Caswell wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I also think we should have a 'state of the library' talk.
>>>>>>>>
>>>>>>>> We definitely have a few important things to announce/show off:
>>>>>>>> - FSA
>>>>>>>> - nbagg/notebook
>>>>>>>> - new default colors
>>>>>>>> - style module
>>>>>>>>
>>>>>>>> and should have a couple more by July
>>>>>>>> - sane serialize/deserialize + interop with plotly/bokeh
>>>>>>>> - better toolbar
>>>>>>>> - better interactive OO
>>>>>>>> - improved docs
>>>>>>>>
>>>>>>>> I will be there for the main conference and the sprints and am
>>>>>>>> willing to give this talk, but will defer if someone else wants to do it.
>>>>>>>>
>>>>>>>> Does anyone want to volunteer to be Ben's second on his tutorial?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 13, 2015 at 2:46 PM Olga Botvinnik <obo...@uc...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'd be very interested in hearing a "state of matplotlib" talk.
>>>>>>>>>
>>>>>>>>> On Fri, Mar 13, 2015, 11:29 Phil Elson <pel...@gm...>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Orchestrating MPL tutorials and talks in this thread would be a
>>>>>>>>>> good idea. I'd be happy to help anybody planning on submitting anything
>>>>>>>>>> relating specifically to matplotlib, and wonder if we should do a "state of
>>>>>>>>>> matplotlib" type talk similar to the one Mike did 2 years ago.
>>>>>>>>>>
>>>>>>>>>> On 13 March 2015 at 02:05, Benjamin Root <ben...@ou...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yes, I plan to submit my time-honored, and requested "Anatomy
>>>>>>>>>>> of Matplotlib" tutorial. Now, I am not entirely sure I will be able to
>>>>>>>>>>> attend the conference this year, so perhaps someone else might be willing
>>>>>>>>>>> to step in and give it this year?
>>>>>>>>>>>
>>>>>>>>>>> Note that my tutorial is geared for beginners. So there is still
>>>>>>>>>>> plenty of opportunity for someone else to submit a tutorial for more
>>>>>>>>>>> advanced users!
>>>>>>>>>>>
>>>>>>>>>>> Cheers!
>>>>>>>>>>> Ben Root
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 12, 2015 at 6:46 PM, Nelle Varoquaux <
>>>>>>>>>>> nel...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> Is someone submitting a tutorial on matplotlib? The call for
>>>>>>>>>>>> tutorial is open, and I think it would be nice to have one on matplotlib.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> N
>>>>>>>>>>>>
>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>> From: SciPy 2015 Organizers <sci...@sc...>
>>>>>>>>>>>> Date: 11 March 2015 at 01:02
>>>>>>>>>>>> Subject: SciPy 2015 CFP Email 2
>>>>>>>>>>>> To: nel...@gm...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [image: SciPy 2015 Logo]
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>>>>>>>>>>>>
>>>>>>>>>>>> Tick-Tock, Tick-Tock:
>>>>>>>>>>>> T-Minus 6 Days for Tutorial Submissions
>>>>>>>>>>>> *Due Date: March 16, 2015*
>>>>>>>>>>>>
>>>>>>>>>>>> The SciPy experience kicks off with two days of tutorials
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259288/%7CQ%7C>
>>>>>>>>>>>> (July 6-7). These sessions provide extremely affordable access to expert
>>>>>>>>>>>> training, and consistently receive fantastic feedback from participants.
>>>>>>>>>>>> We're looking for submissions on topics from introductory to advanced -
>>>>>>>>>>>> we'll have attendees across the gamut looking to learn. Plus, you can earn
>>>>>>>>>>>> an instructor stipend to apply towards your conference participation. Visit
>>>>>>>>>>>> the SciPy 2015 website for details
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org>
>>>>>>>>>>>> or submit a proposal here
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> Submit a Tutorial Proposal Here
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969> Talk
>>>>>>>>>>>> and Poster Proposals Due April 1st
>>>>>>>>>>>>
>>>>>>>>>>>> There's always something new and exciting going on in the world
>>>>>>>>>>>> of Science + Python, this is your chance to get up and talk about it!
>>>>>>>>>>>>
>>>>>>>>>>>> *Visit the SciPy 2015 website
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>>>>>>>>>>>> for full details or click here to submit a proposal
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>.*
>>>>>>>>>>>> Choose a topic in one of the 3 main conference tracks:
>>>>>>>>>>>>
>>>>>>>>>>>> - Scientific Computing in Python (General track)
>>>>>>>>>>>> - Python in Data Science
>>>>>>>>>>>> - Quantitative and Computational Social Sciences
>>>>>>>>>>>>
>>>>>>>>>>>> * And/or submit for one of the 7 domain-specific mini-symposia
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>:*
>>>>>>>>>>>>
>>>>>>>>>>>> - Astronomy and astrophysics
>>>>>>>>>>>> - Computational life and medical sciences
>>>>>>>>>>>> - Engineering
>>>>>>>>>>>> - Geographic information systems (GIS)
>>>>>>>>>>>> - Geophysics
>>>>>>>>>>>> - Oceanography and meteorology
>>>>>>>>>>>> - Visualization, vision and imaging
>>>>>>>>>>>>
>>>>>>>>>>>> Submit a Talk or Poster Proposal Here
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969> Need
>>>>>>>>>>>> some inspiration? Follow @SciPy on Twitter
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=https://twitter.com/scipyconf>
>>>>>>>>>>>> for highlights from previous SciPy conferences and all of the latest 2015
>>>>>>>>>>>> updates.
>>>>>>>>>>>>
>>>>>>>>>>>> - Previous year's conferences with talk information
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://conference.scipy.org/past.html>
>>>>>>>>>>>> - SciPy 2014 Talk & Tutorial Video playlist
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog>
>>>>>>>>>>>> - SciPy 2013 Talk & Tutorial Video playlist
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GeTWcUQTbXVdllyp-Ie3r-y>
>>>>>>>>>>>>
>>>>>>>>>>>> Financial Scholarship Applications Now Being Accepted
>>>>>>>>>>>>
>>>>>>>>>>>> With the support of our sponsors, the SciPy conference provides
>>>>>>>>>>>> financial assistance to attendees based on both community contribution and
>>>>>>>>>>>> financial need.
>>>>>>>>>>>>
>>>>>>>>>>>> In 2014 we were able to support 19 applicants, including 5
>>>>>>>>>>>> diversity aid recipients, selected for their outstanding contributions to
>>>>>>>>>>>> open source scientific Python projects. *If you'd like to be
>>>>>>>>>>>> considered for financial scholarship, please apply here
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259279/?&>
>>>>>>>>>>>> before April 15, 2015.*
>>>>>>>>>>>> Sponsor Thank Yous! We gratefully recognize our SciPy
>>>>>>>>>>>> conference sponsors, whose contributions ensure the accessibility of the
>>>>>>>>>>>> conference and growth of the important work being done by the scientific
>>>>>>>>>>>> Python community.
>>>>>>>>>>>>
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=www.kitware.com>
>>>>>>>>>>>>
>>>>>>>>>>>> *This week's sponsor highlight is silver sponsor, Kitware:*
>>>>>>>>>>>> * Kitware, Inc. is a leader in the creation and support of
>>>>>>>>>>>> open-source software and state of the art technology. By fostering
>>>>>>>>>>>> extended, collaborative communities, Kitware is able to provide flexible,
>>>>>>>>>>>> cost-effective visualization, computer vision, medical imaging, data
>>>>>>>>>>>> publishing, and quality software process solutions to a variety of academic
>>>>>>>>>>>> and government institutions and private corporations worldwide.*
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>> Know a company that might want to sponsor SciPy 2015 or provide
>>>>>>>>>>>> scholarship funding? Share the sponsorship prospectus
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259285/?&>
>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>> To unsubscribe from this mailing list, please click here
>>>>>>>>>>>> <https://www.eiseverywhere.com/emarketing/profile.php?id=BctbGJi3EKrTogVy7ttdnrT0TTsw6Zr%2FRzGhBzBXaDM%3D>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> ------------------
>>>>>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>>>>>> Website, sponsored
>>>>>>>>>>>> by Intel and developed in partnership with Slashdot Media, is
>>>>>>>>>>>> your hub for all
>>>>>>>>>>>> things parallel software development, from weekly thought
>>>>>>>>>>>> leadership blogs to
>>>>>>>>>>>> news, videos, case studies, tutorials and more. Take a look and
>>>>>>>>>>>> join the
>>>>>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>>>>> Mat...@li...
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>> ------------------
>>>>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>>>>> Website, sponsored
>>>>>>>>>>> by Intel and developed in partnership with Slashdot Media, is
>>>>>>>>>>> your hub for all
>>>>>>>>>>> things parallel software development, from weekly thought
>>>>>>>>>>> leadership blogs to
>>>>>>>>>>> news, videos, case studies, tutorials and more. Take a look and
>>>>>>>>>>> join the
>>>>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>>>> Mat...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>> ------------------
>>>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>>>> Website, sponsored
>>>>>>>>>> by Intel and developed in partnership with Slashdot Media, is
>>>>>>>>>> your hub for all
>>>>>>>>>> things parallel software development, from weekly thought
>>>>>>>>>> leadership blogs to
>>>>>>>>>> news, videos, case studies, tutorials and more. Take a look and
>>>>>>>>>> join the
>>>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>>> Mat...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ------------------
>>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>>> Website, sponsored
>>>>>>>>> by Intel and developed in partnership with Slashdot Media, is your
>>>>>>>>> hub for all
>>>>>>>>> things parallel software development, from weekly thought
>>>>>>>>> leadership blogs to
>>>>>>>>> news, videos, case studies, tutorials and more. Take a look and
>>>>>>>>> join the
>>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>> _______________________________________________
>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>> Mat...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>>>>>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>>>>>>> things parallel software development, from weekly thought leadership blogs to
>>>>>>>> news, videos, case studies, tutorials and more. Take a look and join the
>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ------------------
>>>>>>>> Dive into the World of Parallel Programming The Go Parallel
>>>>>>>> Website, sponsored
>>>>>>>> by Intel and developed in partnership with Slashdot Media, is your
>>>>>>>> hub for all
>>>>>>>> things parallel software development, from weekly thought
>>>>>>>> leadership blogs to
>>>>>>>> news, videos, case studies, tutorials and more. Take a look and
>>>>>>>> join the
>>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>>> _______________________________________________
>>>>>>>> Matplotlib-devel mailing list
>>>>>>>> Mat...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------
>>>>>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>>>>>> sponsored
>>>>>>> by Intel and developed in partnership with Slashdot Media, is your
>>>>>>> hub for all
>>>>>>> things parallel software development, from weekly thought leadership
>>>>>>> blogs to
>>>>>>> news, videos, case studies, tutorials and more. Take a look and join
>>>>>>> the
>>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-devel mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

On Jun 17, 2015 8:36 AM, "OceanWolf" <jui...@ya...> wrote:
>
> Another question, why does a reason exist why the colour-maps start at
yellow and go to blue, either anti-clockwise, or clockwise? What about a
rotation of 90deg rather than just a mirror inverse on the a' b' plane?
Colorblind users can reliably distinguish blue/yellow and dark/light, but
that's all, so an accessible colormap has to use those for its dominant
axis. And then you have to do dark+bluish and light+yellowish if you want
something colorful, because it just turns out that the way the brain works,
there is no such thing as a saturated light blue or a saturated dark yellow.
-n

Ooh, I do like Eric's v2, I see much more of a fall off in the sample images, so I would say v2 > D > ?
Any chance of the galaxy animation with v2?
Another question, why does a reason exist why the colour-maps start at yellow and go to blue, either anti-clockwise, or clockwise? What about a rotation of 90deg rather than just a mirror inverse on the a' b' plane?

I think I mean that before we cherrypicked from master to colouroverhaul, as we only wanted a few things from master to go out in the next release, but now if I understand correctly we want most of master to go out in the next release, so we have to uncherrypick out the stuff we don't want, and I fear that such a branch won't have had the rigorous testing that the current color-overhaul branch has had. Metaphorically speaking we have a mixture of different fluids that have settled into clear stratified layers, now we plan to give that mixture a good shake and hope we don't break everything.
Meh, perhaps I just act too overcautious.
________________________________
From: Thomas Caswell <tca...@gm...>
To: OceanWolf <jui...@ya...>; "mat...@li..." <mat...@li...> 
Sent: Wednesday, 17 June 2015, 6:04
Subject: Re: [matplotlib-devel] Release schedule
I am not sure what you mean by cherry-picking/uncherry picking. I just looked at what is on `color_overhaul` which is not in master and it is: changes that should be discarded (changes to cxx / changes to _tri.* that rely on cxx), one change related to mathtext layout (and conflicts due to mathext_*68 being added on both branches) which we do not want to cherry pick, and documentation about pkg-config and a minor doc which will be easy to cherry-pick (I am going to do in now).
There is documentation about the coming color change in master, but that is probably ok to include in a point release (as it is just plans).
In either case the 2.0 release will contain _only_ style related API breaks and will be based on what ever the last point release was.
Tom
On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...> wrote:
The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work in uncherrypicking recherrypicking. Given the amount of testing that both master and color-overhaul have gone through by us devs and other interested people, I feel it perhaps better to keep the release schedule as it was.
>
>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and then depreciate (or fully-remove) in 2.0, but personally I opt for safety over nicety (plus it gives us more time to get MEP22/27 completed and have time for more people to test it, find bugs, though I doubt we will have any O:)).
>
>
>Best,
>OceanWolf
>

I am not sure what you mean by cherry-picking/uncherry picking. I just
looked at what is on `color_overhaul` which is not in master and it is:
changes that should be discarded (changes to cxx / changes to _tri.* that
rely on cxx), one change related to mathtext layout (and conflicts due to
mathext_*68 being added on both branches) which we do not want to cherry
pick, and documentation about pkg-config and a minor doc which will be easy
to cherry-pick (I am going to do in now).
There is documentation about the coming color change in master, but that is
probably ok to include in a point release (as it is just plans).
In either case the 2.0 release will contain _only_ style related API breaks
and will be based on what ever the last point release was.
Tom
On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...>
wrote:
> The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra
> work in uncherrypicking recherrypicking. Given the amount of testing that
> both master and color-overhaul have gone through by us devs and other
> interested people, I feel it perhaps better to keep the release schedule as
> it was.
>
> From the perspective of working on MEP22/27 it would feel nice to do a 1.5
> and then depreciate (or fully-remove) in 2.0, but personally I opt for
> safety over nicety (plus it gives us more time to get MEP22/27 completed
> and have time for more people to test it, find bugs, though I doubt we will
> have any O:)).
>
>
> Best,
> OceanWolf
>

On Jun 16, 2015 7:31 PM, "Juan Nunez-Iglesias" <jni...@gm...> wrote:
>
> As long as A and B are included as named options, I have no objections to
D as default.
Yeah, all the colormaps will be available over way or another, it's just
the default in question.
-n

As long as A and B are included as named options, I have no objections to D
as default. (From a branding perspective though, I preferred being closer
to GNUPlot than Matlab, but whatevs. Show MPL's roots I guess! =)
Juan.
On Wed, Jun 17, 2015 at 12:14 PM, Nathaniel Smith <nj...@po...> wrote:
> Greetings, matplotliberators!
>
> I've counted up the various "votes" people made regarding the
> different colormap options at
> https://bids.github.io/colormap
> including the ones in the matplotlib-devel and -users threads and
> elsewhere (private email, twitter), etc.
>
> There were two phases -- some people saw A/B/C, and some saw A/B/C/D,
> so I'll separate the votes into those two groups. It's a bit
> complicated to break down, also, because people expressed preferences
> with different degrees of specificity ("I like X" vs total order vs
> partial order...).
>
> ----------- Round 1 votes -----------
>
> For those comparing A/B/C, the number of people with different preferences
> were:
>
> First choice A: 6 votes
> Of which:
> A > C > B got 1 vote
> A > B > C got 2 votes
>
> First choice B: 8 votes
> Of which:
> B > A > C got 3 votes
> B > C > A got 1 vote
>
> First choice C: 7 votes
> Of which:
> C > A > B got 1 vote
> C > B > A got 4 votes
>
> ----------- end of round 1 votes -----------
>
> Then we added option D.
>
> ----------- Round 2 votes -----------
>
> For those comparing A/B/C/D, the number of people with different
> preferences were:
>
> First choice A: 0 votes
>
> First choice B: 2 votes
> Of which:
> B > A > C/D got 1 vote
>
> First choice C: 1 votes
> Of which:
> C > D > A/B got 1 vote
>
> First choice D: 12 votes
> Of which:
> D > C > A/B got 1 vote
> D > A > C > B got 1 vote
>
> ----------- end of round 2 votes -----------
>
> It seems that voting works better in some cases than others.
>
> So the next question is where we go from here. We need to pick a color
> for this bikeshed at some point. One theory is that the next step is
> to propose a bunch of variations on option D and have another round of
> voting etc. Another is that we should just call it a day and decide
> now :-).
>
> For reference, here's option D:
> https://bids.github.io/colormap/images/screenshots/option_d.png
>
> And here are the other greenish colormaps that have been mentioned:
> https://bids.github.io/colormap/images/screenshots/fake_parula.png
>
> https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png
>
> https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png
>
> https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png
>
> My personal feeling is that all these alternatives are basically
> reasonable colormaps, but compared to option D I find them kinda ugly,
> and, more importantly, substantially worse for colorblind users, which
> IMO should outweigh a marginal/debateable improvement for the rest of
> us.
>
> So if it were up to me I'd be inclined to declare we've reached the
> point of diminishing returns and go with D, but I don't know how
> everyone else is feeling. Shall we just go for it?
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

As a heads up, there is now a `pyplot` and a `pylab` packages on pypi.
I have created an issue with the pypi folks
https://sourceforge.net/p/pypi/support-requests/512/
and with both projects
https://github.com/javipalanca/pylab/issues/1
https://github.com/sirrice/pyplot/issues/2
I found both of these via SO questions so I suspect that there is a coming
wave of confused new users who did `pip install pyplot` or `pip install
pylab`.
Tom

Greetings, matplotliberators!
I've counted up the various "votes" people made regarding the
different colormap options at
 https://bids.github.io/colormap
including the ones in the matplotlib-devel and -users threads and
elsewhere (private email, twitter), etc.
There were two phases -- some people saw A/B/C, and some saw A/B/C/D,
so I'll separate the votes into those two groups. It's a bit
complicated to break down, also, because people expressed preferences
with different degrees of specificity ("I like X" vs total order vs
partial order...).
----------- Round 1 votes -----------
For those comparing A/B/C, the number of people with different preferences were:
First choice A: 6 votes
 Of which:
 A > C > B got 1 vote
 A > B > C got 2 votes
First choice B: 8 votes
 Of which:
 B > A > C got 3 votes
 B > C > A got 1 vote
First choice C: 7 votes
 Of which:
 C > A > B got 1 vote
 C > B > A got 4 votes
----------- end of round 1 votes -----------
Then we added option D.
----------- Round 2 votes -----------
For those comparing A/B/C/D, the number of people with different
preferences were:
First choice A: 0 votes
First choice B: 2 votes
 Of which:
 B > A > C/D got 1 vote
First choice C: 1 votes
 Of which:
 C > D > A/B got 1 vote
First choice D: 12 votes
 Of which:
 D > C > A/B got 1 vote
 D > A > C > B got 1 vote
----------- end of round 2 votes -----------
It seems that voting works better in some cases than others.
So the next question is where we go from here. We need to pick a color
for this bikeshed at some point. One theory is that the next step is
to propose a bunch of variations on option D and have another round of
voting etc. Another is that we should just call it a day and decide
now :-).
For reference, here's option D:
 https://bids.github.io/colormap/images/screenshots/option_d.png
And here are the other greenish colormaps that have been mentioned:
 https://bids.github.io/colormap/images/screenshots/fake_parula.png
 https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png
 https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png
 https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png
My personal feeling is that all these alternatives are basically
reasonable colormaps, but compared to option D I find them kinda ugly,
and, more importantly, substantially worse for colorblind users, which
IMO should outweigh a marginal/debateable improvement for the rest of
us.
So if it were up to me I'd be inclined to declare we've reached the
point of diminishing returns and go with D, but I don't know how
everyone else is feeling. Shall we just go for it?
-n
-- 
Nathaniel J. Smith -- http://vorpus.org

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work in uncherrypicking recherrypicking. Given the amount of testing that both master and color-overhaul have gone through by us devs and other interested people, I feel it perhaps better to keep the release schedule as it was.
>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and then depreciate (or fully-remove) in 2.0, but personally I opt for safety over nicety (plus it gives us more time to get MEP22/27 completed and have time for more people to test it, find bugs, though I doubt we will have any O:)).
Best,
OceanWolf

Following up on the last email, I would like to aim for a 1.5 release at
the end of July, with the sprint at scipy being focused on finishing it
off. The 2.0 color/style release will happen (hopefully soon) after that.
Does this schedule seem ok to everyone?
I have started to triage the issues/PRs tagged as 'next point release', if
anyone has issues/PRs they consider blockers please tag them as release
critical or leave a note.
Tom

I think that worked! I made a PR:
https://github.com/matplotlib/matplotlib/pull/4530
On Mon, Jun 15, 2015 at 9:50 AM, Benjamin Root <ben...@ou...> wrote:
> No, I did not try that one. I'll give it a shot. I don't do any Tkinter
> programming, so I wasn't familiar with that one.
>
> On Mon, Jun 15, 2015 at 9:23 AM, Joe Kington <jof...@gm...>
> wrote:
>
>>
>>
>> On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
>>
>>> That's the weird thing... I couldn't! I tried a few different things and
>>> I couldn't make it go away. I'll probably give it another shot during
>>> scipy2015.
>>>
>> I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
>> E.g., something like:
>>
>> widget.config(borderwidth=0, highlightthickness=0)
>>
>> It's a moderately classic Tkinter gotcha. You remove all the borders and
>> there's still one (hightlightthickness) still there, but it only shows up
>> when you interact with the Frame.
>>
>> Hope that helps,
>> -Joe
>>
>
>

No, I did not try that one. I'll give it a shot. I don't do any Tkinter
programming, so I wasn't familiar with that one.
On Mon, Jun 15, 2015 at 9:23 AM, Joe Kington <jof...@gm...> wrote:
>
>
> On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
>
>> That's the weird thing... I couldn't! I tried a few different things and
>> I couldn't make it go away. I'll probably give it another shot during
>> scipy2015.
>>
> I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
> E.g., something like:
>
> widget.config(borderwidth=0, highlightthickness=0)
>
> It's a moderately classic Tkinter gotcha. You remove all the borders and
> there's still one (hightlightthickness) still there, but it only shows up
> when you interact with the Frame.
>
> Hope that helps,
> -Joe
>

On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
> That's the weird thing... I couldn't! I tried a few different things and I
> couldn't make it go away. I'll probably give it another shot during
> scipy2015.
>
I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
E.g., something like:
widget.config(borderwidth=0, highlightthickness=0)
It's a moderately classic Tkinter gotcha. You remove all the borders and
there's still one (hightlightthickness) still there, but it only shows up
when you interact with the Frame.
Hope that helps,
-Joe

Perhaps MEP27 will make that job easier, we shall see...
 From: Benjamin Root <ben...@ou...>
 To: Daniele Nicolodi <da...@gr...> 
Cc: matplotlib development list <mat...@li...> 
 Sent: Monday, 15 June 2015, 13:23
 Subject: Re: [matplotlib-devel] Tk backend different from others
 
That's the weird thing... I couldn't! I tried a few different things and I couldn't make it go away. I'll probably give it another shot during scipy2015.Ben Root
On Jun 15, 2015 4:50 AM, "Daniele Nicolodi" <da...@gr...> wrote:
Hello Ben,
On 15/11/14 17:14, Benjamin Root wrote:
> Second, while I haven't tried out all the backends yet, I noticed that
> the Figure window for tkagg has an annoying border that the other
> backends don't have. It is fairly wide, 4 pixels. I would like to get
> rid of that. Does anybody object to that? I can make a PR for that and
> any other border widths I find.
I'm trying to switch from the MacOSX backend to the the WXAgg backend
because the font handling in the first is quite a bit broken. However
the black border is very annoying. Did you manage to get rid of it?
Cheers,
Daniele
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

That's the weird thing... I couldn't! I tried a few different things and I
couldn't make it go away. I'll probably give it another shot during
scipy2015.
Ben Root
On Jun 15, 2015 4:50 AM, "Daniele Nicolodi" <da...@gr...> wrote:
> Hello Ben,
>
> On 15/11/14 17:14, Benjamin Root wrote:
> > Second, while I haven't tried out all the backends yet, I noticed that
> > the Figure window for tkagg has an annoying border that the other
> > backends don't have. It is fairly wide, 4 pixels. I would like to get
> > rid of that. Does anybody object to that? I can make a PR for that and
> > any other border widths I find.
>
> I'm trying to switch from the MacOSX backend to the the WXAgg backend
> because the font handling in the first is quite a bit broken. However
> the black border is very annoying. Did you manage to get rid of it?
>
> Cheers,
> Daniele
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello Ben,
On 15/11/14 17:14, Benjamin Root wrote:
> Second, while I haven't tried out all the backends yet, I noticed that
> the Figure window for tkagg has an annoying border that the other
> backends don't have. It is fairly wide, 4 pixels. I would like to get
> rid of that. Does anybody object to that? I can make a PR for that and
> any other border widths I find.
I'm trying to switch from the MacOSX backend to the the WXAgg backend
because the font handling in the first is quite a bit broken. However
the black border is very annoying. Did you manage to get rid of it?
Cheers,
Daniele

Great to hear this!
> - re-order feature release/style change if needed
> - can focus sprint effort at scipy on new features
> - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
> - keep style change-only release plan
> - start adding color maps as named maps on master
> - color map
> - D seems to be leader, maybe variation on theme
> - stefan is working on circular color maps
> - other style changes
> - adopt most of seaborn as defaults ?
I think it would be good to have a set of core stylesheets in mpl that include
* Slight modifications of the existing mpl theme (outward ticks?,
different default cmap and color cycle)
* The default seaborn style that closely follows that of ggplot2
* Stylesheets that mimic the "contexts" of seaborn
I would also like to see a few more style helper methods such as
despine, ticks_out/in, etc.
> - start putting in style sheets as soon as possible
> - may not be worth big drawn out decision, just change them
> - line color cycle
> - need to do something, maybe related to circular color maps
> - use something from seaborn
> - get time for style BoF at scipy
I would love to participate in any mpl BoFs at SciPy. Also, I have a
student working for me this summer and one of his focus areas will be
visualization. I can likely have him work on some of the
stylesheet+traitlets+nbagg stuff as part of this work. He will also be
at SciPy.
Cheers,
Brian
>
> Any feed back is welcome.
>
> Tom
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgr...@ca... and ell...@gm...

It's good to hear Stefan is working on circular colormaps as the hsv
colormap is way too saturated, ignoring any perceptual aspects. For this,
it might be possible to provide some sort of saturation parameter in a
function along the lines of the parameters in the cubehelix function? Also,
sympy/mpmath's cplot function allows you to modulate the
nominally-perceptually-flat hsv map with a value-related function, which
they take as the absolute value of the function, but ideally it would be
any function or array that could ideally be passed in as a parameter. I
have plotted images like this in the past, where I was plotting the phase
of a complex number field but only wanted to use the envelope of the
overall function to control the saturation so you could see the structure
near the singularities but the brightness would fall off in the outer parts
of the image.
Gary R
On 10 June 2015 at 09:17, Thomas Caswell <tca...@gm...> wrote:
> Hey all,
>
> Today we had a phone call with myself, Eric Firing, Micheal
> Droettboom, Stéfan van der Walt, and Nathaniel Smith to discuss the path
> forward for the changes to the default color map / style. The notes are
> below:
>
> - re-order feature release/style change if needed
> - can focus sprint effort at scipy on new features
> - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
> - keep style change-only release plan
> - start adding color maps as named maps on master
> - color map
> - D seems to be leader, maybe variation on theme
> - stefan is working on circular color maps
> - other style changes
> - adopt most of seaborn as defaults ?
> - start putting in style sheets as soon as possible
> - may not be worth big drawn out decision, just change them
> - line color cycle
> - need to do something, maybe related to circular color maps
> - use something from seaborn
> - get time for style BoF at scipy
>
> Any feed back is welcome.
>
> Tom
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hey all,
Today we had a phone call with myself, Eric Firing, Micheal
Droettboom, Stéfan van der Walt, and Nathaniel Smith to discuss the path
forward for the changes to the default color map / style. The notes are
below:
 - re-order feature release/style change if needed
 - can focus sprint effort at scipy on new features
 - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
 - keep style change-only release plan
 - start adding color maps as named maps on master
 - color map
 - D seems to be leader, maybe variation on theme
 - stefan is working on circular color maps
 - other style changes
 - adopt most of seaborn as defaults ?
 - start putting in style sheets as soon as possible
 - may not be worth big drawn out decision, just change them
 - line color cycle
 - need to do something, maybe related to circular color maps
 - use something from seaborn
 - get time for style BoF at scipy
Any feed back is welcome.
Tom

On 2015年06月07日 12:05 PM, Nathaniel Smith wrote:
> On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
>> Matplotlib's pyplot retains quite a few vestiges from its original
>> Matlab-workalike heritage; we would like to gradually eliminate those
>> that no longer make sense. One such candidate is the "hold" kwarg that
>> every pyplot function has, with a "True" default. I don't think it
>> serves any useful purpose now, and getting rid of it would allow
>> considerable simplification to the code and, to a lesser extent, the
>> documentation. The default behavior would not change, only the ability
>> to change that behavior via either the rcParams['axes.hold'] parameter
>> or the "hold" kwarg in a pyplot function call.
>>
>> If you routinely use 'hold=False' and believe that removing it would be
>> a mistake, please let us know.
>
> I do actually use it with some regularity interactively, though I'm
> not particularly attached to it. Is there some equivalent though, like
> plt.whatever(..., hold=False)
> can become
> plt.clear(); plt.whatever(...)
It's exactly equivalent to:
	plt.cla(); plt.whatever(...)
> ? The semantics would be that the current figure remains the current
> figure, but is reset so that the next operation starts from scratch. I
> notice that plt.clear() does not exist, but maybe it has another
> spelling :-).
There are two types of "clear":
	plt.clf() # clear the current Figure
	plt.cla() # clear the current Axes
Eric
>
> (Basically the use case here is getting something like the
> edit-and-rerun-a-cell workflow, but when using a classic interactive
> REPL rather than the ipython notebook -- so I have a specific plot
> window up on my screen at a size and place where I can see it, and
> maybe some other plots in other windows in the background somewhere,
> and I want to quickly display different things into that window.)
>
> -n
>

On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
> Matplotlib's pyplot retains quite a few vestiges from its original
> Matlab-workalike heritage; we would like to gradually eliminate those
> that no longer make sense. One such candidate is the "hold" kwarg that
> every pyplot function has, with a "True" default. I don't think it
> serves any useful purpose now, and getting rid of it would allow
> considerable simplification to the code and, to a lesser extent, the
> documentation. The default behavior would not change, only the ability
> to change that behavior via either the rcParams['axes.hold'] parameter
> or the "hold" kwarg in a pyplot function call.
>
> If you routinely use 'hold=False' and believe that removing it would be
> a mistake, please let us know.
I do actually use it with some regularity interactively, though I'm
not particularly attached to it. Is there some equivalent though, like
 plt.whatever(..., hold=False)
can become
 plt.clear(); plt.whatever(...)
? The semantics would be that the current figure remains the current
figure, but is reset so that the next operation starts from scratch. I
notice that plt.clear() does not exist, but maybe it has another
spelling :-).
(Basically the use case here is getting something like the
edit-and-rerun-a-cell workflow, but when using a classic interactive
REPL rather than the ipython notebook -- so I have a specific plot
window up on my screen at a size and place where I can see it, and
maybe some other plots in other windows in the background somewhere,
and I want to quickly display different things into that window.)
-n
-- 
Nathaniel J. Smith -- http://vorpus.org

Matplotlib's pyplot retains quite a few vestiges from its original 
Matlab-workalike heritage; we would like to gradually eliminate those 
that no longer make sense. One such candidate is the "hold" kwarg that 
every pyplot function has, with a "True" default. I don't think it 
serves any useful purpose now, and getting rid of it would allow 
considerable simplification to the code and, to a lesser extent, the 
documentation. The default behavior would not change, only the ability 
to change that behavior via either the rcParams['axes.hold'] parameter 
or the "hold" kwarg in a pyplot function call.
If you routinely use 'hold=False' and believe that removing it would be 
a mistake, please let us know.
Thanks.
Eric

Is there any news about this thing?
anyone know of a working matplotlib on arm chips?
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-on-Android-tp44304p45739.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Members of the matplotlib community,
As one of the co-chairs in charge of organizing the birds-of-a-feather sessions at SciPy this year I wanted to reach out to your community to encourage you to submit a BoF proposal to open up a discussion on topics related to matplotlib development, future or just general questions. Please let us know if there is anything we can help with in terms of organization.
Kyle Mandli and Matt McCormick