...I added the process book keeping code that I found at the bottom of the opengl-ffi.lisp example to my program, namely:
(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 <k2msm...@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 <g...@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 >>> >>> >>> >
_______________________________________________ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel