From jamesjb at jamesjb.com  Wed Aug 23 08:35:01 2006
From: jamesjb at jamesjb.com (James Bielman)
Date: Wed, 23 Aug 2006 01:35:01 -0700
Subject: [cl-opengl-devel] patch for review: implement numeric GL state
	queries
Message-ID: <874pw33l56.fsf@jamesjb.com>

Hi all,

I propose the following patch to implement the remaining state query
functions (glGetInteger, glGetBoolean, etc) in CL-OPENGL.  The
interface is pretty straightforward, and the user can omit the number
of values to return when the query is known to the library.

For example (from a running OpenGL program):

CL-USER> (gl:get-float :viewport)
#(0.0 0.0 640.0 480.0)
CL-USER> (gl:get-float :texture-matrix)
#(1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0)
CL-USER> (gl:get-boolean :blend)
T
CL-USER> (gl:get-enum :depth-func 'gl::compare-func)
:LESS

I'm becoming fairly convinced that the separation of GLenum into
discrete enum types based on context may not be a good idea.  OpenGL
doesn't make any distinction between different types of enums, and it
feels as though we are going against the grain trying to separate
them.

There are a lot of duplicate definitions, and it also makes it hard to
deal with a case like glGetInteger where you want to say, "this
function returns a GLenum", because you don't know which CL-OPENGL
enum type to use (hence the additional argument to GL:GET-ENUM in my
implementation).

I'd be willing to do the grunt work on a patch to move to one unified
enum type---hopefully such a beast could be mostly machine generated
from a header file or specification document (and updated by hand from
then on).

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: query.patch
Type: text/x-patch
Size: 19594 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20060823/03d2d3d4/attachment.bin>

From tl at di.fc.ul.pt  Thu Aug 31 15:57:24 2006
From: tl at di.fc.ul.pt (Thibault Langlois)
Date: Thu, 31 Aug 2006 16:57:24 +0100
Subject: [cl-opengl-devel] Problem compiling cl-opengl for cmucl
Message-ID: <1157039844.6123.12.camel@wok>

Hello,
I'm trying open-gl for the first time and I get the following error:

Undefined foreign symbol: "glAttachShader"
   [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of
#P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/funcs.x86f".
  1: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {58E5F46D}> on
#<ASDF:CL-SOURCE-FILE "funcs" {58DF96D5}>.
  2: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {58E5F46D}> on
#<ASDF:CL-SOURCE-FILE "funcs" {58DF96D5}> as having been successful.
  3: [ABORT-REQUEST] Abort handling SLIME request.
  4: [DESTROY] Destroy the process

I am using cmucl 19c on a intel linux. I fetched cffi and cl-opengl from
their respective websites today.

Any advice ?

Thibault Langlois


---
The full session:

CL-USER> (asdf:operate 'asdf:load-op 'cl-opengl)
; loading system definition from /home/tl/Projects/Systems/cl-opengl.asd
; into #<The ASDF0 package>
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/cl-opengl.asd".
; registering #<SYSTEM :CL-OPENGL {584F4DED}> as CL-OPENGL
; loading system definition from /home/tl/Projects/Systems/cffi.asd into
; #<The ASDF0 package>
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/cffi.asd".
; registering #<SYSTEM CFFI {5851DA7D}> as CFFI
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): 
; Compiling Top-Level Form: 
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/utils.x86f".
; Loading
#P"/home/tl/comp/lang/lisp/code/cffi-060626/src/features.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/cffi-
cmucl.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/package.x86f".
; Loading
#P"/home/tl/comp/lang/lisp/code/cffi-060626/src/libraries.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/early-
types.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/types.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/enum.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/strings.x86f".
; Loading
#P"/home/tl/comp/lang/lisp/code/cffi-060626/src/functions.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cffi-060626/src/foreign-
vars.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/package.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/library.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/types.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/enums.x86f".
; Loading #P"/home/tl/comp/lang/lisp/code/cl-opengl/gl/funcs.x86f".

; Compilation unit aborted.

; Evaluation aborted
CL-USER> (lisp-implementation-version)
"19c (19C)"
CL-USER> (lisp-implementation-type)
"CMU Common Lisp"
CL-USER> 
-- 
Thibault Langlois <tl at di.fc.ul.pt>
FCUL / DI



From jamesjb at jamesjb.com  Thu Aug 31 18:09:33 2006
From: jamesjb at jamesjb.com (James Bielman)
Date: Thu, 31 Aug 2006 11:09:33 -0700
Subject: [cl-opengl-devel] Problem compiling cl-opengl for cmucl
In-Reply-To: <1157039844.6123.12.camel@wok> (Thibault Langlois's message of
	"Thu, 31 Aug 2006 16:57:24 +0100")
References: <1157039844.6123.12.camel@wok>
Message-ID: <87ac5klqua.fsf@jamesjb.com>

Thibault Langlois <tl at di.fc.ul.pt> writes:

> I'm trying open-gl for the first time and I get the following error:
>
> Undefined foreign symbol: "glAttachShader"
>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>
> I am using cmucl 19c on a intel linux. I fetched cffi and cl-opengl from
> their respective websites today.

IIRC, CMUCL is unique in that it is rather eager about resolving
foreign function linkage at compile-time.  In most other Lisps, you
can define an interface to a C function that doesn't exist, and you
are alright unless you call it.

Unfortunately, CL-OPENGL's strategy of defining linkage for every
OpenGL 2.0 function will break horribly in CMUCL if the GL library
version is lower, which is probably what's going on in your situation.

As a workaround for now, you could comment out the DEFCFUNs in
funcs.lisp that give you errors, or try in SBCL instead of CMUCL,
which resolves foreign linkage lazily.

I'm not sure what a long-term solution to this would involve---we'd
have to resolve functions that may or may not be present at runtime
(like C programs do with GL_EXTENSIONS).  Blech.

James


From tl at di.fc.ul.pt  Thu Aug 31 23:42:50 2006
From: tl at di.fc.ul.pt (Thibault Langlois)
Date: Fri, 01 Sep 2006 00:42:50 +0100
Subject: [cl-opengl-devel] Problem compiling cl-opengl for cmucl
In-Reply-To: <87ac5klqua.fsf@jamesjb.com>
References: <1157039844.6123.12.camel@wok>  <87ac5klqua.fsf@jamesjb.com>
Message-ID: <1157067770.5952.12.camel@wok>

On Thu, 2006-08-31 at 11:09 -0700, James Bielman wrote:
> Thibault Langlois <tl at di.fc.ul.pt> writes:
> 
> > I'm trying open-gl for the first time and I get the following error:
> >
> > Undefined foreign symbol: "glAttachShader"
> >    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> >
> > I am using cmucl 19c on a intel linux. I fetched cffi and cl-opengl from
> > their respective websites today.
> 
> IIRC, CMUCL is unique in that it is rather eager about resolving
> foreign function linkage at compile-time.  In most other Lisps, you
> can define an interface to a C function that doesn't exist, and you
> are alright unless you call it.
> 
> Unfortunately, CL-OPENGL's strategy of defining linkage for every
> OpenGL 2.0 function will break horribly in CMUCL if the GL library
> version is lower, which is probably what's going on in your situation.
> 
> As a workaround for now, you could comment out the DEFCFUNs in
> funcs.lisp that give you errors, or try in SBCL instead of CMUCL,
> which resolves foreign linkage lazily.
> 

Even after commenting the functions that were giving this kind of error,
some examples do not work. 
So I installed sbcl to experiment. cl-opengl compiles fine with sbcl
but, like with cmucl, the only examples that worked are gears and glut-
teapot. The examples from the red book give a division by zero with both
lisps.

CL-GLUT-EXAMPLES> (rb-double)

arithmetic error DIVISION-BY-ZERO signalled
   [Condition of type DIVISION-BY-ZERO]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-
thread" {A6539D1}>)

Backtrace:
  0: ((FLET #:G150))
  1: (SB-VM:SIGFPE-HANDLER #<unavailable argument> #<unavailable
argument> #.(SB-SYS:INT-SAP #X04B0D6D8))
  2: (SB-SYS:INVOKE-INTERRUPTION #<CLOSURE (LAMBDA NIL) {B7C72BD}>)
  3: ("foreign function: call_into_lisp")
  4: ("foreign function: funcall3")
  5: ("foreign function: interrupt_handle_now")
  6: ("foreign function: #x8053C58")

Is it a known issue ?

Another detail: when gears or glut-teapot are running if I destroy the
window (clicking on the cross), the lisp dies too. Is it supposed to to
behave like this ?

Thibault 

> I'm not sure what a long-term solution to this would involve---we'd
> have to resolve functions that may or may not be present at runtime
> (like C programs do with GL_EXTENSIONS).  Blech.
> 
> James



From luismbo at gmail.com  Thu Aug 31 23:52:37 2006
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Fri, 1 Sep 2006 00:52:37 +0100
Subject: [cl-opengl-devel] Problem compiling cl-opengl for cmucl
In-Reply-To: <1157067770.5952.12.camel@wok>
References: <1157039844.6123.12.camel@wok> <87ac5klqua.fsf@jamesjb.com>
	<1157067770.5952.12.camel@wok>
Message-ID: <391f79580608311652r66788ca1y1661bb7f4651ca06@mail.gmail.com>

On 9/1/06, Thibault Langlois <tl at di.fc.ul.pt> wrote:
> CL-GLUT-EXAMPLES> (rb-double)
>
> arithmetic error DIVISION-BY-ZERO signalled
>    [Condition of type DIVISION-BY-ZERO]
[...]
> Is it a known issue ?

Maybe. Try the following perhaps:

(sb-int:with-float-traps-masked (:invalid :divide-by-zero)
  (rb-double))


> Another detail: when gears or glut-teapot are running if I destroy the
> window (clicking on the cross), the lisp dies too. Is it supposed to to
> behave like this ?

Not at all. Someone else mentioned this problem in #lisp and was using
FreeGLUT 2.2. IIRC, upgrading to version 2.4 fixed that.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/