Y2K problems in TIME breaking Macsyma build

[TheFausap]

Hello,

I did in the morning a git pull, and I got a build timeout using KLH10:

MCLDAT 
;GC DUE TO USER
; 4169.[15%] LIST, 3337.[72%] FIXNUM, 494.[96%] FLONUM, 
; 507.[99%] BIGNUM, 312.[4%] SYMBOL, 424.[82%] HUNK8, 
; 432.[84%] HUNK16, 434.[84%] ARRAY WORDS FREE
;GC-DAEMON: cons-rate%[oldgcsize->marked/gcsize/spcsize]
; Consed=5743, Marked=31513, Allocated/Marked=1.0, Memfree= 26624
; LIST 74%[30208->23057/33280/27136]  FIXNUM 24%[4608->1331/5120/4608]  FLONUM 0%[512->18/512]  BIGNUM 0%[512->5/512]  
; SYMBOL 0%[7680->6856/7168]  HUNK8 0%[512->88/512]  HUNK16 0%[512->80/512]  ARRAY 0%[512->78/512]  

(SETQ ERRSET (FUNCTION ERRSET-BREAK)) => ERRSET-BREAK 
(STATUS MEMFREE) => 26624. 
(STATUS FEATURES) => (IOTA GRINDEF DEFSTRUCT FORMAT FASLAP NCOMPLR COMPLR MACLISP PDP10 BIGNUM FASLOAD HUNK FUNARG ROMAN SFA PAGING!
 NEWIO DB ITS) 
MAXMAC 227
DEFMAX 98
EVONCE 14
DEBUG 69
DEFINE 65
EXTHUK 34
MAILER 2
FORMAT 827.
EXPAND 10
MOPERS 49
MCOMPILER 32.
MFORMA 104
LMMAC 87
MLMAC 92
EXTSTR 96
MACAID 120
LET 98
BREAKLEVEL 
ERRCK 30
NUMERM 21
TIME 4
DEFSTRUCT 280
GRINDEF 462
MACSYMA-MODULE 9
SMURF 
BLTARRAY 2
PROCS 16
DEFOPT 8
UMLMAC 42
QUERIO 51
BACKQ 53
DEFMACRO 166
USER-QUERY 6
COMPLR 2155
DEFVSY 84
SETF 293
TRANSM 129
MLSUB 17
MCL 59
DCL 7/26/18 12:42:01
IOTA 40
GETMIDASOP 17
ERMSGC 210
SHARABLE 47
SHARPM 82
YESNOP 44
;Loading CERROR 47
Today is a Friday, not a Thursday.
;NIL ?

;BKPT *RSET-TRAP

The last command timed out.
Makefile:49: recipe for target 'out/klh10/rp0.dsk' failed
make: *** [out/klh10/rp0.dsk] Error 1

What does it mean "Today is a Friday, not a Thursday." ? :-)

regards,
Fausto

[atsampson]

I'm seeing this as well - it's fallout from #1092, I think.

The message is from TIME:VERIFY-DATE, called from TIME:PRINT-DATE which takes a time represented as a list including a date and weekday. It means that TIME:ON-WHAT-DAY-OF-THE-WEEK? thinks it's Friday, but the weekday passed in was (correctly) Thursday.

We used to have this check disabled because the weekday calculation was wrong (#716). The idea behind #1092 was to fix the calculation and reinstate the check...

[TheFausap]

I tried also with SIMS, but I got the same error... so it seems not emulator dependent.
I'll try with SIMH

[atsampson]

Ah, I think I see what's wrong - there's another Y2K problem in that bit of code!

(load "liblsp;time")
(time:get-time-list)
(31 72 20 32 7 22 |Thursday|)

It's returned the year as 22 = 18. Which STANDARDIZE-YEAR will convert to 1918, not 2018, and indeed 26th July 1918 was a Friday...

(time:on-what-day-of-the-week? 26. 7. 2018.)
3
(time:on-what-day-of-the-week? 26. 7. 1918.)
4
(time:on-what-day-of-the-week? 26. 7. 18.)
4

TIME:GET-TIME-LIST uses (STATUS DATE), which uses .RDATE (see SDATE in L; STATUS). Maybe we need a (STATUS YEAR) for this kind of thing?

[eswenson1]

So doesn't this mean we had two bugs here -- and we were depending on both of them for "successful" builds? And when we fixed one (but not the other), we get the build failure?

So what is the right thing to do here? There is little we can do with the return value of .RDATE, since it is limited to a sixbit word in YYMMDD format, preventing us from returning a 4-digit year. I assume callers of (STATUS DATE) are probably expecting a two-digit year and assuming a base of 1900. We could either add a new (STATUS NDATE) (or some other name) that returns a 4-digit year using a base of 2000 when calling .RDATE -- and then change all lisp callers of (STATUS DATE) to use (STATUS NDATE) with suitable changes to handle the 4-digit year. Or we could change (STATUS DATE) to do this -- an incompatible change (and change all callers to handle the 4-digit year). Or we could (maybe?) add a new ITS UUO (similar to .RDATE, but returning an integer time (epoch or similar) and then change (STATUS DATE) to call it. Of course, in any case, we'd have to change (STATUS DATE) to return a 4-digit year or add a new STATUS option (NDATE) if we were worried about unknown callers that couldn't deal with a 4-digit year.

Thoughts?

[eswenson1]

Actually, maybe if we update ITS to support returning 4-digit years, we should not add a new UUO, but add a new-style system call.

[eswenson1]

Ahhh, the .RYEAR UUO returns the full year. So no need to change/update ITS. We just have to decide whether to change (STATUS DATE) to return a 4-digit year (by calling .RDATE and .RYEAR) or whether to add a new STATUS that returns the 4-digit year.

$1B; START>>.RYEAR A, A/ 0 a/ 0 ◊↑N
START+1>>.LOGOU A, A/ HRRM A,3742 a/ HRRM A,3742 =542040003742

Where 3742o = 2018.

[atsampson]

I quite like the idea of making (STATUS DATE) return a 4-digit year, based on .RYEAR or .CALL /RQDATE/.

A grep shows there are various places that use it, some of which add 1900 to get the year, some of which string-prepend "19", and some which assume it's year % 100 and print it directly. So we'd need to do trivial fixes to much of the code that uses it whatever we do, and returning the 4-digit date directly looks like it would simplify many of the users.

[eswenson1]

I agree. I’ll update (status date) to return 4-digit year and fix callers.

[larsbrinkhoff]

Something to keep in mind when importing Lisp programs in the future.

[atsampson]

@eswenson1 - I've had a quick try at this on the ats/lispyear branch. I'm doing a full build at the moment to see if it's broken anything else in the process...

[eswenson1]

Gee, it looks a lot like my implementation! Looks good. Does it work?