Note: SHRDLU only works with the visual block rendering on pdp10-ka with the
Type 340 display enabled. Even then, there is some issue that causes the
SLAVE interface to the Type 340 display to fail, with an error indicating that
the 340 is not available. This is still to be tracked down.
Without the Type 340 display, SHRDLU should work reasonably well. It fails at
some things that the DEMO apparently succeeded in doing. It is not clear why,
but likely the demo was created at one point, and the SHRDLU sources were updated
after that point, breaking some things.
SHRDLU can be invoked with :SHRDLU;SHRDLU.
Once you invoke SHRDLU, you'll see output similar to this:
SHRDLU VERSION 1000 LOADED 2024-07-21 IN BLISP 2156
REFER
COMMENTS AND QUESTIONS TO DDM
VERSION
RECONSTRUCTED BY EJS
-IF YOU ARE NEAR A DEC-340
DO YOU WANT THE DISPLAY (TYPE " Y " OR " N " )
If you are running the pdp10-ka emulator, have enabled the DPY device, and want
to see the display, answer "Y". Otherwise, answer "N".
Then, after some more output you will see:
YOU ARE NOW IN A READ-EVAL-PRINT LOOP
TYPE " GO " TO ENTER READY STATE
>>>
You are now in command mode and can type various commands, such as "SHOW".
You can also type "GO" to enter ready mode. It is in ready mode that you can
issue commands like "pick up a big red block.", to which SHRDLU should
respond "OK.". Note that commands should be ended with a period (".").
Questions should be ended with an exclamation mark ("?"). An example question
might be: "what is in the box?".
MicroPlanner can be invoked with :SHRDLU;PLNR. As a simple test of MicroPlanner,
you can enter these expressions (marked with "==>" -- don't type that). If the
(THVAL ...) form results in printing "(FALLIBLE TURING)" then you know that basic
goal reaching works.
>>> TOPLEVEL
LISTENING THVAL
==> (THASSERT (HUMAN TURING))
((HUMAN TURING))
==> (DEFPROP THEO1 (THCONSE (X) (FALLIBLE $?X) (THGOAL (HUMAN $?X))) THEOREM)
THEO1
==> (THASSERT THEO1)
THEO1
==> (THVAL (THGOAL (FALLIBLE TURING) (THTBF THTRUE)) NIL)
(FALLIBLE TURING)
The TIME program checks the SYS;RECORD TIME timestamp to see if a new
uptime record has been set. It's not a normal timestamp, but is
relative to day 0 of month 0 in year 1900.
Thanks for Heinz-Bernd Eggenstein for discovering this.
KA10 specific programs: DECtape tools, programs related to the Rubin
10-11 interface (including the Knight TV), programs using the 340
display, and programs using the PDP-6.
KL10 specific programs: microcode, frontend programs, and LSPEED.
KS10 specific programs: microcode, frontend programs, MTBOOT, and TENTH.
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.
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.
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.
Modifying some of the sources has changed these from the values
previously in lisp.tcl and build.tcl; it now matches any string of
numbers on a line by itself (optionally with "." and spaces afterwards).
After typing (todo) or (todoi), wait for the string ") \r" to appear.
This signals the end of of a list printed right before reading new
input from the console.
