Add show_gm_changes script: show change revisions and hashes for a GM

Add show_gm_changes script: show change revisions and hashes for a GM

BUG=skia:1920
Committed: http://code.google.com/p/skia/source/detail?r=14015

[borenet, 2014-04-01 13:49:57]

Might this be a useful tool?

Example run:

$ python gm/show_gm_changes.py Test-Mac10.7-MacMini4.1-GeForce320M-x86-Debug
shadertext_gpu --autogen-path .gm-actuals
Rev	Hash
15990	10904734222736193002
10729	10752292282035416719
8504	2915063876615374518
71	7546128203733045901

Now I know which revisions may be useful for launching the rebaseline server. 
It would probably be more useful if it also listed whether the GM succeeded or
failed comparison at each revision.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py
File gm/show_gm_changes.py (right):

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode36
gm/show_gm_changes.py:36: ': \[\s*\n\s+(\d+)\s+.+\s+\[
"bitmap-64bitMD5",\s+\n*(\d+)')
This isn't quite right, since it will only find changes in the first hash. 
AFAIK we don't have any GMs with multiple supported hashes, but this could be a
problem in the future.

[epoger, 2014-04-01 17:39:02]

LGTM with or without some minor changes.

Thanks for whipping this up... nice quick and handy tool!

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py
File gm/show_gm_changes.py (right):

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode7
gm/show_gm_changes.py:7: """Find and display recent changes in the given GM."""
Please paste your example run command line within this docstring.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode25
gm/show_gm_changes.py:25: filepath: string: path to the actual-results.json
file.
maybe semicolon after "string" just to be consistent

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode36
gm/show_gm_changes.py:36: ': \[\s*\n\s+(\d+)\s+.+\s+\[
"bitmap-64bitMD5",\s+\n*(\d+)')
On 2014/04/01 13:49:57, borenet wrote:
> This isn't quite right, since it will only find changes in the first hash. 
> AFAIK we don't have any GMs with multiple supported hashes, but this could be
a
> problem in the future.

That's not a problem; see https://code.google.com/p/skia/issues/detail?id=1787
('proposal: stop pretending to support multiple image results per GM')

I am a bit worried that this pattern may prove to be fragile in some other way,
because it is so dependent on the exact formatting of the line, but I think we
can cross that bridge when we come to it.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcod...
gm/show_gm_changes.py:105: sys.exit(main())
Does this mean main() should return an int?  Because it seems like it doesn't...

[borenet, 2014-04-01 18:11:37]

Uploaded patch set 2.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py
File gm/show_gm_changes.py (right):

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode7
gm/show_gm_changes.py:7: """Find and display recent changes in the given GM."""
On 2014/04/01 17:39:02, epoger wrote:
> Please paste your example run command line within this docstring.

Done.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode25
gm/show_gm_changes.py:25: filepath: string: path to the actual-results.json
file.
On 2014/04/01 17:39:02, epoger wrote:
> maybe semicolon after "string" just to be consistent

Whoops. Done.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcode36
gm/show_gm_changes.py:36: ': \[\s*\n\s+(\d+)\s+.+\s+\[
"bitmap-64bitMD5",\s+\n*(\d+)')
On 2014/04/01 17:39:02, epoger wrote:
> On 2014/04/01 13:49:57, borenet wrote:
> > This isn't quite right, since it will only find changes in the first hash. 
> > AFAIK we don't have any GMs with multiple supported hashes, but this could
be
> a
> > problem in the future.
> 
> That's not a problem; see https://code.google.com/p/skia/issues/detail?id=1787
> ('proposal: stop pretending to support multiple image results per GM')
> 
> I am a bit worried that this pattern may prove to be fragile in some other
way,
> because it is so dependent on the exact formatting of the line, but I think we
> can cross that bridge when we come to it.

Agreed.  I guess another way to do it would be to go through the output of "svn
blame" line-by-line looking for the GM name and then look for the line of the
next hash.  I think it's going to be fragile either way though, unfortunately.

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcod...
gm/show_gm_changes.py:105: sys.exit(main())
On 2014/04/01 17:39:02, epoger wrote:
> Does this mean main() should return an int?  Because it seems like it
doesn't...

This is a convention I've seen in a number of places and just sort of followed
for no particular reason.  Since main() returns None (there's no return
statement), it's equivalent to exiting with code 0.  I guess the arguable
benefit is that main() could "return 1" instead of sys.exit(1)?

[epoger, 2014-04-01 18:18:55]

lgtm

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py
File gm/show_gm_changes.py (right):

https://codereview.chromium.org/213833017/diff/1/gm/show_gm_changes.py#newcod...
gm/show_gm_changes.py:105: sys.exit(main())
On 2014/04/01 18:11:38, borenet wrote:
> On 2014/04/01 17:39:02, epoger wrote:
> > Does this mean main() should return an int?  Because it seems like it
> doesn't...
> 
> This is a convention I've seen in a number of places and just sort of followed
> for no particular reason.  Since main() returns None (there's no return
> statement), it's equivalent to exiting with code 0.  I guess the arguable
> benefit is that main() could "return 1" instead of sys.exit(1)?

I would buy that.

[borenet, 2014-04-01 18:19:34]

The CQ bit was checked by borenet@google.com

[commit-bot: I haz the power, 2014-04-01 18:19:39]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/borenet@google.com/213833017/20001

[commit-bot: I haz the power, 2014-04-01 19:03:21]

Change committed as 14015