Add docs on the return type for DekuRead#196
Conversation
|
Also, it's probably worth adding an example of a custom implementation of |
|
Thanks! I made some other modifications here: fcfdc24 |
|
I created this ticket for the DekuRead/DekuWrite implementation: #197 Out of curiosity, is the data format you're parsing shareable? I'd like to understand your use-case better. Pseudo code/format works too. |
|
Yeah sure! I'm trying to write a parser for RTMP. The part I wound up implementing myself was the Chunk Basic Header. Essentially the issue is that the header is either one, two, or three bytes. And the length of the header is determined by the last six bits of the first byte. So I could either define a bunch of Here's the implementation I wound up writing. Feel free to use this as your example for the docs, although it may be worth generify-ing it slightly so you don't need any background on the RTMP Chunk Stream to understand what's going on. Also -- this library is awesome! I tried writing an RTMP parser by hand some months ago, and Deku saves me so much time, and it's always correct. Huge props ❤️ |
|
@sharksforarms pinging just in case u didn't see this 🙈 forgive me |
|
Thanks @caass for the kind words I appreciate it! I've added your example to the issue 👍 |
When trying to write my own implementation of DekuRead, instead of
#[derive]ing it,I was a little confused about the function signature of
DekuRead::read.Adding the return type to the documentation makes it easier for folks to write
their own implementations in cases where the provided tooling
(which is very good and extensive, btw) doesn't suffice.
FWIW my specific use-case involves a bitfield that's of variable length, and I couldn't think
of a simple way to use the
#[deku]attributes to make it work in an elegant way.