(progn
(ccl:process-run-function
"housekeeping"
#'ccl::housekeeping-loop)
(ccl:process-interrupt
ccl::*initial-process*
(lambda ()
;; CCL::%SET-TOPLEVEL is sort of like PROCESS-PRESET for the
;; initial process; CCL::TOPLEVEL is sort of like PROCESS-RESET
;; for that process.
(ccl::%set-toplevel
(lambda ()
;;; Set the OSX Window Server's notion of the name of the
;;; current process.
(rlet ((psn #>ProcessSerialNumber))
(#_GetCurrentProcess psn)
(with-cstrs ((name "simple OpenGL example"))
(ccl::external-call "_CPSSetProcessName" :address psn :address name :void)))
(ccl::%set-toplevel nil)
(main)))
(ccl::toplevel))))
..in addition to hacks mentioned below. I got the window to come up and display my OpenGL graphics, but the GLUT event loop seems to be hanging (which I use cl-glut to access).
So, further progress - I am guessing from this adventure that there are not many user's of cl-opengl on clozure because it doesn't work :-)..
I'm not a huge fan of glut so, maybe ultimately it would be better to port my work to one of the toolkits already supported by CCL and it's native ffi open-gl, but that is a lot of work for me right now and I think it makes it more difficult for me to go back to SBCL should I choose to use that environment....I'll have to give it some thought. I am definitely suffering a bit with swig and interfacing with C++ code right now through CFFI (although I must admit, I really do like the cl-opengl interface for it's elegance - different topic). If CCL makes interfacing with C++ a little easier through it's FFI database, then maybe another reason for me to look into it....
On Mon, Aug 2, 2010 at 9:41 AM, Kevin Smith
<k2msmith@gmail.com> wrote:
I had some chance to play around with this and got a little further, but not much...
I added a hack in my code to do this as per the example file mentioned below...
;;;(use-foreign-library opengl)
(eval-when (:compile-toplevel :load-toplevel :execute)
(let* ((s (ccl:make-semaphore)))
(ccl:process-interrupt ccl::*initial-process*
(lambda ()
(ccl:open-shared-library "OpenGL.framework/OpenGL")
(ccl:open-shared-library "GLUT.framework/GLUT")
(ccl:signal-semaphore s)))
(ccl:wait-on-semaphore s))
With this code, the shared libraries appear to load, but I do get the error message:
kevin-mac-pro-3:lisp kevinsmith$ ccl64
; loading system definition from /Users/kevinsmith/ccl-lisp/babel/babel.asd into #<Package "ASDF0">
; registering #<SYSTEM BABEL> as BABEL
; loading system definition from /Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into #<Package "ASDF0">
; registering #<SYSTEM :ALEXANDRIA> as ALEXANDRIA
; loading system definition from /Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into #<Package "ASDF0">
; registering #<SYSTEM TRIVIAL-FEATURES> as TRIVIAL-FEATURES
Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk (DarwinX8664)!
? (require :cl-opengl)
; Warning: Don't know how to setup a hook before saving cores on this Lisp.
; While executing: #<Anonymous Function #x302000D3A5DF>, in process listener(1).
:CL-OPENGL
NIL
?
I created a stripped down version of my program that just has the cl-opengl and GLUT libraries in it and it looks like the first window comes up, but then it hangs before GL gets a chance to clear the window and do its thing... Is the warning (the hook) the problem ?
On Sun, Aug 1, 2010 at 8:02 PM, Gary Byers
<gb@clozure.com> wrote:
Apple decided to enforce the restriction that some shared libraries (I don't
remember which one(s)) only be initialized on the initial thread of the OS-level
process by executing a breakpoint instruction. (It's the World's Most Advanced
Operating System!) That breakpoint causes the process to terminate with the
message you're seeing when the library in question is loaded (directly or as
the result of loading some library which depends on it) from a CCL listener
thread (or a SLIME REPL thread, or ... any thread other than the initial
one.)
The general workaround is to replace:
(open-shared-library "culprit.dylib")
with
(run-in-initial-thread-and-wait-until-done
(lambda () (open-shared-library "culprit.dylib")))
There are a few issues:
1) The affected code may be in a third-party lisp library; it'd be good if
the authors of such libraries made the necessary changes so that people
didn't keep running into this.
2) It can be hard to know which libraries are affected. I think that the
actual check-and-breakpoint is in the initialization code for the
CoreFoundation library; whether that's correct or not, it's in some
library that's used by many other things on OSX, so the rule of thumb
is something like "when in doubt, force library loading to happen on
the initial thread in OSX."
3) There are several ways to do what I'm calling
RUN-IN-INITIAL-THREAD-AND-WAIT-UNTIL-DONE; I don't think that we yet
offer a standard way of doing this (though CCL::CALL-IN-INITIAL-PROCESS
us present in recent versions of the trunk and is intended to become
an exported/documented/standard interface in the near future.)
We changed some of our examples when this "check and breakpoint" behavior
was introduced (in 10.6, IIRC); see "ccl:examples;opengl-ffi.lisp", for
instance.
4) I'd want to think about this more than I have, but at the moment I can't
think of a reason for OPEN-SHARED-LIBRARY not to at least default to
doing what it does on the initial thread by default.
On Sun, 1 Aug 2010, Kevin Smith wrote:
The only hurdle for me for trying out (and maybe switching) to clozure on the mac platform is that I can't seem to get the
cl-opengl package loaded. I get the error: "Trace/BPT trap" when I try to load that package. (All other dependent packages
like cffi, loaded successfully).
I am using ccl64, version 1.5 on Darwin/MAC OS (DarwinX8664). Latest version of cl-opengl.
I believe I also tried it on the 32-bit ccl. Same problem. It looks like it only compiles a few source files in the
cl-opengl package before it dies.
If someone can point out to me how I can trace this to provide more information on where it is crashing or maybe someone has
run across this already with this particular package.
Thanks,
Kevin