News for hackers. Stuff that matters.
Re:Kaitai: Describe the structure of data, not how you read ... by jacb on Saturday December 05, 2020 @03:41PM (#25318125)
I might be missing something - why would this be a breakthrough? It sounds complicated to generate the interfaces, sure, but is there a theoretical problem blocking this, or just practical?
Re:Kaitai: Describe the structure of data, not how you read ... by convolvatron on Saturday December 05, 2020 @03:57PM (#25318274)
I've looked at this problem quite a bit over the years...I agree with you completely. there isn't anything fundamental here, just the normal cultural adoption issues, usability, etc. There may be some compilation/complexity issues around formats with variable length fields and self-description, but certainly less problematic than general purpose programming.

I really wish though that there were more traction here, as I really believe that we should be quite prepared do deal with bits and not protobufs by default. nothing wrong with protobufs for quite a number of uses. I just don't know why people are so afraid of and/or biased against bit strings.

Re:Kaitai: Describe the structure of data, not how you read ... by joshspankit on Saturday December 05, 2020 @04:33PM (#25318606)
Through this thread I really feel like I’m missing something.

Are we not talking about writing binary files that conform to the spec?

Like, in the case of a GIF: simply writing valid garbage data should produce a file that presents as a valid GIF with noise for the image. Similarly: reading the file through the parser and writing it out unmodified should create an identical file (assuming no stenography).

Right?

Re:Kaitai: Describe the structure of data, not how you read ... by IceDane on Saturday December 05, 2020 @07:10PM (#25319678)
You're right. The person saying this would be a breakthrough doesn't understand what this is doing.

There are already similarly declarative tools which can accomplish this. Haskell has binary parsing libraries which work similarly and give you both reading and writing capabilities.

Re:Kaitai: Describe the structure of data, not how you read ... by spullara on Saturday December 05, 2020 @05:21PM (#25318970)
I honestly don't get it either. The inverse of the read spec is the write spec. My guess having not dug deeply is that they don't distinguish between required and optional fields, that said, they should still be able to write what they have based on the read spec but could potentially be still an invalid file.
Re:Kaitai: Describe the structure of data, not how you read ... by armsforsharks on Saturday December 05, 2020 @06:53PM (#25319574)
It's a really interesting idea! I'm also surprised there hasn't been much traction here. I've started a Rust library for this: https://github.com/sharksforarms/deku

It's a declarative bit-level symmetrical reader writer generator library.

Re:Kaitai: Describe the structure of data, not how you read ... by afranchuk on Saturday December 05, 2020 @09:23PM (#25320457)
Yeah I was also confused. I wrote a bidirectional parser/writer layer for yaml in a haskell program I had at work. The yaml structure mappings were all declarative in the code and even allowed documentation for the structures to be printed out. It's not that hard once you define the primitive bidirectional (higher-order) mapping function to go from a `Configurable a` to a `Configurable b`, the rest kind of unfolds from there.
Re:Kaitai: Describe the structure of data, not how you read ... by HelloNurse on Sunday December 06, 2020 @10:37AM (#25324157)
Binary file formats can be vastly more convoluted than YAML. For example, consider roundtripping ZIP archives or PDF documents, or both at the same time (see https://www.alchemistowl.org/pocorgtfo/).