cl-opengl-devel August 2010

cl-opengl-devel@common-lisp.net

4 participants
9 discussions

[cl-opengl-devel] Unkown option: CONVENTION
by Kevin Smith 25 Aug '10

25 Aug '10

Anyone know why I am getting this warning now ? ; loading system definition from ; /Users/kevinsmith/sbcl-lisp/cl-opengl/cl-glu.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-GLU {1002C81C61}> as CL-GLU WARNING: Unkown option: CONVENTION

2 2

Re: [cl-opengl-devel] cl-opengl-devel Digest, Vol 45, Issue 7
by Luke Crook 12 Aug '10

12 Aug '10

From: Kalyanov Dmitry <kalyanov.dmitry(a)gmail.com> To: cl-opengl-devel(a)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

1 0

[cl-opengl-devel] no longer calling glut:init at load time
by Bart Botta 10 Aug '10

10 Aug '10

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-

1 0

[cl-opengl-devel] cl-opengl in a standard X-window based canvas widget ?
by Kevin Smith 10 Aug '10

10 Aug '10

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.

2 1

Re: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading
by Kevin Smith 07 Aug '10

07 Aug '10

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 <gb(a)clozure.com> 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@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(a)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 <ralex(a)cs.colorado.edu> 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(a)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(a)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 >> > >> > >> > >> > >> > >> > >> >

1 0

Re: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading
by k2msmith＠gmail.com 05 Aug '10

05 Aug '10

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 <ralex(a)cs.colorado.edu> 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(a)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(a)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

1 0

Re: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading
by Kevin Smith 02 Aug '10

02 Aug '10

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(a)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 >> >> >>

2 3

Re: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading
by Kevin Smith 02 Aug '10

02 Aug '10

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 >>

1 0

[cl-opengl-devel] Trace/BPT trap with cl-opengl loading
by Kevin Smith 02 Aug '10

02 Aug '10

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

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel August 2010