The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bqt@update.uu.se (Johnny Billquist)
Subject: [TUHS] Emacs and undump
Date: Mon, 27 Feb 2017 21:09:33 +0100	[thread overview]
Message-ID: <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se> (raw)
In-Reply-To: <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>

Ooo. Fun. We're talking PDP-10s on a Unix list... :-)

On 2017-02-27 16:13, Arthur Krewat <krewat at 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.

Right. But that is a different thing. Each terminal session only have 
one job. The fact that you can detach that, and log in as a new session 
is a different concept.

> 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".

Yes. Again, that is a different thing as well. Hisegs are more related 
to shared memory.

I assume you know all this, so I'm not going to go into details.
But having the memory around for a program, even if it is not running, 
is actually sometimes very useful. If ITS could handle that, while 
treating them as separate processes, all associated to one terminal, and 
let you select which one you were currently fooling around in, while the 
others stayed around, that is something I don't think I've seen elsewhere.

> 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.

That would work, but it would then require that all other users be 
suspended until the first user actually completes the initialization, 
and after that, all the memory must be readonly.

> Not knowing anything about EMACS, I'm not sure that compiled code was
> actually shareable if it was customized, just thinking out loud.

You can certainly customize and save your own image. But the general 
bootstrapping of Emacs consists of starting up the core system, and then 
loading a whole bunch of modules and configurations. All that loading 
and parsing of those files into data structures in memory is quite cpu 
intensive.
Once all that processing is finished, you can start editing.
Each person essentially wants all that work done, no matter what they'd 
like to do later. So, Emacs does it once, and then saves the state at 
the point where you can start editing.

But it does not mean that the memory is shareable. It's full of various 
data structures, and code, and that will change as you go along editing 
things as well.

> 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.

Indeed. Like I said, Tops-10 have the same concept as Emacs does today. 
But there it was essentially what you always did.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


       reply	other threads:[~2017-02-27 20:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
2017-02-27 20:09 ` Johnny Billquist [this message]
2017-02-27 20:26   ` Lars Brinkhoff
2017-02-27 21:06     ` Johnny Billquist
     [not found] <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
2017-02-27 10:24 ` Johnny Billquist
2017-02-27 10:30   ` Lars Brinkhoff
2017-02-27 10:47     ` Johnny Billquist
2017-02-27 14:04       ` Arthur Krewat
2017-02-28 11:55         ` Ronald Natalie
     [not found] <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
2017-02-26 19:16 ` David
2017-02-26 19:28   ` Mantas Mikulėnas
2017-02-27  6:41   ` Tim Bradshaw
2017-02-27  7:19     ` Lars Brinkhoff
2017-02-27  7:26       ` Warner Losh
2017-02-27  8:12         ` Nick Downing
2017-02-27 14:33           ` Derek Fawcus
2017-02-27 14:50             ` Nick Downing
2017-02-27 15:43               ` Derek Fawcus
2017-02-27 16:43             ` Joerg Schilling
     [not found]               ` <CAH1jEzZjvOhHnbvsWcw8gbx9d_W47DbBidYd_tteCr5dC6H2ng@mail.gmail.com>
2017-02-28  0:02                 ` Nick Downing
2017-02-27 12:59       ` tfb
2017-02-27 10:35   ` Joerg Schilling
2017-02-27 15:13     ` Tony Finch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se \
    --to=bqt@update.uu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).