ccl
ccl copied to clipboard
Is support for Apple Silicon coming soon?
SBCL isn't there yet and CCL from a mac store failed on Big Sur even without M1 chip.
Trying from App Store on M1 I see this in the console that comes up.
Unhandled exception 10 at 0x7fff2023abdd, context->regs at #x20446a9b0 Exception occurred while executing foreign code at objc_msgSend + 29 received signal 10; faulting address: 0x18 ? for help [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: Current Thread Context Record (tcr) = 0x504080 Control (C) stack area: low = 0x204208000, high = 0x20446b298 Value (lisp) stack area: low = 0x20c00000, high = 0x20e4c000 Exception stack pointer = 0x20446ae88 [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: [2134] Clozure CL kernel debugger: symbol name :
We want to get it running on Apple Silicon, but there's no timeline at this point.
@sjatkins FWIW, I am able to run the pre-built CCL x86_86 binary on M1/Big Sur. Trying out some cursory lisp expressions works (I haven't tried anything extensive).
However, when I try to build CCL for M1 using lisp (rebuild-ccl :full t)
, I get a rosetta error:
; Including "/Users/joubert/code/lisp/ccl-dev/compiler/nx0.lisp"...rosetta error: unsupported 'int 194' Trace/BPT trap: 5
FYI, I'm not a CCL contributor, but if I get a chance I might dig in to see whether I can figure it out.
What you're seeing is Rosetta not implementing the INT instruction. Lisp code in CCL uses that instruction to request services from the CCL kernel (e.g., perform a GC).
Apple implemented emulation of that instruction as of macOS Big Sur 11.2
But ...
CCL expects floating point exceptions to be raised when appropriate to properly implement Lisp's arithmetic functions. Rosetta does not raise floating point exceptions. While you might think this would only affect floating point operations in Lisp, it in fact also affects rational arithmetic and, possibly, bignums. (If you run the ANSI test suite, you get a large number of failures in its arithmetic tests.)
We've reported this issue to Apple but, so far, there's been no response.
I'd love to see a fundraiser for the port, if that's what it takes to get this going
There are more and more M1/M2 Macs. A port for Apple Silicon would be awesome.
If this is a regular Apple support then I don't think they can help. Probably you have to have Apple developer account and open a ticket.
There are two open source Cocoa frameworks that I know of: GNUstep and Cocotron. There was some effort made in the early days of the CCL IDE to make the code compatible with those frameworks but as far as I know those efforts were abandoned many years ago. Some vestiges of that code are still present in the CCL IDE source. My recollection is that those frameworks were always incomplete w.r.t. whatever the "current" MacOS Cocoa API was providing, and even if the world were static it would require a nonzero amount of effort to make the CCL IDE work acceptably on Linux and Windows with those frameworks, although some limited success was demonstrated early on.
But of course the world is not static, and since MacOS changes frequently, it tends to require a nontrivial amount of effort just to keep the CCL IDE working on MacOS. Add to this the fact that Windows and Linux change frequently too, and the job of keeping GNUstep and Cocotron themselves working -- independently of CCL -- is challenging to whomever their current maintainers are. The amount of work necessary to keep the CCL IDE working with open source frameworks that may or may not track what's current in the MacOS, Windows, and Linux worlds was deemed too much and it was abandoned.
You're of course welcome to try to port the CCL IDE to Linux using GNUstep or Cocotron, but in my opinion it's a waste of time because of the ongoing maintenance nightmare you'll encounter.
A much better approach in my opinion is to cleanly refactor the CCL IDE into a frontend written in Lisp and a backend written with Lisp wrappers around the native windowing system and/or foreign function calls. This would enable a relatively straightforward port to X11 or Wayland or even Windows because only the backend would need to be changed for the port. (I know, famous last words.) But at the moment the CCL IDE is not cleanly separated in this way; there are Cocoa constructs deeply intertwined within the Lisp code and there's no easy way to separate them.
A much better approach in my opinion is to cleanly refactor the CCL IDE into a frontend written in Lisp and a backend written with Lisp wrappers around the native windowing system and/or foreign function calls. This would enable a relatively straightforward port to X11 or Wayland or even Windows because only the backend would need to be changed for the port. (I know, famous last words.) But at the moment the CCL IDE is not cleanly separated in this way; there are Cocoa constructs deeply intertwined within the Lisp code and there's no easy way to separate them.
So basically, rewrite CCL IDE using McCLIM.
So basically, rewrite CCL IDE using McCLIM.
Or (for people like me with more, er median, IQs) Tk? There are more than one TK projects in Tk for Common Lisp:
or write a TK McCLIM backend, and write the CCL IDE using McCLIM. https://github-wiki-see.page/m/McCLIM/McCLIM/wiki/Backends
duplicates #11