macos support - #2
Conversation
macos requires window operations run on the main thread. Added dependency for trivial-main-thread on macos and wrapped window functions inside `trivial-main-thread:call-on-main-thread' on macos (just progn on other systems) also added macos target to Makefile
| :depends-on (:trivial-garbage | ||
| #+darwin :trivial-main-thread) |
There was a problem hiding this comment.
There should be a way to specify the dependency without an inline feature flag like this, such that vend can properly detect it.
There was a problem hiding this comment.
I'm unsure on that, could just have it as a dependency for all platforms? It's not a very big library and isn't platform dependant. Alternatively implement it (for just sbcl and ecl) inside the wrappers? Sorry, I'm still quite new to lisp. Do you have a suggestion?
There was a problem hiding this comment.
Here's an example of how to do that:
https://github.com/fosskers/parcom/blob/master/parcom.asd#L48-L49
You would just need to specify the :darwin feature instead.
Here's an even more complex one: https://github.com/Shirakumo/harmony/blob/master/harmony.asd#L25-L34
| (defmacro with-main-thread (&body body) | ||
| "Execute BODY on the main thread on macOS, or directly on other platforms." | ||
| #+darwin | ||
| `(tmt:call-in-main-thread (lambda () ,@body)) |
There was a problem hiding this comment.
Will this cause a lambda allocation upon every invocation?
There was a problem hiding this comment.
I did some testing and you're right it would. Both SBCL and ECL.
;; On macOS, window operations must run on the main thread.
(defmacro with-main-thread (&body body)
"Execute BODY on the main thread on macOS, or directly on other platforms."
#+darwin
(let ((thunk (gensym "THUNK")))
`(flet ((,thunk () ,@body))
(declare (dynamic-extent #',thunk))
(tmt:call-in-main-thread #',thunk)))
#-darwin
`(progn ,@body))Using flet and dynamic-extend makes SBCL optimise out the allocation but it doesn't work in ECL, which stays the same either way. I don't know of a way around it for ECL personally.
There was a problem hiding this comment.
Try some some additional optimize flags, like:
(declare (optimize (speed 3)))within the quoted part of the macro.
There was a problem hiding this comment.
Hey man sorry for the late response, I already tried that when I tested before and unfortunately it didn't change anything for ecl.
My thoughts are if the extra allocations aren't acceptable (which I totally get) you could close this merge and just include the changes to the makefile + the dylib loading? then just tell people that on mac window related code needs to be executed on the main thread and suggest trivial-main-thread. Then the user can just wrap the whole entry point in a call-in-main-thread call rather than each function being individually wrapped. I only did it this way as to try and hide it. That would also solve the dependency issue lol.
There was a problem hiding this comment.
Hm, yes I'd like to avoid those allocations.
and just include the changes to the makefile + the dylib loading?
I'm happy to follow this as well.
Then the user can just wrap the whole entry point in a call-in-main-thread
Since I don't have a mac, could you test this out for me and confirm that it works?
2 participants
macos requires window operations run on the main thread. Added dependency for trivial-main-thread on macos and wrapped window functions inside `trivial-main-thread:call-on-main-thread' on macos (just progn on other systems) also added macos target to Makefile.