[Complete Newbie Response] Re: End-user accessing Squeak "program"
from a VT220 terminal?
fragment at nas.com
Fri Feb 14 17:49:16 UTC 2003
Nevin Pratt wrote:
>> As for connecting Squeak to a serial port, which as you say must be
>> polled, another idea comes to mind: write a small C program that
>> talks to the telnet port, and then turns around and talks to Squeak
>> via TCP/IP.
> Err, I meant "that talks to the serial port"
Just off the top of my head, there are a couple of packages in existence
already, Telnet and CommandShell, that might come in handy.
Essentially, the info coming from the terminal could be considered
events. You could buffer/echo text coming from the terminal until a CR,
and then have Squeak process the contents of the buffer as a discrete
message. The screen draw/refresh on the other end could be handled by a
set of primitives that do the VT100 escape sequences (which should all
be in the Telnet client already), so you wouldn't have to transmit full
screen updates. Tabs and menu selection (if they're pre-existing in the
software you're trying to replace or mimic) could be handled by
pre-selecting certain events -- namely tabs -- to manage changing the
selected fields, but ultimately it would still be event driven rather
than a strict oldschool I/O call-and-response kind of scenario.
Plus, if you write it well, you'll only have to change the UI events
when you move away from the terminals (though if your data people are
oldschool, I think terminals can be faster -- tab, tab, x, enter without
bothering to read or target with a cursor).
If you need a kludge to connect your code into your terminal, snag the
telnet code and dangle your terminal from a Unixlike box, and then use
some thing like cu, tip or C-Kermit to manage the telnet-to-serial
Or, preferably, run the VM on the same box so you can secure the traffic
to and from the terminal. Has anyone run Squeak under VNC (Unix-native,
More information about the Squeak-dev