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?
-- Larry
Larry Clapp <·····@theclapp.org> wrote in message news:<·············@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.
········@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.
Or use Daniel Barlow's detachtty <http://ww.telent.net/cliki/detachtty>.
Edi.
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>
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 ······@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
Larry Clapp <·····@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.
* Kent M Pitman <······@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 <····@naggum.net>, speaking about the non-triviality of
implementing a full TELNET client or sever, wrote in message news:<················@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, ···@tkb.mpl.com
···@tkb.mpl.com (T. Kurt Bond) wrote:
> Erik Naggum <····@naggum.net>, ... 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.>
[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...
In FreeBSD under TCSH one can do the following:
snapdragon:wlp > cat
load: 0.00 cmd: cat 83847 [ttyin] 0.00u 0.00s 0% 96k
load: 0.00 cmd: cat 83847 [ttyin] 0.00u 0.00s 0% 96k
load: 0.00 cmd: cat 83847 [ttyin] 0.00u 0.00s 0% 96k
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 ······@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
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
>
> 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.
Geoff
* 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.
--tim
From: Michael J. Ferrador
Subject: Re: Lisp apps, threading, & debugging
Date:
Message-ID: <3C76699F.6FBF19A2@orn.com>
Erik Naggum wrote:
>
> * Kent M Pitman <······@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.
"Michael J. Ferrador" <·····@orn.com> writes:
> The CMU telnet REPL
> seems to have CR/LF problems
> with windows clients.
Hmm. Looks like the kind of "lossage" that happens when LF is
interpreted as what it actually means rather than as what people
wish it meant.