- cl-opengl-devel - mailman3.common-lisp.net

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

02 Aug '10

thank you I will give this a try in the morning..By the way, I was able to trace my problem with cl-opengl a little further to the cffi function: (cffi:load-foreign-library '(:framework "OpenGL)) (called from the libraries.lisp file in cl-opengl package) I manually tried this call in the repl outside of the cl-opengl package and it also crashes. checked my *darwin-framework-directories* variable and that seems OK. then I found, you can enter the full path of the framework (library ?) directly, like so: (cffi:load-foreign-library "/System/Library/Frameworks/OpenGL.framework/OpenGL") That also crashes it. Incidentally, the same call worked OK with other non-framework libraries that I tried, like /usr/lib/libm.dylib... but I'll look at your suggestion more closely.. I use this library in sbcl without a problem...(but have other problems with sbcl on the mac). -K On Aug 1, 2010, at 8:02 PM, Gary Byers wrote: > Apple decided to enforce the restriction that some shared libraries (I don't > remember which one(s)) only be initialized on the initial thread of the OS-level > process by executing a breakpoint instruction. (It's the World's Most Advanced > Operating System!) That breakpoint causes the process to terminate with the > message you're seeing when the library in question is loaded (directly or as > the result of loading some library which depends on it) from a CCL listener > thread (or a SLIME REPL thread, or ... any thread other than the initial > one.) > > The general workaround is to replace: > > (open-shared-library "culprit.dylib") > > with > > (run-in-initial-thread-and-wait-until-done > (lambda () (open-shared-library "culprit.dylib"))) > > There are a few issues: > > 1) The affected code may be in a third-party lisp library; it'd be good if > the authors of such libraries made the necessary changes so that people > didn't keep running into this. > > 2) It can be hard to know which libraries are affected. I think that the > actual check-and-breakpoint is in the initialization code for the > CoreFoundation library; whether that's correct or not, it's in some > library that's used by many other things on OSX, so the rule of thumb > is something like "when in doubt, force library loading to happen on > the initial thread in OSX." > > 3) There are several ways to do what I'm calling > RUN-IN-INITIAL-THREAD-AND-WAIT-UNTIL-DONE; I don't think that we yet > offer a standard way of doing this (though CCL::CALL-IN-INITIAL-PROCESS > us present in recent versions of the trunk and is intended to become > an exported/documented/standard interface in the near future.) > > We changed some of our examples when this "check and breakpoint" behavior > was introduced (in 10.6, IIRC); see "ccl:examples;opengl-ffi.lisp", for > instance. > > 4) I'd want to think about this more than I have, but at the moment I can't > think of a reason for OPEN-SHARED-LIBRARY not to at least default to > doing what it does on the initial thread by default. > > > > On Sun, 1 Aug 2010, Kevin Smith wrote: > >> The only hurdle for me for trying out (and maybe switching) to clozure on the mac platform is that I can't seem to get the >> cl-opengl package loaded. I get the error: "Trace/BPT trap" when I try to load that package. (All other dependent packages >> like cffi, loaded successfully). >> I am using ccl64, version 1.5 on Darwin/MAC OS (DarwinX8664). Latest version of cl-opengl. >> I believe I also tried it on the 32-bit ccl. Same problem. It looks like it only compiles a few source files in the >> cl-opengl package before it dies. >> If someone can point out to me how I can trace this to provide more information on where it is crashing or maybe someone has >> run across this already with this particular package. >> Thanks, >> Kevin >>

1 0

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

02 Aug '10

The only hurdle for me for trying out (and maybe switching) to clozure on the mac platform is that I can't seem to get the cl-opengl package loaded. I get the error: "Trace/BPT trap" when I try to load that package. (All other dependent packages like cffi, loaded successfully). I am using ccl64, version 1.5 on Darwin/MAC OS (DarwinX8664). Latest version of cl-opengl. I believe I also tried it on the 32-bit ccl. Same problem. It looks like it only compiles a few source files in the cl-opengl package before it dies. If someone can point out to me how I can trace this to provide more information on where it is crashing or maybe someone has run across this already with this particular package. Thanks, Kevin

1 1

[cl-opengl-devel] build-2d-mipmaps
by José Lopes 18 Jul '10

18 Jul '10

Hi, I was trying to create textures using glu:build-2d-mipmaps (I also tried using gl:tex-image-2d) and I had a few problems. I'm using jpeg:decode-image which produces a vector of unsigned bytes from the image that it loads. However, the function build-2d-mipmaps cannot handle properly a vector of data (or so I think). So I had to use cffi:with-foreign-pointer to allocate memory and copy all the bytes from the image to a cffi pointer so that it could be passed correctly to the underlying cffi layer through build-2d-mipmaps. This is the code I have now (defmethod glut:display-window :before ((window texture-window)) (gl:clear-color 0 0 0 0) (gl:shade-model :flat) (multiple-value-bind (data height width channels) (jpeg:decode-image "/home/joe/tux.jpg") (let ((texture (first (gl:gen-textures 1)))) (gl:bind-texture :texture-2d texture) (setf (texture window) texture) (gl:tex-env :texture-env :texture-env-mode :modulate) (gl:tex-parameter :texture-2d :texture-min-filter :linear-mipmap-linear) (gl:tex-parameter :texture-2d :texture-mag-filter :linear) (gl:tex-parameter :texture-2d :texture-wrap-s :repeat) (gl:tex-parameter :texture-2d :texture-wrap-t :repeat) (cffi:with-foreign-pointer (buf (* width height channels)) (loop for i from 0 below (* width height channels) do (setf (cffi:mem-ref buf :char i) (aref data i))) (glu:build-2d-mipmaps :texture-2d :rgb width height :bgr :unsigned-byte buf))))) I would like to avoid cffi calls. Do you have any suggestion? Regards, José Lopes

1 0

[cl-opengl-devel] threaded glut main loop
by Kevin Smith 15 Jul '10

15 Jul '10

Has anyone gotten glut:main-loop to work in it's own thread ? I'd like to be able to asynchronously execute opengl calls while the main loop is running. I have a bit of a hack that can do this in effect, by calling glut:leave-main-loop inside a callback, going the repl and running list and then manually starting the mainloop again to refresh, but it would be nice to use threaded main loop. I'm using sbcl on mac OS, so I am not even sure if threading is going to work.

1 0

[cl-opengl-devel] windows dll's
by Mirko Vukovic 13 Jun '10

13 Jun '10

Hello, I am using clisp on cygwin+windows. Where do people get precompiled dll's for glu & glut? I found a few online, but I would appreciate if someone could share their experience about which worked and which did not (and one site looked a bit suspicious - I was not sure if I would be installing a legit dll) Thank you, Mirko

3 3

[cl-opengl-devel] Error
by José Lopes 13 Jun '10

13 Jun '10

Hi, I'm trying to use cl-opengl. I cannot run any of the examples. For instance, when I run rb-cube with Allegro 8.2 I get the following error: Attempt to call #("glutCloseFunc" 3074974352 0 2 3074974352 4) for which the definition has not yet been (or is no longer) loaded. [Condition of type SIMPLE-ERROR] I have also tried with the latest version of SBCL and I get the following error: GLUT: Warning in (unamed): invalid glutGet parameter: 124 debugger invoked on a SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR in thread #<THREAD "initial thread" RUNNING {A9F37B1}>: Attempt to call an undefined alien function. Can you help me? José

2 1

Re: [cl-opengl-devel] gluProject and gluUnProject
by David Davis 09 Apr '10

09 Apr '10

Charlie McMackin wrote: > DEF-FOREIGN-ROUTINE is not something the cl-opengl library uses. A > cursory google lookup suggests it's something that's used in CL-SDL's > opengl bindings however. I might be wrong but if it's for SDL you're > looking, lispbuilder-sdl seems to have the greater 'mindshare' at the > moment.. Though cl-opengl's project site is > http://common-lisp.net/project/cl-opengl/ :) > HTH > > Yeah, the example I was basing my code off of may have been from cl-sdl, since it used both SDL and OpenGL. In the past, I've used SDL and OpenGL in conjunction, but I can probably get away with just using http://github.com/3b/cl-opengl without SDL as it looks like it implements gluProject and gluUnProject and I don't need SDL. Thanks! -Dave

1 0

[cl-opengl-devel] gluProject and gluUnProject
by David Davis 09 Apr '10

09 Apr '10

I want to use gluUnProject in order to do things on-screen when the user clicks with the mouse. I'm using Ubuntu, and it seems that the opengl libraries that come with it do not come with the glu(Un)Project methods defined. However, after poking around a bit in the source, it looks pretty straight-forward to create the lisp methods from the c methods, so I added the following to my glu.lisp file: (def-foreign-routine ("gluProject" project) void (obj-x gl:double) (obj-y gl:double) (obj-z gl:double) (modelview (* gl:double) (projection (* gl:double) (viewport (* gl:int)) (win-x (* gl:double) (win-y (* gl:double) (win-z (* gl:double))))))) (def-foreign-routine ("gluUnProject" unproject) void (win-x gl:double) (win-y gl:double) (win-z gl:double) (modelview (* gl:double) (projection (* gl:double) (viewport (* gl:int)) (obj-x (* gl:double) (obj-y (* gl:double) (obj-z (* gl:double))))))) These are purely based off of looking around at how the other glu methods were defined. Are these definitions correct? I'm unable to really try them out because I don't understand how to pass double pointers to these methods. I'm just getting started with CL, and loving it so far, but the application I'm currently working on has definitely hit a roadblock. Can somone point me in the right direction as far as whether how I'm defining these methods is correct, and if so, how I pass pointer-style vars to the method calls to get the results? Thanks!

3 3

[cl-opengl-devel] OpenGL 3.3/4.0 bindings
by Bart Botta 02 Apr '10

02 Apr '10

I've updated the low level bindings (%gl package) in my cl-opengl fork at http://github.com/3b/cl-opengl to version 60 of the .spec files, including gl 3.3 and gl 4.0. Only minimally tested, but shouldn't have any effect on existing code aside from a few extension functions whose names changed (named-make-buffer-resident-nv and named-make-buffer-non-resident-nv are make-named-* now), an OpenGLES-only enum name change (:writeonly-rendering-amd to :writeonly-rendering-qcom), and the disappearance of framebuffer-texture-face, but that doesn't seem to be in the specification either. see http://github.com/3b/cl-opengl/issues for a list of known issues, feel free to add more if you run into any problems with it. -- b

3 4

[cl-opengl-devel] get-tex-image not external?
by Malcolm Reynolds 23 Feb '10

23 Feb '10

Hi >>> Try the version at http://github.com/3b/cl-opengl I'm using this github branch you pointed me to and it's been working very well so far, so thanks for going to effort to keep the package updated for Snow Leopard. A minor point I've come across is that get-tex-image doesn't seem to be external, is there any particular reason for this / is there some interface I should be accessing it through? I couldn't find one with a quick bit of grepping.. Cheers, Malcolm

1 0