Added JSON schema compiler support for serialized types

Added JSON schema compiler support for serialized types

Currently supports string->int, string->int64, and int->string.

BUG=139076
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=149302

[not at google - send to devlin, 2012-07-26 04:51:42]

High level comment:

There's more extra code for this than I would have expected; and it seems like
it's a bit hard to keep up to date.

E.g. doing the GURL thing would be pretty cool. Perhaps it's even worth trying
to do in this change; certainly it's worth thinking about.

By GURL I mean like, in tabs.create there's a "url" property which looks like

"url": {
  "type": "string",
},

but it would be cool as

"url": {
  "type": "string",
  "compiled_type": "url"
}

Also, does going back to the original value work? Like, if some type comes from
the JSON as a string but into the client as an int64, it also needs to be able
to come from the client as an int64 and go to the JSON as a string.

Rather than thinking about this like "there is a type; sometimes there's a
serialized type", think about it as "there's a type in the JSON and a type in
the compiled code". The type in the JSON is just it's usual "type" field. The
type in the client is what you're calling "serialized type" but I think that's a
confusing name, because it could refer to JSON serialization or client
serialization (so if anything I'd expect it to be called "deserialiazed type"),
but how about "compiled_type"?

Anyway, so yeah, then "compiled_type" defaults to "type" but can be overridden.
Code which needs to know to generate a conversion function can do so with
"prop.type_ != prop.compiled_type" etc.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
File tools/json_schema_compiler/cpp_type_generator.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_type_generator.py:232: c.Append('#include
"base/string_number_conversions.h"')
bleh, just include it unconditionally. Too much of a pain to do this otherwise.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
File tools/json_schema_compiler/cpp_util.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_util.py:85: """Converts from prop.type_ to
prop.serialized_type.
erm maybe a less ambiguous name, like GenerateTypeConversionCall or something.

Please also describe what from_ and to are.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_util.py:93: }[prop.type_]
here and above, what happens if the types aren't supported? I think it would
return None thing or something. But it should raise an exception.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
File tools/json_schema_compiler/model.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:229: else:
this might as well be the same code that parses 'type' into a PropertyType. Can
you pull that into a helper?

Let code that uses the model support what it can.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:302: INT64 = _Info(True, "INT64")
ooh maybe we can use this to serialize GURLs directly later!

[mitchellwrosen, 2012-07-26 20:00:27]

On 2012/07/26 04:51:42, kalman wrote:
> High level comment:
> 
> There's more extra code for this than I would have expected; and it seems like
> it's a bit hard to keep up to date.
> 
> E.g. doing the GURL thing would be pretty cool. Perhaps it's even worth trying
> to do in this change; certainly it's worth thinking about.
> 
> By GURL I mean like, in tabs.create there's a "url" property which looks like
> 
> "url": {
>   "type": "string",
> },
> 
> but it would be cool as
> 
> "url": {
>   "type": "string",
>   "compiled_type": "url"
> }

A couple APIs I looked at initialize GURLs like this:
   GURL url(url_string);

However, tabs.create does this:
   GURL url = ExtensionTabUril::ResolvePossiblyRelativeURL(url_string,
GetExtension();

Therefore, a "compiled_type": "url" would only make sense in the more simple
case. Right?

> Also, does going back to the original value work? Like, if some type comes
from
> the JSON as a string but into the client as an int64, it also needs to be able
> to come from the client as an int64 and go to the JSON as a string.

Do you mean the the calls to Results::Create need to treat the compiled_types
like their original types?

> Rather than thinking about this like "there is a type; sometimes there's a
> serialized type", think about it as "there's a type in the JSON and a type in
> the compiled code". The type in the JSON is just it's usual "type" field. The
> type in the client is what you're calling "serialized type" but I think that's
a
> confusing name, because it could refer to JSON serialization or client
> serialization (so if anything I'd expect it to be called "deserialiazed
type"),
> but how about "compiled_type"?

That actually is how I wrote the code initially, with prop.compiled_type
initialized to prop.type_, but I changed the code around because I decided there
might be only this one instance of a compiled type differing from the json type.
You have talked sense into me though.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
File tools/json_schema_compiler/cpp_type_generator.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_type_generator.py:232: c.Append('#include
"base/string_number_conversions.h"')
On 2012/07/26 04:51:42, kalman wrote:
> bleh, just include it unconditionally. Too much of a pain to do this
otherwise.

I thought so too =)

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
File tools/json_schema_compiler/cpp_util.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_util.py:85: """Converts from prop.type_ to
prop.serialized_type.
On 2012/07/26 04:51:42, kalman wrote:
> erm maybe a less ambiguous name, like GenerateTypeConversionCall or something.
> 
> Please also describe what from_ and to are.

Done.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_util.py:93: }[prop.type_]
On 2012/07/26 04:51:42, kalman wrote:
> here and above, what happens if the types aren't supported? I think it would
> return None thing or something. But it should raise an exception.

It'll return a KeyError. Should I catch that and raise something else?

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
File tools/json_schema_compiler/model.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:229: else:
On 2012/07/26 04:51:42, kalman wrote:
> this might as well be the same code that parses 'type' into a PropertyType.
Can
> you pull that into a helper?
> 
> Let code that uses the model support what it can.

Hmm. Correct me if I'm wrong but it may not make sense to consider the same set
of types valid for both type_ and compiled_type. What about gurl and int64?
Those could only exist on the c++ side. Furthermore, it may be awkward to pull
into a helper function because there is special handling in the case that
json_type is an array or an object.

What do you think?

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:302: INT64 = _Info(True, "INT64")
On 2012/07/26 04:51:42, kalman wrote:
> ooh maybe we can use this to serialize GURLs directly later!

What do you mean?

[not at google - send to devlin, 2012-07-27 04:14:28]

To answer a couple of your overall comments:

> A couple APIs I looked at initialize GURLs like this:
>    GURL url(url_string);
> 
> However, tabs.create does this:
>    GURL url = ExtensionTabUril::ResolvePossiblyRelativeURL(url_string,
> GetExtension();
>
> Therefore, a "compiled_type": "url" would only make sense in the more simple
> case. Right?

Good point. I think in the case of URLs we might want to do something like

{
  "type": "string",
  "compiled_type": "url",
  "url_scheme": "chrome-extension://",
}

then the URL would be parsed with that URL scheme. That should parse. Calling
code can then do that ResolvePossiblyRelativeURL thing if it wants, like, insert
the extension's path before the URL in this case.

> Do you mean the the calls to Results::Create need to treat the compiled_types
> like their original types?

Yep. I think it makes sense? If it does you can make it a TODO; enforce that in
the code though, like "objects from the client cannot have compiled types". It
does mean you won't be able to have types with compiled types.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
File tools/json_schema_compiler/cpp_util.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/cpp...
tools/json_schema_compiler/cpp_util.py:93: }[prop.type_]
On 2012/07/26 20:00:27, mitchellwrosen wrote:
> On 2012/07/26 04:51:42, kalman wrote:
> > here and above, what happens if the types aren't supported? I think it would
> > return None thing or something. But it should raise an exception.
> 
> It'll return a KeyError. Should I catch that and raise something else?

Yeah, would be nice to include in the exception why it's happening (so that the
poor hapless future user of this doesn't have to dig through python source code
to figure out what the problem is).

And NotImplementedError would be more appropriate.

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
File tools/json_schema_compiler/model.py (right):

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:229: else:
On 2012/07/26 20:00:27, mitchellwrosen wrote:
> On 2012/07/26 04:51:42, kalman wrote:
> > this might as well be the same code that parses 'type' into a PropertyType.
> Can
> > you pull that into a helper?
> > 
> > Let code that uses the model support what it can.
> 
> Hmm. Correct me if I'm wrong but it may not make sense to consider the same
set
> of types valid for both type_ and compiled_type. What about gurl and int64?
> Those could only exist on the c++ side. Furthermore, it may be awkward to pull
> into a helper function because there is special handling in the case that
> json_type is an array or an object.
> 
> What do you think?

Yes, that's true. Hmm.

For for the types that only make sense for compiled code, that can be left to
the generators to figure out; nothing bad will happen.

For the types where special stuff is done, we can easily pull that out into
here. Like,

def _JsonTypeToPropertyType(json_type):
  if json_type == 'string':
    return PropertyType.STRING
  if json_type == 'any':
    return PropertyType.ANY
  ...
  if json_type == 'int64'
    return PropertyType.INT_64
  raise NotImplementedError(...)

then here,

self.type_ = _JsonToPropertyType(json['type'])
if self.type_ is PropertyType.ARRAY:
  # normal array stuff
elif self.type_ = PropertyType.OBJECT:
  # normal object stuff

compiled_type = json.get('compiled_type', None)
if compiled_type:
  self.compiled_type = _JsonToPropertyType(compiled_type)

http://codereview.chromium.org/10825029/diff/1/tools/json_schema_compiler/mod...
tools/json_schema_compiler/model.py:302: INT64 = _Info(True, "INT64")
On 2012/07/26 20:00:27, mitchellwrosen wrote:
> On 2012/07/26 04:51:42, kalman wrote:
> > ooh maybe we can use this to serialize GURLs directly later!
> 
> What do you mean?

I made this comment first. Just meant what I said about GURL earlier.

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
File tools/json_schema_compiler/cc_generator.py (right):

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
tools/json_schema_compiler/cc_generator.py:472: '%(fundamental_value_dst)s'))
can you inline this value? It's only used once so unfortunately to have to
scroll down 100 lines to see what it is.

I'd put it up on line 466,

if prop.type_ == prop.compiled_type:
  assignment_target = '&%s->%s' % (dst, prop.unix_name)
else:
  c.Append('%(ctype)s temp;')
  assignment_target = '&temp'

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
File tools/json_schema_compiler/cpp_type_generator.py (right):

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
tools/json_schema_compiler/cpp_type_generator.py:119: convert_type=False):
Could you put this in 2 separate methods, GetType and GetCompiledType? It can be
as dumb as

def GetType(...):
  return self._GetTypeHelper(...)

def GetCompiledType(...):
  return self._GetTypeHelper(..., use_compiled_type=True)

def _GetTypeHelper(..., use_compiled_type=False):
  ...

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
File tools/json_schema_compiler/cpp_util.py (right):

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
tools/json_schema_compiler/cpp_util.py:88: from_: The variable name of the type
to be converted from.
... as plain data or a reference.

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
tools/json_schema_compiler/cpp_util.py:89: to: The variable name of the type to
be converted to.
... as a pointer.

http://codereview.chromium.org/10825029/diff/4001/tools/json_schema_compiler/...
tools/json_schema_compiler/cpp_util.py:96: }[prop.compiled_type] % (from_, to)
see previous comment about NotImplementedError.

[mitchellwrosen, 2012-07-30 20:52:45]

This patch adds code that generates the appropriate Values of the right type.

No GURL code yet. Could you explain the "url_scheme" property one more time?
What other values might it take besides "chrome-extension://"?

https://chromiumcodereview.appspot.com/10825029/diff/1/tools/json_schema_comp...
File tools/json_schema_compiler/cpp_util.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/1/tools/json_schema_comp...
tools/json_schema_compiler/cpp_util.py:93: }[prop.type_]
On 2012/07/27 04:14:28, kalman wrote:
> On 2012/07/26 20:00:27, mitchellwrosen wrote:
> > On 2012/07/26 04:51:42, kalman wrote:
> > > here and above, what happens if the types aren't supported? I think it
would
> > > return None thing or something. But it should raise an exception.
> > 
> > It'll return a KeyError. Should I catch that and raise something else?
> 
> Yeah, would be nice to include in the exception why it's happening (so that
the
> poor hapless future user of this doesn't have to dig through python source
code
> to figure out what the problem is).
> 
> And NotImplementedError would be more appropriate.

Done.

https://chromiumcodereview.appspot.com/10825029/diff/1/tools/json_schema_comp...
File tools/json_schema_compiler/model.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/1/tools/json_schema_comp...
tools/json_schema_compiler/model.py:229: else:
On 2012/07/27 04:14:28, kalman wrote:
> On 2012/07/26 20:00:27, mitchellwrosen wrote:
> > On 2012/07/26 04:51:42, kalman wrote:
> > > this might as well be the same code that parses 'type' into a
PropertyType.
> > Can
> > > you pull that into a helper?
> > > 
> > > Let code that uses the model support what it can.
> > 
> > Hmm. Correct me if I'm wrong but it may not make sense to consider the same
> set
> > of types valid for both type_ and compiled_type. What about gurl and int64?
> > Those could only exist on the c++ side. Furthermore, it may be awkward to
pull
> > into a helper function because there is special handling in the case that
> > json_type is an array or an object.
> > 
> > What do you think?
> 
> Yes, that's true. Hmm.
> 
> For for the types that only make sense for compiled code, that can be left to
> the generators to figure out; nothing bad will happen.
> 
> For the types where special stuff is done, we can easily pull that out into
> here. Like,
> 
> def _JsonTypeToPropertyType(json_type):
>   if json_type == 'string':
>     return PropertyType.STRING
>   if json_type == 'any':
>     return PropertyType.ANY
>   ...
>   if json_type == 'int64'
>     return PropertyType.INT_64
>   raise NotImplementedError(...)
> 
> then here,
> 
> self.type_ = _JsonToPropertyType(json['type'])
> if self.type_ is PropertyType.ARRAY:
>   # normal array stuff
> elif self.type_ = PropertyType.OBJECT:
>   # normal object stuff
> 
> compiled_type = json.get('compiled_type', None)
> if compiled_type:
>   self.compiled_type = _JsonToPropertyType(compiled_type)

Done.

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
File tools/json_schema_compiler/cc_generator.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
tools/json_schema_compiler/cc_generator.py:472: '%(fundamental_value_dst)s'))
On 2012/07/27 04:14:28, kalman wrote:
> can you inline this value? It's only used once so unfortunately to have to
> scroll down 100 lines to see what it is.
> 
> I'd put it up on line 466,
> 
> if prop.type_ == prop.compiled_type:
>   assignment_target = '&%s->%s' % (dst, prop.unix_name)
> else:
>   c.Append('%(ctype)s temp;')
>   assignment_target = '&temp'

Done.

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
File tools/json_schema_compiler/cpp_type_generator.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
tools/json_schema_compiler/cpp_type_generator.py:119: convert_type=False):
On 2012/07/27 04:14:28, kalman wrote:
> Could you put this in 2 separate methods, GetType and GetCompiledType? It can
be
> as dumb as
> 
> def GetType(...):
>   return self._GetTypeHelper(...)
> 
> def GetCompiledType(...):
>   return self._GetTypeHelper(..., use_compiled_type=True)
> 
> def _GetTypeHelper(..., use_compiled_type=False):
>   ...

Done.

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
File tools/json_schema_compiler/cpp_util.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
tools/json_schema_compiler/cpp_util.py:88: from_: The variable name of the type
to be converted from.
On 2012/07/27 04:14:28, kalman wrote:
> ... as plain data or a reference.

Done.

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
tools/json_schema_compiler/cpp_util.py:89: to: The variable name of the type to
be converted to.
On 2012/07/27 04:14:28, kalman wrote:
> ... as a pointer.

Done.

https://chromiumcodereview.appspot.com/10825029/diff/4001/tools/json_schema_c...
tools/json_schema_compiler/cpp_util.py:96: }[prop.compiled_type] % (from_, to)
On 2012/07/27 04:14:28, kalman wrote:
> see previous comment about NotImplementedError.

Done.

[mitchellwrosen, 2012-07-31 00:10:37]

https://chromiumcodereview.appspot.com/10825029/diff/8002/tools/json_schema_c...
File tools/json_schema_compiler/cc_generator.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/8002/tools/json_schema_c...
tools/json_schema_compiler/cc_generator.py:470: .Append('if (!%s)' %
Ugh, mis-aligned indents here. I'll fix it in a second, sorry about that.

[not at google - send to devlin, 2012-07-31 06:37:41]

lgtm

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
File tools/json_schema_compiler/cc_generator.py (right):

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/cc_generator.py:356: if prop.optional and prop.type_
== prop.compiled_type:
line surprises me. Explain in comment perhaps?

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/cc_generator.py:587: 'failure_value': failure_value
ending with comma is fine, in fact nitfully preferred, since it makes it easier
to add additional lines to the object without worrying about commas.

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
File tools/json_schema_compiler/cpp_util.py (right):

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/cpp_util.py:116: raise NotImplementedError()
Exception message? "Conversion from blah to blah in blah not supported".

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
File tools/json_schema_compiler/model.py (right):

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/model.py:183: self.compiled_type = self.type_
a lot of repetitive assigning to compiled_type. Could be the source of subtle
bugs in the future? Certainly it could be more concise, by doing that "if
'compiled_type' in json" check after all this if/elif stuff.

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/model.py:261: raise NotImplementedError('Type %s not
recognized' % json_type)
you could do the old

try:
  return {
    'any': PropertyType.ANY,
    ...
  }[json_type]
except KeyError:
  raise NotImplementedError(..)

thing, right?

http://codereview.chromium.org/10825029/diff/13001/tools/json_schema_compiler...
tools/json_schema_compiler/model.py:306: INT_64 = _Info(True, "INT_64")
the c++ type is int64 not int_64 so this should be INT64.

[mitchellwrosen, 2012-07-31 17:50:25]

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
File tools/json_schema_compiler/cc_generator.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/cc_generator.py:356: if prop.optional and prop.type_
== prop.compiled_type:
On 2012/07/31 06:37:41, kalman wrote:
> line surprises me. Explain in comment perhaps?

Done.

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/cc_generator.py:587: 'failure_value': failure_value
On 2012/07/31 06:37:41, kalman wrote:
> ending with comma is fine, in fact nitfully preferred, since it makes it
easier
> to add additional lines to the object without worrying about commas.

'nitfully' - I like that. Done.

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
File tools/json_schema_compiler/cpp_util.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/cpp_util.py:116: raise NotImplementedError()
On 2012/07/31 06:37:41, kalman wrote:
> Exception message? "Conversion from blah to blah in blah not supported".

Right, meant to go back and put that in. I had to pull the try/catch outside of
the helper to get prop.name in the message. Hope that small bit of duplicate
code is okay.

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
File tools/json_schema_compiler/model.py (right):

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/model.py:183: self.compiled_type = self.type_
On 2012/07/31 06:37:41, kalman wrote:
> a lot of repetitive assigning to compiled_type. Could be the source of subtle
> bugs in the future? Certainly it could be more concise, by doing that "if
> 'compiled_type' in json" check after all this if/elif stuff.

Okay. I was originally thinking that a compiled_type is only valid if there's a
type as well. Should I put a check to see that 'type' is in the json if
'compiled_type' is as well, and throw a ParseException?

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/model.py:261: raise NotImplementedError('Type %s not
recognized' % json_type)
On 2012/07/31 06:37:41, kalman wrote:
> you could do the old
> 
> try:
>   return {
>     'any': PropertyType.ANY,
>     ...
>   }[json_type]
> except KeyError:
>   raise NotImplementedError(..)
> 
> thing, right?

Yes. My never-written-python-before-in-my-life is showing =(

https://chromiumcodereview.appspot.com/10825029/diff/13001/tools/json_schema_...
tools/json_schema_compiler/model.py:306: INT_64 = _Info(True, "INT_64")
On 2012/07/31 06:37:41, kalman wrote:
> the c++ type is int64 not int_64 so this should be INT64.

Sure, I actually changed it from INT64 to INT_64 because of an earlier comment
of yours. A typo I'm sure =)

[commit-bot: I haz the power, 2012-07-31 19:11:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mitchellwrosen@chromium.org/10825029/4004

[commit-bot: I haz the power, 2012-07-31 19:27:19]

Try job failure for 10825029-4004 (retry) on mac_rel for steps "base_unittests,
browser_tests, cacheinvalidation_unittests, jingle_unittests,
remoting_unittests, interactive_ui_tests, crypto_unittests, net_unittests,
unit_tests, gpu_unittests, nacl_integration, media_unittests,
safe_browsing_tests, ipc_tests, printing_unittests, sql_unittests,
content_unittests, sync_unit_tests".
It's a second try, previously, steps "base_unittests, browser_tests,
cacheinvalidation_unittests, jingle_unittests, remoting_unittests,
interactive_ui_tests, crypto_unittests, net_unittests, unit_tests,
gpu_unittests, nacl_integration, media_unittests, safe_browsing_tests,
ipc_tests, printing_unittests, sql_unittests, content_unittests,
sync_unit_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2012-07-31 21:30:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mitchellwrosen@chromium.org/10825029/4004

[commit-bot: I haz the power, 2012-07-31 22:47:51]

Change committed as 149302