This may not be the proper list (I'm tempted to cross-post to the clozure one), but I have to start somewhere. I'm putting together a wrapper around the recently released version of the C library GLFW. In the middle of a callback (written in CL and mostly using cl-glfw), I'm winding up in the debugger, and I'm not having any luck figuring out why. I don't have a minimal test-case to share, yet. That's my next step. I'm being lazy and asking before I start trying to trim pieces down. The best nutshell of the problem I have at the moment is that the callback in question looks like: (cffi:defcallback window-sizer :void ((window glfw3::glfw-window) (width :int) (height :int)) ;; Have to have the OpenGL context before we can do this. ;; Q: Should I be making that window's context current? ;; A: Seems really stupid to think otherwise. (declare (ignore window)) (format t "Resizing to ~A x ~A~%" width height) (gl:viewport 0 0 width height) (format t "Setting projecting matrix~%") (gl:matrix-mode :projection) (gl:load-identity) (let ((ratio (/ width height))) (format t "Setting ortho: ~A~%" ratio) ;; This next line is failing here, pretty spectacularly. ;; with an error message that doesn't seem to make any sense. ;; It appears to run fine (even if it does nothing) when ;; I run it throuh the REPL. (gl:ortho (- ratio) ratio -1 1 1 -1)) (format t "Returning~%")) The stack trace (FWIW) looks like: The value 17465867632912 is not of the expected type DOUBLE-FLOAT. [Condition of type TYPE-ERROR] 0: (CFFI-CALLBACKS::|GLFW3-EXAMPLE::WINDOW-SIZER| 17465867632956) Locals: #:G7819 = 17465867632956 #:G7822 = #<A Foreign Pointer [stack-allocated] #x7F14B6B009E0> GLFW3-EXAMPLE::WINDOW = #<A Foreign Pointer #x7F149C034C70> GLFW3-EXAMPLE::WIDTH = 649 GLFW3-EXAMPLE::HEIGHT = 502 COMMON-LISP:RATIO = 649/502 CL-OPENGL-BINDINGS::LEFT = -649/502 #:G7833 = -1.292828685258964D0 #:G7834 = 1.292828685258964D0 #:G7835 = -1.0D0 #:G7836 = 1.0D0 #:G7837 = 1.0D0 #:G7838 = -1.0D0 1: (CCL::%PASCAL-FUNCTIONS% 5 17465867632956) Locals: INDEX = 5 ARGS-PTR-FIXNUM = 17465867632956 LISP-FUNCTION = #<Compiled-function CFFI-CALLBACKS::|GLFW3-EXAMPLE::WINDOW-SIZER| (Non-Global) #x302001CF9B0F> WITHOUT-INTERRUPTS = NIL *CALLBACK-TRACE-P* = NIL 2: (NIL #<Unknown Arguments>) 3: (POLL-EVENTS) 4: (CCL::CALL-CHECK-REGS POLL-EVENTS) 5: (CCL::CHEAP-EVAL (POLL-EVENTS)) Does anyone have a suggestion about where I should look to try to figure out where that value it's complaining about comes from? Or what's expecting the DOUBLE-FLOAT? Is there something else in the stack trace (or anywhere else) that I'm just totally missing due to my noobishness? The C signature of the callback function is typedef void (* GLFWwindowsizefun)(GLFWwindow*,int,int); Is there something else I can supply that I didn't realize is important? Just for the record, I'm much more interested in learning how I can diagnose and fix these sorts of problems for myself than anything else. I just seemed to run into a total dead end on google. Thanks in advance, James
James Ashley <james.ashley@gmail.com> writes:
(let ((ratio (/ width height))) (format t "Setting ortho: ~A~%" ratio) ;; This next line is failing here, pretty spectacularly. ;; with an error message that doesn't seem to make any sense. ;; It appears to run fine (even if it does nothing) when ;; I run it throuh the REPL. (gl:ortho (- ratio) ratio -1 1 1 -1))
[...]
The value 17465867632912 is not of the expected type DOUBLE-FLOAT.
[...]
COMMON-LISP:RATIO = 649/502 CL-OPENGL-BINDINGS::LEFT = -649/502
[...]
Does anyone have a suggestion about where I should look to try to figure out where that value it's complaining about comes from? Or what's expecting the DOUBLE-FLOAT? Is there something else in the stack trace (or anywhere else) that I'm just totally missing due to my noobishness?
The stack trace is not being very helpful, no. GL:ORTHO tries to coerce each of its arguments into doubles via (float x 1.0d0). Maybe something's going wrong in that process? There's also inlining going on, as the GL:ORTHO is defined via %GL:DEFGLFUN which might not get triggered when you try it out from the REPL. So, I'd try to (1) convert the ratio to double before passing it to GL:ORTHO and maybe the other arguments as well, (2) call glOrtho() using plain CFFI:FOREIGN-FUNCALL, (3) use CCL:EXTERNAL-CALL. You can quickly figure out how to get the appropriate CCL:EXTERNAL-CALL form by macroexpansing CFFI:FOREIGN-FUNCALL. HTH, -- Luís Oliveira http://kerno.org/~luis
Luís Oliveira <luismbo <at> gmail.com> writes:
James Ashley <james.ashley <at> gmail.com> writes:
The value 17465867632912 is not of the expected type DOUBLE-FLOAT.
[...]
COMMON-LISP:RATIO = 649/502 CL-OPENGL-BINDINGS::LEFT = -649/502
[...]
The stack trace is not being very helpful, no. GL:ORTHO tries to coerce each of its arguments into doubles via (float x 1.0d0). Maybe something's going wrong in that process? There's also inlining going on, as the GL:ORTHO is defined via %GL:DEFGLFUN which might not get triggered when you try it out from the REPL.
So, I'd try to (1) convert the ratio to double before passing it to GL:ORTHO and maybe the other arguments as well, (2) call glOrtho() using plain CFFI:FOREIGN-FUNCALL,
The combination of these two fixes my immediate problem. Thank you!
(3) use CCL:EXTERNAL-CALL. You can quickly figure out how to get the appropriate CCL:EXTERNAL-CALL form by macroexpansing CFFI:FOREIGN-FUNCALL.
This also works fine (as it should, based on the previous 2 steps...thank you, again). So...what does that imply for what I should take-away on this? The original version seems to work fine on SBCL. cl-opengl doesn't claim to run on CCL. I haven't had a chance to try it on different platforms to even begin getting a clue about whether it's isolated that way (though 64-bit linux can't be a common target platform). I'm inclined to suspect that the actual problem lies in CCL, but it seems like it could also just relate to ambiguity in interpreting the spec. So maybe it really is more just a matter of lee-way in cl-opengl's defglfun. Sorry. Now I'm probably just babbling, being stupid, and wasting bandwidth. I'd like to volunteer what little help I have to offer to help fix the actual problem, but this probably isn't the forum.
HTH,
Thanks again, James
On Thu, Jun 20, 2013 at 2:09 AM, James Ashley <james.ashley@gmail.com> wrote:
The original version seems to work fine on SBCL. cl-opengl doesn't claim to run on CCL. I haven't had a chance to try it on different platforms to even begin getting a clue about whether it's isolated that way (though 64-bit linux can't be a common target platform).
cl-opengl should work pretty much wherever there's CFFI (and OpenGL of course).
I'm inclined to suspect that the actual problem lies in CCL, but it seems like it could also just relate to ambiguity in interpreting the spec. So maybe it really is more just a matter of lee-way in cl-opengl's defglfun.
I agree that the problem is likely to be with CCL. First off, try running the CFFI test suite just to weed out any obvious issues specific to CCL on linux/x86-64. Afterwards we want to replicate what's going on in DEFGLFUN without CFFI. I got to this by calling M-x slime-macroexpand-1-inplace on the (defglfun ("glOrtho" ...) ...) form a couple of times: (in-package :%gl) (declaim (inline ortho)) (defun ccl-ortho (left right bottom top znear zfar) (multiple-value-prog1 (let ((g2863 (cl:float left 1.0d0))) (let ((g2864 (cl:float right 1.0d0))) (let ((g2865 (cl:float bottom 1.0d0))) (let ((g2866 (cl:float top 1.0d0))) (let ((g2867 (cl:float znear 1.0d0))) (let ((g2868 (cl:float zfar 1.0d0))) (ccl:external-call "glOrtho" :double-float g2863 :double-float g2864 :double-float g2865 :double-float g2866 :double-float g2867 :double-float g2868 :void))))))) (check-error 'ortho))) If you replace your original call to gl:ortho with %gl::ccl-ortho, does it still trigger the bug your originally reported? (Make sure you compile everything properly, since I suspect some inlining bug might be involved.) Cheers, -- Luís Oliveira http://kerno.org/~luis/
James Ashley <james.ashley@gmail.com> writes:
I don't have a minimal test-case to share, yet. That's my next step. I'm being lazy and asking before I start trying to trim pieces down. The best nutshell of the problem I have at the moment is that the callback in question looks like:
(cffi:defcallback window-sizer :void ((window glfw3::glfw-window) (width :int) (height :int))
...
(gl:viewport 0 0 width height) ...
(let ((ratio (/ width height))) (format t "Setting ortho: ~A~%" ratio) ;; This next line is failing here, pretty spectacularly. ;; with an error message that doesn't seem to make any sense. ;; It appears to run fine (even if it does nothing) when ;; I run it throuh the REPL. (gl:ortho (- ratio) ratio -1 1 1 -1)) (format t "Returning~%"))
The stack trace (FWIW) looks like: The value 17465867632912 is not of the expected type DOUBLE-FLOAT. [Condition of type TYPE-ERROR]
Just for the record, I'm much more interested in learning how I can diagnose and fix these sorts of problems for myself than anything else. I just seemed to run into a total dead end on google.
Here are my two cents. I have been using cl-opengl with CCL on OSX and I have noticed a few times that either cl-opengl, cffi or the ffi of CCL are picky about the exact numerical types that are passed. So your problem is most likely not in the callback, but either in the gl:viewport of gl:ortho call. Try coercing the arguments to a float before calling the gl:ortho function. Disclaimer, this is from memory and from personal anecdotal evidence, so most likely very unreliable. Debugging wise, it looks to me that the cffi:defcallback has created a function. Maybe you can macro expand the callback definition (maybe more than once) and see what it tries to do. Kind regards, Wim Oudshoorn.
participants (4)
-
James Ashley -
Luís Oliveira -
Luís Oliveira -
Willem Rein Oudshoorn