Open Mingun opened 4 months ago
Not solving the problem, but.:
d = Struct(
"a" / Computed(42),
"b" / Computed(this.a),
)
could be a interesting alternative to the lambdas... it allows for the compile feature to work better (or at all).
would you mind to check this PR?
https://github.com/franzhaas/construct/tree/speedOptimisations
does this solve your issue (this will not work with the lambdas, only with expressions...)?
Kaitai Struct project has a Construct target and it can define so called "instance properties" for types. That properties can use another instance properties to calculate their values.
That properties generated as Construct's
Computed
fields. For example, the KSYwill be generated as:
This code works perfectly fine, but if we change the order slightly in KSY:
then the generated code would be:
Now, however, the exception is raised when you try to
d.parse(b"")
:This is because Kaitai Struct internally keeps instances sorted by name to generate code in the same order each time. Although
IndexMap
would be better in that case (to keep the order the same as in KSY), it still suffer from that problem, because user should ensure the correct order, which is conceptually wrong for the declarative format.The exception seems counter-intuitive in any way. We use a lambda to define rules how property should be computed, but accessing of other properties inside lambda does not call their evaluation, but returns an error instead.
You can see results of such behaviour on the Kaitai CI page which tracks how much features each target language is supported: https://ci.kaitai.io/. For example, the test
BcdUserTypeBe
failed because of this. Although this can be fixed from Kaitai side by generating instances in topological order, I think, that Construct should not raise errors in this case.