Adding retry logic for creatin the tar ball to ensure what we upload is valid.
Looping back to creating the tar ball instead of looping on the download.
The old Maclisp used when SHRDLU was created allowed one to take the CAR
and CDR of atoms. The former returned internal bits associated wih the
symbol, and the latter returned the property list of the symbol.
This was disabled in later verisons of MacLISP, but allowed to be enabled
by setting the value of CAR to T (and the value of CDR to T).
However, doing this masked coding errors that resulted from unintentionally
taking the CAR or CDR of a symbol, when a list or NUL was actually expected.
This commit removes the hack of setting CAR and CDR to T, and adds macros
to replace the use of CAR and CDR in this cases in PLNR and associated PLNR
logic. These macros are found in the MACROS module. Making this change,
and removing the duplicated $ reader macro from PLNR (it is already in
MACROS for the benefit of other files), required making changes to the
loader of SHRDLU and PLNR. I removed the obsolete use of UREAD to load
interpreted files, and replaced with a new NEW-LOAD function. UREAD was
unable to handle the (status macro $ 'thread) code that needed to be included.
The LISTNAMES function needed another conditioanl clause to handle the case where it was
passed the NIL object (meaning "no object"). Now, it correctly answers "NOTHING" rather
than "THE IL".h
Now, we build SHRDLU;TS SHRDLU and SHRDLU;TS PLNR from compiled
lisp code. This should allow it to run faster and have fewer issues
with garbage collection and running out of LIST space.
Found lots of bugs going through the compilation effort. Also fixed
several issues that were resulting in weird/incorrect responses to
standard demo prompts.
Below is a list of prompts that I have tested:
pick up a big red block.
grasp the pyramid
find a block that is taller than the one you are holding and put it into the box.
what does the box contain?
what is the pyramid supported by?
how many blocks are not in the box?
is the red cube supported?
can the table pick up blocks?
can a pyramid be supported by a block?
can a pyramid support a pyramid?
stack up two pyramids.
stack up two red blocks.
put the green pyramid on the red cube.
which cube is sitting on the table?
is there a large block behind a pyramid?
put a small one onto the green cube that supports a pyramid.
put the littlest pyramid on top of it.
does the red cube support anything?
what color is the block that supports the green pyramid?
how many things are on top of green cubes?
had you touched any pyramid before you put the green pyramid on the little cube?
when did you pick it up?
why did you pick it up?
why did you clear off that cube?
how did you clean off the red cube?
how many objects did you touch while you were doing it?
put the blue pyramid on the block in the box.
is there anything which is bigger than every pyramid but is not as wide as the thing that supports it?
thank you.
Of course, lots more things are possible.
It is still best to do this without answering "Y" to the Type 340 display prompt at the
start. There is either an issue with the GRAPHF module or the SLAVE module (or perhaps
with the Type 340 simulator) that is causing crashes after several successful commands
with graphic output.
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 value of the timeout was getting overwritten by incorrect code.
I was seeing timeout errors while trying to write to the display from
SHRDLU. The fix seems to help a lot.
Removed the text about dependencies.sh because it's only to aid
continuous integration builds. We don't want the maintenance burden
of keeping this up to date for everyone's operating system release.
MCL is invoked with :MAXTUL;MCL and can be used to compile any
macsyma source. Of course, if you change IN-CORE sources, you'll
have to dump out a new macsyma, but for non-IN-CORE sources, you'll
get the FASL and UNFASL files in the right places, and any macros
loaded that are needed.
The original link of maxtul;.good. complr was incorrect -- it pointed
to SYS;TS COMPLR. The link is supposed to point to the dumped out
MCL image.
Also fix UTMCL. First, it is not supposed to be a link to MCL. It
is it's own dumped COMPLR image. Added source for UTMCL, and updated
macsyma.tcl to compile it and then load it into a COMPLR to dump
it to MAXTUL;TS UTMCL.
UTMCL is called by Macsyma's COMPILE_LISP_FILE function to compile
a lisp source file with the appropriate Macsyma context.
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.
In 2017, the rules changed from a start date of the 1st Sunday in April to the 2nd Sunday in March.
The end date changed from the last Sunday in October to the 1st Sunday in November.
Adding validation function to the deploy_ftp.sh script to ensure the upload was successful. If the upload was not successful, the script will exit with status code 1 and fail the build
These entries were added, based on information from backed up LSR1
files: APPLE2, DRAGON, DRAW, GFR, GT40, MINI, PDP11, PEEK, TARAKA, and
TEACH.
In the cases where FILDI had a "@machine" part, that has been dropped.
It can interfere, e.g. with $^S DDT commands.
The INQUPD program is run in "normal" mode, such that it processes
files in the INQUIR directory with FN1 = .UPD1., and we provide such a
file with the XGP user defined. We can, of course add other users
that we wish to be "pre-loaded" in the INQUIR database.
This PR changes the way that the INQUIR database is installed into ITS.
Previously, we included a binary INQUIR;LSR1 1 database on the tape we
load. Now, we build the INQUPD program (and INQUIR;DIRS BIN) database,
which is required by INQUPD, when run in LSRINI mode. LSRINI mode,
invoked by a JNAME of LSRINI for INQUPD, generates an empty
.TEMP.;LSR1 EMPTY database for INQUIR. The build scripts generate
this empty database and copy it to the appropriate plact (INQUIR;LSR 1).
SYSNET;TELSER 174, and SYSTEM;TTYTYP 322 were changed in a commit from
about 4 months ago, but the version numbers were not updated.
This makes it really hard for those trying to update their existing ITS
systems with changes from this repository.
Addresses #2280, #2282, #2283, #2284, and #2285.
Since macos ships without a 3rd-party dependency manager, there are two systems in common use - macports and brew. Both support the dependencies required to build this, so support both. Also add guard to ensure that at least one is installed rather than just blowing up if brew is not installed.
