Greater Seattle Area
Comment by ~shunter on ~shunter/wayflan
You can load enums in other protocols by scanning those protocols first.
For example, I'll make a convoluted example where each protocol is in its own package. In the system
myfoo.asd:;; Directory tree: ;; ./myfoo.asd ;; ./packages.lisp ;; ./text-input-unstable-v3.xml ;; ./input-method-unstable-v2.xml ;; ./app.lisp - this would have your application code (defsystem "myfoo" :defsystem-depends-on ("wayflan-client") :components ((:file "packages") (:wayflan-client-impl "text-input-unstable-v3" :in-package "myfoo.text-input" :export t :depends-on ("packages")) (:wayflan-client-impl "input-method-unstable-v2" :in-package "myfoo.input-method" :export t :depends-on ("packages" "text-input-unstable-v3")) (:file "app")))(The
:depends-onis unnecessary as the files are loaded in order. It's only to illustrate how each protocol depends on the other)And in
packages.lisp:(defpackage #:myfoo.text-input (:use #:cl #:wayflan-client)) (defpackage #:myfoo.input-method (:use #:cl #:wayflan-client #:myfoo.text-input))The package
myfoo.input-methoduses the packagemyfoo.text-input, such that it can use the enums of the previous. I can prove this by transforming the enum into a value within the package:(defpackage #:myfoo.text-input (:use #:cl #:wayflan-client)) (defpackage #:myfoo.input-method (:use #:cl #:wayflan-client #:myfoo.text-input))
I made the example convoluted above to explicitly show which code depends on what. You can also keep things simple by putting everything in one package.
In
myfoo.asd:(defsystem "myfoo" :defsystem-depends-on ("wayflan-client") :components ((:file "package") (:wayflan-client-impl "text-input-unstable-v3" :in-package "myfoo") (:wayflan-client-impl "input-method-unstable-v2" :in-package "myfoo") (:file "app")))In
package.lisp:(defpackage #:myfoo (:use #:cl #:wayflan-client))
Comment by ~shunter on ~shunter/wayflan
Fixed, thanks! The issue was that it validates the type of the object received to make sure it matches the expected interface (in this case, toplevel handles), but didn't allow for nil. This bug was missed in the unit test since it only checked receiving nullable any-type objects.
I now go through receiving both typed and untyped, null and not-null objects.
REPORTED RESOLVED CLOSED
Comment by ~shunter on ~shunter/wayflan
Found the source of the bug. I'm validating it with a test and making the change right now
RESOLVED FIXED REPORTED
Comment by ~shunter on ~shunter/wayflan
Fixed in develop. Pull this branch in and let me know when you verified this works.
Thanks!
REPORTED RESOLVED FIXED
Comment by ~shunter on ~shunter/wayflan
I've identified the root cause issue.
The scanner does, in fact, recognize the attribute
allow-null, but the functions generated when reading the event is handled improperly. Insrc/client/client.lisp:((:object &key interface allow-null) (@and `(%find-proxy! (wl-proxy-display ,proxy) id) (if allow-null `(when id ,|@|) @) `(let* ((id (read-wl-uint ,buffer)) (proxy ,|@|)) ,(when interface `(check-type proxy ,interface)) proxy)))The expression
(when id ,|@|), which guards against looking up the proxy, should instead be(when (plusp id) ,|2|). I'll verify this and push the fix. If you can verify this fixes the issue afterwards, that will give me the confidence to cut a release.
Comment by ~shunter on ~shunter/wayflan
I was able to fix the bug I found earlier. Now that I'm back on the grind of developing both Lisp and Wayland, I can better approach the bug! In the meantime, I can give answers to a couple points:
The message "Wayland message: Object ID 0 doesn't exist" implies that the client read a number which, defined in the protocol, should be the ID of a Wayland object. The ID 0 is reserved to mean a null or non-existent object. Looks like the library never checks that it could be null, and tries to look up the object anyways. I'll have to see if the XML docs define whether object args could be nullable. Maybe they're nullable by default? I don't remember.
On the phrase:
I guess that's because wayflan won't parse state enum returned by :state event correctly.
Wayflan won't parse the state enum returned by the :state event by design. You can see in the XML doc that its sole argument is only known as an array, not an array of state values, so the protocol scanner wouldn't be able to tell at all. Wayflan lets you cope with this by giving you the tools to marshal enums manually.
As for removing the events
output_enterandoutput_leave, that will throw the client off, because now the underlying opcodes that describe the event are out of order and incorrect. That's why it works initially, until you get a wl-message-error.I'll try to reproduce the error and look into reading nullable objects. This is probably the source of the issue.
Cheers!
Comment by ~shunter on ~shunter/wayflan
Hi Grigory, thanks for the bug report!
It's been a while since I worked on Common Lisp, so I reinstalled my dev environment and I'll look into this over the week. I'll also take another pass at the tests and examples, as it seems even Waycalc breaks on KDE:
The assertion (PLUSP CFFI::MAX-CHARS) failed with CFFI::MAX-CHARS = 0. [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Retry assertion. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT] abort thread (#<THREAD tid=77665 "repl-thread" RUNNING {1000BB0003}>) Backtrace: 0: (SB-KERNEL:ASSERT-ERROR (PLUSP CFFI::MAX-CHARS) 1 CFFI::MAX-CHARS 0) 1: (CFFI:FOREIGN-STRING-TO-LISP #.(SB-SYS:INT-SAP #X7FBB58029940) :OFFSET 4 :COUNT NIL :MAX-CHARS 0 :ENCODING :UTF-8) 2: (XYZ.SHUNTER.WAYFLAN.WIRE:READ-WL-STRING (#.(SB-SYS:INT-SAP #X7FBB58029940) 4 . 8))I'll continue working on this
Bug added by ~shunter on ~shunter/wayflan