From k2msmith at gmail.com Mon Aug 2 01:04:43 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Sun, 1 Aug 2010 18:04:43 -0700 Subject: [cl-opengl-devel] Trace/BPT trap with cl-opengl loading Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Mon Aug 2 02:11:11 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Sun, 1 Aug 2010 19:11:11 -0700 Subject: [cl-opengl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: further to this message.. I tried the lastest svn "trunk" release of ccl (which incidentally looks like it has some extra goodies in it for the mac platform).. Here is what I get (after startup).. Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk (DarwinX8664)! ? (require :cl-opengl) Trace/BPT trap All other require packages got loaded successfully on startup prior. I played around with "trace" and "step" but none of those debugging functions seem to give me the equivalent of a "stack trace' in C. Not sure how to proceed to find out where it is crashing... Thanks, Kevin On Sun, Aug 1, 2010 at 6:04 PM, 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Mon Aug 2 04:53:16 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Sun, 1 Aug 2010 21:53:16 -0700 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: thank you I will give this a try in the morning..By the way, I was able to trace my problem with cl-opengl a little further to the cffi function: (cffi:load-foreign-library '(:framework "OpenGL)) (called from the libraries.lisp file in cl-opengl package) I manually tried this call in the repl outside of the cl-opengl package and it also crashes. checked my *darwin-framework-directories* variable and that seems OK. then I found, you can enter the full path of the framework (library ?) directly, like so: (cffi:load-foreign-library "/System/Library/Frameworks/OpenGL.framework/OpenGL") That also crashes it. Incidentally, the same call worked OK with other non-framework libraries that I tried, like /usr/lib/libm.dylib... but I'll look at your suggestion more closely.. I use this library in sbcl without a problem...(but have other problems with sbcl on the mac). -K On Aug 1, 2010, at 8:02 PM, Gary Byers 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 >> From k2msmith at gmail.com Mon Aug 2 16:41:41 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Mon, 2 Aug 2010 09:41:41 -0700 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: 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 # ; registering # as BABEL ; loading system definition from /Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into # ; registering # as ALEXANDRIA ; loading system definition from /Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into # ; registering # 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: #, 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 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 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Mon Aug 2 17:16:35 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Mon, 2 Aug 2010 10:16:35 -0700 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: ...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 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 # > ; registering # as BABEL > ; loading system definition from > /Users/kevinsmith/ccl-lisp/alexandria/alexandria.asd into # > ; registering # as ALEXANDRIA > ; loading system definition from > /Users/kevinsmith/ccl-lisp/trivial-features/trivial-features.asd into > # > ; registering # 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: #, 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 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 >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Mon Aug 2 17:18:50 2010 From: 00003b at gmail.com (Bart Botta) Date: Mon, 2 Aug 2010 12:18:50 -0500 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: On Mon, Aug 2, 2010 at 11:41 AM, Kevin Smith wrote: > ; Warning: Don't know how to setup a hook before saving cores on this Lisp. That warning just means you can't reliably save a core if you have called any OpenGL functions, it shouldn't affect anything for normal usage. -b- From 00003b at gmail.com Mon Aug 2 17:24:26 2010 From: 00003b at gmail.com (Bart Botta) Date: Mon, 2 Aug 2010 12:24:26 -0500 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: Message-ID: On Mon, Aug 2, 2010 at 12:16 PM, Kevin Smith wrote: > 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. cl-opengl does not depend on glut, so you should be able to use it with any other methods of creating an OpenGL context, for example lispbulder-sdl, cl-glfw, glop, etc. You just need to set %gl:*gl-get-proc-address* to whatever function is used to get GL extension pointers on that platform/library. -b- From k2msmith at gmail.com Thu Aug 5 14:10:56 2010 From: k2msmith at gmail.com (k2msmith at gmail.com) Date: Thu, 05 Aug 2010 14:10:56 +0000 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: <1729D79B-D708-4F0C-9D5E-9DF923CF2CE7@cs.colorado.edu> Message-ID: <00163646ce7c794cb0048d141e5f@google.com> Are you running this on clozure 1.5 with Snow Leopard MAC OS (ie: version 10.6.4 ) ? On Aug 5, 2010 4:36am, Alexander Repenning wrote: > XMLisp http://code.google.com/p/xmlisp/ works fine, ie, it is not an > OpenGL problem. > alex > On Aug 2, 2010, at 4:11 AM, Kevin Smith wrote: > further to this message.. I tried the lastest svn "trunk" release of ccl > (which incidentally looks like it has some extra goodies in it for the > mac platform).. Here is what I get (after startup).. > Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk > (DarwinX8664)! > ? (require :cl-opengl) > Trace/BPT trap > All other require packages got loaded successfully on startup prior. I > played around with "trace" and "step" but none of those debugging > functions seem to give me the equivalent of a "stack trace' in C. Not > sure how to proceed to find out where it is crashing... > Thanks, > Kevin > On Sun, Aug 1, 2010 at 6:04 PM, Kevin Smith k2msmith at gmail.com> 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 > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Prof. Alexander Repenning > University of ColoradoComputer Science DepartmentBoulder, CO 80309-430 > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Sat Aug 7 04:34:26 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Fri, 6 Aug 2010 21:34:26 -0700 Subject: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading In-Reply-To: References: <00163646ce7c794cb0048d141e5f@google.com> Message-ID: btw, I just tried the threaded version of sbcl (1.0.39) which I built from macports and it worked with no problems with all the same code (same cffi and cl-opengl packages), including my opencv libraries. I've not investigated what sbcl (or cffi) maybe doing that is different in this case, but it all seems to be working. On Thu, Aug 5, 2010 at 8:20 AM, Gary Byers wrote: > The "trace/bkpt trap" happens - as you've already confirmed - when > a thread other than the initial thread tries to open/initialize > a particular shared library. (I'm fairly sure that the library > in question is CoreFoundation, which is used by many other things > on OSX.) > > Alex's XMLisp stuff runs on top of CCL's Cocoa environment, which > takes great care to ensure that the Cocoa framework (and therefore > CoreFoundation) are loaded on the initial thread. (If it didn't, > it would run into the same breakpoint trap. Honest.) > > [~] gb at antinomial> ccl > Welcome to Clozure Common Lisp Version 1.6-dev-r14118M-trunk > (DarwinX8632)! > ;;; Two lisp processes are running: the listener, and the initial > ;;; process. Each of these lisp processes is implemented as a > ;;; native OS thread. > ? :proc > 1 : -> listener [Active] 0 : Initial [Sleep] ;;; Let's try to > open the CoreFoundation library from the listener > ;;; process. > ? (open-shared-library "CoreFoundation.framework/CoreFoundation") > Trace/BPT trap > > Lots of other OSX libraries will (directly or transitively) load > CoreFoundation. CoreFoundation's initialization code checks in 10.6 > to see if it's being called on the initial thread; if not, it executes > an illegal debugging instruction and the process terminates. That's > not a particulary graceful way to fail, but that's what happens. > > I hope that this is clear; apologies to everyone to which it was > already clear. > > > On Thu, 5 Aug 2010, k2msmith at gmail.com wrote: > > Are you running this on clozure 1.5 with Snow Leopard MAC OS (ie: version >> 10.6.4 ) ? >> >> On Aug 5, 2010 4:36am, Alexander Repenning wrote: >> > XMLisp http://code.google.com/p/xmlisp/ works fine, i.e., it is not an >> OpenGL problem. >> > >> > >> > alex >> > >> > >> > >> > >> > >> > On Aug 2, 2010, at 4:11 AM, Kevin Smith wrote: >> > >> > further to this message.. I tried the lastest svn "trunk" release of ccl >> (which incidentally looks like it has some extra goodies in it for the mac >> platform).. Here is what I get (after startup).. >> > >> > >> > Welcome to Clozure Common Lisp Version 1.5-dev-r13523M-trunk >> (DarwinX8664)! >> > ? (require :cl-opengl) >> > Trace/BPT trap >> > >> > >> > All other require packages got loaded successfully on startup prior. I >> played around with "trace" and "step" but none of those debugging >> functions >> seem to give me the equivalent of a "stack trace' in C. Not sure how to >> proceed to find out where it is crashing... >> > >> > >> > >> > Thanks, >> > Kevin >> > >> > >> > >> > >> > >> > >> > On Sun, Aug 1, 2010 at 6:04 PM, Kevin Smith k2msmith at gmail.com> 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 >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Openmcl-devel mailing list >> > Openmcl-devel at clozure.com >> > http://clozure.com/mailman/listinfo/openmcl-devel >> > >> > >> > >> > Prof. Alexander Repenning >> > University of ColoradoComputer Science DepartmentBoulder, CO 80309-430 >> > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> > >> > >> > >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Tue Aug 10 15:13:48 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Tue, 10 Aug 2010 08:13:48 -0700 Subject: [cl-opengl-devel] cl-opengl in a standard X-window based canvas widget ? Message-ID: Has anyone used cl-opengl inside a standard X-window based drawing widget (one that supports simple refresh and input event call backs ) ? I am interested in bypassing GLUT (which I currently use) and using another lisp-based toolkit, potentially mcclim. I would like to continue using cl-opengl, though because I like it's interface. I am assuming that if I have a low-level window , I can create an OpenGL context for it and the cl-opengl binding would just work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kalyanov.dmitry at gmail.com Tue Aug 10 15:50:44 2010 From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry) Date: Tue, 10 Aug 2010 19:50:44 +0400 Subject: [cl-opengl-devel] cl-opengl in a standard X-window based canvas widget ? In-Reply-To: References: Message-ID: <201008101950.50244.Kalyanov.Dmitry@gmail.com> On Tuesday 10 August 2010 19:13:48, Kevin Smith wrote: > Has anyone used cl-opengl inside a standard X-window based drawing widget > (one that supports simple refresh and input event call backs ) ? > > I am interested in bypassing GLUT (which I currently use) and using > another lisp-based toolkit, potentially mcclim. I would like to continue > using cl-opengl, though because I like it's interface. > > I am assuming that if I have a low-level window , I can create an OpenGL > context for it and the cl-opengl binding would just work. Hi! I've used cl-opengl with cl-gtk2-gtkglext which is a binding to GtkGlExt library. GtkGlExt provides Gtk+ widget that is painted with opengl calls (https://clgtk2.wordpress.com/2009/08/29/gtkglext-binding/). Window is painted inside 'expose-event' handler with cl-opengl calls, input handling is done by usual Gtk+ events ('motion-notify', 'button-press-event', 'key-press-event' etc.). cl-gtk2 works on Linux and Windows with SBCL and Clozure CL. From 00003b at gmail.com Tue Aug 10 23:37:16 2010 From: 00003b at gmail.com (Bart Botta) Date: Tue, 10 Aug 2010 18:37:16 -0500 Subject: [cl-opengl-devel] no longer calling glut:init at load time Message-ID: I disabled the call to glut:init when cl-glut is loaded, since it was breaking things that just want to load the code (to verify it compiles, check dependencies, build a binary, or whatever) but don't have a display available, and I'm guessing it wasn't helping with the threading problems on OSX either. If anyone runs into problems because of that, please file a bug or send a message to the list, so we can try to work out a better compromise between use-cases that need it initialized and those that need it not initialized. -b- From luke at balooga.com Thu Aug 12 02:10:06 2010 From: luke at balooga.com (Luke Crook) Date: Wed, 11 Aug 2010 19:10:06 -0700 Subject: [cl-opengl-devel] cl-opengl-devel Digest, Vol 45, Issue 7 In-Reply-To: References: Message-ID: From: Kalyanov Dmitry To: cl-opengl-devel at common-lisp.net Date: Tue, 10 Aug 2010 19:50:44 +0400 Subject: Re: [cl-opengl-devel] cl-opengl in a standard X-window based canvas widget ? On Tuesday 10 August 2010 19:13:48, Kevin Smith wrote: > Has anyone used cl-opengl inside a standard X-window based drawing widget > (one that supports simple refresh and input event call backs ) ? > > I am interested in bypassing GLUT (which I currently use) and using > another lisp-based toolkit, potentially mcclim. I would like to continue > using cl-opengl, though because I like it's interface. > > I am assuming that if I have a low-level window , I can create an OpenGL > context for it and the cl-opengl binding would just work. Correct. lispbuilder-sdl is used with cl-opengl in this way. The example below shows lispbuilder-sdl creating the OpenGL context. http://article.gmane.org/gmane.lisp.cl-lispbuilder.general/648 -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2msmith at gmail.com Wed Aug 25 00:46:22 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Tue, 24 Aug 2010 17:46:22 -0700 Subject: [cl-opengl-devel] Unkown option: CONVENTION Message-ID: Anyone know why I am getting this warning now ? ; loading system definition from ; /Users/kevinsmith/sbcl-lisp/cl-opengl/cl-glu.asd into # ; registering # as CL-GLU WARNING: Unkown option: CONVENTION -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Wed Aug 25 04:11:10 2010 From: 00003b at gmail.com (Bart Botta) Date: Tue, 24 Aug 2010 23:11:10 -0500 Subject: [cl-opengl-devel] Unkown option: CONVENTION In-Reply-To: References: Message-ID: On Tue, Aug 24, 2010 at 7:46 PM, Kevin Smith wrote: > Anyone know why I am getting this warning now ? > ; loading system definition from > ; /Users/kevinsmith/sbcl-lisp/cl-opengl/cl-glu.asd into # > ; registering # as CL-GLU > WARNING: Unkown option: CONVENTION Try upgrading cffi. -b- From k2msmith at gmail.com Wed Aug 25 04:53:59 2010 From: k2msmith at gmail.com (Kevin Smith) Date: Tue, 24 Aug 2010 21:53:59 -0700 Subject: [cl-opengl-devel] Unkown option: CONVENTION In-Reply-To: References: Message-ID: Thanks..upgrading to (new) 0.10.6 cffi took care of it. On Tue, Aug 24, 2010 at 9:11 PM, Bart Botta <00003b at gmail.com> wrote: > On Tue, Aug 24, 2010 at 7:46 PM, Kevin Smith wrote: > > Anyone know why I am getting this warning now ? > > ; loading system definition from > > ; /Users/kevinsmith/sbcl-lisp/cl-opengl/cl-glu.asd into # "ASDF0"> > > ; registering # as CL-GLU > > WARNING: Unkown option: CONVENTION > > Try upgrading cffi. > > -b- > -------------- next part -------------- An HTML attachment was scrubbed... URL: