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

[Frank Goenninger]

Hi again..

On Mon, 2004-10-25 at 10:46, Kenny Tilton wrote:
> 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).
> 
You're right here. My assumption (and assumptions are never an easy
thing) was that -1 meant "Not initialized yet" and I didn't check the
GLUT specs for that.

> This is where it gets tricky being a Lisp developer. :)  

Well, still counting myself as a newbie I am looking for ways of
learning the art of being more advanced ...

> 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).

I will check the GLUT specs for that now.

> >
> >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.
> 
Fully understood so far with more than 5 years of professional C
programming under my belt ;-))

> 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.

Yep. I suppose that's what is happening here.

> 
> 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.

Not seen any of kind of source for Apple's GLUT yet. So this will be key
if we want to go the route you suggested for debugging. 

> 
> cheers, kt

Now I have a busy Monday just starting with writing a proposal for a
(hopefully) client to get some money flowing in ...

Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041025/a7f71f2d/attachment.sig>