27 Feb
2017
27 Feb
'17
10:24 a.m.
On 2017-02-27 08:26, Lars Brinkhoff <lars(a)nocrew.org> wrote:
Tim Bradshaw wrote:
Emacs came from ITS, and
many Lisps derive from Maclisp which also came
from ITS. In ITS, it was common for applications to be dumped into a
loadable core image, even if they were written in assembly language.
Not only i ITS. This is how things work in OS/8, for example. I believe
it is also how things work in TOPS-10 and quite possible also in TOPS-20.
Not sure about RT-11, but I wouldn't be surprised if that's the way
there too.
Essentially, the linker leaves the image in memory. It does not write it
to a file. And then, the command decode have a command for dumping your
memory to disk, as a runable image. There is some information kept
around that the linker sets up, which means you don't normally have to
tell the command decoder which parts of memory to save, or what the
start address is, and so on. But you can also give that information in
your save command.
One of the nice things of this approach is that you can load an image
into memory, and then use the debugger to look around in it, change it,
or run it. And if the program exists, it is still in memory, including
all data, which means you can check the state of everything at exit
time. And of course, if you want to, you can load a program, patch
around in it, in memory, and then run it. And, of course, you can load a
program, run some part of it, and dump it to disk at that stage, so all
initializations have been done.
Your memory is always around, and is not tied to a process that comes
and goes.
Of course, the back side of that is that you can't really run several
programs at once.
But it's not hard to see that RMS and GNU Emacs (coming from these
systems) wanted the same thing again. It do have some points.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David
wrote:
I remember that GNU Emacs launched the first time and then dumped
itself out as a core file. Each subsequent launch would then ‘undump’
itself back into memory. All this because launching emacs the first
time required compiling all that lisp code.
It still works like that. Indeed
that's the conventional way that
Lisp systems tend to work for delivering applications 
27 Feb
27 Feb
10:30 a.m.
New subject: Emacs and undump
Johnny Billquist <bqt(a)update.uu.se> writes:
Of course, the back side of that is that you
can't really run several
programs at once.
In ITS you can. You have one active job to which your command apply by
default. But you can create new jobs and switch beteen them.
10:47 a.m.
New subject: Emacs and undump
On 2017-02-27 11:30, Lars Brinkhoff wrote:
Johnny Billquist <bqt(a)update.uu.se> writes:
Ah. It was so long ago, and I never learned ITS that well. However, I
don't think you can have several jobs in Tops-10, and I know you can't
in OS/8 or RT-11.
But that's an interesting capability. To have several jobs around, with
the memory intact, and you can switch between them, and play with their
memory.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Of course, the back side of that is that you
can't really run several
programs at once.
In ITS you can. You have one active job to which your command apply by
default. But you can create new jobs and switch beteen them. 
2:04 p.m.
New subject: Emacs and undump
In TOPS-10, you could detach from your current job, login again, and
keep going. Then, attach to the previous job, and go back and forth
endlessly.
As for keeping memory around, it was very common on TOPS-10 to put code
in a "hiseg" that would stick around, and was shareable between
"jobs".
For something like EMACS, it would be very efficient to have the first
person run it "compile" all the LISP, leave it in the hiseg, and other
jobs can then run that code.
Not knowing anything about EMACS, I'm not sure that compiled code was
actually shareable if it was customized, just thinking out loud.
But even without leveraging the hiseg capability, it was relatively easy
to save an entire core image back to a .SAV or .LOW or later a .EXE. I
don't remember how easy it was to do that programmatically, but it was
easy from the terminal and if it saves a lot of processor time (and
elapsed time) people would have been happy to do it manually.
On 2/27/2017 5:47 AM, Johnny Billquist wrote:
Ah. It was so long ago, and I never learned ITS that well. However, I
don't think you can have several jobs in Tops-10, and I know you can't
in OS/8 or RT-11.
But that's an interesting capability. To have several jobs around,
with the memory intact, and you can switch between them, and play with
their memory.
Johnny
28 Feb
28 Feb
11:55 a.m.
New subject: Emacs and undump
On Feb 27, 2017, at 9:04 AM, Arthur Krewat
<krewat(a)kilonet.net> wrote:
In TOPS-10, you could detach from your current job, login again, and keep going. Then,
attach to the previous job, and go back and forth endlessly.
ITS had this feature as well.
I actually implemented this for UNIX in a crude way. I put a program as my login shell
that spawned off a shell on a PTY and the program did sort of a lightweight “telnet”
between the PTY and my login terminal.
I could then make the intermediary program go away (effectively logging out of the system)
while leaving the shell running on the PTY. The subsequent login, the program would
notice I still had my previous session running and offer to reconnect it for me.
2621
days inactive
2622
days old
4 comments
4 participants
participants (4)
-
Arthur Krewat -
Johnny Billquist -
Lars Brinkhoff -
Ronald Natalie