PDP-10 / its

Incompatible Timesharing System
Other
861 stars 83 forks source link

EMACS; TS 126 size difference (DB vs PI) #1506

Closed eswenson1 closed 5 years ago

eswenson1 commented 5 years ago

I noticed that EMACS; TS 126 on ES is size 7+31, while the same file on DB is 5+322. This suggests that we are not including all the same libraries that the PI distribution did.

larsbrinkhoff commented 5 years ago

I wonder how? There's not much user input.

INFO; CONV > documents the procedure:


How to Build and Dump a New EMACS

  Before building a new dumped EMACS, you may wish to Generate
up-to-date versions of the essential libraries.  This can be done by

        M-X Run$EINIT$? Generate

However, there is no need to do this if the new versions of functions
to be changed are present in the patch files (see below).

  The visible procedure for building a new EMACS is simply to do

        EMACS$^S
        :NTECO

which runs NTECO using EMACS's TECO init file.  On Twenex, simply run
TECO while connected to <EMACS>.  This leaves you in the
TECO top-level loop, typing TECO command strings, and should display
an EMACS-style mode line.  Then, to dump the EMACS, type

        MMRun$PURIFY$Dump$<filename>$$

which will dump the environment you have built.  Then kill the job.
eswenson1 commented 5 years ago

Yeah, I'm wondering the same. The EINIT on DB and ES (PI) is the same.

eswenson1 commented 5 years ago

Interesting. I just followed the same process as we use in the DB build for building and dumping an emacs, and I see the following results:

ES:EMACS;
  0   TS     126      7  +31    8/12/85 23:34:33  (1/28/119) -??-
  1   TS     127      5 +337  ! 1/28/119 15:03:02 (1/28/119) EJS

TS 126 was the original (PI) version. TS 127 was the one I generated today. So we are quite a bit smaller. I wonder why?

eswenson1 commented 5 years ago

I just compared all the sources used to generate [pure] and [prfy], as well as EINIT and EMACS TECO, and they are identical between ES and DB. I'm assuming the version of emacs used to build emacs on DB is EMACS; TS 126, and that it is identical to the EMACS; TS 126 on ES -- I haven't verified that since the DB build deletes the file. And I've verified that the version of TECO used in doing the dumping is the same (1212). So I really can't figure out what is different.

I just did a comparison of the TECPUR 1212 files (between ES and DB) and they are different. But they are the same size. I'll probe a little more.

larsbrinkhoff commented 5 years ago

The bootstrap EMACS is EMACS; TS 126 from AI.

TECO is built from the MIDAS source code. Metadata in the binary SBLK file should be different.

eswenson1 commented 5 years ago

The TS 126 on ES and DB (from sources tape) are identical. So are the various [pure] and [purify] and einit files. The teco used to build emacs on ES and DB is the same (1212). The tecos compare the same between the two (srccom /$). I still haven't found why the one DB is building (and the one I build on ES) is 2 pages shorter than the one that was on ES to begin with.

eswenson1 commented 5 years ago

The only COMPRS file that is different in size is KBDMAC. It looks like the COMPRS on ES was made from KBDMAC 44 and the one we use on DB is based on KBDMAC 46. The sources are pretty different. But the one in DB (KBDMAC 46's COMPRS) is actually larger than the one on ES (KBDMAC 44's COMPRS). So that would tend to make the resulting image larger -- not smaller.

eswenson1 commented 5 years ago

Interestingly, the TS files we build for EMACS, INFO, and TEACH files are all 2 pages smaller than the original PI/ES versions. I wonder if it the patch files. Investigating.

eswenson1 commented 5 years ago

Ahhh, that appears to be it. There is a patch file in ES -- EMACS; PAT162 12 that is loaded in if the version of [pure] is 162. When I recreated my emacs on ES, I created [pure] 163. There is no patch file for version 163. However, I deleted [pure] 163, making [pure] 162 the "latest" version. When I dumped out a new emacs, it was 7+41 words long. TS 126 was 7+31 words long (pretty darned close). This compares much better than the TS 126 we create in DB, which is 5+322 words long.

So..... what this means is that we have to include the patches in DB. I'll check in the patch file. Since our DB build currently renames [pure] to version 162 (from the 163 that actually resulted), TECO (from EMACS; EMACS TECO) will load in EMACS;PAT162 >. It looks at the version number of [pure] and uses that to find patches for that version.

larsbrinkhoff commented 5 years ago

I'd like to see the following:

  1. Check in the patch file.
  2. Make sure 126/162 is built with it.
  3. Make source updates to make version 127/163.
eswenson1 commented 5 years ago

Yes. I entered this ticket: https://github.com/PDP-10/its/issues/1520 to incorporate the patches into the relevant source files and build a new emacs (without patches).

I'm going to do this in two steps. First PR is to add the patches. We'll make sure the resulting emacs works fine and is about the right size. Then, as a second PR, I'll merge the patches into the relevant sources so that we can have no patches in the next build, and update the build to build the new emacs (sans patches). Ok?

larsbrinkhoff commented 5 years ago

Yes, OK.

There's also EMACS 170: https://github.com/PDP-10/its/issues/64

eswenson1 commented 5 years ago

It gets a little more interesting. I found EMACS; FILES 439 and EMACS; FILES 440. We have EMACS; FILES 434 in DB now. The patch to Write File (from FILES) includes a fix that is in neither 439 nor 440. But 439/440 have fixes not found in the patch file.

So I think the first thing to do is to incorporate the patches into a FILES 435. And then merge in the fixes from 439 and 440. Alternatively, we could just create a FILES 441 that includes the 439/440 and PAT162 fixes. I have only checked FILES (Write File -- the first entry in the patch file). There might well be other discrepancies.

eswenson1 commented 5 years ago

Some notes: PAT162 contains the following three patches:

  1. Write File (EMACS1; FILES).
  2. & Read Command Name (EMACS1;CRL)
  3. ^R Incremental Search (EMACS1;ISEARCH)

So we'll need to provide updated versions of these three files. I think FILES is the only one that we have later versions for.

eswenson1 commented 5 years ago

Hmm.... the version of & Read Command Name in the patch file is quite different from that in the latest source (EMACS; CRL 208). CRL 208 was in ES/PI. It is also in DB. I don't have any later version (maybe in Emacs 170 -- I haven't checked yet). In any case, I'm not sure which is "better" the one in CRL 208 or the one in PAT162 12.

eswenson1 commented 5 years ago

Looks like only the doc string for ^R Incremental Search was changed in PAT162 12. So the ISEARCH update is trivial.

eswenson1 commented 5 years ago

I will study the various versions we have of Write File (FILES 434, FILES 439, FILES 440, PAT162 12) and see if I can figure out what is the "best" version. Same with & Read Command Name (CRL 208 and PAT162 12). For ^R Incremental Search, I'll just create an ISEARCH 75 (current version is 74).

We'll just have to be careful when we merge Emacs 170 to make sure that we don't assume that like versioned files are the same. We'll have to scrutinize the differences to come up with appropriate FN2s.

rmaldersoniii commented 5 years ago

We'll just have to be careful when we merge Emacs 170 to make sure that we don't assume that like versioned files are the same. We'll have to scrutinize the differences to come up with appropriate FN2s.

As I stated in a comment to issue #64, EMACS 170 (and TECO 1220) were TOPS-20 only updates based on the Stanford TOPS-20 version of TECO and EMACS 16507 (a couple of edits later than 165). I did this in order to create the best version of EMACS for XKL's expected customer customer base, with enhancements from SimTel20 and MIT. In early 1996, there really was no expectation that ITS would ever resurface. As it happens, the work was completed two months before Richard Troiano and I did the customer survey which showed that 60 TOPS-20 systems had been retired in the previous 12 months, killing the Toad-1's chances in the marketplace, and leading to XKL's decision to return to the networking arena.

eswenson1 commented 5 years ago

Yes, I plan on being very careful when I merge in the emacs 170 changes. I'll make sure that any changes work in ITS and are good (and don't revert any changes in our 162 (and soon our 163). I'm not going to blindly take the 170 changes. Also, we should probably close this ticket since we already have a ticket for emacs 170 (and we have one for incorporating the patches from 162 into a new release (163) -- #1520.

eswenson1 commented 5 years ago

I wonder if the emacs 170 changes will run on teco 1212, given that you said they were implemented on version 1220 of teco. Do we have the 1220 teco sources? Do we know if a teco built from them would run on ITS?

eswenson1 commented 5 years ago

I just tried to assemble the TECO (on ITS) from the emacs 170 tape and ran into a bunch of unresolved symbols. I'm going to grab the rest of the midas files from that tape and see if I can get TECO to assemble.

eswenson1 commented 5 years ago

I was able to assemble TECO from the emacs 170 tape on ITS. I had to add a couple defines (TEXTIF and STANSW) to the IFN ITS[] section. I successfully dumped it out and ran the resulting image. It claims to be version TECO.262143 (seems awfully close to 2^18, so probably some bug in the version printing).

However, I'm unable to dump out an emacs using this version of teco. I get the error:

M^R     Attempted to macro a meaningless number?

when I try to run:

mmrun$purify$dump$ts 130$$
eswenson1 commented 5 years ago

It turns out that something has broken the ability to specify the MSNAME override to find the TECO init file. If you patch the call to open the init file with emacs; emacs teco, it not only allows you to run out the emacs, but the resulting emacs runs fine.

So we have to decide whether we want to upgrade teco to this version (with patches to a) allow it to assemble on ITS and b) correctly use the MSNAME rather than the HSNAME to locate the init file.

larsbrinkhoff commented 5 years ago

The size difference has been explained, and fixed. So I'll close this. You can still add more comments if you like.