Split --debug mode into several flags

[GreyCat]

I guess the time had come to think of splitting --debug mode, which was originally designed solely for visualization tools integration, into several meaningful compilation options / flags:

1. Store positions of attributes in the stream — my_obj._debug['attr_id']
   1.1. May be additional submode — store positions of individual elements in the array
2. Read-in-constructor vs separate constructor + _read() call
3. Dump sequence of seq elements as array — MyType::SEQ_FIELDS

May be also we could think of:

• dump doc / doc-ref elements as strings for visualization tools to annotate fields
• dump other metainformation (title, license, etc) as strings
• dump unofficial YAML fields (i.e. stuff like -webide-representation, etc) as is into relevant parts of the class
• for hardcore languages such as C++ — preparing arrays of getter function pointers, i.e. something like:

The main concern is that (1) is super slow and actually rarely needed outside of visualization / debugging purposes. (2) is super useful per se for parsing "bad" data and being able to cope with half-filled classes. (3) is not a big deal, but it adds extra pollution and, again, is pretty much useless outside of scope of vis tools.

From top of my head, I'd go with --debug-pos for (1), --no-ctor-read for (2), --debug-seq for (3).

[KOLANICH]

For 1 we need more meaningful names. I guess _offsets and --save-offsets.

[GreyCat]

Currently, it's highly implementation-dependent:

• Ruby uses:
  • _debug hashmap of attribute name strings which map to:
    • {:start => ..., :end => ...} if that's a regular attribute
    • {:arr => [{:start => ..., :end => ...}, {:start => ..., :end => ...}, ...]} additionally, if that's an array
  • SEQ_FIELDS class-level constant, array of strings
• Java uses:
  • _attrStart + _attrEnd, which are Map<String, Long>
  • _arrStart + _arrEnd, which are Map<String, ArrayList<Integer>>
  • _seqFields class-level static string array
• JavaScript uses:
  • _debug object, inside which by name of the attribute we can get:
    • { start: ..., ioOffset: ..., end: ... } for regular attributes
    • { arr: [{ start: ..., ioOffset: ..., end: ... }, ...] } for arrays
• Python uses:
  • _debug dictionary of attribute name strings which map to:
    • {'start': ..., 'end': ...} if that's a regular attribute
    • {'arr': [{'start': ..., 'end': ...}, {'start': ..., 'end': ...}, ...]} additionally, if that's an array
  • SEQ_FIELDS class-level constant, array of strings

[GreyCat]

--debug is now separated into --no-auto-read for (2) and --read-pos for (1).

[GreyCat]

Python support was added in kaitai-io/kaitai_struct_compiler@18cecf4 in 2018-07. I'll update the overall description of data structures above.

[GreyCat]

The --debug flag has been split. On the second though, it's kind of pointless to have separate flag for SEQ_FIELDS generation. Right now it just uses config.readStoresPos (--read-pos in command line).

Closing this one as done.