rebaseline_server: generate JSON that can be viewed without a live server

rebaseline_server: generate JSON that can be viewed without a live server

BUG=skia:1919
NOTREECHECKS=True
NOTRY=True

Committed: http://code.google.com/p/skia/source/detail?r=13783

[epoger, 2014-03-12 21:08:35]

Ready for review at patchset 1.

With these changes, the rebaseline_server server.py still works as it always
has, but now results.py can generate a full JSON results summary that can be
downloaded/viewed from any HTTP server.

The one thing that doesn't work yet: the client UI is unable to display image
diffs.  (It displays the % differing pixels, but the diff images show up as
broken links.)  I have a couple of ideas for this, but since server.py continues
to work I can figure that out later.

You can view it via standard HTTP server vs server.py :

http://c128.i.corp.google.com:8888/static/view.html#/view.html?resultsToLoad=...
vs
http://c128.i.corp.google.com/rbs/static/view.html#/view.html?resultsToLoad=....

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results.py
File gm/rebaseline_server/results.py (right):

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results.py:180: def get_packaged_results_of_type(self,
results_type, reload_seconds=None,
moved here from server.py

[epoger, 2014-03-12 23:45:08]

Changing reviewer to Mr. Early Riser

[rmistry, 2014-03-13 13:11:45]

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results.py
File gm/rebaseline_server/results.py (right):

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results.py:490: 'defaults to \'%(default)s\' .')
This is cool, I did not know you could do this to get the default value.

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server.py
File gm/rebaseline_server/server.py (right):

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server....
gm/rebaseline_server/server.py:44: import results as results_mod
This seems inconsistent with other imported modules in this framework, is there
a specific reason we are doing this for the results module?

[rmistry, 2014-03-13 13:12:49]

On 2014/03/12 21:08:35, epoger wrote:
> Ready for review at patchset 1.
> 
> With these changes, the rebaseline_server server.py still works as it always
> has, but now results.py can generate a full JSON results summary that can be
> downloaded/viewed from any HTTP server.
> 
> The one thing that doesn't work yet: the client UI is unable to display image
> diffs.  (It displays the % differing pixels, but the diff images show up as
> broken links.)  I have a couple of ideas for this, but since server.py
continues
> to work I can figure that out later.
> 
> You can view it via standard HTTP server vs server.py :
> 
>
http://c128.i.corp.google.com:8888/static/view.html#/view.html?resultsToLoad=...
> vs
>
http://c128.i.corp.google.com/rbs/static/view.html#/view.html?resultsToLoad=....

Why are the rows with the images shifted further down in the link with the
broken images? Do the broken images have something to do with this?

> 
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results.py
> File gm/rebaseline_server/results.py (right):
> 
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results...
> gm/rebaseline_server/results.py:180: def get_packaged_results_of_type(self,
> results_type, reload_seconds=None,
> moved here from server.py

[epoger, 2014-03-13 14:37:04]

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results.py
File gm/rebaseline_server/results.py (right):

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results.py:2: 
On 2014/03/13 13:12:49, rmistry wrote:
>
http://c128.i.corp.google.com:8888/static/view.html#/view.html?resultsToLoad=...
> > vs
> >
>
http://c128.i.corp.google.com/rbs/static/view.html#/view.html?resultsToLoad=....
> 
> Why are the rows with the images shifted further down in the link with the
> broken images? Do the broken images have something to do with this?

Probably.  If it's OK with you, I'll wait until I fix those broken image embeds
to get this worked out.

By the way, I have an idea for supplying the broken image embeds:  For now, keep
the specialized server.py running just to serve out those images.  (The JSON can
be loaded from Google Storage, and the web client will contact the special
server to download the diff images.)  I may take a different tack later, but for
now that will allow us to generate multiple JSONs (expected vs actual at HEAD,
expected vs actual at a particular revision, gpu vs cpu, etc.) and serve them
from Google Storage.

What do you think of that idea, for the time being at least?

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server.py
File gm/rebaseline_server/server.py (right):

https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server....
gm/rebaseline_server/server.py:44: import results as results_mod
On 2014/03/13 13:11:46, rmistry wrote:
> This seems inconsistent with other imported modules in this framework, is
there
> a specific reason we are doing this for the results module?

Indeed.  I changed this because I noticed that I had defined a property
results() with the same name as the imported module.  While Python keeps them
distinct (you refer to one as "self.results", the other just as "results") I was
worried it might be confusing.

I'm happy to handle it some other way, such as:
1. leave it as it was before
2. leave the imported module name as "results", and replace the results()
property with a get_results() method
3. <your idea here>

Let me know what you think is best...

[rmistry, 2014-03-13 14:41:27]

On 2014/03/13 14:37:04, epoger wrote:
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results.py
> File gm/rebaseline_server/results.py (right):
> 
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/results...
> gm/rebaseline_server/results.py:2: 
> On 2014/03/13 13:12:49, rmistry wrote:
> >
>
http://c128.i.corp.google.com:8888/static/view.html#/view.html?resultsToLoad=...
> > > vs
> > >
> >
>
http://c128.i.corp.google.com/rbs/static/view.html#/view.html?resultsToLoad=....
> > 
> > Why are the rows with the images shifted further down in the link with the
> > broken images? Do the broken images have something to do with this?
> 
> Probably.  If it's OK with you, I'll wait until I fix those broken image
embeds
> to get this worked out.
> 
> By the way, I have an idea for supplying the broken image embeds:  For now,
keep
> the specialized server.py running just to serve out those images.  (The JSON
can
> be loaded from Google Storage, and the web client will contact the special
> server to download the diff images.)  I may take a different tack later, but
for
> now that will allow us to generate multiple JSONs (expected vs actual at HEAD,
> expected vs actual at a particular revision, gpu vs cpu, etc.) and serve them
> from Google Storage.
> 
> What do you think of that idea, for the time being at least?

SGTM. For my understanding, it would pull the images from the specialized
server.py till you figure out how to get those images directly from Google
Storage instead. Is that correct?

> 
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server.py
> File gm/rebaseline_server/server.py (right):
> 
>
https://codereview.chromium.org/195943004/diff/1/gm/rebaseline_server/server....
> gm/rebaseline_server/server.py:44: import results as results_mod
> On 2014/03/13 13:11:46, rmistry wrote:
> > This seems inconsistent with other imported modules in this framework, is
> there
> > a specific reason we are doing this for the results module?
> 
> Indeed.  I changed this because I noticed that I had defined a property
> results() with the same name as the imported module.  While Python keeps them
> distinct (you refer to one as "self.results", the other just as "results") I
was
> worried it might be confusing.
> 
> I'm happy to handle it some other way, such as:
> 1. leave it as it was before
> 2. leave the imported module name as "results", and replace the results()
> property with a get_results() method
> 3. <your idea here>
> 
> Let me know what you think is best...

1. leave it as it was before (and add a comment explaining why only this import
is renamed).
2. get_results() method works too but I would be ok with (1), this is not a big
deal either way.

[epoger, 2014-03-13 14:48:33]

On 2014/03/13 14:41:27, rmistry wrote:
> SGTM. For my understanding, it would pull the images from the specialized
> server.py till you figure out how to get those images directly from Google
> Storage instead. Is that correct?

You are correct about the first part.  As for where we will get the diff images
later, static files in Google Storage may or may not be the answer.  I'm not
sure yet.

> 1. leave it as it was before (and add a comment explaining why only this
import
> is renamed).

Done.

[rmistry, 2014-03-13 14:51:13]

On 2014/03/13 14:48:33, epoger wrote:
> On 2014/03/13 14:41:27, rmistry wrote:
> > SGTM. For my understanding, it would pull the images from the specialized
> > server.py till you figure out how to get those images directly from Google
> > Storage instead. Is that correct?
> 
> You are correct about the first part.  As for where we will get the diff
images
> later, static files in Google Storage may or may not be the answer.  I'm not
> sure yet.
> 
> > 1. leave it as it was before (and add a comment explaining why only this
> import
> > is renamed).
> 
> Done.

LGTM

[epoger, 2014-03-13 14:56:16]

The CQ bit was checked by epoger@google.com

[commit-bot: I haz the power, 2014-03-13 14:56:20]

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

[commit-bot: I haz the power, 2014-03-13 14:56:33]

Change committed as 13783