matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Phil E. <pel...@gm...>]

Firstly, I think you are right to bring this up Eric, we should all agree
what the best course is to take, and then all work together to get us there
with the least amount of disruption possible.

> if we leave PEP8 out of v1.2.x, and decide that once it is released,
v1.2.x will be changed
> only if critical bugs are found, requiring a v1.2.1 release

I agree. I think it is important here to be very clear about what
constitutes a "critical bug". In my opinion, releasing a v1.2.1 would be a
very last resort and I would sooner see us move forward by fixing bugs in a
new feature release (1.3). In order to do this we should have a schedule
for our next release *now*, and ideally it shouldn't be that far away (i.e.
no longer than 8-9 months). Some of my reasons for this assertion include:

   1. We have an amazing community of people who help us build our release
   bundles - so the actual release deployment mechanisms are no longer a
   limiting factor
   2. We have a long period between identification of features, their
   implementation and then seeing those features available in the latest
   release to our users. I would love to see that time shorten to share some
   of the cool new features that are being developed with non-developers
   sooner so that we can get feedback and go through the development cycle
   quicker.
   3. Currently making a release is a massive task which takes many
   developers out of actually being able to focus on new features or bugfixes.
   Having a quicker release cycle should mean we have fewer large changes per
   release and reduce the need we currently have to squeeze as much as we can
   into the next release - ultimately I think it will mean that we need to
   expend fewer developer hours focused on release management and last minute
   code reviewing.

This is not intended to be a criticism of our current system, simply an
observation that I think could help us to be more responsive and agile in
the future. If anybody wants to share their experiences with other
development methodologies I would love to hear about them (I guess if it is
not strictly related to this thread, then perhaps we should start up a new
conversation on the mailing list).

In short, provided we can agree a future matplotlib version schedule, I
agree with Eric. In terms of reverting the already cherry picked commits, I
am less sure. My heart is telling me to draw a line in the sand, accept
what is on the v1.2.x branch currently, and accept the suggested approach
for all future commits.

Finally, I agree with Ben. This is not a criticism of Nelle's PEP8 pull
requests, or of Damon and other's hard work in reviewing and merging them,
it is simply that we should agree the best course to get the best possible
release of v1.2.0 without dragging it out long beyond our original schedule.

Cheers,

Phil





On 15 October 2012 09:08, Damon McDougall <dam...@gm...> wrote:
> On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
> <nel...@gm...> wrote:
>>
>>
>> On 15 October 2012 06:10, Eric Firing <ef...@ha...> wrote:
>>>
>>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...>
wrote:
>>> >> All,
>>> >>
>>> >> I think we are in a messy situation, and we need to reach some
>>> >> agreement
>>> >> as to how to proceed.  This has been discussed a bit in this thread:
>>> >>
>>> >>
>>> >>
http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>>> >>
>>> >> The name of that thread did not reflect the importance of the
>>> >> discussion
>>> >> it prompted, hence the present message.
>>> >>
>>> >> To summarize my view:
>>> >>
>>> >> 1) We have a flood of PEP8 PRs based on master, many of which have
been
>>> >> merged, some by myself--so I have no objection to this aspect of the
>>> >> situation, though I would have preferred a slower pace, a garden hose
>>> >> rather than a fire hose.  I am happy to see continued merging of
these
>>> >> PRs into master.
>>> >>
>>> >> 2) We are also trying to stabilize v1.2.x, getting in the last few
bug
>>> >> fixes and doc updates, so we can get a release out, with a high
>>> >> probability that it will be solid.
>>> >>
>>> >> 3) The potential disagreement is over whether the PEP8 changes should
>>> >> be
>>> >> cherry-picked into v1.2.x, or simply left in master.  I favor the
>>> >> latter
>>> >> course.  First, because massive code churn shortly before a release
>>> >> seems unwise.  Second, because I think we should stick to the
strategy
>>> >> we started with, in which an effort is made to choose the most
>>> >> appropriate target for each PR, frequently merge the maintenance
branch
>>> >> into master, and reserve cherry-picking for occasional corrections.
>>> >>
>>> >> 4) The PEP8 changes will cause some merge problems no matter what we
>>> >> do;
>>> >> but I think that they can be minimal and manageable if we leave PEP8
>>> >> out
>>> >> of v1.2.x, and decide that once it is released, v1.2.x will be
changed
>>> >> only if critical bugs are found, requiring a v1.2.1 release. This
also
>>> >> assumes that we have only a few changes left to be made in v1.2.x
>>> >> before
>>> >> a final rc and a release.
>>> >>
>>> >> Therefore I recommend that the PEP8 changes that have already been
>>> >> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
>>> >> milestone be removed from all PEP8 changes.
>>> >>
>>> >> If some of the PEP8 commits include genuine bug-fixes that need to be
>>> >> in
>>> >> v1.2.x, then these fixes should be made via PRs directly against
>>> >> v1.2.x.
>>> >>
>>> >> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
>>> >>
>>> >> Eric
>>> >
>>> > I'm happy with whatever is decided. I'd rather not have merge
>>> > conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
>>> > not cherry-pick them into 1.2.x.
>>> >
>>> > If it is decided that we are to revert all the PEP8 changes in 1.2.x,
>>> > what should be done about PEP8 changes that were merged into master
>>> > before the v1.2.x branch was created?
>>> >
>>>
>>> Damon,
>>>
>>> As I said, I would not advocate trying to back out everything, and maybe
>>> not any of what is already in 1.2.x, or maybe just the most recent
>>> bunch.  Anticipating that Mike D. might want to make a decision tomorrow
>>> (or today from your timezone), perhaps it would be helpful if you could
>>> make an approximate map of which PEP8 commits were cherry-picked to
>>> 1.2.x, and how recently?  I have been trying to figure this out with
>>> qgit and git log with various options, but it makes my head spin.
>>
>>
>> List of commits that were cherry-picked recently (names only, but I can
do
>> the commit id as well):
>>
>> PEP8 fixes on blocking_input.py
>> PEP8 fixes on blocking_input (patch n°2)
>> PEP_ fixes on cbook.py
>> PEP8 fixes 2. => 2.0
>> PEP8 fixes on tight_bbox.py
>> PEP8 fixes on tight_layout.py
>> PEP8 fixes - break points and identation
>> PEP8 fixes on type1font.py
>> PEP8 fixes - small backslashes and breaks fixes
>> PEP8 fixes on transforms.py
>> FIX - travis-ci is failing
>> Fix typo in transforms.py
>> PEP8 fixes on scale.py
>> PEP8 fixes on legend.py
>> PEP8 fixes on ticker.py
>> PEP8 fixes on streamplot.py
>> PEP8 fixes on stackplot.py
>> PEP8 fixes on hatch.py
>> PEP8 fixes on table.py
>
> Thanks Nelle.
>
> Eric, is the list Nelle has provided what you were expecting?
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom
>
>
------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Benjamin R. <ben...@ou...>]

On Monday, October 15, 2012, Nelle Varoquaux wrote:

>
>
> On 15 October 2012 04:49, Jae-Joon Lee <lee...@gm...<javascript:_e({}, 'cvml', 'lee...@gm...');>
> > wrote:
>
>> I'd agree with Eric on most of his points.
>>
>> On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <ef...@ha...<javascript:_e({}, 'cvml', 'ef...@ha...');>>
>> wrote:
>> > If some of the PEP8 commits include genuine bug-fixes that need to be in
>> > v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>>
>> I think it is not a good idea to have a PR that mixes a bug-fix with a
>> PEP8 fix that is not related with the bug.
>> Maybe we need to ask for separate PRs, one for PEP8 fix and one for
>> bug-fixes.
>>
>
> I usually add a FIXME note in the code. I wouldn't rush those bug fixes,
> as they often have been there for a long time and corresponds to code that
> just would not run (hence, code that isn't tested).
>
>

Nelle, let me just take a moment to thank you for all the PEP8 work you
have done.  At first I was fine with these PRs being in v1.2.x, but now
that some ports are being removed, perhaps it is best for these to all go
into master.
>
>
Cheers!
Ben Root

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Damon M. <dam...@gm...>]

On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
<nel...@gm...> wrote:
>
>
> On 15 October 2012 06:10, Eric Firing <ef...@ha...> wrote:
>>
>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
>> >> All,
>> >>
>> >> I think we are in a messy situation, and we need to reach some
>> >> agreement
>> >> as to how to proceed.  This has been discussed a bit in this thread:
>> >>
>> >>
>> >> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>> >>
>> >> The name of that thread did not reflect the importance of the
>> >> discussion
>> >> it prompted, hence the present message.
>> >>
>> >> To summarize my view:
>> >>
>> >> 1) We have a flood of PEP8 PRs based on master, many of which have been
>> >> merged, some by myself--so I have no objection to this aspect of the
>> >> situation, though I would have preferred a slower pace, a garden hose
>> >> rather than a fire hose.  I am happy to see continued merging of these
>> >> PRs into master.
>> >>
>> >> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
>> >> fixes and doc updates, so we can get a release out, with a high
>> >> probability that it will be solid.
>> >>
>> >> 3) The potential disagreement is over whether the PEP8 changes should
>> >> be
>> >> cherry-picked into v1.2.x, or simply left in master.  I favor the
>> >> latter
>> >> course.  First, because massive code churn shortly before a release
>> >> seems unwise.  Second, because I think we should stick to the strategy
>> >> we started with, in which an effort is made to choose the most
>> >> appropriate target for each PR, frequently merge the maintenance branch
>> >> into master, and reserve cherry-picking for occasional corrections.
>> >>
>> >> 4) The PEP8 changes will cause some merge problems no matter what we
>> >> do;
>> >> but I think that they can be minimal and manageable if we leave PEP8
>> >> out
>> >> of v1.2.x, and decide that once it is released, v1.2.x will be changed
>> >> only if critical bugs are found, requiring a v1.2.1 release. This also
>> >> assumes that we have only a few changes left to be made in v1.2.x
>> >> before
>> >> a final rc and a release.
>> >>
>> >> Therefore I recommend that the PEP8 changes that have already been
>> >> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
>> >> milestone be removed from all PEP8 changes.
>> >>
>> >> If some of the PEP8 commits include genuine bug-fixes that need to be
>> >> in
>> >> v1.2.x, then these fixes should be made via PRs directly against
>> >> v1.2.x.
>> >>
>> >> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
>> >>
>> >> Eric
>> >
>> > I'm happy with whatever is decided. I'd rather not have merge
>> > conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
>> > not cherry-pick them into 1.2.x.
>> >
>> > If it is decided that we are to revert all the PEP8 changes in 1.2.x,
>> > what should be done about PEP8 changes that were merged into master
>> > before the v1.2.x branch was created?
>> >
>>
>> Damon,
>>
>> As I said, I would not advocate trying to back out everything, and maybe
>> not any of what is already in 1.2.x, or maybe just the most recent
>> bunch.  Anticipating that Mike D. might want to make a decision tomorrow
>> (or today from your timezone), perhaps it would be helpful if you could
>> make an approximate map of which PEP8 commits were cherry-picked to
>> 1.2.x, and how recently?  I have been trying to figure this out with
>> qgit and git log with various options, but it makes my head spin.
>
>
> List of commits that were cherry-picked recently (names only, but I can do
> the commit id as well):
>
> PEP8 fixes on blocking_input.py
> PEP8 fixes on blocking_input (patch n°2)
> PEP_ fixes on cbook.py
> PEP8 fixes 2. => 2.0
> PEP8 fixes on tight_bbox.py
> PEP8 fixes on tight_layout.py
> PEP8 fixes - break points and identation
> PEP8 fixes on type1font.py
> PEP8 fixes - small backslashes and breaks fixes
> PEP8 fixes on transforms.py
> FIX - travis-ci is failing
> Fix typo in transforms.py
> PEP8 fixes on scale.py
> PEP8 fixes on legend.py
> PEP8 fixes on ticker.py
> PEP8 fixes on streamplot.py
> PEP8 fixes on stackplot.py
> PEP8 fixes on hatch.py
> PEP8 fixes on table.py

Thanks Nelle.

Eric, is the list Nelle has provided what you were expecting?

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Nelle V. <nel...@gm...>]

On 15 October 2012 04:49, Jae-Joon Lee <lee...@gm...> wrote:

> I'd agree with Eric on most of his points.
>
> On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <ef...@ha...> wrote:
> > If some of the PEP8 commits include genuine bug-fixes that need to be in
> > v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>
> I think it is not a good idea to have a PR that mixes a bug-fix with a
> PEP8 fix that is not related with the bug.
> Maybe we need to ask for separate PRs, one for PEP8 fix and one for
> bug-fixes.
>

I usually add a FIXME note in the code. I wouldn't rush those bug fixes, as
they often have been there for a long time and corresponds to code that
just would not run (hence, code that isn't tested).


>
> Regards,
>
> -JJ
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Nelle V. <nel...@gm...>]

On 15 October 2012 06:10, Eric Firing <ef...@ha...> wrote:

> On 2012/10/14 12:44 PM, Damon McDougall wrote:
> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
> >> All,
> >>
> >> I think we are in a messy situation, and we need to reach some agreement
> >> as to how to proceed.  This has been discussed a bit in this thread:
> >>
> >>
> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
> >>
> >> The name of that thread did not reflect the importance of the discussion
> >> it prompted, hence the present message.
> >>
> >> To summarize my view:
> >>
> >> 1) We have a flood of PEP8 PRs based on master, many of which have been
> >> merged, some by myself--so I have no objection to this aspect of the
> >> situation, though I would have preferred a slower pace, a garden hose
> >> rather than a fire hose.  I am happy to see continued merging of these
> >> PRs into master.
> >>
> >> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
> >> fixes and doc updates, so we can get a release out, with a high
> >> probability that it will be solid.
> >>
> >> 3) The potential disagreement is over whether the PEP8 changes should be
> >> cherry-picked into v1.2.x, or simply left in master.  I favor the latter
> >> course.  First, because massive code churn shortly before a release
> >> seems unwise.  Second, because I think we should stick to the strategy
> >> we started with, in which an effort is made to choose the most
> >> appropriate target for each PR, frequently merge the maintenance branch
> >> into master, and reserve cherry-picking for occasional corrections.
> >>
> >> 4) The PEP8 changes will cause some merge problems no matter what we do;
> >> but I think that they can be minimal and manageable if we leave PEP8 out
> >> of v1.2.x, and decide that once it is released, v1.2.x will be changed
> >> only if critical bugs are found, requiring a v1.2.1 release. This also
> >> assumes that we have only a few changes left to be made in v1.2.x before
> >> a final rc and a release.
> >>
> >> Therefore I recommend that the PEP8 changes that have already been
> >> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
> >> milestone be removed from all PEP8 changes.
> >>
> >> If some of the PEP8 commits include genuine bug-fixes that need to be in
> >> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
> >>
> >> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
> >>
> >> Eric
> >
> > I'm happy with whatever is decided. I'd rather not have merge
> > conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
> > not cherry-pick them into 1.2.x.
> >
> > If it is decided that we are to revert all the PEP8 changes in 1.2.x,
> > what should be done about PEP8 changes that were merged into master
> > before the v1.2.x branch was created?
> >
>
> Damon,
>
> As I said, I would not advocate trying to back out everything, and maybe
> not any of what is already in 1.2.x, or maybe just the most recent
> bunch.  Anticipating that Mike D. might want to make a decision tomorrow
> (or today from your timezone), perhaps it would be helpful if you could
> make an approximate map of which PEP8 commits were cherry-picked to
> 1.2.x, and how recently?  I have been trying to figure this out with
> qgit and git log with various options, but it makes my head spin.
>

List of commits that were cherry-picked recently (names only, but I can do
the commit id as well):

PEP8 fixes on blocking_input.py
PEP8 fixes on blocking_input (patch n°2)
PEP_ fixes on cbook.py
PEP8 fixes 2. => 2.0
PEP8 fixes on tight_bbox.py
PEP8 fixes on tight_layout.py
PEP8 fixes - break points and identation
PEP8 fixes on type1font.py
PEP8 fixes - small backslashes and breaks fixes
PEP8 fixes on transforms.py
FIX - travis-ci is failing
Fix typo in transforms.py
PEP8 fixes on scale.py
PEP8 fixes on legend.py
PEP8 fixes on ticker.py
PEP8 fixes on streamplot.py
PEP8 fixes on stackplot.py
PEP8 fixes on hatch.py
PEP8 fixes on table.py

Thanks,
N


>
> Thanks.
>
> Eric
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Eric F. <ef...@ha...>]

On 2012/10/14 12:44 PM, Damon McDougall wrote:
> On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
>> All,
>>
>> I think we are in a messy situation, and we need to reach some agreement
>> as to how to proceed.  This has been discussed a bit in this thread:
>>
>> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>>
>> The name of that thread did not reflect the importance of the discussion
>> it prompted, hence the present message.
>>
>> To summarize my view:
>>
>> 1) We have a flood of PEP8 PRs based on master, many of which have been
>> merged, some by myself--so I have no objection to this aspect of the
>> situation, though I would have preferred a slower pace, a garden hose
>> rather than a fire hose.  I am happy to see continued merging of these
>> PRs into master.
>>
>> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
>> fixes and doc updates, so we can get a release out, with a high
>> probability that it will be solid.
>>
>> 3) The potential disagreement is over whether the PEP8 changes should be
>> cherry-picked into v1.2.x, or simply left in master.  I favor the latter
>> course.  First, because massive code churn shortly before a release
>> seems unwise.  Second, because I think we should stick to the strategy
>> we started with, in which an effort is made to choose the most
>> appropriate target for each PR, frequently merge the maintenance branch
>> into master, and reserve cherry-picking for occasional corrections.
>>
>> 4) The PEP8 changes will cause some merge problems no matter what we do;
>> but I think that they can be minimal and manageable if we leave PEP8 out
>> of v1.2.x, and decide that once it is released, v1.2.x will be changed
>> only if critical bugs are found, requiring a v1.2.1 release. This also
>> assumes that we have only a few changes left to be made in v1.2.x before
>> a final rc and a release.
>>
>> Therefore I recommend that the PEP8 changes that have already been
>> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
>> milestone be removed from all PEP8 changes.
>>
>> If some of the PEP8 commits include genuine bug-fixes that need to be in
>> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>>
>> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
>>
>> Eric
>
> I'm happy with whatever is decided. I'd rather not have merge
> conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
> not cherry-pick them into 1.2.x.
>
> If it is decided that we are to revert all the PEP8 changes in 1.2.x,
> what should be done about PEP8 changes that were merged into master
> before the v1.2.x branch was created?
>

Damon,

As I said, I would not advocate trying to back out everything, and maybe 
not any of what is already in 1.2.x, or maybe just the most recent 
bunch.  Anticipating that Mike D. might want to make a decision tomorrow 
(or today from your timezone), perhaps it would be helpful if you could 
make an approximate map of which PEP8 commits were cherry-picked to 
1.2.x, and how recently?  I have been trying to figure this out with 
qgit and git log with various options, but it makes my head spin.

Thanks.

Eric

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Eric F. <ef...@ha...>]

On 2012/10/14 4:49 PM, Jae-Joon Lee wrote:
> I'd agree with Eric on most of his points.
>
> On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <ef...@ha...> wrote:
>> If some of the PEP8 commits include genuine bug-fixes that need to be in
>> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>
> I think it is not a good idea to have a PR that mixes a bug-fix with a
> PEP8 fix that is not related with the bug.
> Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

I think that has been the case; certainly it has been the general 
intention.  I put in the remark you quoted in case there might have been 
one or two small exceptions.

Eric

>
> Regards,
>
> -JJ
>

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Jae-Joon L. <lee...@gm...>]

I'd agree with Eric on most of his points.

On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing <ef...@ha...> wrote:
> If some of the PEP8 commits include genuine bug-fixes that need to be in
> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

I think it is not a good idea to have a PR that mixes a bug-fix with a
PEP8 fix that is not related with the bug.
Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes.

Regards,

-JJ

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Thomas K. <th...@kl...>]

On 14 October 2012 21:22, Eric Firing <ef...@ha...> wrote:
> 3) The potential disagreement is over whether the PEP8 changes should be
> cherry-picked into v1.2.x, or simply left in master.  I favor the latter
> course.

I'm not familiar with matplotlib's merge strategy, but I'd agree with
you that making those changes post-RC doesn't sound sensible. There's
always the chance of something getting broken, especially when diffs
get too big to review carefully.

Thomas

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Eric F. <ef...@ha...>]

On 2012/10/14 12:44 PM, Damon McDougall wrote:
> On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
>> All,
>>
>> I think we are in a messy situation, and we need to reach some agreement
>> as to how to proceed.  This has been discussed a bit in this thread:
>>
>> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>>
>> The name of that thread did not reflect the importance of the discussion
>> it prompted, hence the present message.
>>
>> To summarize my view:
>>
>> 1) We have a flood of PEP8 PRs based on master, many of which have been
>> merged, some by myself--so I have no objection to this aspect of the
>> situation, though I would have preferred a slower pace, a garden hose
>> rather than a fire hose.  I am happy to see continued merging of these
>> PRs into master.
>>
>> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
>> fixes and doc updates, so we can get a release out, with a high
>> probability that it will be solid.
>>
>> 3) The potential disagreement is over whether the PEP8 changes should be
>> cherry-picked into v1.2.x, or simply left in master.  I favor the latter
>> course.  First, because massive code churn shortly before a release
>> seems unwise.  Second, because I think we should stick to the strategy
>> we started with, in which an effort is made to choose the most
>> appropriate target for each PR, frequently merge the maintenance branch
>> into master, and reserve cherry-picking for occasional corrections.
>>
>> 4) The PEP8 changes will cause some merge problems no matter what we do;
>> but I think that they can be minimal and manageable if we leave PEP8 out
>> of v1.2.x, and decide that once it is released, v1.2.x will be changed
>> only if critical bugs are found, requiring a v1.2.1 release. This also
>> assumes that we have only a few changes left to be made in v1.2.x before
>> a final rc and a release.
>>
>> Therefore I recommend that the PEP8 changes that have already been
>> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
>> milestone be removed from all PEP8 changes.
>>
>> If some of the PEP8 commits include genuine bug-fixes that need to be in
>> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>>
>> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
>>
>> Eric
>
> I'm happy with whatever is decided. I'd rather not have merge
> conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
> not cherry-pick them into 1.2.x.
>
> If it is decided that we are to revert all the PEP8 changes in 1.2.x,
> what should be done about PEP8 changes that were merged into master
> before the v1.2.x branch was created?
>

I didn't know there were any; but anything that far back should be left 
alone, because subsequent things are based on it, and it has been 
getting tested along the way during the rc cycle.  My concern is with 
massive changes shortly before release, and about getting the release 
over and done with so we can move on.

Eric

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Damon M. <dam...@gm...>]

On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
> All,
>
> I think we are in a messy situation, and we need to reach some agreement
> as to how to proceed.  This has been discussed a bit in this thread:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>
> The name of that thread did not reflect the importance of the discussion
> it prompted, hence the present message.
>
> To summarize my view:
>
> 1) We have a flood of PEP8 PRs based on master, many of which have been
> merged, some by myself--so I have no objection to this aspect of the
> situation, though I would have preferred a slower pace, a garden hose
> rather than a fire hose.  I am happy to see continued merging of these
> PRs into master.
>
> 2) We are also trying to stabilize v1.2.x, getting in the last few bug
> fixes and doc updates, so we can get a release out, with a high
> probability that it will be solid.
>
> 3) The potential disagreement is over whether the PEP8 changes should be
> cherry-picked into v1.2.x, or simply left in master.  I favor the latter
> course.  First, because massive code churn shortly before a release
> seems unwise.  Second, because I think we should stick to the strategy
> we started with, in which an effort is made to choose the most
> appropriate target for each PR, frequently merge the maintenance branch
> into master, and reserve cherry-picking for occasional corrections.
>
> 4) The PEP8 changes will cause some merge problems no matter what we do;
> but I think that they can be minimal and manageable if we leave PEP8 out
> of v1.2.x, and decide that once it is released, v1.2.x will be changed
> only if critical bugs are found, requiring a v1.2.1 release. This also
> assumes that we have only a few changes left to be made in v1.2.x before
> a final rc and a release.
>
> Therefore I recommend that the PEP8 changes that have already been
> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
> milestone be removed from all PEP8 changes.
>
> If some of the PEP8 commits include genuine bug-fixes that need to be in
> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
>
> Agreement?  Disagreement?  Discussion?  Related aspects of strategy?
>
> Eric

I'm happy with whatever is decided. I'd rather not have merge
conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
not cherry-pick them into 1.2.x.

If it is decided that we are to revert all the PEP8 changes in 1.2.x,
what should be done about PEP8 changes that were merged into master
before the v1.2.x branch was created?

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

[Eric F. <ef...@ha...>]

All,

I think we are in a messy situation, and we need to reach some agreement 
as to how to proceed.  This has been discussed a bit in this thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel

The name of that thread did not reflect the importance of the discussion 
it prompted, hence the present message.

To summarize my view:

1) We have a flood of PEP8 PRs based on master, many of which have been 
merged, some by myself--so I have no objection to this aspect of the 
situation, though I would have preferred a slower pace, a garden hose 
rather than a fire hose.  I am happy to see continued merging of these 
PRs into master.

2) We are also trying to stabilize v1.2.x, getting in the last few bug 
fixes and doc updates, so we can get a release out, with a high 
probability that it will be solid.

3) The potential disagreement is over whether the PEP8 changes should be 
cherry-picked into v1.2.x, or simply left in master.  I favor the latter 
course.  First, because massive code churn shortly before a release 
seems unwise.  Second, because I think we should stick to the strategy 
we started with, in which an effort is made to choose the most 
appropriate target for each PR, frequently merge the maintenance branch 
into master, and reserve cherry-picking for occasional corrections.

4) The PEP8 changes will cause some merge problems no matter what we do; 
but I think that they can be minimal and manageable if we leave PEP8 out 
of v1.2.x, and decide that once it is released, v1.2.x will be changed 
only if critical bugs are found, requiring a v1.2.1 release. This also 
assumes that we have only a few changes left to be made in v1.2.x before 
a final rc and a release.

Therefore I recommend that the PEP8 changes that have already been 
cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x 
milestone be removed from all PEP8 changes.

If some of the PEP8 commits include genuine bug-fixes that need to be in 
v1.2.x, then these fixes should be made via PRs directly against v1.2.x.

Agreement?  Disagreement?  Discussion?  Related aspects of strategy?

Eric

Re: [matplotlib-devel] PEP8 github label

[Eric F. <ef...@ha...>]

On 2012/10/14 12:17 AM, Damon McDougall wrote:
> On Sun, Oct 14, 2012 at 2:23 AM, Eric Firing <ef...@ha...> wrote:
>> That would be my preference; but has Mike written anything about where PEP8
>> changes should go?
>
> All I can find is this: https://github.com/matplotlib/matplotlib/pull/1153
>

Thanks.  It's better than nothing, but hardly crystal-clear as guidance 
for the present situation.

Mike's idea, as a compromise, was to "put some cleanup things (such as 
this) prior to the RC" but after creation of the branch.  It is now well 
past rc3.  It seems to me that putting such massive changes in now means 
that we should get them all in, then have another RC, and then wait a 
while.

In addition, if this is to be the course of action, I think it would be 
better to rebase each PR against v1.2.x prior to review and merging so 
that we can be inspecting exactly the changes that will be made to 
v1.2.x, instead of cherry-picking.  I did ask Mike earlier about 
cherry-picking backwards versus merging maintenance into master, and he 
confirmed that the latter remained the normal practice.

My first choice would still be to not put any of the PEP8 things in 
1.2.x, and absolutely minimize future changes on 1.2.x, freezing it ASAP.

Eric

Re: [matplotlib-devel] PEP8 github label

[Damon M. <dam...@gm...>]

On Sun, Oct 14, 2012 at 2:23 AM, Eric Firing <ef...@ha...> wrote:
> That would be my preference; but has Mike written anything about where PEP8
> changes should go?

All I can find is this: https://github.com/matplotlib/matplotlib/pull/1153

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] PEP8 github label

[Eric F. <ef...@ha...>]

On 2012/10/13 1:52 PM, Damon McDougall wrote:
> On Sun, Oct 14, 2012 at 1:29 AM, Eric Firing <ef...@ha...> wrote:
>> On 2012/10/13 1:16 PM, Damon McDougall wrote:
>>> I probably should have tested the waters first, but I added a PEP8
>>> github label. It's neon orange so you can't miss it. The reason I did
>>> this is so that the list of v1.2.x milestoned issues can be easily
>>> filtered by eye. That way it looks less daunting (since PEP8 isn't a
>>> huge priority for version 1.2 (at least not compared to bug fixes))
>>> and it's easier to see the more important issues.
>>>
>>> It's also temporary. Nelle's done a great job trawling through the
>>> codebase and raising some important points. There's a finite amount of
>>> bulk work to do and then the label can be removed.
>>>
>>> If anyone is offended by neon orange, please feel free to change it. I
>>> just wanted to be able to organise things a little more succinctly.
>>>
>>
>> I don't care about the color, but I don't understand the rationale for
>> putting these PEP8 changes in v1.2.x, especially when they are based on
>> master.  It seemed to me that the thing to do was get out a v1.2 release
>> without the PEP8 changes, and let them be the basis in master for
>> proceeding to v1.3.
>>
>> Evidently I was wrong, and we are instead doing massive cherry-picking
>> from master.
>>
>> A disadvantage of this is that PEP8 changes, though seemingly innocuous,
>> could introduce subtle bugs, so rushing them in at the end of the rc
>> cycle seems like it is taking an unnecessary risk for no functional benefit.
>>
>> Eric
>
> The downside of merging them into master without cherry-picking into
> 1.2 is the horrific merge conflicts that will occur whenever there's a
> pull request based on 1.2.

To clarify, you are referring to what would happen if we did not 
cherry-pick, when bug-fixes are made in 1.2, and then 1.2 is merged into 
master?  My preference would be to minimize this problem by moving 
quickly on 1.3, with *very* few changes in 1.2.x after the release--just 
quick fixes of critical bugs, if any, for a quick followup release, if 
necessary. In that case there are very few changes that need to be 
merged from 1.2.x into master, hence minimal merge conflicts.

Part of my puzzlement is why, if the strategy is to get all the PEP8 
changes into 1.2, Nelle hasn't been asked to base them on 1.2.x, so they 
could be merged from there into master in the usual way, by merging in 
the whole branch.  It seems to me that cherry-picking from master into 
1.2 should be something one does rarely, to fix an error of judgment as 
to which branch a change should go to, not something that should be done 
routinely with a whole series of PRs.

>
> I see your point of introducing subtle bugs. I'm happy to wait on the
> PEP8 changes if it seems too risky.
>

That would be my preference; but has Mike written anything about where 
PEP8 changes should go?

Eric

Re: [matplotlib-devel] PEP8 github label

[Damon M. <dam...@gm...>]

On Sun, Oct 14, 2012 at 1:29 AM, Eric Firing <ef...@ha...> wrote:
> On 2012/10/13 1:16 PM, Damon McDougall wrote:
>> I probably should have tested the waters first, but I added a PEP8
>> github label. It's neon orange so you can't miss it. The reason I did
>> this is so that the list of v1.2.x milestoned issues can be easily
>> filtered by eye. That way it looks less daunting (since PEP8 isn't a
>> huge priority for version 1.2 (at least not compared to bug fixes))
>> and it's easier to see the more important issues.
>>
>> It's also temporary. Nelle's done a great job trawling through the
>> codebase and raising some important points. There's a finite amount of
>> bulk work to do and then the label can be removed.
>>
>> If anyone is offended by neon orange, please feel free to change it. I
>> just wanted to be able to organise things a little more succinctly.
>>
>
> I don't care about the color, but I don't understand the rationale for
> putting these PEP8 changes in v1.2.x, especially when they are based on
> master.  It seemed to me that the thing to do was get out a v1.2 release
> without the PEP8 changes, and let them be the basis in master for
> proceeding to v1.3.
>
> Evidently I was wrong, and we are instead doing massive cherry-picking
> from master.
>
> A disadvantage of this is that PEP8 changes, though seemingly innocuous,
> could introduce subtle bugs, so rushing them in at the end of the rc
> cycle seems like it is taking an unnecessary risk for no functional benefit.
>
> Eric

The downside of merging them into master without cherry-picking into
1.2 is the horrific merge conflicts that will occur whenever there's a
pull request based on 1.2.

I see your point of introducing subtle bugs. I'm happy to wait on the
PEP8 changes if it seems too risky.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] PEP8 github label

[Eric F. <ef...@ha...>]

On 2012/10/13 1:16 PM, Damon McDougall wrote:
> I probably should have tested the waters first, but I added a PEP8
> github label. It's neon orange so you can't miss it. The reason I did
> this is so that the list of v1.2.x milestoned issues can be easily
> filtered by eye. That way it looks less daunting (since PEP8 isn't a
> huge priority for version 1.2 (at least not compared to bug fixes))
> and it's easier to see the more important issues.
>
> It's also temporary. Nelle's done a great job trawling through the
> codebase and raising some important points. There's a finite amount of
> bulk work to do and then the label can be removed.
>
> If anyone is offended by neon orange, please feel free to change it. I
> just wanted to be able to organise things a little more succinctly.
>

I don't care about the color, but I don't understand the rationale for 
putting these PEP8 changes in v1.2.x, especially when they are based on 
master.  It seemed to me that the thing to do was get out a v1.2 release 
without the PEP8 changes, and let them be the basis in master for 
proceeding to v1.3.

Evidently I was wrong, and we are instead doing massive cherry-picking 
from master.

A disadvantage of this is that PEP8 changes, though seemingly innocuous, 
could introduce subtle bugs, so rushing them in at the end of the rc 
cycle seems like it is taking an unnecessary risk for no functional benefit.

Eric

[matplotlib-devel] PEP8 github label

[Damon M. <dam...@gm...>]

I probably should have tested the waters first, but I added a PEP8
github label. It's neon orange so you can't miss it. The reason I did
this is so that the list of v1.2.x milestoned issues can be easily
filtered by eye. That way it looks less daunting (since PEP8 isn't a
huge priority for version 1.2 (at least not compared to bug fixes))
and it's easier to see the more important issues.

It's also temporary. Nelle's done a great job trawling through the
codebase and raising some important points. There's a finite amount of
bulk work to do and then the label can be removed.

If anyone is offended by neon orange, please feel free to change it. I
just wanted to be able to organise things a little more succinctly.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [IPython-dev] Interactive Matplotlib in the browser

[Ludwig S. <lud...@gm...>]

Exciting stuff!

The latency would be an important factor for the user experience, but this neatly sidesteps a lot of the JS issues. This would keep the main matplotlib machinery on the Python side, which is great.

We could still do simple high-speed annotations requiring very low latency such as cursors or selection rectangles on the JS side. I therefore don't foresee the requirement of sending hundreds or thousands of PNGs during e.g. a simple zoom (smooth resizing might be more intensive...).

Ironically, one of the motivations for the mplh5canvas backend is also to send *less* data over the network, as matplotlib's path simplification would effectively compress large data sets. However, path simplification does not yet apply to scatter plots, an important use case for us (although there are ways to implement that with clustering algorithms).

Obviously, a large number of vector operations could still end up being more data than a PNG file, where this idea will work better. I'm very keen to see how this pans out!

Regards,
Ludwig

Re: [matplotlib-devel] Upload a higher res logo to github

[Jens N. <jen...@gm...>]

That looks nice.

On a related note, should the link below the logo not point to
matplotlib.org since  http://matplotlib.sf.net/ just redirects to this site?

In addition it the python code for the sidebar illustrations on the
front side i.e.
http://matplotlib.org/_static/logo_sidebar_horiz.png available somewhere.
The polar plot is clipped in the top an bottom and it would be nice
to fix that and add these plot examples to the screenshot page opened
when clicking on the image.

Plots similar to 1 and 3 are there but no contour plot is shown.

Jens

On Fri, Oct 12, 2012 at 2:47 PM, Benjamin Root <ben...@ou...> wrote:
> Oh, that is *much* better.  Thank you!
>
> Ben Root
>
>
> On Fri, Oct 12, 2012 at 8:44 AM, Michael Droettboom <md...@st...> wrote:
>>
>> It is now fixed.  I just uploaded a higher resolution image of the same
>> thing.
>>
>> Mike
>>
>> On 10/10/2012 04:31 PM, Damon McDougall wrote:
>> > On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
>> >> Looks like github has changed the layout of the default landing page
>> >> for any
>> >> github account.  This now has the account's profile image shown much
>> >> larger
>> >> than originally intended.  Our front page now has a very pixelated logo
>> >> on
>> >> display.  Given how much we pride ourselves on high-quality images, we
>> >> should probably fix this:
>> >>
>> >> https://github.com/matplotlib
>> >>
>> >> Cheers!
>> >> Ben Root
>> > This has been bugging me for a while...
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Interactive Matplotlib in the browser

[Nathaniel S. <nj...@po...>]

On Thu, Oct 11, 2012 at 10:49 PM, Michael Droettboom <md...@st...> wrote:
> I have a proof-of-concept way to make interactive plots in the browser work
> using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.

As a bit of spiritual support for the underlying concept, I mostly use
matplotlib via exactly this mechanism, today. Except I didn't want to
modify matplotlib, so my solution is a bit more elaborate:
http://xpra.org/

There's an astonishing amount of nonsense involved in setting up a
headless X server, registering as a window manager and compositing
manager, fighting with the X keyboard model, etc., but at the end of
the day it just works by shipping PNG-style compressed screenshots
over the wire in one direction, and input events over the wire in the
other. Perhaps surprisingly, the result is dramatically more usable
over remote links than vanilla X forwarding is, and it's very
maintainable. So +1 to this approach.

-n

Re: [matplotlib-devel] Upload a higher res logo to github

[Benjamin R. <ben...@ou...>]

Oh, that is *much* better.  Thank you!

Ben Root

On Fri, Oct 12, 2012 at 8:44 AM, Michael Droettboom <md...@st...> wrote:

> It is now fixed.  I just uploaded a higher resolution image of the same
> thing.
>
> Mike
>
> On 10/10/2012 04:31 PM, Damon McDougall wrote:
> > On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
> >> Looks like github has changed the layout of the default landing page
> for any
> >> github account.  This now has the account's profile image shown much
> larger
> >> than originally intended.  Our front page now has a very pixelated logo
> on
> >> display.  Given how much we pride ourselves on high-quality images, we
> >> should probably fix this:
> >>
> >> https://github.com/matplotlib
> >>
> >> Cheers!
> >> Ben Root
> > This has been bugging me for a while...
> >
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Upload a higher res logo to github

[Michael D. <md...@st...>]

It is now fixed.  I just uploaded a higher resolution image of the same 
thing.

Mike

On 10/10/2012 04:31 PM, Damon McDougall wrote:
> On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
>> Looks like github has changed the layout of the default landing page for any
>> github account.  This now has the account's profile image shown much larger
>> than originally intended.  Our front page now has a very pixelated logo on
>> display.  Given how much we pride ourselves on high-quality images, we
>> should probably fix this:
>>
>> https://github.com/matplotlib
>>
>> Cheers!
>> Ben Root
> This has been bugging me for a while...
>

Re: [matplotlib-devel] [IPython-dev] Interactive Matplotlib in the browser

[Brian G. <ell...@gm...>]

It is not clear to me that the stream of PNGs will win in the end.  If
you make a single static plot of a large data set, that is way better
than trying to send the data to the browser and rendering it there.
But if you have to send hundreds or thousands of PNGs to get
interactivity, that benefit may be washed out.  Especially if you have
multiple users interacting with plots - the server could quickly grind
to a halt.  I think we should do tests to see how bad it gets, taking
into account the multiple user question.  The one performance benefit
that I can think of is that you can tune the level of interactivity to
limit the data that comes back.  For large data sets, users might be
willing to settle for less interactivity.  That option doesn't exist
when you send all the data back.

Cheers,

Brian



On Thu, Oct 11, 2012 at 2:49 PM, Michael Droettboom <md...@st...> wrote:
> I have a proof-of-concept way to make interactive plots in the browser work
> using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.
>
> Mike
>
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgr...@ca... and ell...@gm...

Re: [matplotlib-devel] [IPython-dev] Interactive Matplotlib in the browser

[Jason G. <jas...@cr...>]

On 10/11/12 4:49 PM, Michael Droettboom wrote:
> I have a proof-of-concept way to make interactive plots in the browser
> work using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.
>

A sample implementation using websockets instead of polling is here:

https://gist.github.com/3875846

It still requests the file, which causes a delay.  I think doing a png 
diff sounds like a great idea.  What if we also transfer the png diff 
over the websocket connection (maybe in a binary frame)?

Thanks,

Jason