[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New mis-feature of TOPS-20, Release 5, and/or search rules for Logical names
- To: Admin.MRC at SU-SCORE
- Subject: New mis-feature of TOPS-20, Release 5, and/or search rules for Logical names
- From: Jon L White <JONL at MIT-MC>
- Date: Wed, 18 Nov 81 18:38:00 GMT
- Cc: JONL at MIT-MC, "(FILE LISP;BUG MAIL)" at MIT-MC, RYLAND at SRI-KL, ADMIN.JQJ at SU-SCORE, CSD.CLAYTON at SU-SCORE, CSD.GENESERETH at SU-SCORE, ZUBKOFF at CMU-20C, BUG-TWENEX at MIT-XX
- Original-date: 18 November 1981 13:38-EST
Problems with logical names under Twenex have come up in the past,
and the new state, having PS: be a 'logical name', will break MacLISP.
Since it is now installed on SCORE that way, then SCORE's MacLISP
will essentially be unusable until there is some resolution -- I don't
yet know of other sites with Release 5 yet, so maybe we can 'fix' this
before too many others are affected.
One fix I suggested is having MacLISP 'special-case' the PS: device, but
that amounts to defeating this new misfeatureful generality and I'm not
sure that that's wise in the long run. The only other alternative is
for the searching rules to act in accord with my suggestion below, which
is part of my reply to your reply:
Date: 17 Nov 1981 1519-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
In-Reply-To: Your message of 17-Nov-81 1130-PST
. . .
Yes, the systemwide logical name of PS: is a new feature of TOPS-20. . .
The bug is MACLISP's. It should supply both the device and the directory
specification to GTJFN in all circumstances.
This doesn't work -- when the GTJFN supplies a directory specification,
it overrides any such in the logical name. E.g., suppose you have
@DEF FOO: PS:<JONL>,PS:<MACLISP>
and suppose <MACLISP> has a BS.LSP, but <JONL> doesn't. Then using
"FOO:BS.LSP" will succeed, but "FOO:<JONL>BS.LSP" will not. I suspect
that in the latter case, the "FOO:" part is limited to supplying a real
device name (i.e., PS:) for the searching procedure, whereas it should
go through its search sequence independently of the <JONL>. The MacLISP
user will find himself 'supplying' directory specifications without
conscious effort, since that is the reason for the DEFAULTF variable;
possibly initializing it to ((* *) * ...) would get around some problems,
but may introduce other undesirable perturbations.
If it needs the true location
of the file, it should GTJFN it with GJ%OLD (to force a chase down the
logical name tree to find an existing file) then use JFNS to get the string
That's indeed how the PROBEF and TRUENAME functions work.
Release 5 is going to be this way as a standard.
HELP! Any of you Twenex wizards out there got an idea?