On 2017-02-27 08:26, Lars Brinkhoff <lars(a)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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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(a)schily.net> wrote:
Derek Fawcus <dfawcus+lists-tuhs(a)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@schily.net (home) Jörg Schilling D-13353
Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.org/private/http://sourceforge.net/
projects/schilytools/files/
Ooo. Fun. We're talking PDP-10s on a Unix list... :-)
On 2017-02-27 16:13, 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.
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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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
On 26 February 2017 at 12:28, Andy Kosela <andy.kosela(a)gmail.com> wrote:
[...]
> Are you sure it was emacs? Most probably it was pico, which was the default
> editor for pine. We used pine/pico for all email at our university in the
> 90's. It was wildly popular.
Ah well, I am not sure -- that betrayed my emacs bias. I saw ^X^C and
assumed emacs.
N.
> From: Deborah Scherrer
> On 2/25/17 11:25 AM, Cory Smelosky wrote:
>> MtXinu is something I really want.
> I worked there for 10 years (eventually becoming President). I'll try
> to dig up a tape.
Say what you will about RMS, but he really did change the world of software.
Most code (except for very specialized applications) just isn't worth much
anymore (because of competition from open source) - which is part of why all
these old code packages are now freely available.
Although I suppose the development of portabilty - which really took off with
C and Unix, although it had existed to some degree before that, q.v. the tools
collection in FORTRAN we just mentioned - was also a factor, it made it
possible to amortize code writing over a number of different types of
machines.
There were in theory portable languages beforehand (e.g. PL/1), but I think it
probably over-specified things - e.g. it would be impossible to port Multics
to another architecture without almost completely re-writing it from scratch,
the code is shot through with "fixed bin(18)"'s every other line...
Noel
On 26 February 2017 at 07:46, Michael Kjörling <michael(a)kjorling.se> wrote:
> On 26 Feb 2017 07:39 -0500, from jnc(a)mercury.lcs.mit.edu (Noel Chiappa):
>> I was never happy with the size of EMACS, and it had nothing to do with the
>> amount of memory resources used. That big a binary implies a very large amount
>> of source, and the more lines of code, the more places for bugs...
>
> But remember; without Emacs, we might never have had _The Cuckoo's
> Egg_. Imagine the terror of that loss.
Hhhmmm.... I must dig my copy out of storage because I do not remember
emacs in there.
As for emac uses, my wife was on (non-CS) staff at a local college
affiliated with U of T. At the time, DOS boxes sat on staff desks and
email was via a telnet connection to an SGI box somewhere on campus.
A BATch file connected and ran pine but shelled out to an external
editor. What was the editor? Well, I saw her composing a message
once and ending the editor session by ^X^C.
N.
Wasn't the default FS type S51K? Limitations like 14 chars directory
names only. No symbolic link ?
>Date: Sun, 26 Feb 2017 11:13:25 -0500
>From: Arthur Krewat <krewat(a)kilonet.net>
>To: Cory Smelosky <b4(a)gewt.net>, Jason Stevens
> <jsteve(a)superglobalmegacorp.com>, tuhs(a)minnie.tuhs.org
>Subject: Re: [TUHS] SCO OpenDesktop 386 2.0.0
>Message-ID: <f5a1d513-3cc1-6a4d-64a3-669b49d7226f(a)kilonet.net>
>Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>What filesystem type does it use for root/boot/whatever?
>
>Install operating system "X" that supports that filesystem type in the
>virtual guest, create a new disk, newfs/mkfs it, arrange the bits from
>the tape, take the newly-assembled disk and move to another VM and try
>to boot it.
>
>Not remembering anything about how SVR3.2 boots (I think that's what
>Opendesktop is?) that's the end of my help on the subject :)
Hey,
Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got
damaged in a dehumidifier failure before they got to California. The
only survivor was of all things...the QIC-24 tape (which I have read
fine)
sco-tape> tar tf file0 | more
./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1
Anyone know a good starting point for attempting to install it in to a
VM? ;)
--
Cory Smelosky
b4(a)gewt.net
