Enum feature: shifted values

[lundmark]

Enum feature: shifted values (1ULL << 34ULL) etc.

[wc-duck]

Sounds like valid requests, would you mind doing one issue per request?

[lundmark]

Sure thing!

[lundmark]

Did you fix it? I still kept this one as a feature :)

[wc-duck]

Since I'm working on enums now this might get in there as well... But I'm not sure how to support this in a nice way? This would make the value a string and I would need to create a small DSL for this. Maybe there is a better way to do it directly in json? Something like "bits" : [2, 4]? But all suggestions are welcome!

[lundmark]

This is a suggestion of what it could look like:

"MyFlags" : { "values" : [ { "name" : "MY_FLAGS_NONE", "value" : 0 }, { "name" : "MY_FLAGS_SOME", "bits" : [ 16 ] }, { "name" : "MY_FLAGS_SOME_LESS", "bits" : [ 15 ] }, { "name" : "MY_FLAGS_COMBINED", "combine" : [ "MY_FLAGS_SOME", "MY_FLAGS_SOME_LESS" ] } ], "type" : "uint32" }

I guess? Does that seem reasonable?

[wc-duck]

Quite verbose :(... Maybe some mini-DSL is better?

"val1": "bits(1)", "val2": "bits(2,3)", "val3": "combine(val1,val2)"

I have to think about it a bit more

[wc-duck]

Would #126 be enough to solve this?

[lundmark]

126 is not enough, but it's a very good part of the way! binary format is useable, but not as useable as the bitshift-thing.

[wc-duck]

I was working on #126 last night when it hit me that I might not be solving the correct issue. Supporting bitflags in enums as enums work now will be quite hard, at least for bin -> text. I could maybe "guess" what values made up the value but that sounds brittle. What I thought about instead was adding a new "type" implemented by a flag on enums. "flags" : true would make all enums-values into 1-bit values, would pack to an enums and be specified as [ "value1", "value5"] in text. Does that sound like a good solution? If I go this route I might not implement #126 and auto-add #124 if an enums is a flag-enum.

[wc-duck]

58 is also mentioning bitfield ops on enums, do you have any specific usecasese for this as I have a hard time coming up with cases for myself where I would do this in dl-data

[lundmark]

Right so the issue is mainly when declaring the types not when reading actual data. You want to be able to configure bits to exact bitfields. You want to be able to specify that a certain flag is some so upper bits, or you want a value to be defined to another value but with not applied, and all of those bitfield settings. This is not because you neccessary want to READ something like that from a config file, but you want to declare a certain value of a certain enum to be a very specific bitfield and all that it entails.

Does that make sense?

Cheers, Simon

On Mon, Jul 29, 2019 at 12:40 PM Fredrik Kihlander notifications@github.com wrote:

58 https://github.com/wc-duck/datalibrary/issues/58 is also mentioning

bitfield ops on enums, do you have any specific usecasese for this as I have a hard time coming up with cases for myself where I would do this in dl-data

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wc-duck/datalibrary/issues/57?email_source=notifications&email_token=AAC44MVP3DZJF2EGJM2N53TQB3CJVA5CNFSM4EGZI4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3AKDDA#issuecomment-515940748, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC44MTIXXSWQSLMTJ3UBDLQB3CJVANCNFSM4EGZI4SA .

[wc-duck]

That is still not touching on your usecasese, just re-stating what was said in the issue. My biggest problem here is the fact that I'm not sure how to handle bin to text conversions of custom bitfield enums. The only thing I can think of, except the one above, is to support reading enums from ints and fall back to that if unpack could not find a good marching enum-value. But I'm not really convinced that it is worth it... Yet.