01:17 DemiMarie: wl_shm is an (extremely) special case
07:33 daniels: dmabuf is extremely the same
07:48 emersion: dmabuf doesn't have an enum
07:48 emersion: but tehre are more weird cases
07:49 emersion: e.g. when an external enum is referenced
07:49 emersion: (doesn't make sure to use the object version to check for validity there)
07:49 emersion: sense*
10:34 wlb: wayland-protocols/main: Simon Ser * xdg-decoration: add invalid_mode error https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/df2b5e5e7b50 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
10:34 wlb: wayland-protocols Merge request !265 merged \o/ (xdg-decoration: add invalid_mode error https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/265)
12:28 kennylevinsen: mclasen: my point was to abstract away from both rust and glib
12:34 kennylevinsen: changed the wording to help in that regard
12:35 mclasen: its fine, just a tangent to avoid
12:35 kennylevinsen: I agree
13:30 emersion: yeah, i don't think it was kenny's intention to compare rust and glib - on the contrary, the conmment explained how these are somewhat similar (provide unsafe funcs taking already-validated strings)
13:34 mclasen: ftr, the functions aren't unsafe, they simply need to be used according to their documentation
13:38 emersion: right, "unsafe" is rust terminology
13:39 emersion: (for "might blow up")
13:39 DemiMarie: Exactly
13:43 mclasen: I know
13:49 DemiMarie: I’d like to add enough information to the protocol XML so that libraries can validate enum values automatically.
13:50 DemiMarie: Right now I have code that automatically validates enum values, but it emits a wl_display.invalid_method error.
13:57 mclasen: does this work come with tests ?
13:57 mclasen: better tests would be a most useful outcome
13:57 DemiMarie: Not yet, and it is for ocaml-wayland, not libwayland.
13:58 DemiMarie: ocaml-wayland uses generated code for unmarshaling so this kind of change is much simpler
14:01 DemiMarie: If I add this to libwayland it will also generate an invalid_method error, unless the XML is changed to provide more information.
14:03 DemiMarie: There ought to be integration tests in the form of a standalone binary that can be used with any server.
14:03 vyivel: way-assay might be that
14:03 mclasen: that would be ideal
14:06 DemiMarie: mclasen: what do you think about automatic enum validation in and of itself?
14:07 DemiMarie: For tests, I think the best approach is to generate the tests from the protocol XML, but that is likely out of scope for my current project.
14:29 emersion: DemiMarie: the wayland XML semantics is that values can live outside of the enum
14:29 emersion: that could be seen as a defect of the original design
14:30 DemiMarie: Fixable one, though: add a new attribute that specifies an error for out of range enums.
14:32 kennylevinsen: if the issue is that the range is not defined by the spec, how would you know if an enum is out of range?
14:33 DemiMarie: The presence of the new attribute would imply that the range is defined by the spec.
14:33 kennylevinsen: Okay, that at least does seem possible
14:34 emersion: yes, that would be one way to do it
14:34 emersion: (still unclear how that would work for foreign enums)
14:35 kennylevinsen: although note that some enums are bitmasks (e.g., `zwlr_layer_surface_v1::anchor`), so that's at least two different validation types
14:35 emersion: the auto-generated libwayland validators handle this
14:36 kennylevinsen: oh yeah, we have a flag for that already - nice
14:52 wlb: weston Merge request !1608 opened by () Add support for LED_COMPOSE and LED_KANA USB HID LEDs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1608
15:16 DemiMarie: emersion: for foreign enums my plan is to include the generated headers for the other protocols if possible
15:16 DemiMarie: If that is not possible, I can use extern symbols.
15:17 emersion: that doesn't help trying to validate them
15:17 emersion: foo has version 1, and an enum with entries "a", "b
15:17 emersion: bar references such enum
15:17 emersion: foo introduces v2 with a new entry "c" for the enum
15:18 emersion: from bar, how to validate the foo enum?
15:19 DemiMarie: Call foo's validation function?
15:20 emersion: with v1? or accept v2 values?
15:20 emersion: what if the new enum entry requires special considerations in bar?
15:20 DemiMarie: How is a compositor supposed to know what to do?
15:20 emersion: right now it's up to the protocol docs
15:21 emersion: and most of it is 🤷
15:22 DemiMarie: Any specific protocols with this problem?
15:22 emersion: in the most complicated instance, we'd need to define a mapping between bar's versions and accepted foo enum versions
15:23 emersion: or pass a version number in the bar request
15:23 emersion: hm, latter would not work, nvm
15:24 emersion: worst case, foo could have an enum entry saying "from version 2, behavior changes"
15:24 emersion: (wl_data_* has some of these iirc)
15:26 emersion: the other direction (foreign enum in an event) is also interesting
15:26 DemiMarie: Could this be made an error condition, with the resolution being to copy and paste the enum definition?
15:27 emersion: popular foreign enums are: wl_output.transform, wl_pointer.button_state, wl_pointer.axis_source, wl_pointer.axis
15:27 emersion: well, i think it's a bit late for that
15:27 emersion: since it's a pretty widely used feature
15:30 DemiMarie: Could the existing ones be special-cased in the scanner?
15:43 DemiMarie: More generally, is the XML meant to include semantics or just the wire format?
15:58 kennylevinsen: Hmm? The XML specs define high-level messages and their semantics, not wire format
15:59 DemiMarie: I'm wondering if I am trying to do too much.
16:03 soreau: less is the new more
16:05 kennylevinsen: as `man 1 more` states, "Users should realize that less provides more"
16:06 DemiMarie: soreau kennylevinsen: are you joking or being serious?
16:07 kennylevinsen: I’m just quoting the man page
16:11 kennylevinsen: But it might seem like you’re trying to fight an uphill battle - adding the foreign enum flag and then skipping all validation of that, checking just the range of “normal” enums could be a simplification
16:11 kennylevinsen: Foreign enums are special regardless
16:11 emersion: Kenny follows man pages for all important life decisions
16:12 kennylevinsen: When I have a kid, I’ll hand them the command-line “man man” and consider my job raising them done
16:12 emersion: rtfm education
16:13 soreau: I'll teach mine to rtfs :P
16:19 kennylevinsen: DemiMarie: you can also consider if invalid enums is enough of an issue to bother with at all of course - the problem is much smaller than the utf8 validity thing, yet more annoying to implement
16:20 kennylevinsen: Your time has value, so spend it wisely
20:59 daniels: DemiMarie: the XML doesn't try to encode every possible error condition - for instance, trying to make a toplevel from a surface that's also a subsurface is described as being erroneous in text, but not in XML