From soemraws at xs4all.nl Tue Jun 2 04:24:50 2009 From: soemraws at xs4all.nl (Sumant Oemrawsingh) Date: Mon, 1 Jun 2009 21:24:50 -0700 Subject: [cl-opengl-devel] gl:clear and depth-buffer Message-ID: <20090602042449.GB10994@pkd.Belkin> Hi, After successfully installing cl-opengl, I ran into the following problem when trying to run the examples. I found that the demo's ran without explicit errors, but the output didn't look right. Basically, gl:clear wasn't doing its job. After some messing around and help from people on #lisp, I found that after (gl:clear :color-buffer :depth-buffer), a (gl:get-error) returned INVALID-VALUE. When removing the :depth-buffer bit, it returned ZERO. When keeping the :depth-buffer and removing the :color-buffer, it returned INVALID-VALUE again. The constants in constants.lisp match those in GL.h, so that shouldn't be the problem. I'm using SBCL 1.0.28, nvidia binary drivers as well as intel (crappy) drivers. The libGL.so is symlinked to the card that I'm using, and I've verified that when loading cl-opengl, the correct library is used for the card that I'm running. So this is more of a "is this a bug?" or "help, it doesn't work!" type mail, and am not sure if I should have sent it to devel. However, I didn't know what else to do. Regards, Sumant From soemraws at xs4all.nl Tue Jun 2 04:17:11 2009 From: soemraws at xs4all.nl (Sumant Oemrawsingh) Date: Mon, 1 Jun 2009 21:17:11 -0700 Subject: [cl-opengl-devel] cl-opengl and *READ-DEFAULT-FLOAT-FORMAT* Message-ID: <20090602041710.GA10994@pkd.Belkin> Hi, I recently installed cl-opengl, but had problems during compilation, regarding an asserted type (single-float) not matching a derived type (double-float). After some time of looking into the problem, I found that I was compiling in a lisp (sbcl) where I redefined *READ-DEFAULT-FLOAT-FORMAT* to DOUBLE-FLOAT) for something or other. Setting this back (or restarting) allowed compilation. I would expect that a library is independent on this. I.e. constant floats should be consistently written as either 1.0d0 or 1.0f0, no? Anyway, just thought to let you know that this _might_ cause problems for others. Or maybe others aren't so stupid to globally change *R-D-F-F*... -Sumant From thecodewitch at yahoo.com Tue Jun 2 05:51:16 2009 From: thecodewitch at yahoo.com (Greg Santucci) Date: Mon, 1 Jun 2009 22:51:16 -0700 (PDT) Subject: [cl-opengl-devel] Clozure and cl-opengl Message-ID: <473534.7602.qm@web33606.mail.mud.yahoo.com> Hi, Is cl-opengl supposed to work with Clozure? I'm running Clozure on Win32, and I'm able to load cl-opengl using (asdf:oos 'asdf:load-op :cl-glut- examples), however upon running one of the examples Clozure crashes out to its kernel debugger. I'm using: * Clozure 1.3 for Windows * cl-opengl from darcs get http://www.common-lisp.net/project/cl-opengl/darcs/cl-opengl/ * Alexandria from http://common-lisp.net/~loliveira/tarballs/inofficial/alexandria-2008-07-29.tar.gz * Babel 0.3.0 * CFFI 0.10.4 * trivial-features 0.4 Regards, Greg Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline From thecodewitch at yahoo.com Tue Jun 2 05:45:23 2009 From: thecodewitch at yahoo.com (Greg Santucci) Date: Mon, 1 Jun 2009 22:45:23 -0700 (PDT) Subject: [cl-opengl-devel] Clozure and cl-opengl Message-ID: <579640.92888.qm@web33604.mail.mud.yahoo.com> Hi, Is cl-opengl supposed to work with Clozure? I'm running Clozure on Win32, and I'm able to load cl-opengl using (asdf:oos 'asdf:load-op :cl-glut- examples), however upon running one of the examples Clozure crashes out to its kernel debugger. I'm using: * Clozure 1.3 for Windows * Alexandria from http://common-lisp.net/~loliveira/tarballs/inofficial/alexandria-2008-07-29.tar.gz * Babel 0.3.0 * CFFI 0.10.4 * trivial-features 0.4 Regards, Greg Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline From luismbo at gmail.com Tue Jun 2 08:59:24 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 2 Jun 2009 09:59:24 +0100 Subject: [cl-opengl-devel] Clozure and cl-opengl In-Reply-To: <473534.7602.qm@web33606.mail.mud.yahoo.com> References: <473534.7602.qm@web33606.mail.mud.yahoo.com> Message-ID: <391f79580906020159i7cc7b6b7rabeacc734aa34c@mail.gmail.com> On Tue, Jun 2, 2009 at 6:51 AM, Greg Santucci wrote: > Is cl-opengl supposed to work with Clozure? I'm running Clozure on Win32, > and I'm able to load cl-opengl using (asdf:oos 'asdf:load-op :cl-glut- > examples), however upon running one of the examples Clozure crashes out to > its kernel debugger. Yes, and it works for me on Linux/x86-64. I do not have access to a Windows system at the moment. Perhaps you could paste a backtrace? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From thecodewitch at yahoo.com Tue Jun 2 10:18:36 2009 From: thecodewitch at yahoo.com (Greg Santucci) Date: Tue, 2 Jun 2009 03:18:36 -0700 (PDT) Subject: [cl-opengl-devel] Clozure and cl-opengl Message-ID: <149269.39154.qm@web33608.mail.mud.yahoo.com> --- On Tue, 2/6/09, Lu?s Oliveira wrote: > > Is cl-opengl supposed to work with Clozure? I'm > running Clozure on Win32, > > and I'm able to load cl-opengl using (asdf:oos > 'asdf:load-op :cl-glut- > > examples), however upon running one of the examples > Clozure crashes out to > > its kernel debugger. > > Yes, and it works for me on Linux/x86-64. I do not have > access to a > Windows system at the moment. Perhaps you could paste a > backtrace? > Certainly. Exception on foreign stack Exception occurred while executing foreign code ? for help [7560] Clozure CL kernel debugger: B current thread: tcr = 0x5cb310, native thread ID = 0x1980, interrupts enabled (#x00B80D44) #x08DC69A5 : # + 95 (#x00B80D4C) #x08DC676D : # + 23 (#x00B80D54) #x081139A5 : # + 679 (#x00B80D8C) #x083686DD : # + 247 (#x00B80DA8) #x083744B5 : # + 751 (#x00B80DE8) #x08375E25 : # + 1815 (#x00B80EFC) #x0836832D : # + 71 (#x00B80F04) #x08318175 : # + 95 (#x00B80F14) #x083D945D : # + 583 (#x00B80F60) #x08330A95 : # + 671 (#x00B80FA4) #x083312E5 : # + 335 (#x00B80FCC) #x083061BD : # + 279 [7560] Clozure CL kernel debugger: Here are the messages that appeared when loading cl-opengl with (asdf:operate 'asdf:load-op :cl-glut-examples) ; loading system definition from C:/lispbox/packages/cl-opengl/cl-glut-examples.asd into # ; registering # as CL-GLUT-EXAMPLES ; loading system definition from C:/lispbox/packages/cl-opengl/cl-glut.asd into # ; registering # as CL-GLUT ; loading system definition from C:/lispbox/packages/cl-opengl/cl-opengl.asd into # ; registering # as CL-OPENGL ; loading system definition from C:/lispbox/packages/cffi-090526/cffi.asd into # ; registering # as CFFI ; loading system definition from C:/lispbox/packages/babel_0.3.0/babel.asd into # ; registering # as BABEL ; loading system definition from C:/lispbox/packages/alexandria/alexandria.asd into # ; registering # as ALEXANDRIA ; loading system definition from C:/lispbox/packages/trivial-features_0.4/trivial-features.asd into # ; registering # as TRIVIAL-FEATURES ; loading system definition from C:/lispbox/packages/cl-opengl/cl-glu.asd into # ; registering # as CL-GLU ; Warning: Don't know how to setup a hook before saving cores on this Lisp. ; While executing: #, in process listener(1). ;Compiler warnings for "C:/lispbox/packages/cl-opengl/glu/glu.lisp" : ; In CL-GLU:UN-PROJECT4: Undefined function CL-GLU::%GLUUNPROJECT4 ;Compiler warnings for "C:/lispbox/packages/cffi-090526/src/cffi-openmcl.lisp" : ; In CFFI-SYS:%CLOSE-FOREIGN-LIBRARY: Undefined function CLOSE-SHARED-LIBRARY NIL Regards, Greg Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline From luismbo at gmail.com Tue Jun 2 12:46:33 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 2 Jun 2009 13:46:33 +0100 Subject: [cl-opengl-devel] Clozure and cl-opengl In-Reply-To: <149269.39154.qm@web33608.mail.mud.yahoo.com> References: <149269.39154.qm@web33608.mail.mud.yahoo.com> Message-ID: <391f79580906020546k6a875ee7nf51896df9737f4b1@mail.gmail.com> On Tue, Jun 2, 2009 at 11:18 AM, Greg Santucci wrote: > Exception occurred while executing foreign code Are you using FreeGLUT? If not, you should. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From thecodewitch at yahoo.com Tue Jun 2 13:05:05 2009 From: thecodewitch at yahoo.com (Greg Santucci) Date: Tue, 2 Jun 2009 06:05:05 -0700 (PDT) Subject: [cl-opengl-devel] Clozure and cl-opengl Message-ID: <439475.33208.qm@web33602.mail.mud.yahoo.com> --- On Tue, 2/6/09, Lu?s Oliveira wrote: > > Exception occurred while executing foreign code > > Are you using FreeGLUT? If not, you should. > > -- > Lu?s Oliveira > http://student.dei.uc.pt/~lmoliv/ > Yes, I'm using FreeGLUT. Its the same freeglut.dll I used with CLisp 2.42 that worked without any problems. It comes from here: http://www.turtle.dds.nl/gl4newlisp/freeglut.dll I also rebuilt it with MingW. It works with CLisp. I don't know if I am using a version of cffi that Clozure doesn't like. In the kernel debugger, if I choose "Exit from this debugger, asserting that any exception was handled", it runs for one frame, refreshes the display, then throws another exception. Thank you for your time. Regards, Greg Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline From luismbo at gmail.com Tue Jun 2 13:05:18 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 2 Jun 2009 14:05:18 +0100 Subject: [cl-opengl-devel] cl-opengl and *READ-DEFAULT-FLOAT-FORMAT* In-Reply-To: <20090602041710.GA10994@pkd.Belkin> References: <20090602041710.GA10994@pkd.Belkin> Message-ID: <391f79580906020605j1c4f08e7t3fda2b108dcb02e@mail.gmail.com> On Tue, Jun 2, 2009 at 5:17 AM, Sumant Oemrawsingh wrote: > I recently installed cl-opengl, but had problems during compilation, regarding > an asserted type (single-float) not matching a derived type (double-float). > After some time of looking into the problem, I found that I was compiling in a > lisp (sbcl) where I redefined *READ-DEFAULT-FLOAT-FORMAT* to DOUBLE-FLOAT) for > something or other. Thanks for the report. This should now be fixed. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From luismbo at gmail.com Tue Jun 2 13:07:27 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 2 Jun 2009 14:07:27 +0100 Subject: [cl-opengl-devel] gl:clear and depth-buffer In-Reply-To: <20090602042449.GB10994@pkd.Belkin> References: <20090602042449.GB10994@pkd.Belkin> Message-ID: <391f79580906020607h537c6f2bld74a9874b6772020@mail.gmail.com> On Tue, Jun 2, 2009 at 5:24 AM, Sumant Oemrawsingh wrote: > After successfully installing cl-opengl, I ran into the following problem when > trying to run the examples. I found that the demo's ran without explicit > errors, but the output didn't look right. Basically, gl:clear wasn't doing its > job. Can you give us a specific example so that we can try and reproduce the problem? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From jpb at rrette.com Tue Jun 2 13:46:15 2009 From: jpb at rrette.com (Jean-Philippe Barette-LaPierre) Date: Tue, 2 Jun 2009 09:46:15 -0400 Subject: [cl-opengl-devel] GLUT on Mac OS X Message-ID: <4e3cf5960906020646r43b72ff5w93f5d5b5f4a5fb10@mail.gmail.com> I know this question seems to be asked quite frequently, but I was wondering what is the status of the bindings of GLUT.Framework on Mac OS X? I know that some time ago, there was a branch named thomas that I heard succeeded to use GLUT.Framework instead of freeglut. That branch was supposed to be merged in the main branch. I'm asking, because I tried to use GLUT.Framework, but it seems that I there's many obstacles. If I remember correctly, I'm not using an old version of cl-opengl. So, I was wondering if there was a person working on this. If there is such a person (or not), I would like to help getting this working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismbo at gmail.com Tue Jun 2 14:23:56 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 2 Jun 2009 15:23:56 +0100 Subject: [cl-opengl-devel] GLUT on Mac OS X In-Reply-To: <4e3cf5960906020646r43b72ff5w93f5d5b5f4a5fb10@mail.gmail.com> References: <4e3cf5960906020646r43b72ff5w93f5d5b5f4a5fb10@mail.gmail.com> Message-ID: <391f79580906020723n49d9049cxbd662c7e6e6e1676@mail.gmail.com> On Tue, Jun 2, 2009 at 2:46 PM, Jean-Philippe Barette-LaPierre wrote: > bindings of GLUT.Framework on Mac OS X? I know that some time ago, there was > a branch named thomas > that I heard succeeded to use GLUT.Framework instead of freeglut. That > branch was supposed to be merged > in the main branch. It was indeed merged but I don't recall it having any OSX-specific changes. > I'm asking, because I tried to use GLUT.Framework, but > it seems that I there's many obstacles. > If I remember correctly, I'm not using an old version of cl-opengl. So, I > was wondering if there was a person working > on this. If there is such a person (or not), I would like to help getting > this working. There was some discussion recently, yes. Unfortunately, I don't have access to an OSX system at the moment. If you need any help with the porting just send a message to this mailing list. Sometimes you might also find us at freenode's #lisp. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From soemraws at xs4all.nl Tue Jun 2 22:41:18 2009 From: soemraws at xs4all.nl (Sumant Oemrawsingh) Date: Tue, 2 Jun 2009 15:41:18 -0700 Subject: [cl-opengl-devel] gl:clear and depth-buffer In-Reply-To: <391f79580906020607h537c6f2bld74a9874b6772020@mail.gmail.com> References: <20090602042449.GB10994@pkd.Belkin> <391f79580906020607h537c6f2bld74a9874b6772020@mail.gmail.com> Message-ID: <20090602224115.GA14014@pkd.Belkin> Hi, To answer Edward Tate: I'm not using LispBuilderSDL. In fact, I'm not "using" cl-opengl at all at the moment. What I was talking about was, right after installation of cl-opengl running some examples in the source tree to see if it works. So I guess to answer the question properly, I'm using GLUT then. So I tried two examples: glut-teapot and gears. Both of these suffer from the same problem with gl:clear (i.e. gl:get-errror returns invalid-value when depth-buffer is set). So, here are some details. For the teapot, what happens is that the window shows the (in)famous teapot, but the background is a copy of the place on my desktop where the window was instantiated, i.e. not black. For gears, I can't see the gears rotating, because the "teeth" of the gears smear out and cause the gears to have a more wheel-like appearance. I also had a quick look at render-to-texture, which is... well, weird... On #lisp, it was suggested that this means that gl:clear doesn't do it's job properly, and that I should see what cl:get-error returns. So I altered the code for the teapot and put a cl:get-error before and after the (cl:clear :color-buffer :depth-buffer), and the error is printed on screen. Result is that before the call to clear, get-error returns zero, but after, it returns invalid-value. So I proceeded to find out which of the two flags is bogus. Removing :color-buffer and keeping :depth-buffer from the call to cl:clear still returned invalid-value, while removing :depth-buffer and keeping :color-buffer returned zero. So both the original and former calls to cl:clear failed, while the latter succeeded. Of course, the result is still wrong, because the depth buffer isn't cleared. But at least I know that using (cl:clear :depth-buffer) fails. I've verified in my GL.h file that the constant for the depth buffer bit matches the one in constants.lisp, so there's no problem there. Also, using lsof, I've verified that when I (require 'cl-opengl) in SBCL, that SBCL indeed uses the correct libGL.so. Now, when I compile and run glxgears, the C program, it works fine. I'm not sure where else I can look for more info. I don't think my X logs say anything, and I don't see any error messages when running the (gears) example, nor when running the (glut-teapot) example. It is highly probable that you won't be able to reproduce this problem, or else, you would have noticed immediately, since it is the examples already that don't work, right? :) If you need more information or there are things you want me to try to debug what's going on, then I'm willing to help. At the moment, though, since the examples don't work, I'm not using cl-opengl, while I really want to. Thanks, Sumant On Tue, Jun 02, 2009 at 02:07:27PM +0100, Lu?s Oliveira wrote: > On Tue, Jun 2, 2009 at 5:24 AM, Sumant Oemrawsingh wrote: > > After successfully installing cl-opengl, I ran into the following problem when > > trying to run the examples. I found that the demo's ran without explicit > > errors, but the output didn't look right. Basically, gl:clear wasn't doing its > > job. > > Can you give us a specific example so that we can try and reproduce the problem? > > -- > Lu?s Oliveira > http://student.dei.uc.pt/~lmoliv/ > From luismbo at gmail.com Tue Jun 2 23:39:31 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 3 Jun 2009 00:39:31 +0100 Subject: [cl-opengl-devel] gl:clear and depth-buffer In-Reply-To: <20090602224115.GA14014@pkd.Belkin> References: <20090602042449.GB10994@pkd.Belkin> <391f79580906020607h537c6f2bld74a9874b6772020@mail.gmail.com> <20090602224115.GA14014@pkd.Belkin> Message-ID: <391f79580906021639y7b7dba93kf136e55208347bf8@mail.gmail.com> On Tue, Jun 2, 2009 at 11:41 PM, Sumant Oemrawsingh wrote: > It is highly probable that you won't be able to reproduce this problem, or > else, you would have noticed immediately, since it is the examples already > that don't work, right? :) If you need more information or there are things > you want me to try to debug what's going on, then I'm willing to help. At the > moment, though, since the examples don't work, I'm not using cl-opengl, while > I really want to. Indeed, I can't reproduce your problem. What version of FreeGLUT are you using? Also, perhaps you can try to call (%gl:clear #x100) and see if that helps. That's all I can think of right now. HTH. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From soemraws at xs4all.nl Wed Jun 3 00:10:27 2009 From: soemraws at xs4all.nl (Sumant Oemrawsingh) Date: Tue, 2 Jun 2009 17:10:27 -0700 Subject: [cl-opengl-devel] gl:clear and depth-buffer In-Reply-To: <391f79580906021639y7b7dba93kf136e55208347bf8@mail.gmail.com> References: <20090602042449.GB10994@pkd.Belkin> <391f79580906020607h537c6f2bld74a9874b6772020@mail.gmail.com> <20090602224115.GA14014@pkd.Belkin> <391f79580906021639y7b7dba93kf136e55208347bf8@mail.gmail.com> Message-ID: <20090603001026.GC14521@pkd.Belkin> On Wed, Jun 03, 2009 at 12:39:31AM +0100, Lu?s Oliveira wrote: > On Tue, Jun 2, 2009 at 11:41 PM, Sumant Oemrawsingh wrote: > > It is highly probable that you won't be able to reproduce this problem, or > > else, you would have noticed immediately, since it is the examples already > > that don't work, right? :) If you need more information or there are things > > you want me to try to debug what's going on, then I'm willing to help. At the > > moment, though, since the examples don't work, I'm not using cl-opengl, while > > I really want to. > > Indeed, I can't reproduce your problem. What version of FreeGLUT are > you using? Also, perhaps you can try to call (%gl:clear #x100) and see > if that helps. Hi Lu?s, It's solved now. Basically, I was using an old version, not the darcs version... Will you release stable versions again, or is darcs the only place to get it? Anyway, read on if you're interested in what I tried and what I found out. I'm using freeglut 2.4.0. In both the teapot and gears demo, I replaced (gl:clear :color-buffer :depth-buffer) into (format t "~a~%" (gl:get-error)) (gl:clear :color-buffer) (format t "~a~%" (gl:get-error)) (gl:clear :depth-buffer) (format t "~a~%" (gl:get-error)) which gives ZERO ZERO INVALID-VALUE and terrible visual output, the same as with the original call. So I replace the last gl:clear call with (%gl:clear #x100) as you suggested. The result is ZERO ZERO ZERO and gives me a nice teapot, and nice, fast rotating gears! This appears to work fine! So I looked again at the source file constants.lisp which seemed fine. However, I suddenly noticed that asdf wasn't using the darcs version I downloaded a few days ago, but an older version 0.1_p20080926 that was installed through my dists package manager! D'oh! In the old version, :depth-buffer-bit is defined as #x100, but :depth-buffer is defined as #x8223. I removed the old one, and pointed asdf to the new one. Everything works as advertised now! Sorry for wasting your time. Sumant From jpb at rrette.com Wed Jun 3 00:58:40 2009 From: jpb at rrette.com (Jean-Philippe Barette-LaPierre) Date: Tue, 2 Jun 2009 20:58:40 -0400 Subject: [cl-opengl-devel] Native glut support for mac os x: Draft Message-ID: <4e3cf5960906021758q5d6aae34x780fe36f83020d89@mail.gmail.com> Here's a first working draft for GLUT.Framework support. I'm not familiar with either lisp or opengl, so if you want me to improve the patch in any way, just tell me what you want and I'll modify it. Currently, the first obvious problem is that there's no way to choose between the freeglut library or the native one (GLUT.Framework). So, how do you want to manage the future patches I'll send? Do you want to store a branch somewhere? BTW, I want to thanks "esden": http://www.esden.net/blog/ >From which I took most of the changes: http://www.esden.net/blog/2007/12/31/cl-opengl-thomas-mac-os-x-bindings-with-native-glutframework/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-opengl-macosx-native.diff Type: application/octet-stream Size: 9600 bytes Desc: not available URL: From luismbo at gmail.com Thu Jun 4 21:56:54 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Thu, 4 Jun 2009 22:56:54 +0100 Subject: [cl-opengl-devel] Native glut support for mac os x: Draft In-Reply-To: <4e3cf5960906021758q5d6aae34x780fe36f83020d89@mail.gmail.com> References: <4e3cf5960906021758q5d6aae34x780fe36f83020d89@mail.gmail.com> Message-ID: <391f79580906041456x2271658an8f004d74f4227064@mail.gmail.com> On Wed, Jun 3, 2009 at 1:58 AM, Jean-Philippe Barette-LaPierre wrote: > Here's a first working draft for GLUT.Framework support. I'm not familiar > with either lisp or opengl, so if you want me to improve the patch in any > way, just tell me what you want and I'll modify it. I borrowed a Mac mini for a few minutes (yay clbuild!) and tried your patch. Things seemed to work though closing a window didn't return me to the REPL. (I tried the gears example.) Also, I don't think this patch will work as is on e.g. Clozure CL since the event loop needs to run on the initial thread. glut/interface.lisp has some commented out code at the end to do just that. > Currently, the first > obvious problem is that there's no way to choose between the freeglut > library or the native one (GLUT.Framework). I wouldn't worry much about that for now. I don't think OSX users want to deal with X11 or FreeGLUT at all. > So, how do you want to manage > the future patches I'll send? Diffs are fine, thanks. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From thecodewitch at gmail.com Mon Jun 22 04:45:21 2009 From: thecodewitch at gmail.com (Greg Santucci) Date: Mon, 22 Jun 2009 15:45:21 +1100 Subject: [cl-opengl-devel] cl-opengl not running with CLisp Message-ID: <66c9435a0906212145o9cf20eax4350b9d55343f805@mail.gmail.com> I'm using the latest cl-opengl, cffi, babel, alexandria and trivial-features, and I get the following errors when I try to run glut examples: [3]> (cl-glut-examples:gears) *** - FFI::WRITE-MEMORY-AS: 5.0s0 cannot be converted to the foreign type SINGLE-FLOAT [3]> (cl-glut-examples:rb-robot) *** - FFI::FOREIGN-CALL-OUT: 0.0s0 cannot be converted to the foreign type SINGLE-FLOAT I've tried several versions of CLisp, it happens on all of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismbo at gmail.com Mon Jun 22 10:59:43 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Mon, 22 Jun 2009 11:59:43 +0100 Subject: [cl-opengl-devel] cl-opengl not running with CLisp In-Reply-To: <66c9435a0906212145o9cf20eax4350b9d55343f805@mail.gmail.com> References: <66c9435a0906212145o9cf20eax4350b9d55343f805@mail.gmail.com> Message-ID: <391f79580906220359q38adf1ebl39ef2e7d032d4ae7@mail.gmail.com> On Mon, Jun 22, 2009 at 5:45 AM, Greg Santucci wrote: > [3]> (cl-glut-examples:gears) > > *** - FFI::WRITE-MEMORY-AS: 5.0s0 cannot be converted to the foreign type > SINGLE-FLOAT Ugh, my bad. Should be fixed now. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From josepadovani at yahoo.com.br Wed Jun 24 04:23:12 2009 From: josepadovani at yahoo.com.br (padovani) Date: Wed, 24 Jun 2009 01:23:12 -0300 Subject: [cl-opengl-devel] sbcl "sb-ext:save-lisp-and-die" does not run (glutInit ?) Message-ID: <4A41AA30.2000002@yahoo.com.br> hello, I am making some tests with cl-opengl to make standalone executables with "sb-ext:save-lisp-and-die"... I am usign SBCL 1.0.29 in Mac OSX and have downloaded the "thomas" version available from (http://www.esden.net/content/lisp/cl-mac-native-opengl-thomas-0.1.tar.bz2)... (is this one the recommended version for Mac OSX?) My first attempt was to create an external from the redbook cube.lisp example... so, after evaluating through slime "(require 'asdf)" and all the functions of cube.lisp, I have evalueted this code: (sb-ext:save-lisp-and-die "rb-cube-binario" :executable t :save-runtime-options t :toplevel 'rb-cube) But when I try to run the executable binary "./rb-cube-binario" from terminal I get this error: /Users/ze/sbcl-lib/cl-opengl-thomas-0.1/examples/redbook/rb-cube-binario ; exit; 2009-06-24 01:14:32.606 rb-cube-binario[67793:10b] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: Error (1002) creating CGSWindow It seems to be related to "glutInit(&argc, argv);", in a C syntax, but I have no idead on how to add this in cl-opengl style... When running "(rb-cube)" from slime I get no errors... Thanks for any tips. jos? -- http://www.padovani.googlepages.com From luismbo at gmail.com Wed Jun 24 05:29:14 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 24 Jun 2009 06:29:14 +0100 Subject: [cl-opengl-devel] sbcl "sb-ext:save-lisp-and-die" does not run (glutInit ?) In-Reply-To: <4A41AA30.2000002@yahoo.com.br> References: <4A41AA30.2000002@yahoo.com.br> Message-ID: <391f79580906232229i691364b6h59783d4a8869711d@mail.gmail.com> On Wed, Jun 24, 2009 at 5:23 AM, padovani wrote: > I am usign SBCL 1.0.29 in Mac OSX and have downloaded the "thomas" > version available from > (http://www.esden.net/content/lisp/cl-mac-native-opengl-thomas-0.1.tar.bz2)... > > (is this one the recommended version for Mac OSX?) I can't recommend that version because I don't know what's in it. I suggest you download that latest version from the darcs repository and help test this patch: , a work-in-progress by Jean-Philippe apparently based on that same code. > (sb-ext:save-lisp-and-die "rb-cube-binario" :executable t > :save-runtime-options t :toplevel 'rb-cube) [...] > It seems to be related to "glutInit(&argc, argv);", in a C syntax, but I > have no idead on how to add this in cl-opengl style... GLUT:INIT is the respective Lisp function. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From xristos at suspicious.org Wed Jun 24 17:44:56 2009 From: xristos at suspicious.org (xristos) Date: Wed, 24 Jun 2009 18:44:56 +0100 Subject: [cl-opengl-devel] OSX native glut patch In-Reply-To: <391f79580906232229i691364b6h59783d4a8869711d@mail.gmail.com> References: <4A41AA30.2000002@yahoo.com.br> <391f79580906232229i691364b6h59783d4a8869711d@mail.gmail.com> Message-ID: I cleaned up jpb's patch and added proper window close functionality. Some notes: * It seems that freeglut takes care of destroying windows on close automatically. There is destroy-current-window function in cl-glut but it is not getting called at all by anything in cl-glut. GLUT framework on darwin does not do this, so one has to destroy windows manually. Also, it seems that freeglut takes care of managing the window close behavior as long as one sets it with set-action-on-window-close which calls glutSetOption accordingly. glutSetOption does not exist in darwin glut so one has to manage the window behavior manually from within the close callback. I added wm-close generic methods as glutCloseFunc does not exist in darwin (glutWMCloseFunc should be used instead) which try to do the right thing but i'm sure the behavior can be further improved. Right now, one sets the wanted window-close behavior as before with set-action-on-window-close which, on darwin, instead of calling glutSetOption sets a global variable which is used inside the wm-close methods to decide what to do (all relevant code is in interface.lisp). This works fine with all glut examples here. One can run (cl-glut-examples:run-examples), close windows without terminating glut and only return from the glut event loop when all windows have been closed. Again this works fine here, but i do get some warnings from GLUT when windows are closed: 2009-06-24 18:24:52.884 sbcl[47808:10b] GLUT Warning: glutSetWindow attempted on bogus window. Someone might want to take a look at that as well as game-mode which i did not do anything about. Patch is tested with current cl-opengl on 10.4 and 10.5 on latest sbcl. -------------- next part -------------- A non-text attachment was scrubbed... Name: darwin.patch Type: application/octet-stream Size: 11006 bytes Desc: not available URL: From xristos at suspicious.org Wed Jun 24 18:43:29 2009 From: xristos at suspicious.org (xristos) Date: Wed, 24 Jun 2009 19:43:29 +0100 Subject: [cl-opengl-devel] OSX glut diff Message-ID: <8DA818B8-9165-4011-9257-8B148126C783@suspicious.org> Here is a cleaner version against current cl-opengl without the extra wm-close methods. It uses the existing close generic function in darwin too. I think this is fine to merge as is provided luis or someone else take a look at interface.lisp and figure out if the things i do in close are sane. -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-opengl-darwin.diff Type: application/octet-stream Size: 10879 bytes Desc: not available URL: From luismbo at gmail.com Fri Jun 26 14:55:13 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Fri, 26 Jun 2009 15:55:13 +0100 Subject: [cl-opengl-devel] OSX glut diff In-Reply-To: <8DA818B8-9165-4011-9257-8B148126C783@suspicious.org> References: <8DA818B8-9165-4011-9257-8B148126C783@suspicious.org> Message-ID: <391f79580906260755o8587fcct654e30a1a4db438d@mail.gmail.com> On Wed, Jun 24, 2009 at 7:43 PM, xristos wrote: > Here is a cleaner version against current cl-opengl > without the extra wm-close methods. Looking good, though it still doesn't seem to exit the main loop. Here's how I reproduce that bug: * (require :cl-glut-examples) ... * (cl-glut-examples:rb-cube) ; for instance Also, this patch doesn't work on at least CCL because of that threading issue I mentioned earlier. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From xristos at suspicious.org Fri Jun 26 21:25:20 2009 From: xristos at suspicious.org (xristos) Date: Fri, 26 Jun 2009 22:25:20 +0100 Subject: [cl-opengl-devel] OSX glut diff In-Reply-To: <391f79580906260755o8587fcct654e30a1a4db438d@mail.gmail.com> References: <8DA818B8-9165-4011-9257-8B148126C783@suspicious.org> <391f79580906260755o8587fcct654e30a1a4db438d@mail.gmail.com> Message-ID: <02EEF931-58D1-4E05-870D-1AC9FBE46135@suspicious.org> I fixed the main loop issue with destroy-current-window. If something else does not work as it should, someone should post about how freeglut works for these bits. I don't have linux or x11 here and can't test what freeglut does when windows are destroyed. I can't do anything about CCL as the issue is not that simple. The code that is commented out in interface.lisp simply interrupts the initial thread and starts the glut event loop there. This does not work (window comes up but event loop is blocked and i can't do anything) because, in CCL, the initial thread does certain housekeeping tasks and one can not simply hijack it. Someone familiar with how CCL does things might want to look into this, specifically into what CCL does with their cocoa event loop and duplicate the functionality. The same strategy of interrupting the initial thread and starting the glut event loop there works fine in SBCL but i haven't included the code as for most scenarios the default behavior of SBCL where the REPL is on the initial thread (this is not true when slime is involved of course, one has to do the interrupt trick then) should suffice. New patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-opengl-darwin.diff Type: application/octet-stream Size: 11638 bytes Desc: not available URL: -------------- next part -------------- On 26 Jun 2009, at 15:55, Lu?s Oliveira wrote: > On Wed, Jun 24, 2009 at 7:43 PM, xristos > wrote: >> Here is a cleaner version against current cl-opengl >> without the extra wm-close methods. > > Looking good, though it still doesn't seem to exit the main loop. > Here's how I reproduce that bug: > > * (require :cl-glut-examples) > ... > * (cl-glut-examples:rb-cube) ; for instance > > > Also, this patch doesn't work on at least CCL because of that > threading issue I mentioned earlier. > > -- > Lu?s Oliveira > http://student.dei.uc.pt/~lmoliv/ From jpb at rrette.com Sat Jun 27 13:21:13 2009 From: jpb at rrette.com (Jean-Philippe Barette-LaPierre) Date: Sat, 27 Jun 2009 09:21:13 -0400 Subject: [cl-opengl-devel] Fwd: OSX glut diff In-Reply-To: <4e3cf5960906270620p26712686j41323497ed2863d8@mail.gmail.com> References: <8DA818B8-9165-4011-9257-8B148126C783@suspicious.org> <391f79580906260755o8587fcct654e30a1a4db438d@mail.gmail.com> <02EEF931-58D1-4E05-870D-1AC9FBE46135@suspicious.org> <4e3cf5960906270620p26712686j41323497ed2863d8@mail.gmail.com> Message-ID: <4e3cf5960906270621o5a487e88pb48683d0a6460a80@mail.gmail.com> On Fri, Jun 26, 2009 at 5:25 PM, xristos wrote: > I fixed the main loop issue with destroy-current-window. > If something else does not work as it should, someone should > post about how freeglut works for these bits. I don't have > linux or x11 here and can't test what freeglut does when > windows are destroyed. > > I can't do anything about CCL as the issue is not that simple. > The code that is commented out in interface.lisp simply interrupts > the initial thread and starts the glut event loop there. > > This does not work (window comes up but event loop is blocked > and i can't do anything) because, in CCL, the initial thread > does certain housekeeping tasks and one can not simply hijack it. > Someone familiar with how CCL does things might want to look into > this, specifically into what CCL does with their cocoa event loop > and duplicate the functionality. I did solve that issue by "cloning" code taken from examples/opengl-ffi.lisp in CCL source distribution. I still didn't had the time to get on my laptop (where the code is), but I'll be able to send it soon. > > > The same strategy of interrupting the initial thread and starting > the glut event loop there works fine in SBCL but i haven't included > the code as for most scenarios the default behavior of SBCL where > the REPL is on the initial thread (this is not true when slime is > involved of course, one has to do the interrupt trick then) > should suffice. > > New patch: > > > > > On 26 Jun 2009, at 15:55, Lu?s Oliveira wrote: > > On Wed, Jun 24, 2009 at 7:43 PM, xristos wrote: >> >>> Here is a cleaner version against current cl-opengl >>> without the extra wm-close methods. >>> >> >> Looking good, though it still doesn't seem to exit the main loop. >> Here's how I reproduce that bug: >> >> * (require :cl-glut-examples) >> ... >> * (cl-glut-examples:rb-cube) ; for instance >> >> >> Also, this patch doesn't work on at least CCL because of that >> threading issue I mentioned earlier. >> >> -- >> 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: From jakob at resfarm.de Mon Jun 29 18:13:18 2009 From: jakob at resfarm.de (Jakob Reschke) Date: Mon, 29 Jun 2009 20:13:18 +0200 Subject: [cl-opengl-devel] Find out the current matrix-mode? Message-ID: <2f9f12b70906291113h4004bf72y112d4d85f0107aa6@mail.gmail.com> Hello everybody, I dug a little into CFFI now to solve my selection problem and I got it to work with %gl:selection-buffer. (thread "Is this project alive?") However now I am facing another problem: how do I find out the current matrix mode (I want to save it for later return)? gl:get-integer and cl-opengl-bindings::get-integer-v don't seem to return usable values: CL-USER> (mapcar (lambda (mode) (matrix-mode mode) (list mode (get-integer :matrix-mode))) '(:modelview :texture :projection)) ((:MODELVIEW 0) (:TEXTURE 0) (:PROJECTION 0)) CL-USER> (mapcar (lambda (mode) (matrix-mode mode) (list mode (get-integer :matrix-mode))) '(:modelview :texture :projection)) ((:MODELVIEW 0) (:TEXTURE 0) (:PROJECTION 0)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) ; #xBA0 is :matrix-mode according to constants.lisp (list mode (mem-ref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 690846) (:TEXTURE 690846) (:PROJECTION 690846)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-ref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 281840) (:TEXTURE 281840) (:PROJECTION 281840)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-aref mm :int))) ; now with mem-aref instead of mem-ref '(:modelview :texture :projection))) ((:MODELVIEW 675676) (:TEXTURE 675676) (:PROJECTION 675676)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-aref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 671420) (:TEXTURE 671420) (:PROJECTION 671420)) CL-USER> Obviously there it is not the matrix mode which is returned, what am I doing wrong? Thank you in advance, best regards Jakob -- I would like E-Mails beeing encrypted with OpenPGP. You can find my public key here: http://jayk.resfarm.de/key.txt From luismbo at gmail.com Tue Jun 30 01:05:48 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 30 Jun 2009 02:05:48 +0100 Subject: [cl-opengl-devel] Find out the current matrix-mode? In-Reply-To: <2f9f12b70906291113h4004bf72y112d4d85f0107aa6@mail.gmail.com> References: <2f9f12b70906291113h4004bf72y112d4d85f0107aa6@mail.gmail.com> Message-ID: <391f79580906291805j6dbcb0d0j6a39266de22e724f@mail.gmail.com> On Mon, Jun 29, 2009 at 7:13 PM, Jakob Reschke wrote: > However now I am facing another problem: how do I find out the current > matrix mode (I want to save it for later return)? gl:get-integer and > cl-opengl-bindings::get-integer-v don't seem to return usable values: You need an active GL context in order to experiment with these calls. Here's a quick and dirty way to do that: (glut:display-window (make-instance 'glut:window)) (gl:get-string :version) => "3.0.0 NVIDIA 180.44" It occurs to me that it'd be nice to use OSMesa for this sort of thing, namely for a test suite. I've attached some bindings to OSMesa if someone feels like playing with this as I don't have time right now. Here's an example: CL-USER> (gl:matrix-mode :projection) ; No value CL-USER> (gl:get-integer :matrix-mode) 5889 CL-USER> (cffi:foreign-enum-keyword '%gl:enum *) :PROJECTION CL-USER> (gl:get-string :version) "2.1 Mesa 7.4" HTH. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ -------------- next part -------------- A non-text attachment was scrubbed... Name: osmesa.lisp Type: application/octet-stream Size: 1616 bytes Desc: not available URL: