From chris.bagley at gmail.com Wed Oct 30 11:58:25 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Wed, 30 Oct 2013 12:58:25 +0100 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: @bart:sorry if you receive this twice. I didn?t reply-all in gmail. @all: Just resurrecting this question briefly as it has been playing on my mind. We use runtime compiling to create our wrappers in case functionality is not present. That is great, but how do more static languages that don?t have this kind of control handle multiple versions of opengl? If the answer is "go read them and find out" that is fine! On 16 October 2013 18:44, Bart Botta <00003b at gmail.com> wrote: > On Wed, Oct 16, 2013 at 8:58 AM, Chris Bagley > wrote: > > Cheers, good to know. OK going back and reading the code again, this all > > seems to boil down to the fact that some implementations of opengl are > > missing functions > > It is mainly intended for OpenGL extensions, but Windows in particular > only supports gl 1.1 or 1.4 or so in the system libraries, so > everything beyond that has to be loaded the same way. Other systems > might be able to link more functions directly, but I'm not sure it > would be worth the effort to try to figure out which ones, > particularly since it might depend on drivers or hardware so needs to > be checked at runtime anyway. > > > Does the resulting lisp program take a performance hit from having such a > > late compile? > > I think the runtime compilation was intended to improve performance, > by compiling a specific function containing the function pointer > directly rather than precompiling a function that would have to look > it up somewhere for every call. That way the first call is a bit > expensive, but every call after that can be as fast as possible. No > idea how much difference it actually makes, or if it depends on lisp > implementation or platform though. > > > It's a heck of an interesting problem, I hadn't really thought about how > > cl-opengl handled versions before. It's a pretty cool solution! Are there > > any features around this area that that need implementing or > improvements to > > code that are needed? My main part time project totally relies on > cl-opengl > > so it would be nice to give a little back! > > Can't think of anything in that specific area that needs work, but > there is lots of room for improvement in the "high-level api" (the GL: > package) part of cl-opengl, particularly with more modern style of > OpenGL programming (shaders, vbos, etc). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Wed Oct 30 18:23:36 2013 From: 00003b at gmail.com (Bart Botta) Date: Wed, 30 Oct 2013 13:23:36 -0500 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: On Wed, Oct 30, 2013 at 6:58 AM, Chris Bagley wrote: > We use runtime compiling to create our wrappers in case functionality is > not present. > Runtime compilation is more of an optimization, we could store the function pointers in a closure or global array or something instead (and in fact probably should store them differently to be handle multiple drivers on windows correctly, but making that correct/efficient would probably be harder even though not many people would need it.) That is great, but how do more static languages that don?t have this kind > of control handle multiple versions of opengl? > > In C/C++ you can call a function pointer exactly the same way as a normal function, so they usually just define a bunch of function pointers for the extension functions and initialize them all at once. Most people probably use a library like GLEW or GLEE for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Thu Oct 24 13:30:00 2013 From: 00003b at gmail.com (Bart Botta) Date: Thu, 24 Oct 2013 08:30:00 -0500 Subject: OSX and (gl:get-integer :num-extensions) In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 4:31 AM, Chris Bagley wrote: > I have two users for whom a call to (gl:get-integer :num-extensions) > errors with: > OpenGL signaled (1280 . iNVLID-ENUM) from GET-INTGER-V > I think :num-extensions requires a GL 3.0+ context, so in general you should check that before using it. > > The only thing they both have in common it seems is OSX > > It seems from here > https://developer.apple.com/library/mac/releasenotes/general/macosxlionapidiffs/OpenGL.htmlthat this enum was only added in OsX 10.7 (Lion) but at least one of these > folks is using mavericks which has 4.2 support (so I'm told :)) > > On OSX, I think you need to specifically request 3.0+ when creating the context, or it will only give you a 2.x context since it actually separates out the core profile. (On other platforms I think NVidia and AMD drivers will default to the highest version it supports, but enable the backwards compatibility extension or profile or whatever it is) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rujia.liu at gmail.com Fri Oct 4 09:26:21 2013 From: rujia.liu at gmail.com (Rujia Liu) Date: Fri, 4 Oct 2013 17:26:21 +0800 Subject: glClearColor not found on some machine, some CL system Message-ID: Hi! I'm new to cl-opengl and was reading this tutorial: http://nklein.com/2010/06/nehe-tutorial-02-drawing-triangles-and-quadrilaterals/ I've downloaded tut02.lisp, but have trouble running it. On my machine, ccl 1.6 (windows XP, 32 bit, OpenGL 1.5) gives: ; Warning: Don't know how to setup a hook before saving cores on this Lisp. ; While executing: #, in process listener(1). > Error: Couldn't find function glClearColor > While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process listener (1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Skip loading "tut02.lisp" > Type :? for other options. But SBCL 1.1.4 (win32-thread fork) runs perfectly. On another machine (windows 7, 64 bit, OpenGL 4.3), both ccl 1.6 and SBCL (both 32-bit) gave the error message before. Could anyone give me some suggestions? Thanks in advance - Rujia -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Wed Oct 16 12:56:59 2013 From: 00003b at gmail.com (Bart Botta) Date: Wed, 16 Oct 2013 07:56:59 -0500 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: On Wed, Oct 16, 2013 at 6:45 AM, Chris Bagley wrote: > Or is it that once the lambda is compiled, it replaces the version with > generate-gl-function in it? Does that mean that the wrapper functions are > compiled on first call? Right, the call to COMPILE replaces the function with the result of compiling the LAMBDA, so a specialized wrapper is compiled when it is called. If I remember correctly, there is also a commented out version that uses a closure instead, if runtime compilation is a problem. From rujia.liu at gmail.com Fri Oct 4 09:39:00 2013 From: rujia.liu at gmail.com (Rujia Liu) Date: Fri, 4 Oct 2013 17:39:00 +0800 Subject: glClearColor not found on some machine, some CL system In-Reply-To: References: Message-ID: I've tested on 3 other machines. 2 with OpenGL 2.1 and 2 with OpenGL 4.3 It seems that OpenGL 2.1 machines can run SBCL executable while OpenGL 4.3 cannot. But on all machines ccl executable cannot run. I don't think glClearColor has changed between OpenGL 2.1 and OpenGL 4.3, from the latest reference: http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml So I'm confused. Any help would be appreciated. Thanks!!! - Rujia On Fri, Oct 4, 2013 at 5:26 PM, Rujia Liu wrote: > Hi! > > I'm new to cl-opengl and was reading this tutorial: > > > http://nklein.com/2010/06/nehe-tutorial-02-drawing-triangles-and-quadrilaterals/ > > I've downloaded tut02.lisp, but have trouble running it. > > On my machine, ccl 1.6 (windows XP, 32 bit, OpenGL 1.5) gives: > > ; Warning: Don't know how to setup a hook before saving cores on this Lisp. > ; While executing: #, in process listener(1). > > Error: Couldn't find function glClearColor > > While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process > listener > (1). > > Type :GO to continue, :POP to abort, :R for a list of available restarts. > > If continued: Skip loading "tut02.lisp" > > Type :? for other options. > > But SBCL 1.1.4 (win32-thread fork) runs perfectly. > > On another machine (windows 7, 64 bit, OpenGL 4.3), both ccl 1.6 and SBCL > (both 32-bit) gave the error message before. > > Could anyone give me some suggestions? Thanks in advance > > - Rujia > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bagley at gmail.com Wed Oct 16 11:42:42 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Wed, 16 Oct 2013 13:42:42 +0200 Subject: Confused as to how generate-gl-function works Message-ID: It seems to be compiling a new lambda on every call. I'll walk through my logic below: So I am looking at how (gen-buffers) is implemented. (defun gen-buffers (count) (with-foreign-object (buffer-array '%gl:uint count) (%gl:gen-buffers count buffer-array) (loop for i below count collecting (mem-aref buffer-array '%gl:uint i)))) %gl:gen-buffers is deifned as (defglextfun ("glGenBuffers" gen-buffers) :void (n sizei) (buffers (:pointer uint))) which expands to: (progn (declaim (notinline gen-buffers)) (defun gen-buffers (n buffers) (generate-gl-function "glgenbuffers" 'gen-buffers ':void '((n sizei) (buffers (:pointer uint))) n buffers)) (setf (get 'gen-buffers 'proc-address-dummy) #'gen-buffers) 'gen-buffers) and generate-gl-function (defun generate-gl-function (foreign-name lisp-name result-type body &rest args) (let ((address (gl-get-proc-address foreign-name)) (arg-list (mapcar #'first body))) (when (or (not (pointerp address)) (null-pointer-p address)) (error "Couldn't find function ~A" foreign-name)) (compile lisp-name `(lambda ,arg-list (multiple-value-prog1 (foreign-funcall-pointer ,address (:library opengl) ,@(loop for i in body collect (second i) collect (first i)) ,result-type) #-cl-opengl-no-check-error (check-error ',lisp-name)))) (apply lisp-name args))) What is going on here? I don't believe that it is recompiling the wrapper function on every call, but I'm having issues working out how else this works. Hope someone can help me out here. Cheers Baggers -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Fri Oct 4 11:38:03 2013 From: 00003b at gmail.com (Bart Botta) Date: Fri, 4 Oct 2013 06:38:03 -0500 Subject: glClearColor not found on some machine, some CL system In-Reply-To: References: Message-ID: Sounds like https://github.com/3b/cl-opengl/issues/42 which is fixed in the git repo at https://github.com/3b/cl-opengl and should be in next quicklisp update. On Fri, Oct 4, 2013 at 4:39 AM, Rujia Liu wrote: > I've tested on 3 other machines. 2 with OpenGL 2.1 and 2 with OpenGL 4.3 > > It seems that OpenGL 2.1 machines can run SBCL executable while OpenGL 4.3 > cannot. But on all machines ccl executable cannot run. > > I don't think glClearColor has changed between OpenGL 2.1 and OpenGL 4.3, > from the latest reference: > > http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml > > So I'm confused. Any help would be appreciated. Thanks!!! > > - Rujia > > > On Fri, Oct 4, 2013 at 5:26 PM, Rujia Liu wrote: >> >> Hi! >> >> I'm new to cl-opengl and was reading this tutorial: >> >> >> http://nklein.com/2010/06/nehe-tutorial-02-drawing-triangles-and-quadrilaterals/ >> >> I've downloaded tut02.lisp, but have trouble running it. >> >> On my machine, ccl 1.6 (windows XP, 32 bit, OpenGL 1.5) gives: >> >> ; Warning: Don't know how to setup a hook before saving cores on this >> Lisp. >> ; While executing: #, in process >> listener(1). >> > Error: Couldn't find function glClearColor >> > While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process >> > listener >> (1). >> > Type :GO to continue, :POP to abort, :R for a list of available >> > restarts. >> > If continued: Skip loading "tut02.lisp" >> > Type :? for other options. >> >> But SBCL 1.1.4 (win32-thread fork) runs perfectly. >> >> On another machine (windows 7, 64 bit, OpenGL 4.3), both ccl 1.6 and SBCL >> (both 32-bit) gave the error message before. >> >> Could anyone give me some suggestions? Thanks in advance >> >> - Rujia >> >> >> >> >> > From 00003b at gmail.com Wed Oct 30 22:13:44 2013 From: 00003b at gmail.com (Bart Botta) Date: Wed, 30 Oct 2013 17:13:44 -0500 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: On Wed, Oct 30, 2013 at 3:47 PM, Caelan Burris wrote: > IIRC, GLEW basically loads as many functions as possible from a static list > of names, and provides an error thunk for any names it can't load. So the > short version for GLEW is basically, "They don't". As far as I know, GLEW generates its "static list of names" from the specifications, so GLEW handles it pretty much exactly as much as cl-opengl does (I think it uses the text of the specifications rather than the data files cl-opengl uses, but should produce approximately the same results). From chris.bagley at gmail.com Thu Oct 24 13:42:44 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Thu, 24 Oct 2013 15:42:44 +0200 Subject: OSX and (gl:get-integer :num-extensions) In-Reply-To: References: Message-ID: Fantastic, I will try this out tonight. Now I know what to google for the results all seem to be of the same opinion. Cheers On 24 October 2013 15:30, Bart Botta <00003b at gmail.com> wrote: > > On Thu, Oct 24, 2013 at 4:31 AM, Chris Bagley wrote: > >> I have two users for whom a call to (gl:get-integer :num-extensions) >> errors with: >> OpenGL signaled (1280 . iNVLID-ENUM) from GET-INTGER-V >> > I think :num-extensions requires a GL 3.0+ context, so in general you > should check that before using it. > > >> >> The only thing they both have in common it seems is OSX >> >> It seems from here >> https://developer.apple.com/library/mac/releasenotes/general/macosxlionapidiffs/OpenGL.htmlthat this enum was only added in OsX 10.7 (Lion) but at least one of these >> folks is using mavericks which has 4.2 support (so I'm told :)) >> >> > On OSX, I think you need to specifically request 3.0+ when creating the > context, or it will only give you a 2.x context since it actually separates > out the core profile. (On other platforms I think NVidia and AMD drivers > will default to the highest version it supports, but enable the backwards > compatibility extension or profile or whatever it is) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismbo at gmail.com Thu Oct 24 08:23:21 2013 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Thu, 24 Oct 2013 09:23:21 +0100 Subject: [cffi-devel] OSX and (gl:get-integer :num-extensions) In-Reply-To: References: Message-ID: This is an OpenGL error, checked via glGetError(). I've Cc'ed cl-opengl's mailing list to see if anyone can help there. -- Lu?s Oliveira http://kerno.org/~luis (sent from my phone) On Oct 24, 2013 9:14 AM, "Chris Bagley" wrote: > I have two users for whom a call to (gl:get-integer :num-extensions) > errors with: > OpenGL signaled (1280 . iNVLID-ENUM) from GET-INTGER-V > > The only thing they both have in common it seems is OSX > Here is copied from one of their slime error buffers. > > OpenGL signalled (1280 . INVALID-ENUM) from GET-INTEGER-V. > [Condition of type CL-OPENGL-BINDINGS:OPENGL- > ERROR] > > Restarts: > 0: [CONTINUE] Continue > 1: [RETRY] Retry SLIME REPL evaluation request. > 2: [*ABORT] Return to SLIME's top level. > 3: [ABORT] Abort thread (#) > > Backtrace: > 0: (CL-OPENGL-BINDINGS:CHECK-ERROR #) > 1: (CL-OPENGL:GET-INTEGER :NUM-EXTENSIONS 1) > 2: (CEPL::GET-GL-EXTENSIONS) > 3: (CEPL::CEPL-POST-CONTEXT-INITIALIZE) > 4: (CEPL:REPL 640 480) > 5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CEPL:REPL) #) > 6: (EVAL (CEPL:REPL)) > 7: (SWANK::EVAL-REGION "(cepl:repl) ..) > > It seems from here > https://developer.apple.com/library/mac/releasenotes/general/macosxlionapidiffs/OpenGL.htmlthat this enum was only added in OsX 10.7 (Lion) is that the most likely > cause of the issue? > > Baggers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rujia.liu at gmail.com Fri Oct 4 12:04:53 2013 From: rujia.liu at gmail.com (Rujia Liu) Date: Fri, 4 Oct 2013 20:04:53 +0800 Subject: glClearColor not found on some machine, some CL system In-Reply-To: References: Message-ID: great! I'll give it a try. BTW: Is there a binding for cgGL? Before you told me this, I've already moved on by wrapping my OpenGL calls in C functions and call them in Common Lisp via CFFI. It worked for both SBCL and CCL until I added cg support. After that CCL compaint "invalid profile type" and the image is exactly the one without the cg shader. So it would be very helpful if there is a well-written cg binding for cl-opengl. - Rujia On Fri, Oct 4, 2013 at 7:38 PM, Bart Botta <00003b at gmail.com> wrote: > Sounds like https://github.com/3b/cl-opengl/issues/42 which is fixed > in the git repo at https://github.com/3b/cl-opengl and should be in > next quicklisp update. > > On Fri, Oct 4, 2013 at 4:39 AM, Rujia Liu wrote: > > I've tested on 3 other machines. 2 with OpenGL 2.1 and 2 with OpenGL 4.3 > > > > It seems that OpenGL 2.1 machines can run SBCL executable while OpenGL > 4.3 > > cannot. But on all machines ccl executable cannot run. > > > > I don't think glClearColor has changed between OpenGL 2.1 and OpenGL 4.3, > > from the latest reference: > > > > http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml > > > > So I'm confused. Any help would be appreciated. Thanks!!! > > > > - Rujia > > > > > > On Fri, Oct 4, 2013 at 5:26 PM, Rujia Liu wrote: > >> > >> Hi! > >> > >> I'm new to cl-opengl and was reading this tutorial: > >> > >> > >> > http://nklein.com/2010/06/nehe-tutorial-02-drawing-triangles-and-quadrilaterals/ > >> > >> I've downloaded tut02.lisp, but have trouble running it. > >> > >> On my machine, ccl 1.6 (windows XP, 32 bit, OpenGL 1.5) gives: > >> > >> ; Warning: Don't know how to setup a hook before saving cores on this > >> Lisp. > >> ; While executing: #, in process > >> listener(1). > >> > Error: Couldn't find function glClearColor > >> > While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process > >> > listener > >> (1). > >> > Type :GO to continue, :POP to abort, :R for a list of available > >> > restarts. > >> > If continued: Skip loading "tut02.lisp" > >> > Type :? for other options. > >> > >> But SBCL 1.1.4 (win32-thread fork) runs perfectly. > >> > >> On another machine (windows 7, 64 bit, OpenGL 4.3), both ccl 1.6 and > SBCL > >> (both 32-bit) gave the error message before. > >> > >> Could anyone give me some suggestions? Thanks in advance > >> > >> - Rujia > >> > >> > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bagley at gmail.com Wed Oct 16 11:45:02 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Wed, 16 Oct 2013 13:45:02 +0200 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: Or is it that once the lambda is compiled, it replaces the version with generate-gl-function in it? Does that mean that the wrapper functions are compiled on first call? On 16 October 2013 13:42, Chris Bagley wrote: > It seems to be compiling a new lambda on every call. I'll walk through my > logic below: > > So I am looking at how (gen-buffers) is implemented. > > (defun gen-buffers (count) > (with-foreign-object (buffer-array '%gl:uint count) > (%gl:gen-buffers count buffer-array) > (loop for i below count > collecting (mem-aref buffer-array '%gl:uint i)))) > > %gl:gen-buffers is deifned as > (defglextfun ("glGenBuffers" gen-buffers) :void > (n sizei) > (buffers (:pointer uint))) > > which expands to: > (progn > (declaim (notinline gen-buffers)) > (defun gen-buffers (n buffers) > (generate-gl-function "glgenbuffers" 'gen-buffers ':void > '((n sizei) (buffers (:pointer uint))) n buffers)) > (setf (get 'gen-buffers 'proc-address-dummy) #'gen-buffers) > 'gen-buffers) > > and generate-gl-function > (defun generate-gl-function (foreign-name lisp-name result-type body &rest > args) > (let ((address (gl-get-proc-address foreign-name)) > (arg-list (mapcar #'first body))) > (when (or (not (pointerp address)) (null-pointer-p address)) > (error "Couldn't find function ~A" foreign-name)) > (compile lisp-name > `(lambda ,arg-list > (multiple-value-prog1 > (foreign-funcall-pointer > ,address > (:library opengl) > ,@(loop for i in body > collect (second i) > collect (first i)) > ,result-type) > #-cl-opengl-no-check-error > (check-error ',lisp-name)))) > (apply lisp-name args))) > > What is going on here? I don't believe that it is recompiling the wrapper > function on every call, but I'm having issues working out how else this > works. > Hope someone can help me out here. > Cheers > Baggers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 00003b at gmail.com Wed Oct 16 16:44:18 2013 From: 00003b at gmail.com (Bart Botta) Date: Wed, 16 Oct 2013 11:44:18 -0500 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: On Wed, Oct 16, 2013 at 8:58 AM, Chris Bagley wrote: > Cheers, good to know. OK going back and reading the code again, this all > seems to boil down to the fact that some implementations of opengl are > missing functions It is mainly intended for OpenGL extensions, but Windows in particular only supports gl 1.1 or 1.4 or so in the system libraries, so everything beyond that has to be loaded the same way. Other systems might be able to link more functions directly, but I'm not sure it would be worth the effort to try to figure out which ones, particularly since it might depend on drivers or hardware so needs to be checked at runtime anyway. > Does the resulting lisp program take a performance hit from having such a > late compile? I think the runtime compilation was intended to improve performance, by compiling a specific function containing the function pointer directly rather than precompiling a function that would have to look it up somewhere for every call. That way the first call is a bit expensive, but every call after that can be as fast as possible. No idea how much difference it actually makes, or if it depends on lisp implementation or platform though. > It's a heck of an interesting problem, I hadn't really thought about how > cl-opengl handled versions before. It's a pretty cool solution! Are there > any features around this area that that need implementing or improvements to > code that are needed? My main part time project totally relies on cl-opengl > so it would be nice to give a little back! Can't think of anything in that specific area that needs work, but there is lots of room for improvement in the "high-level api" (the GL: package) part of cl-opengl, particularly with more modern style of OpenGL programming (shaders, vbos, etc). From caelanburris at gmail.com Wed Oct 30 20:47:14 2013 From: caelanburris at gmail.com (Caelan Burris) Date: Wed, 30 Oct 2013 16:47:14 -0400 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: IIRC, GLEW basically loads as many functions as possible from a static list of names, and provides an error thunk for any names it can't load. So the short version for GLEW is basically, "They don't". -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bagley at gmail.com Wed Oct 16 13:58:52 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Wed, 16 Oct 2013 15:58:52 +0200 Subject: Confused as to how generate-gl-function works In-Reply-To: References: Message-ID: Cheers, good to know. OK going back and reading the code again, this all seems to boil down to the fact that some implementations of opengl are missing functions, which of course makes sense as there is plenty of difference between v2 and v4 (or gles etc) Does the resulting lisp program take a performance hit from having such a late compile? It's a heck of an interesting problem, I hadn't really thought about how cl-opengl handled versions before. It's a pretty cool solution! Are there any features around this area that that need implementing or improvements to code that are needed? My main part time project totally relies on cl-opengl so it would be nice to give a little back! Thanks again for the help On 16 October 2013 14:56, Bart Botta <00003b at gmail.com> wrote: > On Wed, Oct 16, 2013 at 6:45 AM, Chris Bagley > wrote: > > Or is it that once the lambda is compiled, it replaces the version with > > generate-gl-function in it? Does that mean that the wrapper functions are > > compiled on first call? > > Right, the call to COMPILE replaces the function with the result of > compiling the LAMBDA, so a specialized wrapper is compiled when it is > called. If I remember correctly, there is also a commented out version > that uses a closure instead, if runtime compilation is a problem. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.bagley at gmail.com Thu Oct 24 09:31:36 2013 From: chris.bagley at gmail.com (Chris Bagley) Date: Thu, 24 Oct 2013 11:31:36 +0200 Subject: OSX and (gl:get-integer :num-extensions) Message-ID: I have two users for whom a call to (gl:get-integer :num-extensions) errors with: OpenGL signaled (1280 . iNVLID-ENUM) from GET-INTGER-V The only thing they both have in common it seems is OSX Here is copied from one of their slime error buffers. OpenGL signalled (1280 . INVALID-ENUM) from GET-INTEGER-V. [Condition of type CL-OPENGL-BINDINGS:OPENGL- ERROR] Restarts: 0: [CONTINUE] Continue 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT] Abort thread (#) Backtrace: 0: (CL-OPENGL-BINDINGS:CHECK-ERROR #) 1: (CL-OPENGL:GET-INTEGER :NUM-EXTENSIONS 1) 2: (CEPL::GET-GL-EXTENSIONS) 3: (CEPL::CEPL-POST-CONTEXT-INITIALIZE) 4: (CEPL:REPL 640 480) 5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CEPL:REPL) #) 6: (EVAL (CEPL:REPL)) 7: (SWANK::EVAL-REGION "(cepl:repl) ..) It seems from here https://developer.apple.com/library/mac/releasenotes/general/macosxlionapidiffs/OpenGL.htmlthat this enum was only added in OsX 10.7 (Lion) but at least one of these folks is using mavericks which has 4.2 support (so I'm told :)) Any idea what would be causing this? Baggers -------------- next part -------------- An HTML attachment was scrubbed... URL: