| 3 Aug 2024 |
 Néfix Estrada | Oooh | 21:19:03 |
| Néfix Estrada | So, I'd do DataPkt::read() and the response would be a Packet? | 21:19:23 |
 snover | no it would be DataPkt. somehow if you plan to write back out you still need the id and size to write out again | 21:22:04 |
| Néfix Estrada | I see | 21:22:17 |
| snover | these are just different approachs people use for different use cases depending on what feels like it works best to them | 21:22:26 |
| snover | if you are always going to have the length for every variant then having an outer packet type and then inner data type means you do not have to duplicate the field but then you are passing args if the inner variants also need length. this is not necessarily bad since then that requirement is more explicit since it is in the args. | 21:23:33 |
| snover | but it is kind of up to what feels best to you and what your goals are | 21:23:48 |
| Néfix Estrada | The "bad" thing about this is that, when writting, neither the ID or the length are going to be autopopulated | 21:23:54 |
| snover | that’s right. so i would typically use the other approach of reading in the length individually. but sometimes people will just do bookkeeping in the outer struct and that is a valid approach too. | 21:25:36 |
| Néfix Estrada | I see. Thank you very much!! | 21:25:55 |
| 10 Aug 2024 |
| snover | octylFractal: i see you, fellow btrfs sufferer :-) | 00:12:23 |
| 2 Sep 2024 |
|  redstrate removed their profile picture. | 14:30:05 |
| 3 Sep 2024 |
| redstrate changed their display name from redstrate to redstrate ✈️. | 14:40:41 |
| redstrate set a profile picture. | 15:04:24 |
| 4 Sep 2024 |
| redstrate changed their display name from redstrate ✈️ to redstrate 🇩🇪. | 06:44:14 |
| 9 Sep 2024 |
|  chinmay changed their display name from p00f to chinmay. | 19:08:28 |
| 12 Sep 2024 |
| redstrate changed their display name from redstrate 🇩🇪 to redstrate. | 20:07:22 |
| 14 Sep 2024 |
|  unfoot joined the room. | 00:20:28 |
| unfoot | I just came across binrw -- looks awesome, great documentation, nice tutorial. thanks. | 00:20:57 |
| unfoot | I'm just starting to read the code. I started with impl<T> BinWrite for Vec<T> ... unless I'm mis-reading it, it looks like a Vec gets written as just its elements... no length? | 00:46:08 |
| unfoot | ... which matches up with the examples that often show a separate length field before a Vec ... (which also makes sense, because it gives the user control over how wide to make the length representation) | 00:47:22 |
| snover | yes, that’s right | 02:29:55 |
| 15 Sep 2024 |
 quarky | hi! when writing, is there any way to have alignment for each element in a Vec? so, for example, Vec<NullString> would have each string start on a 4-byte boundary - ideally without redefining NullString?. I know about align_after but it only applies to fields, so I guess the vec itself would align rather than the elements. | 06:54:19 |
| snover | quarky: there is not any thing built in. you could avoid changing the type by writing and using a custom writer (write_with) instead of using the default Vec implementation. if you were to decide to change the type i would suggest to change the Vec so you only have one (or two, if you need an index for O(1) lookup) allocations total instead of one per string. | 16:36:02 |
| 23 Sep 2024 |
|  nota changed their display name from notafile to nota. | 09:24:58 |
| 30 Sep 2024 |
| quarky changed their profile picture. | 10:13:37 |
| 1 Nov 2024 |
| quarky changed their profile picture. | 03:22:15 |
| 7 Dec 2024 |
|  Wojciech Niedźwiedź joined the room. | 21:17:15 |
| Wojciech Niedźwiedź | heyy, how to handle EOF? I don't know how much data I'll be reading, so something like
T::read_opt(reader: Read + Seek) -> Result<Option<T>> {}
would save my butt at this point | 21:18:10 |
| 12 Dec 2024 |
|  Romain joined the room. | 03:20:12 |
