Re: Run Io coroutines in background simultaneous to using Io> prompt in foreground?

> The simplest solution may be to use a non blocking keyboard input  
> call. If this is all command line stuff, then you might look at the  
> curses binding (but may have trouble making it portable). If it's in a  
> GUI liek GLUT/OpenGL, then you can just use its' event based keyboard  
> input.

Thanks Steve.  You guys have given me enough to answer my question but I want to talk a little more about it in case any readers are interested in the details.  I actually have 3 environments this will be used in, which complicates matters.  There's a server program that's command-line only and runs on Linux, a debugging client that uses OpenGL and runs on Linux/Windows, and a real game client that will use some other 3-d engine on Windows (with Linux and Mac support planned).

My partner is writing the actual game client for the end users; I'm writing the debugging client to serve as a reference code example for him to see how to talk to my server, and also so that I can verify the server works without having to wait for the real game client to be finished.  I don't want to spend too much time tweaking it because that takes away from work on the server (although technically it shares 90% of its codebase with the server).  Since my debugging client is just for us programmers, and won't be seen by any end-users, I thought wouldn't it be cool if instead of having a GUI, it had a commandline interface with an Io> prompt.  That way instead of being limited to the small repertoire of actions I have time to program into a GUI, you'd have unlimited access to the underlying game engine programmatically.  (It will use an OpenGL window to display things; you just control the view programmatically in a terminal window.)

My partner has talked about having it so that the server can be accessed via a telnet-like interface over TCP/IP.  He was talking about writing a client to connect to in C# using a custom protocol, but I think too much recent exposure to Windows programming has got him thinking everything needs a custom GUI app - why not instead just use ssh to connect to the server (e.g. using PuTTY on Windows)?

So here's what I'm thinking I'll have it do:  the Io program (be it the debugging client, game client, or server program) will listen on some TCP port on 127.0.0.1.  It will doString() any text sent to it over that port and return the result.  We'll use a telnet-like program (or telnet itself, or socat or netcat) running in a totally separate process to connect to this port and send/receive text.  AFAIK, if you bind 127.0.0.1, that's not the same as binding your public ethernet port, so programs on the internet at large can't connect to it.  You have to be already on the machine.  And anyway we'll block that port in the firewall on the network.  The way it would still be accessible on the server even though externally it's not accessible is you first log into the server via ssh, you then run the telnet command inside the ssh session so it's actually running local to the server itself.

developer pc -> ssh port 22 over network -> server PC -> telnet -> port xxxx over localhost -> Io program

On Windows, I believe both PuTTY and HyperTerminal could be used to connect to a *local* instance of the debugging client or game client this way.

So, it might seem like a lot of trouble to go through to just send Io commands nonblocking, but I think TCP is actually the way that will work in all the situations this will be used in.

I'm curious what you guys think of this:  this TCP/IP Io> prompt object would be a way to run Io programs silently as system daemons and still occaisonally communicate with them when you want to.