Poking around in the CMU CL docs, I found mention of the multiprocessing package, and a routine which would allow you to start a read-eval-print-loop (REPL) server that listened to a port, sort of like a telnet server -- you'd telnet to the port and get a REPL.
This seems unutterably cool to me. :) In particular, the ability to debug & patch one's actively running process, even while somebody else uses it, seems pretty nifty.
So I wonder, just out of curiosity, does anyone out there do this? Is it as handy as it looks on the surface?
Larry Clapp <la...@theclapp.org> writes: > Hi, all,
> Poking around in the CMU CL docs, I found mention of the > multiprocessing package, and a routine which would allow you to > start a read-eval-print-loop (REPL) server that listened to a port, > sort of like a telnet server -- you'd telnet to the port and get a > REPL.
> This seems unutterably cool to me. :) In particular, the ability to > debug & patch one's actively running process, even while somebody > else uses it, seems pretty nifty.
> So I wonder, just out of curiosity, does anyone out there do this? > Is it as handy as it looks on the surface?
Keep in mind that Lisp has the full power to run programs and delete files that your login account can access, so if you do this, don't do it in a place where you're open to the whole internet! There are really major security issues here if you don't utterly trust the environment that you are serving such a process to.
That said, it used to be done all the time on the Lisp Machine that one would telnet into a Lisp and use it for all kinds of things. Though in the LispM case, the telnet was to the selfsame address space that all of the machine's processes worked in, so it had a lot more direct access to environment than an isolated server process would have. I could, for example, login remotely and save my unsaved editor buffers ... Of course, the Lisp Machine (at least, the Symbolics branch) also had an integrated command processor (with completing reader) at Lisp toplevel so you could flexibly issue commands or type Lisp forms, and that made getting certain things done easier; in an arbitrary Lisp, you have to kind of build up your own command set for things you like to do. But at least Lisp is a language you presumably know, and programming things that are comfortable to call isn't very hard..
There can be issues of programs that think they can pop up stuff on the display console, which won't exist remotely. This can appear as a process simply freezing with not necessarily any feedback to the remote telnet user about whether a window has popped up on a random person's screen or a system process has blown out for failure to do so or something is wedged in a lock state wishing some other process would try harder or...
And there was an issue with the LispM telnet for many years regarding asynchronous interruption--it required an extra process to listen on the input stream and find the asynchronous-abort-request character and process that ahead of other pending characters in order not to have computations that just lock up and don't listen to the telnet port any more. There may be other ways to implement this, and I don't know if CMU's repl deals with any of this... just something to watch out for.
Larry Clapp <la...@theclapp.org> wrote in message <news:msb45a.gpv.ln@rabbit.ddts.net>... > Poking around in the CMU CL docs, I found mention of the multiprocessing > package, and a routine which would allow you to start a read-eval-print-loop > (REPL) server that listened to a port, sort of like a telnet server -- you'd > telnet to the port and get a REPL.
> This seems unutterably cool to me. :) In particular, the ability to debug & > patch one's actively running process, even while somebody else uses it, seems > pretty nifty.
> So I wonder, just out of curiosity, does anyone out there do this? Is it as > handy as it looks on the surface?
Two similar tricks I use (eg useful for web servers)
- have a lisp evaluation form web-page, where you can type lisp forms and evaluate them from your browser. Naturally, this form must be password protected, running over SSL, and do error catching and redirection of *standard-out* to a string.
- on Unix, start a lisp process using the 'screen' program. This can be done from the command line or from a script, so that screen immediately detaches . Then you can reconnect to it with 'screen -r' whenever you need to interact with your lisp. This is just as handy as the telnet server, and is probably safer.
jk271...@yahoo.com (John Klein) writes: > Two similar tricks I use (eg useful for web servers)
> - have a lisp evaluation form web-page, where you can type lisp > forms and evaluate them from your browser. Naturally, this form > must be password protected, running over SSL, and do > error catching and redirection of *standard-out* to a string.
> - on Unix, start a lisp process using the 'screen' program. > This can be done from the command line or from a script, so > that screen immediately detaches . Then you can reconnect to it > with 'screen -r' whenever you need to interact with your lisp. > This is just as handy as the telnet server, and is probably safer.
* Kent M Pitman <pit...@world.std.com> | And there was an issue with the LispM telnet for many years regarding | asynchronous interruption--it required an extra process to listen on | the input stream and find the asynchronous-abort-request character and | process that ahead of other pending characters in order not to have | computations that just lock up and don't listen to the telnet port any | more. There may be other ways to implement this, and I don't know if | CMU's repl deals with any of this... just something to watch out for.
Implementing a full TELNET client or server is about two weeks' worth of hard labor (each) for one who knows the standards involved. It is not something you whip up in an hour or two just by making or accepting connections. TELNET is a protocol that needs a dedicated programmer's full attention. Option processing in TELNET has non-trivial consequences and should not be ignored because they are mostly not used. The typical 90% solutions of TELNET server or client causes loss of data and/or lockup of the connection. In particular, interrupt processing is hard to get right. Personally, I _really_ like the Are You There facility and use it to test TELNET implementations. Very few get it right.
<nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere, typing ^T (the canonical AYT binding), produced a system status line including system load, number of processes, what your process was doing or waiting on, etc. All extremely useful information when working a system taht occasionally went unresponsive. Sadly, the pathetic Unix terminal drivers and shells and telnet/remote shell clients are _miles_ short of the real thing.>
Unfortunately, if you write a real TELNET client, nobody wants to use it, because they think the retarded HTTP-style interaction is what network protocols should be like, and the only kind of state machines programmers of today are used to working with are regular expressions, and they do not even understand how _those_ work. I fault this incredibly stupid marketing for "object-orientation" as the panacea for the demise of the state machine.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
* Erik Naggum wrote: > <nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere, > typing ^T (the canonical AYT binding), produced a system status line > including system load, number of processes, what your process was doing > or waiting on, etc. All extremely useful information when working a > system taht occasionally went unresponsive. Sadly, the pathetic Unix > terminal drivers and shells and telnet/remote shell clients are _miles_ > short of the real thing.>
I've used some Unix system which did this. It was either a Vax running a (slightly hacked) 4.3 or a Masscomp running RTU (a system that still fills me with cold fear, if it did this right this was nearly its only good feature). It's really annoying: I have a completely clear visual memory of sitting at a specific terminal in the machine room and doing this, but I can't for the life of me remember which system I was connected to.
Erik Naggum <e...@naggum.net>, speaking about the non-triviality of implementing a full TELNET client or sever, wrote in message <news:3223365881868925@naggum.net>...
> <nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere, > typing ^T (the canonical AYT binding), produced a system status line > including system load, number of processes, what your process was doing > or waiting on, etc. All extremely useful information when working a > system taht occasionally went unresponsive. Sadly, the pathetic Unix > terminal drivers and shells and telnet/remote shell clients are _miles_ > short of the real thing.>
FreeBSD does something similar when you press ^T, giving the load and information about the current running process (command, pid, state, times, memory used, etc.), at least when you are running /bin/sh. (I suspect that the other shell interfer with their fancy command-line editing.) -- T. Kurt Bond, t...@tkb.mpl.com
> > <nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere, > > typing ^T (the canonical AYT binding), produced a system status line > > including system load, number of processes, what your process was doing > > or waiting on, etc. All extremely useful information when working a > > system taht occasionally went unresponsive. Sadly, the pathetic Unix > > terminal drivers and shells and telnet/remote shell clients are _miles_ > > short of the real thing.>
[Really just replying to Erik's message, but tkb picked a better subject line]
When interviewing for a summer job at Yale back in 1981, I heard a "horror story" about how someone had forwarded a letter to a secretary to be printed out, but the secretary was not computer-savvy enough to just print the letter from the computer, so she'd pulled it up on screen to type it in. But somehow had typed ^T during the screen display, and the entire status line typeout ended up included verbatim mid-paragraph in the hand-typed letter becuase the person doing the typing had no ability to distinguish the session data (the letter) from the metadata (the ^T output) and just blindly copied it all.
AYT runs a similar risk, though I also like the feature and am routinely annoyed that SSH (at least the one I use) doesn't seem to implement it...
> * Kent M Pitman <pit...@world.std.com> > | And there was an issue with the LispM telnet for many years > | regarding asynchronous interruption--it required an extra process > | to listen on the input stream and find the asynchronous-abort-request > | character and process that ahead of other pending characters in order > | not to have computations that just lock up and don't listen to the > | telnet port any more. There may be other ways to implement this, > | and I don't know if CMU's repl deals with any of this... just > | something to watch out for.
> Implementing a full TELNET client or server is about two weeks' worth > of hard labor (each) for one who knows the standards involved. It is > not something you whip up in an hour or two just by making or > accepting connections. TELNET is a protocol that needs a dedicated > programmer's full attention. Option processing in TELNET has > non-trivial consequences and should not be ignored because they are > mostly not used. The typical
The CMU telnet REPL seems to have CR/LF problems with windows clients.
Larry Clapp wrote:
> Poking around in the CMU CL docs, I found mention of the > multiprocessing package, and a routine which would allow you to > start a read-eval-print-loop
Some limitations -
Seems to be some interactions between MP, the Debugger and Hemlock.
Invoking the debugger in one session will stop the others.
certain (ed) -Hemlock operations on a telnet will stop the primary terminal.
You have to close the telnet session, rather than (quit) If you want to get back in.
These are only the ones I have run across, just playing as a newbie.
> (REPL) server that listened to a port, sort of like a telnet server > -- you'd telnet to the port and get a REPL.
> This seems unutterably cool to me. :) In particular, the ability to debug &
VNC, others? (screen w/ nohup?) Dribble File for logging.
> patch one's actively running process, even while somebody else uses it
There seems to be plenty of warnings about MP, non-atomic operations, redefining thing that are running.
From the regular prompt I think, as someone put it, the shell's command line processing intercepts the ^T. Though all it does is beep at you....
I think there's a way to set this character to do the right thing, but I'm too lazy to figure it out now.
SH works just fine:
snapdragon:wlp > sh $ load: 0.00 cmd: sh 83848 [ttyin] 0.00u 0.00s 0% 436k load: 0.00 cmd: sh 83848 [ttyin] 0.00u 0.00s 0% 436k load: 0.00 cmd: sh 83848 [ttyin] 0.00u 0.00s 0% 436k
-- Fred Gilham gil...@csl.sri.com "...If reason is no longer a faculty enabling us to discern some cosmic design, then it is no longer clear what claim reason has upon us, or upon our politics. On the contrary, the sorts of habits that we associate with `reasoning' --- that is, reflecting and discussing and trying to achieve some kind of coherence among our various opinions --- can come to seem like nothing more than the mental preferences (or prejudices) of a particular class of people --- the dogmatic proceduralism of an educated elite." --- Steven D. Smith
Here's what one can do with CMUCL + multiprocessing:
* (mp::start-lisp-connection-listener)
#<Process Anonymous {4802EF9D}> * ;;; Started lisp connection listener on port 1025 with password 3075180
Then you can telnet to it:
snapdragon:~ > telnet snapdragon 1025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Enter password: 3075180
CMU Common Lisp 18d-pre 20-Dec-2001, running on snapdragon.csl.sri.com Send questions and bug reports to gilham, or see <URL:http://www.cons.org/cmucl/support.html>. Loaded subsystems: Python 1.0, target Intel x86 CLOS based on PCL version: September 16 92 PCL (f) Gray Streams Protocol Support CLX X Library MIT R5.02 *
You can telnet to the lisp multiple times at the same time, and they all seem to work OK, at least with the minimal testing I did.
-- Fred Gilham gil...@csl.sri.com | If sophists such as Richard Rorty are correct, and the West has moved from a post-religious age to a post-metaphysical age, then there is literally nothing Western left about the West to defend. --David Dieteman
> When interviewing for a summer job at Yale back in 1981, I heard a > "horror story" about how someone had forwarded a letter to a secretary > to be printed out, but the secretary was not computer-savvy enough to > just print the letter from the computer, so she'd pulled it up on > screen to type it in. But somehow had typed ^T during the screen > display, and the entire status line typeout ended up included verbatim > mid-paragraph in the hand-typed letter becuase the person doing the > typing had no ability to distinguish the session data (the letter) > from the metadata (the ^T output) and just blindly copied it all.
Reverse english time...
While we're OT, I remember using TECO on a VAX11/780. If you saved a file after getting a system message for new mail or getting paged by that damnable phone exe, it very neatly saved with the system announcement neatly tucked into it. The nasty thing about phone was that it kept announcing the connection attempt. If you weren't careful, your source file could end up with little paging notices all the way through it.
