Adding whether a given field is filling a hole.

Adding whether a given field is filling a hole.

R=viettrungluu@chromium.org

[qsr, 2014-05-06 15:15:01]

I need this information, because when deserialization, if a field that is not
present is filling a hole, I would need to skip bytes to get to the next field.

[viettrungluu, 2014-05-06 21:15:06]

Hmmm, it seems to me that you could infer this from the offset (and ordinal)
information, no?

I admit it's unclear to me what's the advantage of deserializing using a
"linear" approach, rather than always just using the offsets.

(The reason I'm resisting this is that packing should probably be moved to the
"front-end", the packing information put into the IR, and the IR mojom-ified.)

[qsr, 2014-05-07 08:07:36]

On 2014/05/06 21:15:06, viettrungluu wrote:
> Hmmm, it seems to me that you could infer this from the offset (and ordinal)
> information, no?

 Can you elaborate? I don't see how to find this with just ordinal and offset:

int32 x1
int64 x2
int16 x3
int16 x4

How would x4 know that it is in a hole with just its ordinal (3) and its offset
(6), given that in the following case:

int16 x1
int16 x2
int16 x3
int16 x4

the same x4 has exactly the same ordinal and offset?

> I admit it's unclear to me what's the advantage of deserializing using a
> "linear" approach, rather than always just using the offsets.

 Hum, I mainly followed the js approach, so I didn't think a lot about it. The
main issue I will have with just using offset is serializing/deserializing
boolean where the offset is not enough, you also need some bit information,
information that you can keep around if you (de)serialize linearly.


> (The reason I'm resisting this is that packing should probably be moved to the
> "front-end", the packing information put into the IR, and the IR mojom-ified.)

 Sorry, not sure to get what you mean by IR. But even if packing is mojom-ified,
we can still add this boolean, no?
 Also, don't you have some kind of bootstrap issue here, if we need packing to
generate code for mojom and packign is mojom-ified? I think I'm missing
something here...

[viettrungluu, 2014-05-07 17:08:25]

On 2014/05/07 08:07:36, qsr wrote:
> On 2014/05/06 21:15:06, viettrungluu wrote:
> > Hmmm, it seems to me that you could infer this from the offset (and ordinal)
> > information, no?
> 
>  Can you elaborate? I don't see how to find this with just ordinal and offset:
> 
> int32 x1
> int64 x2
> int16 x3
> int16 x4
> 
> How would x4 know that it is in a hole with just its ordinal (3) and its
offset
> (6), given that in the following case:
> 
> int16 x1
> int16 x2
> int16 x3
> int16 x4
> 
> the same x4 has exactly the same ordinal and offset?

I meant ordinal and offset in comparison with the offsets of things with lower
ordinals (i.e., if something with a lower ordinal has a higher offset, then
you're filling in a hole).

> 
> > I admit it's unclear to me what's the advantage of deserializing using a
> > "linear" approach, rather than always just using the offsets.
> 
>  Hum, I mainly followed the js approach, so I didn't think a lot about it. The
> main issue I will have with just using offset is serializing/deserializing
> boolean where the offset is not enough, you also need some bit information,
> information that you can keep around if you (de)serialize linearly.

In that case it should have a bit offset, I guess.

> 
> 
> > (The reason I'm resisting this is that packing should probably be moved to
the
> > "front-end", the packing information put into the IR, and the IR
mojom-ified.)
> 
>  Sorry, not sure to get what you mean by IR. But even if packing is
mojom-ified,
> we can still add this boolean, no?

The IR (= intermediate representation) is currently what's printed out when you
pass --debug_print_intermediate (it's essentially the output of the
parse/translate stage).

Yes, you're right that we can still add the boolean, but the mojom description
of a mojom file should be reasonably minimal and well-designed. (Think of it as
something that may be built into protocols for "introspection"/debugging
purposes.)

>  Also, don't you have some kind of bootstrap issue here, if we need packing to
> generate code for mojom and packign is mojom-ified? I think I'm missing
> something here...

It's the same sort of bootstrapping issue that you get when building a compiler
for a new language in its own language. :)

So at least initially you'd have to hand-roll a deserializer (for a particular
mojom) in python.

[qsr, 2014-05-12 13:56:56]

Closing this, as I will use offset and but to serialize/deserialize.