[TUHS] Emacs and undump

[TUHS] Emacs and undump

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

I ported GNU Emacs to the Celerity product line mostly because most of the programmers there wanted it over vi. Not me, I’m a vi guy.

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.

Does anyone else remember this?

	David

[TUHS] Emacs and undump

[Mantas Mikulėnas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Sun, Feb 26, 2017 at 9:16 PM, David <david at kdbarto.org> wrote:

> I ported GNU Emacs to the Celerity product line mostly because most of the
> programmers there wanted it over vi. Not me, I’m a vi guy.
>
> 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 does that, doesn't it?

https://lwn.net/Articles/673724/

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/acdb500a/attachment.html>

[TUHS] Emacs and undump

[Tim Bradshaw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

> On 26 Feb 2017, at 19:16, David <david at kdbarto.org> 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: you compile and load your code into a running image and then dump that image in a form where it can be reloaded quickly.  The dumped image is either directly executable or is loaded by some small bootstrap loader which might also provide some low-level support (but might not: all that can be in the dumped image).  What you call these dumped images depends on your culture: they might be 'worlds', 'bands' or 'sysouts' among other things.

(There are often also compiled files which are generally called fasl files, though in emacs they are elc files.)

[TUHS] Emacs and undump

[Lars Brinkhoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Tim Bradshaw wrote:
>> 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

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.

[TUHS] Emacs and undump

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
> Tim Bradshaw wrote:
>>> 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
>
> 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.

Unix systems are retiring sbrk(2), so emacs is breaking on those
systems. Trouble is, sbrk is kinda hard to implement on systems that
allocate memory for processes from multiple pools and other crazy
things. So now Emacs has no way of knowing where the upper limit was
so it can't start allocating with its own custom allocator...

At least GNU Emacs...

Warner

[TUHS] Emacs and undump

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

I've been having a bit of trouble with /bin/sh (Bourne's original one)
for the same reason. I described my projects in more detail earlier,
but in a nutshell I have intercepted open() and other syscalls, and I
have implemented replacements so that old code like /bin/sh doesn't
have to change, it sees a pretty BSD-like system. So one thing I had
to do was check if the thing being opened is a directory, and if so I
vacuum up the contents using the modern readdir() supplied in glibc or
whatever, and then write a tempfile in a format which the old style
readdir() understands. Then I return a handle to the tempfile instead
of the directory. Trouble is, this makes a non-stdio-using program be
stdio-using, in the worst case it's a non-stdio-using program that has
its own malloc() based on sbrk()... so we get another malloc()
happening in the middle, I temporarily fixed this by redirecting the
modern system's malloc() into the ancient system's malloc() but this
is a very non desirable solution. As another possibility I was
thinking of changing the ancient system's sbrk() into realloc() and
implementing a routine to relocate the heap, it obviously would have
to understand everything on the heap and everything that can point
into it. It's a real mess. But ultimately if I could get this right, I
could implement a lightweight system with no memory manager where all
processes share the malloc().
cheers, Nick

On Mon, Feb 27, 2017 at 6:26 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
>> Tim Bradshaw wrote:
>>>> 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
>>
>> 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.
>
> Unix systems are retiring sbrk(2), so emacs is breaking on those
> systems. Trouble is, sbrk is kinda hard to implement on systems that
> allocate memory for processes from multiple pools and other crazy
> things. So now Emacs has no way of knowing where the upper limit was
> so it can't start allocating with its own custom allocator...
>
> At least GNU Emacs...
>
> Warner

[TUHS] Emacs and undump

[Derek Fawcus]

On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote:
> I've been having a bit of trouble with /bin/sh (Bourne's original one)
> for the same reason.
 [snip]
> Trouble is, this makes a non-stdio-using program be
> stdio-using, in the worst case it's a non-stdio-using program that has
> its own malloc() based on sbrk()... so we get another malloc()
> happening in the middle, I temporarily fixed this by redirecting the
> modern system's malloc() into the ancient system's malloc() but this
> is a very non desirable solution. As another possibility I was
> thinking of changing the ancient system's sbrk() into realloc() and
> implementing a routine to relocate the heap, it obviously would have
> to understand everything on the heap and everything that can point
> into it.

How about applying Geoff Collyer's change to the shell memory management
routine available here:

    http://www.collyer.net/who/geoff/stak.port.c

DF

[TUHS] Emacs and undump

[Nick Downing]

Thanks for the stak.c it's a good idea. I'm not sure about the stack
freeing routine at the end of the file as it seems to rely on a bit of
pointer voodoo but I think I could rationalize all that.
cheers, Nick

On Feb 28, 2017 1:33 AM, "Derek Fawcus" <dfawcus+lists-tuhs at employees.org>
wrote:

> On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote:
> > I've been having a bit of trouble with /bin/sh (Bourne's original one)
> > for the same reason.
>  [snip]
> > Trouble is, this makes a non-stdio-using program be
> > stdio-using, in the worst case it's a non-stdio-using program that has
> > its own malloc() based on sbrk()... so we get another malloc()
> > happening in the middle, I temporarily fixed this by redirecting the
> > modern system's malloc() into the ancient system's malloc() but this
> > is a very non desirable solution. As another possibility I was
> > thinking of changing the ancient system's sbrk() into realloc() and
> > implementing a routine to relocate the heap, it obviously would have
> > to understand everything on the heap and everything that can point
> > into it.
>
> How about applying Geoff Collyer's change to the shell memory management
> routine available here:
>
>     http://www.collyer.net/who/geoff/stak.port.c
>
> DF
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/b79ae204/attachment.html>

[TUHS] Emacs and undump

[Derek Fawcus]

On Tue, Feb 28, 2017 at 01:50:55a.m. +1100, Nick Downing wrote:
> Thanks for the stak.c it's a good idea. I'm not sure about the stack
> freeing routine at the end of the file as it seems to rely on a bit of
> pointer voodoo but I think I could rationalize all that.

Have a look at the shorter/parent url,  he also has a paper describing what
he's done, a port of the v7 shell (de-ALGOL'ed), and a few small enhancements.

DF

[TUHS] Emacs and undump

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:

> How about applying Geoff Collyer's change to the shell memory management
> routine available here:
>
>     http://www.collyer.net/who/geoff/stak.port.c

Depends on what shell you are talking about.

The code named by you only works with a very old Bourne Shell that can be 
retrieved from the server of Geoff Collyer.

If you are interested in the recent Bourne Shell (SVr4 + Solaris changes), you 
better use my Bourne Shell sources that can be found inside the schily-tools:

	http://sourceforge.net/projects/schilytools/files/

The code from above will not work in a recent Bourne Shell without changes in 
both, Geoff Collyer's stak.c and the rest of the Bourne Shell.



Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Emacs and undump

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

Hmm well I am more interested in the ancient code, I am not averse to
adding improvements but I want to do so in a controlled way. Also I prefer
not to use any Sys3~5 interfaces in my current project which is exclusively
BSD.

Haha, well I de-algoled /bin/sh twice so far, first time was for my uzi to
Z180 port about 10yrs back, and second time was for my 4.3BSD to Linux
porting library project last month. In the intervening time I became quite
a sed wizard and my latest de-algolizer is completely automated and
produces very nice results. Could possibly be improved by astyle's removal
of braces around single statements, I considered this too risky at the time
but I have since realized I can compare the stripped executables to
convince myself that it does not change the logic, indeed I should check
the basic de-algolizer in this way also.

Lately I have been thinking of running all of 4.3BSD through astyle but I
hesitate to do unnecessary changes, one always regrets them when doing any
bisecting or rebasing stuff...

Nick

On Feb 28, 2017 3:43 AM, "Joerg Schilling" <schily at schily.net> wrote:

Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:

> How about applying Geoff Collyer's change to the shell memory management
> routine available here:
>
>     http://www.collyer.net/who/geoff/stak.port.c

Depends on what shell you are talking about.

The code named by you only works with a very old Bourne Shell that can be
retrieved from the server of Geoff Collyer.

If you are interested in the recent Bourne Shell (SVr4 + Solaris changes),
you
better use my Bourne Shell sources that can be found inside the
schily-tools:

        http://sourceforge.net/projects/schilytools/files/

The code from above will not work in a recent Bourne Shell without changes
in
both, Geoff Collyer's stak.c and the rest of the Bourne Shell.



Jörg

--
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353
Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/
projects/schilytools/files/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/84760fd9/attachment-0001.html>

[TUHS] Emacs and undump

[tfb]

On 27 Feb 2017, at 07:19, Lars Brinkhoff <lars at nocrew.org> 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.

I think the history of this must go back beyond ITS.  InterLisp did the same thing, and it's a west-coast Lisp so probably not influenced by ITS (and it probably predates ITS in its beginnings).  So either the idea was just pervasive (which is at least plausible I think) or it has its roots somewhere further back: I wonder what Lisp 1.5 did?

Oddly I once learned something important about TCP because of this.  I had a Xerox D-machine (an 1186, which was a Daybreak I think), which I needed to move somewhere.  I was logged into it and running a Lisp image with lots of state, so I did whatever incantation was needed to write all the dirty pages to disk halt Lisp, turned the machine off and carried it wherever it needed to go, plugged power and network back in and restarted the image.  Unbeknownst to me I had a couple of telnet windows open to Unix machines: when I turned the machine back on they were not only still open but they still had live sessions in them.

Well, it seems obvious now, but that was the moment when I understood how TCP worked.

--tim

[TUHS] Emacs and undump

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

David <david at kdbarto.org> wrote:

> I ported GNU Emacs to the Celerity product line mostly because most of the programmers there wanted it over vi. Not me, I???m a vi guy.
>
> 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.

The file "sendmail.fc" is just the dump of the heap from sendmail.
This method existed since a long time.

BTW: undump(1) has been announced on a Sun User Group in 1987, but the
next year, SunOS-4.0 came out and made things much harder to implement.

I did never see an updated undump(1) source that would be able to deal with 
SunOS-4.0 and it's shared libraries. Does it exist?

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Emacs and undump

[Tony Finch]

Joerg Schilling <schily at schily.net> wrote:
>
> BTW: undump(1) has been announced on a Sun User Group in 1987, but the
> next year, SunOS-4.0 came out and made things much harder to implement.
>
> I did never see an updated undump(1) source that would be able to deal with
> SunOS-4.0 and it's shared libraries. Does it exist?

Emacs uses a thing called "unexec", or rather several things, one for each
OS, with varying complexity and fearsomeness.

The SunOS one was deleted in 2008:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2a5cb2584f9ca171ad4310a464d6236e5f005b0e

The Solaris one is the easiest, because dldump() is part of the OS:
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexsol.c?id=4daca38d5c673c5b6862e10cfade9559852cce12

Of course, the most popular systems (generic ELF, Windows, and Mac OS)
have the most complicated implementations of unexec.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Cyclonic 7 to severe gale 9, occasionally storm 10 later.
Very rough or high, occasionally very high. Rain or showers. Good,
occasionally poor.

[TUHS] Emacs and undump

[Johnny Billquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

On 2017-02-27 08:26, Lars Brinkhoff <lars at nocrew.org> wrote:
> Tim Bradshaw wrote:
>>> 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
> 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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Emacs and undump

[Lars Brinkhoff]

Johnny Billquist <bqt at 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.

[TUHS] Emacs and undump

[Johnny Billquist]

On 2017-02-27 11:30, Lars Brinkhoff wrote:
> Johnny Billquist <bqt at 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.

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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Emacs and undump

[Arthur Krewat]

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
>

[TUHS] Emacs and undump

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]


> On Feb 27, 2017, at 9:04 AM, 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.
> 

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.

[TUHS] Emacs and undump

[Johnny Billquist]

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

[TUHS] Emacs and undump

[Lars Brinkhoff]

Johnny Billquist wrote:
> 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.

And it's not just a list structure, but a tree.  You can e.g. start a
new DDT, which itself can have inferior jobs (subprocesses).

To bring this slightly back on topic, ITS job handling was John Kulp's
inspiration for Unix job control.  Control-Z does pretty much the same
thing in both ITS and Unix.

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

Much is sharable.  There's a concept of purification (which also comes
from ITS).  A purecopy() function is used in temacs to put read-only
data in a special memory area.  That area will become sharable in the
dumped Emacs.

[TUHS] Emacs and undump

[Johnny Billquist]

On 2017-02-27 21:26, Lars Brinkhoff wrote:
> Johnny Billquist wrote:
>> 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.
>
> And it's not just a list structure, but a tree.  You can e.g. start a
> new DDT, which itself can have inferior jobs (subprocesses).

Hmm. That sounds similar to TOPS-20 then maybe.

>> 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.
>
> Much is sharable.  There's a concept of purification (which also comes
> from ITS).  A purecopy() function is used in temacs to put read-only
> data in a special memory area.  That area will become sharable in the
> dumped Emacs.

There are definitely some shareable things, but you need to remember 
that even some pure, read-only data can be problematic in a shared 
segment, as not all people might even have that data loaded, even if the 
data itself is readonly.

	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