Hello,
I’d like to report the folling issue I bumped into: in the cl-opengl-bindings package, extension functions defined with defglextfun will re-define themselves the first time they are called. This is somewhat an unexpected and potentially undesirable behavior: if you store one of those function objects before calling it, it will compile a new object every time it is funcalled.
Thanks
On Fri, Mar 16, 2012 at 9:39 PM, Jocelyn Fréchot jocelyn_frechot@yahoo.fr wrote:
I’d like to report the folling issue I bumped into: in the cl-opengl-bindings package, extension functions defined with defglextfun will re-define themselves the first time they are called. This is somewhat an unexpected and potentially undesirable behavior: if you store one of those function objects before calling it, it will compile a new object every time it is funcalled.
At the end of gl/bindings.lisp there's an alternative implementation of DEFGLEXTFUN that doesn't call compile or redefine anything. Does that work better for you?
On 17/03/2012 11:01, Luís Oliveira wrote:
At the end of gl/bindings.lisp there's an alternative implementation of DEFGLEXTFUN that doesn't call compile or redefine anything. Does that work better for you?
I tried this version:
(defmacro defglextfun ((cname lname) return-type &body args) (alexandria:with-unique-names (pointer) `(let ((,pointer (null-pointer))) (defun ,lname ,(mapcar #'car args) (when (null-pointer-p ,pointer) (setf ,pointer (gl-get-proc-address ,cname)) (assert (not (null-pointer-p ,pointer)) () "Couldn't load symbol ~A~%" ,cname) (format t "Loaded function pointer for ~A: ~A~%" ,cname ,pointer) (push (lambda () (setf ,pointer (null-pointer))) *gl-extension-resetter-list*)) (foreign-funcall-pointer ,pointer (:library opengl) ,@(loop for arg in args collect (second arg) collect (first arg)) ,return-type)))))
However, compilation of gl/funcs.lisp fails due to heap exhaustion (using SBCL 1.0.55).
Hello Jocelyn,
I tried it out as well and got similar results. I also tried using load-time-value for the pointer cache in the hopes that making the DEFUN a top-level form would appease SBCL but that help too much.
Have you tried using a less smart compiler such as CCL ou CLISP?
On 31 March 2012 18:42, Luís Oliveira luismbo@gmail.com wrote:
I tried it out as well and got similar results. I also tried using load-time-value for the pointer cache in the hopes that making the DEFUN a top-level form would appease SBCL but that help too much.
Have you tried using a less smart compiler such as CCL ou CLISP?
Can you point me at right spot in cl-opengl sources, and provide a test-case. I think I have an idea...
Cheers,
-- nikodemus
On Sat, Mar 31, 2012 at 5:02 PM, Nikodemus Siivola nikodemus@random-state.net wrote:
Can you point me at right spot in cl-opengl sources, and provide a test-case. I think I have an idea...
The code is at: https://github.com/luismbo/cl-opengl/tree/sbcl-unfriendly-defglextfun
The test-case is simply compiling cl-opengl. SBCL will exhaust the heap while attempting to compile gl/funcs.lisp which contains about 2000 usages of DEFGLEXTFUN.
Cheers,
On 1 April 2012 02:11, Luís Oliveira luismbo@gmail.com wrote:
The code is at: https://github.com/luismbo/cl-opengl/tree/sbcl-unfriendly-defglextfun
The test-case is simply compiling cl-opengl. SBCL will exhaust the heap while attempting to compile gl/funcs.lisp which contains about 2000 usages of DEFGLEXTFUN.
Thanks!
Patch attached -- probably not something to merge as-is, since I commented out a few extensions due to missing/bad types, but this builds for me on x86-64 using the default 1Gb heap.
Cheers,
-- nikodemus
On 31/03/2012 17:42, Luís Oliveira wrote:
I tried it out as well and got similar results. I also tried using load-time-value for the pointer cache in the hopes that making the DEFUN a top-level form would appease SBCL but that help too much.
Have you tried using a less smart compiler such as CCL ou CLISP?
No I haven’t. For now I store function symbols rather than objects. I guess the overhead of funcall-ing them is negligible in my context.
cl-opengl-devel@common-lisp.net