[slime-devel] OpenGL Integration into the REPL ?

[Sean Charles]

>

> Still, from when glutMainLoopEvent is called until it returns, slime
> will still be unresponsive.  However, if you stick
> SB-SYS:SERVE-ALL-EVENTS in all of your callback functions, then  
> maybe it
> will be good enough.
>

A ZEN MOMENT

I now have a working OpenGL setup *and* a still function REPL/SLIME  
session to SBCL. Thanks to Helmut's suggestion about calling SB- 
SYS:SERVE-ALL-EVENTS. However, I made a fascinating blunder which has  
caused me some time to realise and on reflection is very very funny.  
I have included the mail I was *going* to send at the end as it just  
goes to show how you can be fooled (by yourself) into barking up the  
wrong tree. I am still laughing at my own stupidity as I type this.

It all comes back to Helmuts comment:
	"Maybe SERVE-ALL-EVENTS loops forever if no timeout is given.  Try to
	call it with something small like 100ms."

So I did try it with 100, however, coming from a real-time embedded  
systems background I assumed that the parameter to SERVE-ALL-EVENTS  
would be in 'mS' and passed in 100.  Not until much later did I  
realise! HA HA HA, LOL, and all that.

So, if you want to read and 'see' one mans trip into persona  
debugging hell, read below and enjoy a good laugh on me!

Thanks everybody for your comments. As I speak I have a running gears  
window and a running SLIME session and it all seems to work.


I know that *my* application may have to do something clever about  
changing the display code because I think I am treading on thin-ice  
here. I imagine having to build me new display handler then have an  
internal means to flag that I want to ditch 'a' and use 'b' the next  
time I render a frame... after all, I could be trying to change  
something via SLIME/REPL at the same time that OpenGL is trying to  
render it.


--- here's what I was *going* to send ---


Helmut suggested I do this and I have now tried it with a timeout of  
'100' and the result is the same: the REPLY stays alive but the  
OpenGL application now seems to either have died or broken. If I  
click the 'close window' button it doesn't close.

Pressing keys no longer produces any output to the SLIME/REPL session  
which is how I am assuming my application is broken.

My print statements are using the form

(format *terminal-io* "..." args...)

I guess it is possible that the connection between the OpenGL  
application back to the SLIME session has somehow gotten dazed and  
confused and in fact my progroam might still be working! I shall try  
writing the test output to a file as well.

FLASH OF INSPIRATION! --> I am going to hack the MESADEMOS:GEARS to  
see if it still runs when I call the SB-SERVE-ALL-EVENTS function...  
that way I will know for sure if what I want to do is possible.
[...later...]
Oh dear. I added a call to (sb-sys:serve-all-events) just after the  
swap-buffers call and the gears appear to have stopped in their  
tracks...but no!! What's this.... I resized the window and continued  
typing this message and about 45 seconds later the window updated and  
froze again... it might be alive somewhere. I made the window bigger  
again and this time it took about 90 seconds to update. it seems that  
the glut loop is still alive but it being held inside the SERVE-ALL- 
EVENTS code perhaps???

I have spent several minutes resizing the window gradually down to  
about 30 pixels square and the refresh rate seems to be in multiples  
of approx. 45 seconds:

45
90
45
85
80

It 'feels' like there is some kind of internal timeout maxed at 45  
seconds and occasionally the resize event may miss the 'window of  
opportunity' and that's why I have to wait 2 'cycles' for the update  
to occur. Maybe it's 50 seconds??? Here's the output from the SLIME  
session:

CL-USER> (mesademos:GEARS)
3 frames in 100.0 seconds =  0.030 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 99.3 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS
1 frames in 100.0 seconds =  0.010 FPS

Pressing the Esc key finally terminates the application after a  
suitable period of waiting!

If I remove the call to SB-SYS:SERVE-ALL-EVENTS then all goes back to  
normal. I added a TRACE to the calls

--
My modus operandi for this is that I have used LUSH and it's pretty  
cool and all that but at the end of the day is is not LISP proper.  I  
thought it would be great to be able to have an OpenGL application  
alive and running and still be able to fiddle with the guts of it,  
kind of like changing the tyre on your car without stopping, and just  
as hairy I expect!


> I'm not an expert on slime, but I do know GLUT pretty well and how to
> beat it into playing nicely with other stuff.
>

I'll be in touch then! You'll be sorry you said that!! LOL... I have  
some experience of OpenGL but I am by no means a Guru.