[cells-devel] Small progress: GLUT-INIT not called due to false init value checking

[Kenny Tilton]

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