...I added the process book keeping code that I found at the bottom of the opengl-ffi.lisp example to my program, namely:<div><br></div><div><div>(progn</div><div>  (ccl:process-run-function</div><div>   "housekeeping"</div>
<div>   #'ccl::housekeeping-loop)</div><div>  (ccl:process-interrupt</div><div>   ccl::*initial-process*</div><div>   (lambda ()</div><div>     ;; CCL::%SET-TOPLEVEL is sort of like PROCESS-PRESET for the</div><div>     ;; initial process; CCL::TOPLEVEL is sort of like PROCESS-RESET</div>
<div>     ;; for that process.</div><div>     (ccl::%set-toplevel</div><div>      (lambda ()</div><div>       ;;; Set the OSX Window Server's notion of the name of the</div><div>       ;;; current process.</div><div>       (rlet ((psn #>ProcessSerialNumber))</div>
<div>         (#_GetCurrentProcess psn)</div><div>         (with-cstrs ((name "simple OpenGL example"))</div><div>           (ccl::external-call "_CPSSetProcessName" :address psn :address name :void)))</div>
<div>       (ccl::%set-toplevel nil)</div><div>       (main)))</div><div>     (ccl::toplevel))))</div><div><br></div><div>..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).</div>
<div><br></div><div>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 :-)..</div><div><br></div><div>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....</div>
<div><br></div><div><br></div><br><div class="gmail_quote">On Mon, Aug 2, 2010 at 9:41 AM, Kevin Smith <span dir="ltr"><<a href="mailto:k2msmith@gmail.com">k2msmith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I had some chance to play around with this and got a little further, but not much...<div><br></div><div>I added a hack in my code to do this as per the example file mentioned below...</div><div><br></div><div><div>;;;(use-foreign-library opengl)</div>

<div>(eval-when (:compile-toplevel :load-toplevel :execute)</div><div>  (let* ((s (ccl:make-semaphore)))</div><div>    (ccl:process-interrupt ccl::*initial-process*</div><div><span style="white-space:pre-wrap">            </span>       (lambda ()</div>

<div>                         (ccl:open-shared-library "OpenGL.framework/OpenGL")</div><div><span style="white-space:pre-wrap">                     </span> (ccl:open-shared-library "GLUT.framework/GLUT")</div>
<div><span style="white-space:pre-wrap">                  </span> (ccl:signal-semaphore s)))</div><div>    (ccl:wait-on-semaphore s))</div><div><br></div><div>With this code, the shared libraries appear to load, but I do get the error message:</div>

<div><br></div><div><div>kevin-mac-pro-3:lisp kevinsmith$ ccl64</div><div>; loading system definition from /Users/kevinsmith/ccl-lisp/babel/babel.asd into #<Package "ASDF0"></div><div>; registering #<SYSTEM BABEL> as BABEL</div>

<div>; loading system definition from /Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into #<Package "ASDF0"></div><div>; registering #<SYSTEM :ALEXANDRIA> as ALEXANDRIA</div><div>; loading system definition from /Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into #<Package "ASDF0"></div>

<div>; registering #<SYSTEM TRIVIAL-FEATURES> as TRIVIAL-FEATURES</div><div class="im"><div>Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk  (DarwinX8664)!</div><div>? (require :cl-opengl)</div></div><div>
; Warning: Don't know how to setup a hook before saving cores on this Lisp.</div>
<div>; While executing: #<Anonymous Function #x302000D3A5DF>, in process listener(1).</div><div>:CL-OPENGL</div><div>NIL</div><div>? </div></div><div><br></div><div>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 ?</div>
<div><div></div><div class="h5">
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On Sun, Aug 1, 2010 at 8:02 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Apple decided to enforce the restriction that some shared libraries (I don't<br>
remember which one(s)) only be initialized on the initial thread of the OS-level<br>
process by executing a breakpoint instruction.  (It's the World's Most Advanced<br>
Operating System!)  That breakpoint causes the process to terminate with the<br>
message you're seeing when the library in question is loaded (directly or as<br>
the result of loading some library which depends on it) from a CCL listener<br>
thread (or a SLIME REPL thread, or ... any thread other than the initial<br>
one.)<br>
<br>
The general workaround is to replace:<br>
<br>
(open-shared-library "culprit.dylib")<br>
<br>
with<br>
<br>
(run-in-initial-thread-and-wait-until-done<br>
  (lambda () (open-shared-library "culprit.dylib")))<br>
<br>
There are a few issues:<br>
<br>
1) The affected code may be in a third-party lisp library; it'd be good if<br>
   the authors of such libraries made the necessary changes so that people<br>
   didn't keep running into this.<br>
<br>
2) It can be hard to know which libraries are affected.  I think that the<br>
   actual check-and-breakpoint is in the initialization code for the<br>
   CoreFoundation library; whether that's correct or not, it's in some<br>
   library that's used by many other things on OSX, so the rule of thumb<br>
   is something like "when in doubt, force library loading to happen on<br>
   the initial thread  in OSX."<br>
<br>
3) There are several ways to do what I'm calling<br>
   RUN-IN-INITIAL-THREAD-AND-WAIT-UNTIL-DONE; I don't think that we yet<br>
   offer a standard way of doing this (though CCL::CALL-IN-INITIAL-PROCESS<br>
   us present in recent versions of the trunk and is intended to become<br>
   an exported/documented/standard interface in the near future.)<br>
<br>
   We changed some of our examples when this "check and breakpoint" behavior<br>
   was introduced (in 10.6, IIRC); see "ccl:examples;opengl-ffi.lisp", for<br>
   instance.<br>
<br>
4) I'd want to think about this more than I have, but at the moment I can't<br>
   think of a reason for OPEN-SHARED-LIBRARY not to at least default to<br>
   doing what it does on the initial thread by default.<div><div></div><div><br>
<br>
<br>
<br>
On Sun, 1 Aug 2010, Kevin Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
cl-opengl package loaded.  I get the error:  "Trace/BPT trap" when I try to load that package.  (All other dependent packages<br>
like cffi, loaded successfully).<br>
I am using ccl64,  version 1.5 on Darwin/MAC OS  (DarwinX8664).  Latest version of cl-opengl.<br>
<br>
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<br>
cl-opengl package before it dies.<br>
<br>
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<br>
run across this already with this particular package.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>