sbcl MacOS port about kons-9 HOT 13 CLOSED

Here's kons-9 running on sbcl 2.2.6 on an M1 iMac with Monterey (macOS 12.5.1):

from kons-9.

There's some forward motion on sbcl and macOS, as reported here:

#18 (comment)

I'll make a fork to work on further, and post progress reports here.

from kons-9.

Some quick notes about what we know at the start:

In principle, if CCL can do something, then SBCL can also do it. There are a few complications, though.

CCL relies on its very full-featured Objective-C interface. SBCL doesn't really have one of those--certainly nothing as mature and featureful as CCL's.

It should be possible in principle to reproduce what Kaveh's code needs by using SBCL's FFI to talk to the C Objective-C Runtime APIs:

https://developer.apple.com/documentation/objectivec/objective-c_runtime?language=objc

From experience, the main pain of doinf that is figuring out the size and shape of all the structs we need to pass, passing them the right way, and interacting with Cocoa's memory management the right way. Bunch of crashy grunt work, basically.

CCL can start up in a SLIME session and eval (require :cocoa) to get a fully-functional version of the CCL IDE running as an inferior process in Emacs. It's the only Cocoa app I know of that does that without problems. It does it by calling two low-level Cocoa functions, TransformProcessType and SetFrontProcess (SetFrontProcess has been deprecated since 2014, but still works in macOS Monterey in 2022.)

You can see the CCL code that does it in CCL's sources:

ccl/cocoa-ide/cocoa-window.lisp

...in the definition of the function enable-foreground, at 01cf6cd7.

I don't yet know if we can do this with glut or glfw; these two APIs are functions (not Objective-C methods) in APplication Services, but I don't know what, if any, assumptions they're making about Objective-C Runtime features. I'll have to look into it.

Kaveh wants to standarize on glfw for cross-platform purposes. I'll have to see how--or if--that works with the above considerations. Input from the more clueful than I about any of these details is welcome.

from kons-9.

Official APple references to the abovementioned Application Services functions:

TransformProcessType
https://developer.apple.com/documentation/applicationservices/1462420-transformprocesstype?language=objc

SetFrontProcess
https://developer.apple.com/documentation/applicationservices/1501042-setfrontprocess?language=objc

Apple periodically issues announcements that they will stop accepting app store submissions that contain certain deprecated APIs. As far as I know, they've never said they will stop accepting all deprecated APIs, and the version of CCL that is currently on the App Store definitely uses SetFrontProcess when started up from SLIME (but that may not be detectable to someone who's just running the built app for testing).

from kons-9.

from kons-9.

@awolven I've tried code from your repos (and from other people's) to run GLFW from SBCL with only partial success. I mean, I've gotten GLFW windows up, but always with some variety of breakage (e.g. closing the window throws an error in SBCL about bogus stack frames, or trying to open a window a second time crashes). I'm perfectly willing to believe that I'm doing it wrong; it would be lovely if someone showed me how to do it right.

For what it's worth, I've gotten farther along than that with some other UI libraries (for example, with webview.h), but getting a window up with some content isn't the whole story. You also need to be able to tell the window to update the UI, and I've seen an otherwise fully-functional webview biff when asked by SLIME to do something that would require re-rendering the UI.

Again, if you kow how to do it better, I'm keen to learn.

There are at attempts at Objective-C interfaces that I've seen for SBCL, but nothing completely working, so far. We might want to look at this one:

https://github.com/Angel-Cortez/cl-objc

Its author had this to say on reddit:

https://www.reddit.com/r/lisp/comments/sh6qd0/porting_ccls_objc_bridge_to_sbcl/hv2rtyi/

A fully-working objective-C interface would certainly simplify things.

from kons-9.

A little more detail for correctness' sake:

cl-glfw3 exhibits the misfeatures I mentioned.

@awolven, I tried your cl-vulkan, but, after adjusting load-foreign-libraries to find the VulkanSDK and libglfw.3.4, SBCL complains that it can't find the vulkan driver. I don't know what it's looking for and where it expects to find it. I haven't searched further yet because it's only one of several avenues I'm searching, but if you happen to know what to look for I'll gladly try it.

from kons-9.

The new branch "merge-sbcl-macos" now contains code merged from branch use-cl-opengl of jolby's fork (https://github.com/jolby/kons-9), and from some tinkering I did using input from reddit's /u/byulparan and from @awolven to yield a version of the code that compiles and loads in sbcl on macOS, and which can pose a working glfw window that responds properly to events, and which can execute about the first half of Kaveh's demo.lisp.

I reviewed what works and what doesn't with Kaveh, fixed a ccl-ism or two, and agreed that we can defer work on the later examples in demo.lisp for now, so long as the first half of the file works reproducibly.

This work is tested on my Intel mac. I have not yet tested it on Apple Silicon.

I'll add a document on the merge-sbcl-macos branch that describes how to get set up to run the code with sbcl on macOS.

from kons-9.

Quick status update:

The code in branch "merge-sbcl-macos" is working on Monterey 12.5.1, but not yet on Apple Silicon. Superficially, it looks like it should work; brew installs Apple SIlicon-native versions of sbcl and glfw, but the quickload of cl-glfw3 fails to find the OpenGL framework.

/System/Library/Frameworks/OpenGL.framework is in the same place on the M1 Mac as it is on the Intel Mac, and has the same contents.

I'll look into it further.

from kons-9.

On the Intel Mac:

CFFI> (find-darwin-framework "OpenGL")
#P"/System/Library/Frameworks/OpenGL.framework/OpenGL"

On the M1 Mac:

CFFI> (find-darwin-framework "OpenGL")
NIL

/System/Library/Frameworks/OpenGL.framework/ is there on both systems, and a quick check with Kaleidoscope claims that they are identical.

I'm looking at the sources in CFFI to see what's up.

from kons-9.

Found it; the version of CFFI on my M1 mac was stale.

I can confirm that with the latest quicklisp client and dists, the "merge-sbcl-macos" branch of kons-9 works on Apple Silicon.

from kons-9.

Wow- awesome work and tenacious debugging skills @mikelevins!

from kons-9.

from kons-9.