About Slate and GUI

[Brian Rice]

On Oct 25, 2005, at 3:29 AM, Tony Garnock-Jones wrote:

> Cairo, on the other hand, seems pretty good.

It was definitely written with the Cairo model in mind. But you / 
wrote/ most of that Cairo stuff - so why are you off working on other  
things?

>> It is not so obvious to me (as it seems to be for Brian) why the
>> concurrency have to be
>> implemented in Slate, before working on the GUI code.
>
> Yes, this is the main problem. Without a framework for (something  
> resembling) multi-threaded I/O, there is no way of mediating the  
> many (pseudo-)parallel operations that together make up a  
> functioning GUI.

Agreed. This is the big elephant in Slate design, that we can't  
really handle real concurrency yet. Lee has been evasive or just  
inactive on whatever system design changes would really work for us.

> The main piece missing is an outer driver loop that calls select()  
> to wait for I/O and timeouts, and dispatches I/O events and timeout  
> callbacks. By itself, this isn't so tricky - but integrating with  
> SDL's event sources as well adds a few wrinkles.

Yes, and right now the asynchronous-send loop is REPL driven, so we  
have to reverse this, driving the REPL from the loop.

> Of course, given such a driver, having actual real concurrency is  
> kind of optional, although having call-with-current-continuation  
> would obviously be very nice :-)

Agreed, although this again requires some system changes that Lee  
occasionally responds to and then goes off on his own and does  
nothing about. I'm at a bit of a loss.

> A few months ago (almost a year!) I implemented, in Scheme, a Slate- 
> like language, and I got as far as implementing an SDL + SDL_net  
> based user interface before deciding I'd learnt enough. The key  
> idea is to avoid using SDL's SDL_WaitEvent, and instead to roll  
> one's own from:
>
>  - SDL_PeepEvents
>  - a Slate-implemented Timer queue (heap)
>  - a customisable "delay" function
>
> The delay function is called when SDL-proper decides nothing has  
> happened. The time-to-next-timer-event is retrieved from the timer  
> queue, and passed in to the delay function. In simple cases, the  
> delay function can be SDL_Delay, but to integrate with SDL_net, the  
> delay function should be the piece of code that checks for socket  
> activity, i.e. that calls select().

Yeah, that's a decent start. Why did you do this? Or rather, why did  
you not come back?

--
-Brian