I just realized a couple of things....
Frank Goenninger wrote:
Hi Kenn & all:
I just discovered that GLUT wasn't initialized properly in cl-glut-init.
This is due to the (zerop glut-state) which I turned into
(or (eq glut-state 0) (eq glut-state -1))
I am guessing you did this because you saw -1 coming back from (glutGet glut_init_state). That would mean glut is already initialized, and it might be an error (leading to a silent shut-down via exit()) to call glutInit when glut is already initialized (I do seem to recall that in Freeglut).
This is where it gets tricky being a Lisp developer. :) Anyway, I /think/ the zerop was the correct test. If you are seeing a -1 come back when you are sure glut is not initialized, then we might have an FFI problem (I doubt -1 is being used to signify false).
Also, I found that when calling glut-init I run into a
"a MACPTR cannot be coerced to INTEGER"
error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1.
Whoa, I missed that. Two things:
(1) glutInit wants a pointer to an integer. That is why we allocate an array, stuff the integer into index zero and pass the array -- that is effectively passing a pointer to the first element of the array.
(2) We are not passing any argv's to glutInit, so you have to pass (a pointer to) zero as the argc. C functions have no way of knowing how many argvs are being passed, so that is why there is also the argc argument. I do not know how C survived being passed an integer address of 1, but if it does not see zero it takes the value of argv as a pointer to the first pointer to an argv. We are passing null for argv, so C would blindly be examining address 0 and thinking it was a pointer.
Possibly what has happened is that glutInit saw enough to decide it should start up a proper app with window, so things happened in the dock, but when it finally got around to looking at the args, it died on a bad pointer.
On win32 I was able to place breakpoints (by coding "assert( false );") in glut code in VC6 and rebuilding the DLL. (I had to call unload-foreign-library on the dll before rebuilding or VC6 would be unable to overwrite the old one). Then when I ran I could (at first) actually get into the VC6 debugger. Unfortunately, the last time I tried this I could not debug, so it was one test and then shutdown the whole Lisp IDE. To improve on this, I had Freeglut put up a win32 alert box instead of using assert( false), so I could get the DLL to report back some info before continuing execution.
In this case I would add alerts to glutInit and glutCheckLoop and glutCreateWindow so I could see what was going on. Well, that is if Apple makes a Glut ProjectBuilder. I will install XCode on my new toy now and see what I can see.
cheers, kt