ITS configuration has the Rubin 10-11 in the 3,,0-3,,777777 range.
The documentation says it's one moby lower.
Two more PDP-11s were attached at some point.
Since we're interacting with ITS through the system console, one cause
of build failures is the messages the system job prints to the console
at unpredictable times -- for example, periodic timestamps and
notifications of changes to files in system directories. If one of these
gets printed while we're expecting something else, it's hard for the
Expect script to recover.
Avoid this by patching STYO, the system job's character-printing
routine, to return without doing anything if this system is up.
Adjust the pdset routine so it's matching PDSET's output rather than the
system job's to tell when the time has been set.
Doing expect_after before a child process has been spawned causes Expect
to try reading from stdin. If stdin is /dev/null, it gets an EOF from
the read, assumes it's been closed... and closes stdout too, so we don't
see any more of the child process interaction.
When shutting down the emulator and starting another, it's otherwise
possible for the first read from the new emulator to return an error
(EIO from the pty read in Expect).
On my machine the expect script fails to see the ". words" because the "." is
separated by a newline and the message "IT IS NOW..." (time) followed by a newline with "words". Chnaged from ". words" to "words".
Resolves#1134.
This avoids problems when the full path to the build directory has
spaces in it; make needs spaces in target/dependency names to be quoted.
If the paths are all relative, then we only need to use $(CURDIR) (and
quote carefully) when adjusting PATH, etc.
Resolves#1125. This reverts the compilation of TRANSS and uses the
FASL file from MC. I'll have to figure out what is wrong with the
source/compilation in another ticket.
Trying to match the list output from these functions, without also
matching the "; Loading" messages from Lisp, is difficult to do reliably
in expect (as demonstrated by a series of test builds on a slowish VM).
Instead, use a marker ("=Build=") that won't appear in the output.
At some point, AIOPUSH was changed not to load B from (R). On top of
that, the call to AIOPP1 clobbers B. This makes TYIIOP unhappy,
because it expects B to retain the information from AIOPUSH. Since R
is unchanged, we can just restore B in AIOPP1.
The DB and KA configurations have different console terminal widths, and
format these lists differently: DB puts a space after the right bracket,
and KA doesn't, so the build was hanging here on KA.
