It may make sense to display KS type and length in the Extractor for each item

[KOLANICH]

No description provided.

[hello-adam]

Ok, the keys being used in the extractor are just the names of generic HighlightRanges, so I think this is doable by just making the string something like "name(type:length)" in the parser instead of just "name". Let me know if you have a suggestion for exactly how the string should be formatted (e.g. "name:type[length]", "name : type : length" etc.)

[KOLANICH]

name <type> (length) I guess. But having own colums is still beneficial.

[hello-adam]

yeah, there are definitely some weaknesses with how decoupled plugins are. It's possible that the rangehighlight strings could have a syntax like "[val1, val2, val3]" that is readable on its own by a dumb plugin, but then also parse-able into columns by the extractor or the KS plugin itself. I'll start with just the single-column compound string for now.

[hello-adam]

Let me know if the new type and value display satisfies this requirement

[KOLANICH]

Type and value display on the screenshot looks OK, what is missing is displaying of size of arrays. Also a yet another issue - it doesn't work for me locally, 2 column is empty for me.

[hello-adam]

Ok, adding an array type should be pretty straightforward.

The type column will be empty unless the type is an Enum or a KaitaiStruct - I can't find a way to see the other types (u4, u1, etc) in the parsed data, and saying the Python type ("int", "float", ""bytes", etc) seems like it might be noisy. Maybe not though?

[KOLANICH]

The type column will be empty unless the type is an Enum or a KaitaiStruct - I can't find a way to see the other types (u4, u1, etc) in the parsed data

Thanks, exactly this case for fields in structs. But it also doesn't work for array items of struct type.

I guess we can just parse KS YAML and fetch types from there for primitives. Alternatively, it can be possible to create a bug in KS for adding this info by inheriting primitive types and using their subclasses.

[hello-adam]

I'd rather hold off on adding a parser for the KS YAML - I'll submit the issue for it to be included in the _debug data somehow.

[hello-adam]

I took a minute to think about this, and I guess we can infer primitives from the size, the Python type, and an evaluation of the actual data chunk (for signed-ness and endianness), so we wouldn't need to parse the KSY for most (all?) cases except the binary one you bring up in kaitai-io/kaitai_struct#896

Am I missing something?

[KOLANICH]

Looks like that that's all for the fields. There are also value-instances, for which no _debug is generated, and which type is usually infered, and params, which type is implicitly specified. But they are not so important since they don't have to be visualized, so they can wait.

Also I remember there was an issue about making KSC embed into code info in machine-readable form having not involved into parsing directly (--attrs (-webide-representation, -orig-id), meta), but I couldn't find that issue.