Telnetting into Squeeek.

David T. Lewis lewis at mail.msen.com
Wed Jun 25 02:53:32 UTC 2003


On Tue, Jun 24, 2003 at 09:20:53PM -0700, Alan Grimes wrote:
> 
> I was messing around with Squeek today and notied that Ian's great
> Telnet utity had an absolutly fantastic editing window while
> CommandShell had a very poor one so I started trying to put them
> togeather. I made some progress and went to #squeeek for help.. I
> learned that CommandShell's edit window supported a special "pluggable"
> interface and hence would require much additional work. =\ Not really
> knowing about what this pluggable stuff was I decided to set it asside. 

You are exactly right. Ian's Telnet provides excellent protocol and
terminal emulation support, and CommandShell uses a sloppy hack based
on a clone of Transcript. On the other hand, CommandShell does all
the shell semantics and file system parsing in Squeak rather than
in Unix, and permits you to do Smalltalky things in the "terminal"
window. So it would be nice to glue Ian's protocol and terminal stuff
onto CommandShell so that more of the evaluation happens in Squeak
rather than out there in OS-land. This has been on my extremely low
priority to-do list, but it would be great if someone else wants to
pick it up and have a bash (sic) at it.

> Once CommandShell is correctly adapted to TerminalWindow setting it up
> behind a telnet/terminal/X-term window is no stunt at all... The only
> function of the telnetd utility is to set up a connection between the
> remote and local hosts. Once login has occoured, things get sent to the
> user's prefered shell. This could be squeak....

Sure, no problem. I have this working such that Squeak runs headless
as a teletype "command shell" that you can actually use as your Unix
login shell. This is with a Squeak command shell connected to standard
input/output/error pipes, so pty support may still be required in order
to make everything work right. In any case, at the moment I still can't
pass my own SUnit tests follow a rather extensive rewrite of some of the
command shell and OSProcess aio handling stuff, so I have not released
it yet. Sorry, hopefully RSN.

> The major drawback to this approch are severalfold: 
> 
> 1. Because the current squaek system is single-threaded, it will need to
> block and sit on the read(); call or poll it... neither solution is
> especially great... 

This is not as bad as it seems. You have to avoid blocking the VM on
an external IO operation, but it turns out that this can be handled
(at least on some platforms) with the "aio" event mechanism in Ian's VM,
combined with some primitive support to forward IO events to the
Squeak VM (the primitives are in the currently released OSProcess
plugin, but image-side support is stuck in the aforementioned stuff
that won't yet pass my SUnit tests).

> 2. This doesn't account for connecting to already running VMs... I don't
> know enough about pe-unix IPC to know wheather it is feasable for a
> session shell to connect to a back-end server that is sitting on
> standby.... If there is a way it's probably some gawdawful hack. This
> means that all instances of squeak started in this manner will be on
> completely seperate instances of the VM -- which could be more than a
> little problematic. 

Definitely a gawdawfal hack, but you could just stick it behind an
inetd service or something of the sort. More importantly from the point
of view of the user, how do you conceptually keep track of shared
object memories? It's not a single-user system at that point, so you
are into Gemstone territory now.

> What you really want, of course, is to have a multithreaded squeak (I'm
> now using my dual athlon as my main machine) so that a thread can be
> forked to sit on the console while allowing other processes within the
> immage to procede unhindered. 

Not really. A multithreaded VM might be nice, but you only really *need* it
to prevent blocking on IO, which can be handled through other techniques
as noted above.

> I'll start working on the VM but can easily forsee that disentangeling
> all those variables will take a long time........ =\ 

Well, yes.

> Testimonial: I wasted 2,000 hours using Linux.

And another 2000 hours "wasted" on Squeak, neither of which I regret in
the least.

Dave



More information about the Squeak-dev mailing list