From luke at balooga.com  Sun Mar 11 05:44:55 2007
From: luke at balooga.com (Luke Crook)
Date: Sun, 11 Mar 2007 05:44:55 +0000 (UTC)
Subject: [cl-opengl-devel] cl-opengl in win32, was working now not so much
Message-ID: <loom.20070311T064205-660@post.gmane.org>

cl-opengl seemed to be working fine for me on 01/30; see:

http://article.gmane.org/gmane.lisp.cl-lispbuilder.general/648

But after downloading the latest version of CFFI I get the following error in 
CLISP. Anyone know what the problem may be?

Thanks,
- Luke

EVAL: undefined function CFFI::LISP-FUNCTION-NAME
   [Condition of type SYSTEM::SIMPLE-UNDEFINED-FUNCTION]

Restarts:
  0: [USE-VALUE] You may input a value to be used instead of (FDEFINITION
 'CFFI::LISP-FUNCTION-NAME).
  1: [RETRY] Retry
  2: [STORE-VALUE] You may input a new value for (FDEFINITION 'CFFI::LISP-
FUNCTION-NAME).
  3: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL #x19FF2479> on #<ASDF:CL-
SOURCE-FILE "funcs" #x19FF1F49>.
  4: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL #x19FF2479> on #<ASDF:CL-
SOURCE-FILE "funcs" #x19FF1F49> as having been successful.
  5: [ABORT-REQUEST] Abort handling SLIME request.




From luismbo at gmail.com  Sun Mar 11 17:33:03 2007
From: luismbo at gmail.com (Luis Oliveira)
Date: Sun, 11 Mar 2007 17:33:03 +0000
Subject: [cl-opengl-devel] Re: cl-opengl in win32,
	was working now not so much
References: <loom.20070311T064205-660@post.gmane.org>
Message-ID: <m1veh7r8hc.fsf@deadspam.com>

Luke Crook <luke at balooga.com> writes:
> But after downloading the latest version of CFFI I get the following error in
> CLISP. Anyone know what the problem may be?
[...]
> EVAL: undefined function CFFI::LISP-FUNCTION-NAME
>    [Condition of type SYSTEM::SIMPLE-UNDEFINED-FUNCTION]

That function doesn't exist anymore, so that's the problem.  BTW, on an
unrelated note, I really don't understand very well how the current
cl-opengl works in windows at all, since it doesn't specify the stdcall
convention. (It doesn't matter for SBCL and Allegro as they handle
stdcall automagically but should be an issue for CLISP, Lispworks, etc.)

I guess you have three options:

  1. Substitute cffi::lisp-function-name for cffi::lisp-name.

  2. Use http://common-lisp.net/~loliveira/darcs/cl-opengl-thomas
     which requires http://common-lisp.net/~loliveira/darcs/cffi-newtypes
     and should have much better Win32 support.

  3. Wait until CFFI and cl-opengl merge all or some of the changes in
     the above trees.

HTH.

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



From 3.14159 at gmx.net  Sat Mar 10 01:28:28 2007
From: 3.14159 at gmx.net (thomas weidner)
Date: Sat, 10 Mar 2007 01:28:28 +0000 (UTC)
Subject: [cl-opengl-devel] Re: generating function bindings,
	extension loading
References: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com>
	<DDE6AE71-36B6-4998-A948-764F9D0DC0F1@entrox.org>
Message-ID: <loom.20070310T020958-244@post.gmane.org>

> trick stupid gmane web poster here...

I'm somehow concerned about the constants issue myself,so i think this is the
right place to post my thoughts.

Oliver Markovic <entrox <at> entrox.org> writes:
> 
> > Second is changing the GLenums from cffi:defcenums to defconstants.
> > Advantages I can think of from doing that:
> 
> This is not. The whole point of cl-opengl was having hand-written  
> bindings
> that feel Lispy and not like a direct mapping to C. I do NOT want to  
> write
> code like (gl:clear-color (logior gl:+color-buffer-bit+ gl:+depth- 
> buffer-bit+))
> or having to think about how to construct a foreign array to pass to  
> glLightfv.
opengl is state based and therefore not lispy at all, it's all about side
effects. Wrapping it to a lispy interface is for a higher level interface like a
whole gfx engine, not for a simple opengl bindings package. you can still have
(clear +color-buffer-bit+ +depth-buffer-bit+) which has much less overhead.
> 
> If somebody wants to use bindings like this, Glouton[1] or kt-opengl 
> [2] seem
> like a better fit. They follow a different, more direct approach for  
> people who
> prefer that model. Writing bindings isn't exactly rocket science, so  
> having more
> than one way to do things is a good thing as far as I'm concerned.
where is the cl-opengl approach indirect? replacing constants by keywords
doesn't change the way the binding work,it's only cosmetic for the end user.

[snip, agreed as solveable with keywords]
> I neither care about GLX nor CL-SDL. If neither CLX, nor any other  
> non-C library
> use +foo+, why should we? Personally, I think it looks way too ugly.
> 
> >  *possibly speed. If cffi can remap values at compile time it
> > probably isn't too bad, but it probably wouldn't be too hard to find
> > code with a lot of enums specified at runtime.
> 
> It does remap values where possible. Here's an example from OpenMCL:
> 
> ? (defun foo ()
>      (gl:clear :color-buffer-bit :depth-buffer-bit))
> FOO
> ? (disassemble 'foo)
>    (TWNEI NARGS 0)
>    (MFLR LOC-PC)
>    (BLA .SPSAVECONTEXTVSP)
>    (STWU SP -80 SP)
>    (STW RZERO 8 SP)
>    (LWZ ARG_Y '#<EXTERNAL-ENTRY-POINT "_glClear" (#x92E83368) /System/ 
> Library/Frameworks/OpenGL.framework/OpenGL #x8476C8E> FN)
>    (LWZ ARG_Z 2 ARG_Y)
>    (TWEQI ARG_Z NIL)
>    (VPUSH ARG_Z)
>    (LI IMM0 16640)
>    (STW IMM0 24 SP)
>    (LWZ ARG_Z 0 VSP)
>    (LA VSP 4 VSP)
>    (BLA .SPPOWEROPEN-FFCALL)
>    (LI ARG_Z NIL)
>    (BA .SPPOPJ)
> 
> Note the LI IMM0 16640. GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT =>  
> 0x4100 => 16640.
> 
> But even then, the performance impact of doing so at runtime is  
> neglible.
no it is not. 
here (sbcl/amd64) a (defun clear (&rest args) ...) is ~15-20 instructions long,
no extra function call. the standard keyword based version is ~120 instructions
long and calls a generic function. this _IS_ a lot of overhead for such
fundamental functions as opengl operations. 
I think the more the applications become the less are the possibilities for the
compiler to optimize at compile time. think of extra effect files or external
data in general where constants are simply unknown at compile time and
keyword->constant dispatch has to be done at runtime. 
Sure, it doesn't matter for any glut demo, and also for any small game or
application, but complex applications (think of a lisp version of Oblivion) it
will become significant. I really don't see why we should slow down opengl
applications for a small bit of "beauty". It [beauty] will be there when higher
level apis are written based upon cl-opengl. 
My last thought: what are your points for using keywords? you seem to be really
keen on not dropping them; from changing cffi to accept runtime overhead. why?

   mfg thomas

PS: don't get me wrong, i really like to see that there is a opengl wrapper in
active development. sorry if i hit the wrong note.



From luismbo at gmail.com  Sun Mar 11 18:12:03 2007
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Sun, 11 Mar 2007 18:12:03 +0000
Subject: [cl-opengl-devel] Re: generating function bindings,
	extension loading
In-Reply-To: <loom.20070310T020958-244@post.gmane.org>
References: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com>
	<DDE6AE71-36B6-4998-A948-764F9D0DC0F1@entrox.org>
	<loom.20070310T020958-244@post.gmane.org>
Message-ID: <391f79580703111112s6bc53225h13a55278515d3a5d@mail.gmail.com>

On 10/03/07, thomas weidner <3.14159 at gmx.net> wrote:
> here (sbcl/amd64) a (defun clear (&rest args) ...) is ~15-20 instructions long,
> no extra function call. the standard keyword based version is ~120 instructions
> long and calls a generic function. this _IS_ a lot of overhead for such
> fundamental functions as opengl operations.

You should mention that this only happens if the arguments aren't
constant. GL:CLEAR has  a compiler macro that removes all that
overhead.

If this turns out to be a problem we can also have the enum type
accept integers as well and add some operators to get the value of the
keywords at compile-time. Then you can play with LOGIOR all you want.
:-)


> My last thought: what are your points for using keywords? you seem to be really
> keen on not dropping them; from changing cffi to accept runtime overhead. why?

I'd be in favor of, in addition to the big enum, having restricted
enums like we used to so that we get errors (at compile-time usually)
when we pass the wrong keyword.

The spec even gives us that info in enum.spec and gl.spec. Not a big
priority though.

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


From thekingoftruth at gmail.com  Fri Mar 16 21:29:24 2007
From: thekingoftruth at gmail.com (sathya gnanasekaran)
Date: Fri, 16 Mar 2007 14:29:24 -0700
Subject: [cl-opengl-devel] Helping out from OSX
Message-ID: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>

Hello all,

My name is Sathya, and I would like to contribute to cl-opengl.

I use cl-opengl on OSX to play with opengl in lisp. I use it by
changing the library from freeglut to apple's cocoa-based glut
framework. (Although I'm sure I could use apple's X11 + freeglut, X
has given be trouble.)

If there's anything in particular you would like help with, I'm here.
(It could be anything from OSX based testing to simple bug fixes.)

Thanks


From luismbo at gmail.com  Fri Mar 16 23:17:15 2007
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Fri, 16 Mar 2007 23:17:15 +0000
Subject: [cl-opengl-devel] Helping out from OSX
In-Reply-To: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>
References: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>
Message-ID: <391f79580703161617u6981e499i5777806ba0386e92@mail.gmail.com>

On 16/03/07, sathya gnanasekaran <thekingoftruth at gmail.com> wrote:
> I use cl-opengl on OSX to play with opengl in lisp. I use it by
> changing the library from freeglut to apple's cocoa-based glut
> framework. (Although I'm sure I could use apple's X11 + freeglut, X
> has given be trouble.)

That GLUT will call exit() (and kill your Lisp) very often, doesn't
that annoy you? Hey, you could port freeglut to Cocoa (or is it
Carbon?), that'd be nice. :-)

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


From thekingoftruth at gmail.com  Sat Mar 17 00:11:31 2007
From: thekingoftruth at gmail.com (sathya gnanasekaran)
Date: Fri, 16 Mar 2007 17:11:31 -0700
Subject: [cl-opengl-devel] Helping out from OSX
In-Reply-To: <391f79580703161617u6981e499i5777806ba0386e92@mail.gmail.com>
References: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>
	<391f79580703161617u6981e499i5777806ba0386e92@mail.gmail.com>
Message-ID: <fd4af15d0703161711w745f2c72v78a7f1dfa29ba626@mail.gmail.com>

Yeah, it annoys me a lot. I'll check if anyone has any prior work done in
that direction first, but if not, I'll look into it. The problem is I have
little cocoa/carbon experience. Time to learn I guess.

On 3/16/07, Lu?s Oliveira <luismbo at gmail.com> wrote:
>
> On 16/03/07, sathya gnanasekaran <thekingoftruth at gmail.com> wrote:
> > I use cl-opengl on OSX to play with opengl in lisp. I use it by
> > changing the library from freeglut to apple's cocoa-based glut
> > framework. (Although I'm sure I could use apple's X11 + freeglut, X
> > has given be trouble.)
>
> That GLUT will call exit() (and kill your Lisp) very often, doesn't
> that annoy you? Hey, you could port freeglut to Cocoa (or is it
> Carbon?), that'd be nice. :-)
>
> --
> Lu?s Oliveira
> http://student.dei.uc.pt/~lmoliv/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070316/063ba783/attachment.html>

From sean.charles at objitsu.com  Sat Mar 17 09:23:52 2007
From: sean.charles at objitsu.com (Sean Charles)
Date: Sat, 17 Mar 2007 09:23:52 +0000
Subject: [cl-opengl-devel] Helping out from OSX
In-Reply-To: <fd4af15d0703161711w745f2c72v78a7f1dfa29ba626@mail.gmail.com>
References: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>
	<391f79580703161617u6981e499i5777806ba0386e92@mail.gmail.com>
	<fd4af15d0703161711w745f2c72v78a7f1dfa29ba626@mail.gmail.com>
Message-ID: <E3B8BD7B-2E4A-4E6D-AD4E-B117E8302C91@objitsu.com>

I am sure the thing that stopped me was not being able to call  
NSApplicationInit()... I did manage to get something going but it  
kept dropping out with an error, which, on looking it up said I had  
to call NSApplicationInit() but my CFFI experience is limited and I  
couldn't work out how to do it.

I looked at Verrazano as well but in the end time pressures made me  
go for X11. It just worked, I had to make a small change to get it to  
work on an intel mac though if I remember I just modded the  
library.lisp file a bit. My finally chaotic glut def looks like:

(define-foreign-library glut
   ;;-- (sjc-03-jul-06) -- added this line to ensure my locally built
   ;;-- OpenGLUT library is loaded as the "glut" library!
   ;;
   ;; (1) /usr/local/lib/libopenglut.dylib  => my build from OpenGLUT  
source package.
   ;; (2) /sw/lib/libglut.dylib => FINK installation of 3.7-1025
   ;;
   ;; Q. Which one is 'better' to use, if any ?!
   ;;    (1) because (2) doesn't have glutLeaveMainLoop etc !!!
   ;;
   ;((:and :darwin :x86) "/sw/lib/libglut.dylib")
   ((:and :darwin :x86) "/usr/local/lib/libopenglut.dylib")
   ;((:and :darwin :x86) (:framework "GLUT"))
   ;(:darwin (:or "libglut.dylib" "libglut.3.dylib" #-(and) 
(:framework "GLUT")))
   (:windows "freeglut.dll") ; XXX: is this right?
   (:unix (:or "libglut.so" "libglut.so.3")))

which, removing the chaff leaves this, I added the :x86 to make it  
intel friendly!

(define-foreign-library glut
   ((:and :darwin :x86) "/usr/local/lib/libopenglut.dylib")
   (:windows "freeglut.dll") ; XXX: is this right?
   (:unix (:or "libglut.so" "libglut.so.3")))



On 17 Mar 2007, at 00:11, sathya gnanasekaran wrote:

> Yeah, it annoys me a lot. I'll check if anyone has any prior work  
> done in that direction first, but if not, I'll look into it. The  
> problem is I have little cocoa/carbon experience. Time to learn I  
> guess.
>
> On 3/16/07, Lu?s Oliveira <luismbo at gmail.com> wrote:
> On 16/03/07, sathya gnanasekaran <thekingoftruth at gmail.com> wrote:
> > I use cl-opengl on OSX to play with opengl in lisp. I use it by
> > changing the library from freeglut to apple's cocoa-based glut
> > framework. (Although I'm sure I could use apple's X11 + freeglut, X
> > has given be trouble.)
>
> That GLUT will call exit() (and kill your Lisp) very often, doesn't
> that annoy you? Hey, you could port freeglut to Cocoa (or is it
> Carbon?), that'd be nice. :-)
>
> --
> Lu?s Oliveira
> http://student.dei.uc.pt/~lmoliv/
>
> _______________________________________________
> cl-opengl-devel mailing list
> cl-opengl-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070317/50719ac6/attachment.html>

From thekingoftruth at gmail.com  Sat Mar 17 09:46:00 2007
From: thekingoftruth at gmail.com (sathya gnanasekaran)
Date: Sat, 17 Mar 2007 02:46:00 -0700
Subject: [cl-opengl-devel] Helping out from OSX
In-Reply-To: <E3B8BD7B-2E4A-4E6D-AD4E-B117E8302C91@objitsu.com>
References: <fd4af15d0703161429w7b14df94p2b828fead99098c1@mail.gmail.com>
	<391f79580703161617u6981e499i5777806ba0386e92@mail.gmail.com>
	<fd4af15d0703161711w745f2c72v78a7f1dfa29ba626@mail.gmail.com>
	<E3B8BD7B-2E4A-4E6D-AD4E-B117E8302C91@objitsu.com>
Message-ID: <fd4af15d0703170245l57c32a5ldc95bb0fc40bd2dc@mail.gmail.com>

It has something to do with the functions in interface.lisp, I believe. (I
can't remember for sure, but I THINK, if you call glut:init twice using
apple's cocoa glut it gives you that NSApplicationInit() error.)

All I had to do (I think, it's been a while) was to use that (:darwin
(:framework "GLUT")) line in library.lisp.

My sample code is attached, Sean, although it won't run as it is, unless you
install cl-arcball. Remove all of the cl-arcball code and it should run for
you. (Or, since I'm also attaching my cl-arcball asdf-install library, you
can just asdf-install cl-arcball 0.1).

Note all of the cffi foreign function and foreign type conversion and
callback stuff. It's not hard once you read through the code, in my opinion.

On 3/17/07, Sean Charles <sean.charles at objitsu.com> wrote:
>
> I am sure the thing that stopped me was not being able to call
> NSApplicationInit()... I did manage to get something going but it kept
> dropping out with an error, which, on looking it up said I had to call
> NSApplicationInit() but my CFFI experience is limited and I couldn't work
> out how to do it.
> I looked at Verrazano as well but in the end time pressures made me go for
> X11. It just worked, I had to make a small change to get it to work on an
> intel mac though if I remember I just modded the library.lisp file a bit.
> My finally chaotic glut def looks like:
>
> (define-foreign-library glut
>   ;;-- (sjc-03-jul-06) -- added this line to ensure my locally built
>   ;;-- OpenGLUT library is loaded as the "glut" library!
>   ;;
>   ;; (1) /usr/local/lib/libopenglut.dylib  => my build from OpenGLUT
> source package.
>   ;; (2) /sw/lib/libglut.dylib => FINK installation of 3.7-1025
>   ;;
>   ;; Q. Which one is 'better' to use, if any ?!
>   ;;    (1) because (2) doesn't have glutLeaveMainLoop etc !!!
>   ;;
>   ;((:and :darwin :x86) "/sw/lib/libglut.dylib")
>   ((:and :darwin :x86) "/usr/local/lib/libopenglut.dylib")
>   ;((:and :darwin :x86) (:framework "GLUT"))
>   ;(:darwin (:or "libglut.dylib" "libglut.3.dylib" #-(and)(:framework
> "GLUT")))
>   (:windows "freeglut.dll") ; XXX: is this right?
>   (:unix (:or "libglut.so" "libglut.so.3")))
>
> which, removing the chaff leaves this, I added the :x86 to make it intel
> friendly!
>
> (define-foreign-library glut
>   ((:and :darwin :x86) "/usr/local/lib/libopenglut.dylib")
>   (:windows "freeglut.dll") ; XXX: is this right?
>   (:unix (:or "libglut.so" "libglut.so.3")))
>
>
>
> On 17 Mar 2007, at 00:11, sathya gnanasekaran wrote:
>
> Yeah, it annoys me a lot. I'll check if anyone has any prior work done in
> that direction first, but if not, I'll look into it. The problem is I have
> little cocoa/carbon experience. Time to learn I guess.
>
> On 3/16/07, Lu?s Oliveira <luismbo at gmail.com> wrote:
> >
> > On 16/03/07, sathya gnanasekaran <thekingoftruth at gmail.com> wrote:
> > > I use cl-opengl on OSX to play with opengl in lisp. I use it by
> > > changing the library from freeglut to apple's cocoa-based glut
> > > framework. (Although I'm sure I could use apple's X11 + freeglut, X
> > > has given be trouble.)
> >
> > That GLUT will call exit() (and kill your Lisp) very often, doesn't
> > that annoy you? Hey, you could port freeglut to Cocoa (or is it
> > Carbon?), that'd be nice. :-)
> >
> > --
> > Lu?s Oliveira
> > http://student.dei.uc.pt/~lmoliv/ <http://student.dei.uc.pt/%7Elmoliv/>
> >
>
> _______________________________________________
> cl-opengl-devel mailing list
> cl-opengl-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070317/89b50304/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lisp-opengl.lisp
Type: application/octet-stream
Size: 2986 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070317/89b50304/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-arcball_0.1.tar.gz
Type: application/x-gzip
Size: 11545 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070317/89b50304/attachment.bin>

From hrapof at common-lisp.ru  Sat Mar 17 18:46:48 2007
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Sat, 17 Mar 2007 21:46:48 +0300
Subject: [cl-opengl-devel] new patch
Message-ID: <45FC3798.1080800@common-lisp.ru>

Hello!

I've just finished a substantial project in which I tried lots of new 
Lisp things (for me, that is): foreign libraries, GUI, serial port 
programming, process spawning etc. It's a real time scientific data 
visualisation program, and I am pleased to say that Lisp version is 
faster than C++ one.
Attached is the patch (result of darcs send -o) with modifications that 
I made to cl-opengl in the process. It includes Charlie MacMackin's 
vertex array  patch.

Hope it will be useful.

Sincerely yours,
Dmitri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hrapof.patch
Type: text/x-patch
Size: 15558 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070317/83e755b4/attachment.bin>

From mikael.lax at bredband.net  Sun Mar 25 02:31:03 2007
From: mikael.lax at bredband.net (Mikael Lax)
Date: Sun, 25 Mar 2007 04:31:03 +0200
Subject: [cl-opengl-devel] Patch for compressed textures and draw/read-pixels
Message-ID: <20070325043103.06277290.mikael.lax@bredband.net>

Hi,

these are some small additions I use that I figured might be useful to someone else as well.

Attached is a patch to add support for compressed textures and draw-pixels/read-pixels. I'm not sure of how well these last two play with various pixelstore modes but it does everything I need it to do (eg. take screenshots, peek at the depth-buffer etc).

Sincerely yours,
Mikael Lax

PS: Patch is against cl-opengl-thomas branch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mikael.patch
Type: text/x-patch
Size: 4866 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-opengl-devel/attachments/20070325/c4c52d98/attachment.bin>