BinStruct is a library which main function is to convert readable as possible declarations to robust and performant implementations. It will generate set of functions to make parse → decode → create_new → send process trivial.
I also included example implementation of png parser using BinStruct as alternative to suggested in article in this thread way using raw pattern matching.
I would be very pleased if you could share your ideas that could be implemented using BinStruct, and I could help you with their implementation and later add them to examples. I’m too tired right now, as I’ve spent about a month preparing this library for publication. Custom types and flexible type conversions were specifically added for the community. I apologize for the messy formatting in the documentation and general disorder. I continue working on these improvements.
You can feel free to let me know anything you feel about and ask any questions.
I’m sorry again for this mess. I have a lot of examples from private products which I can’t paste. I want to grow use cases and docs from now every day. You can help me with ideas of any protocol you have worked with but don’t happy with code or you want to work this and I can add such examples. I just don’t have enough time for everything, was busy on work and implementing features/testing/writing basic docs for this lib.
Hi, good library, I’ve read the example and it looks promising! I’ve briefly peeked into the code and it looks interesting, and it has some special formatting, I love that. I also found that some modules are empty and exist only for sake of documentation. I’d suggest to just write separate .md doc files and expose them in hexdocs (absinthe documentation is a good example of how to do this).
I’ll definitely give it a deeper look in some near future!
I like current way of how automatic doc tests are works. Can I achieve same with separate .md’s?
What is actually special formatting?
Some reasoning:
My main goal is to keep things as they are. Simple things will be simple anyway. Hard things will be hard anyway. I don’t see reason in any shortcuts for example for situation where some length is may be directly inferred from other field like most libraries I saw do. Every attempt of introducing multi-field writer or any other complex behavior has failed.
I ended up with idea of dynamic behavior is always a callback, there is a single way of creating virtual field during parse/decode using read_by and single way of creating anything in new context automatically using builder. I got so far with idea not mixing things and I liked it. Once you have finished writing your declaration and tested it you anyway can forget about what is inside. You have guarantees if it is working alone it will be working same inside any tree. Good way to reuse parts is to compose it into higher order macro, which again don’t care of presence of shortcuts and so on.
