Sender | Message | Time |
---|---|---|
25 Jul 2024 | ||
kaiyou | (Sorry if this is unclear, maybe I also misunderstood your question :x) | 19:44:38 |
kaiyou | I am affraid bw(ignore) requires br(temp) though, I am not sure how you may use the id outside the parsing logic. | 19:45:42 |
snover | got it. i think the best thing right now that you can do is to write a member function on the enum that returns the correct id for each enum variant. binrw does not have any thing right now that does this automatically. there are some other crates that you could use to derive. either case ends up requiring to write the magic value twice, which is unfortunate. you can also use import and pre_assert to pick an enum variant instead, but i do not think that any of this will avoid the current requirement to duplicate something—either you will have one unit enum with the magic numbers and then a second data enum with the same variants, using pre_assert , or you will have two things with the same magic numbers, using magic . | 19:49:16 |
ckrenslehner | In reply to @kaiyou:tedomum.netThanks I get this and I can also use this as a workaround. The only thing which bothers me is, that I need to use a kind of half init struct when I want to write the data. When I create a variable of this structure I need to pass a value to the enum and the id (even though the id kinda redundant) of course I can just use private fields and new and just live with it | 19:49:27 |
snover | * got it. i think the best thing right now that you can do is to write a member function on the enum that returns the correct id for each enum variant. binrw does not have any thing right now that does this automatically. there are some other crates that you could use to derive. either case ends up requiring specifying variants twice, which is unfortunate. you can also use import and pre_assert to pick an enum variant instead, but i do not think that any of this will avoid the current requirement to duplicate something—either you will have one unit enum with the magic numbers and then a second data enum with the same variants, using pre_assert , or you will have two things with the same magic numbers, using magic . | 19:49:35 |
ckrenslehner | In reply to @snover:matrix.orgYes that's exactly what I am struggling with! In my original code I was using pre_assert. But then I realized that there is no round-trip anymore. Now I tried to smash everything together to avoid code duplication. I have the feeling that I might be able to achieve it using a custom stream but 3h+ of trying did not yet bring a real success. Basically I wanted to introduce a kind of trait bound which requires T: meta::WriteMagic and then I wanted to use ::Magic to get the actual value. But somehow I just don't succeed. Anyway it was a good learning experience so far :-D | 19:54:58 |
ckrenslehner | * Yes that's exactly what I am struggling with! In my original code I was using pre_assert. But then I realized that there is no round-trip anymore. Now I tried to smash everything together to avoid code duplication. I have the feeling that I might be able to achieve it using a custom stream but 3h+ of trying did not yet bring a real success. Basically I wanted to introduce a kind of trait bound which requires T: meta::WriteMagic and then I wanted to use `T as meta::WriteMagic::Magic` to get the actual value. But somehow I just don't succeed. Anyway it was a good learning experience so far :-D | 19:56:03 |
ckrenslehner | * Yes that's exactly what I am struggling with! In my original code I was using pre_assert. But then I realized that there is no round-trip anymore. Now I tried to smash everything together to avoid code duplication. I have the feeling that I might be able to achieve it using a custom stream but 3h+ of trying did not yet bring a real success. Basically I wanted to introduce a kind of trait bound which requires T: meta::WriteMagic and then I wanted to use <T as meta::WriteMagic::Magic> to get the actual value. But somehow I just don't succeed. Anyway it was a good learning experience so far :-D | 19:56:31 |
snover | i suppose you could write a macro to try to avoid duplicating the values | 19:56:41 |
ckrenslehner | * Yes that's exactly what I am struggling with! In my original code I was using pre_assert. But then I realized that there is no round-trip anymore. Now I tried to smash everything together to avoid code duplication. I have the feeling that I might be able to achieve it using a custom stream but 3h+ of trying did not yet bring a real success. Basically I wanted to introduce a kind of trait bound which requires T: meta::WriteMagic and then I wanted to use `<T as meta::WriteMagic>::Magic` to get the actual value. But somehow I just don't succeed. Anyway it was a good learning experience so far :-D | 19:57:31 |
snover | i have been writing c++ lately so i will not even attempt to provide a starter since it would be utterly broken but since it is just variant names and literal values it should be a mercifully easy macro_rules application | 20:02:31 |
ckrenslehner | Good point thanks. I will give this a try :-) | 20:06:00 |
26 Jul 2024 | ||
ckrenslehner | In reply to @snover:matrix.org https://github.com/Krensi/binrw-datapoints Maybe someone could benefit from this example of how I control writing and reading only via the enum. I also played around with generics to support different types for the encoding format value is the only item of actual interest which is the enum with your tipp to use macro_rules it was actually very easy to get the ID - thanks again :-) | 19:30:55 |
3 Aug 2024 | ||
Néfix Estrada joined the room. | 09:41:20 | |
Néfix Estrada | Hello! Is it possible to use both a
Thanks! :) | 09:43:14 |
Néfix Estrada | And another question. I'm parsing packets. All of them have a header, which specifies the packet type:
The
And then, there's each packet, which has its own structure. Is it possible to make a "generalized parser"? E.g. have a Packet union, which reads the header type and, depending on the packet type read one packet or another. Also, I'd like to have the header "embeded" in each packet, since there are some that depend on it for lenghts:
I'd be nice to be able to simply write a packet and automatically get the header, so:
| 09:50:11 |
snover | In reply to @nefix:matrix.org When you use
| 20:43:16 |
snover | In reply to @nefix:matrix.orgUse a data enum with magic attribute. | 20:43:45 |
snover | In reply to @nefix:matrix.org* Use a data enum with magic attribute on the variants. | 20:43:57 |
Néfix Estrada | In reply to @snover:matrix.orgI see, thanks! | 20:44:31 |
Néfix Estrada | In reply to @snover:matrix.orgCould you provide an example? Thanks! :) | 20:45:53 |
snover |
| 20:47:46 |
Néfix Estrada | I see, I think I've got it. Thanks! :) | 20:49:21 |
Néfix Estrada | In reply to @snover:matrix.orgAnd how can I make the len part of the enum? Or do I need to specify it in all the Packets? Thanks! :) | 21:13:10 |
Néfix Estrada | Right now it's looking as follows:
| 21:13:46 |
snover | to use data enum like this would specify in all of them. you could use composition of inner struct if you want. a common alternative approach for this case is to use a wrapper outer struct and then inner enum and pre_assert on the id instead. | 21:14:58 |
snover | pub struct DataPkt { id: u16, len: u16, #[br(args(id, len))] data: Packet } #[br(import(id: u16, len: u16)] enum Packet { #[br(pre_assert(id == 1))] HandshakeRequest(#[br(args(len))] HandshakeRequestPacket), … } | 21:17:37 |
snover | whoops. formatting. | 21:17:46 |
snover | *
| 21:17:55 |
snover | *
| 21:18:36 |