Number: 1822

Date: 10-Aug-84 18':18':34

Submitter: Sannella.PA

Source: Shrager.pa

Subject: INIT file LOAD vs. SYSLOAD':  change INIT file handling to rationalize editing init files

Assigned To: Masinter

Attn: Release

Status: Open

In/By: 

Problem Type: Design - UI

Impact: Annoying

Difficulty: 

Frequency: 

Priority: Perhaps

System: Programming Environment

Subsystem: File Package

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["masinter" "27-Aug-84 21':50':51" Subject': Assigned% To': Attn': Status':(Open->Fixed) Description':]'
["Kaplan" " 6-Sep-84 13':26':46" Status':(Fixed->Open) Description':]'
["Sannella.PA" "11-Sep-84 10':30':48" Subject': Description':]

Description: '
The documentation of GREET should read':'
'
The system greet file (determined by (GREETFILENAME) ) gets loaded with the SYSLOAD parameter. The user greet file (determined by GREETFILENAME(USER)) gets loaded with normal file package settings, but also under errorset protection and with PRETTYHEADER set to nil to suppress the FILE CREATED message.'
'
Users should also try to make sure that their init file is ''undoable''': if they P some expressions on the file to be evaluated, they should P the "undoable" version, e.g. (/SETSYNTAX --) rather than SETSYNTAX, etc. This is so another user can come up, do a (GREET) and have the first users initialization undone.'
'
'
===== [follows long discussion of the problem, false starts, etc.]'
Date': 25 Jul 84 19':50 PDT'
From': Shrager.pa'
Subject': Lisp': InitComs Vanishes?!'
To': LispSupport.pa,masinter'
'
Lisp System Date': 25-Jul-84 17':48':29'
Machine': Dorado (Shrager)'
Microcode version': 24,4'
Memory size': 10000'
Frequency': Always'
Impact': Fatal'
'
I can no longer just edit my initcoms variable, in order to change my init.lisp file.  Why isn''t initcoms stored anylonger?  How am I supposed to fix my init file?  Actually, there has been a related problem from the beginning, INIT shouldn''t be SYSLOADed.  It''s is something that people change all the time.'
'
-----'
'
Date': 25 Jul 84 21':06 PDT'
From': masinter.pa'
Subject': Re': Lisp': InitComs Vanishes?!'
In-reply-to': Shrager.pa''s message of 25 Jul 84 19':50 PDT'
To': Shrager.pa'
cc': LispSupport.pa, masinter.pa'
'
This is a feature, but an incompatible change. What happened was that the INIT coms were still there, but INIT wasn''t on FILELST, confusing a lot of people. I made it so that INIT was always loaded SYSLOAD': if you wanna edit it, do a LOADFROM.'
'
-----'
'
Date': 25 Jul 84 21':51 PDT'
From': Shrager.pa'
Subject': Re': Lisp': InitComs Vanishes?!'
To': Sannella'
cc': Masinter'
'
Mike,'
'
	Larry "fixed" init file processing so that the INITCOMS was smashed.  This was apparently in response to an AR of mine, complaining that you couldn''t DC INIT, because it was loaded without appropriate filepackage tags -- or something,  instead of simply being loaded.  My intention was, rather, that INIT simply be loaded, so that you could DC it like everything else since LOTS of people do DV INITCOMS and then makefile their init, in order to fix it up.  '
'
	I complained (loudly) at Larry about his interpretation of the fix request, so he said to remark the AR as open.  I can''t find the AR.  Could you mark it for me?'
'
	Here''s a copy of the message Larry sent me when I complained the first time about his fix.  In subsequent conversation, I convinced him that there was at least a 50/50 chance that the fix should be done the other way around.  So, please remark the AR open.'
'
Thanks,'
	Jeff'
-----'
'
Date': 26 Jul 84 15':46 PDT'
From': JonL.pa'
Subject': Re': Lisp': InitComs Vanishes?!'
In-reply-to': Shrager.pa''s message of 25 Jul 84 19':50 PDT'
To': Shrager.pa'
cc': LispSupport.pa, masinter.pa'
'
Most people have an init file called <USERNAME>LISP>INIT rather than <...>INIT.LISP   Hence, if you load in the former you do get INIT.COMS; I''ve ocasionally loaded in {DSK}INIT.LISP (the site-specific initializations -- not the user-specific ones, which are generally stored on a file server) and did get INITCOMS set up ok.'
'
The reason for "sysloading" the init files rather than loading them is that in fact most people change them very rarely, and don''t wan''t all the space taken up by cone that is run only once.'
'
-- JonL --'
'
-----'
'
Date': 26 Jul 84 18':43 PDT'
From': Shrager.pa'
Subject': Re': Lisp': InitComs Vanishes?!'
In-reply-to': JonL.pa''s message of 26 Jul 84 15':46 PDT'
To': JonL.pa'
cc': LispSupport.pa'
'
I don''t think that this is the issue at all.  The problem is that one wants to have a simple means of modifying one''s init file (whereever it may be).  As it was, all you had to do was edit the INITCOMS var (which had to be done with DV since it was a SYSLOADED file) and then do a new makefile.  This made it extremely easy to fix your init, although, according to Richard, the file package may not know all about the things that you hack into it, and so may make a slight mess by this means...This doesn''t surprise me, considering how much of a mess the file package can make even under normal circusmstances, if you aren''t careful about editing coms vars via DC.  '
'
Anyhow, the way things seem to be moving, the way that one updateds one''s init file is to LOADFROM INITCOMS from it, but LOADFROM evals all the P types in the file-- foo!  Thus, you have to put in reloading tests all over the place so that this isn''t a problem.  If you use LOADFNS instead of loadfrom, the eval is taken care of but (in any case) remaking the file causes the OLD version to be reloaded, destroying the newly fixed COMS vars.  (Unless you do ''NEW.)  So, we''ve added six orders of magnitude of complication to the process of initialization and the related process of editing one''s init files.'
'
The claim that this is cleaner because under the old mechanism one ran the risk of lossing due to file package misunderstandings, is bogus because now runs the opposite risk of losing because you didn''t do the six incantations just right (like mis-issuing the LOADFROM) or not having your init set up just right so that the wrong things DONT happen on reload.  I personally consider the old way preferable.'
'
My solution to this will be to have a private file called SETUP.  Lisp initialization won''t be able to find this, and I''ll just have to hand load it when I start up a new environment.  I''m willing to pay this relatively small price, in lieu of  having to deal with the ever-more-crockful initialization procedures.'
'
Cheers,'
	Jeff'
'
-----'
'
Date': 27 Jul 84 02':06 PDT'
From': JonL.pa'
Subject': Re': Lisp': InitComs Vanishes?!'
In-reply-to': Shrager.pa''s message of 26 Jul 84 18':43 PDT'
To': Shrager.pa'
cc': JonL.pa, LispSupport.pa'
'
I SEE.   You reallyn did want special treatment for the init file.'
'
Well, I''ve taken the tack on this one to have a file of "utilities" -- your''s could be called SETUP -- and simply have my INIT file do a FILES on it.  Thus when I need to edit my init file, and LOADFROM it, the "utilities" file, along with all it''s P forms, doesn''t get loaded a second time.'
'
-- JonL --'
'
-----'
'
Date':  5 Sep 84 16':39 PDT'
From': Kaplan.pa'
Subject': GREET/ LOAD SYSLOAD ?'
To': Masinter, LispSupport'
'
I''ve noticed in the last few loadups that when I start out a FULL (don''t know about LISP), FILELST starts out with the value (INIT), and INITCOMS is not smashed.'
'
GREET seems to be getting the user INIT file by calling LOAD with LDFLG=T.  Why isn''t this SYSLOAD ?'
'
--Ron '
'
-----'
'
Date':  5 Sep 84 16':49 PDT'
From': JonL.pa'
Subject': Re': GREET/ LOAD SYSLOAD ?'
In-reply-to': Kaplan.pa''s message of 5 Sep 84 16':39 PDT'
To': Kaplan.pa'
cc': Masinter.pa, LispSupport.pa'
'
I think Larry made some change to acommodate Shrager''s complaint about not being able to edit this init file easily enough.  '
'
Worse yet!  This point is more than academic, since INITCOMS also is somehow marked-as-chaned; and I have a background proces in my environment that periodically inspects FILELST for files that have un-dumped changes (so that one one go away and forget that he made some edits, or so that he won''t depend toooo long on the stability of the hardware).  '
'
And I''m continually getting hassled about INIT now.  There''s got to be a better way to gag this foolishnes than REMPROPing the FILE property of INIT'
'
-- JonL --'
'
-----'
'
From': KAPLAN.pa'
Date':  5-Sep-84 21':45':36 PDT'
Subject': Re': GREET/ LOAD SYSLOAD ?'
In-reply-to': Lispar.auto''s message of 5 Sep 84 16':56 PDT'
To': Lispar.auto'
cc': JonL, Kaplan, Masinter, LispSupport'
'
I don''t know how to Query about a particular topic, if I don''t know the number.  Is there automatic indexing down to the level of "INIT" ?'
'
After 10 years of having it not marked as a loaded file with no complaints, I can''t imagine giving into a couple of new users.  This should have been "declined".'
'
There was a valid complaint a couple of months ago, I believe from Maxwell, to the effect that the INITCOMS variable was not being smashed by the old GREETLST mechanism, which seduced the user into thinking that he COULD edit his INIT by simplying editting INITCOMS.  But then when he tried to dump it, he would get a file-not-loaded error.'
'
But LOADing it SYSLOAD would solve that problem.  In order to work on your INIT, what you have to do is to LOADFROM it.  This is what you have to do to work on any other SYSLOADed file--or any other non-loaded file.  After all, the user didn''t ever LOAD the thing himself; why should he expect to be able to work on it?'
'
Note also':  It is only new users who really spend time working on their inits.  Once you get it set up, you hardly ever do anything to it (except in so far as we start fooling around changing system defaults etc).'
'
It is crazy (forgive my intemperate language) to put in this kind of annoyance for everybody, just to make it easy for new users to diddle their INIT without themselves explicitly loading them.'
'
Do you want every FINDCALLERS to look in your INIT?'
'
Ron'
'
------'
'
Date':  6 Sep 84 09':33 PDT'
From': Masinter.pa'
Subject': Re': GREET/ LOAD SYSLOAD ?'
In-reply-to': KAPLAN.pa''s message of 5-Sep-84 21':45':36 PDT'
To': KAPLAN.pa'
cc': LispSupport'
'
The relevant ARs are 122, 638, 1822. The issue seems to me to be one of making the system less confusing to novices (who uniformly expect that the INIT file is loaded like any other file) at the expense of making experts do a number on their INIT file to get it out of FILELST.'
'
When I go around to random users here and elsewhere, I find that most folks have *lots* of files on FILELST which are things they happened to load, and that they don''t use EDITCALLERS much at all. I found Shrager''s arguments (in AR#1822) compelling, as I did the fact that Maxwell and Shulman both expect their INIT file to be loaded like anything else. '
'
I do expect this to be documented in the release message as an incompatible change, with a suggestion to users who don''t *want* their INIT file to show up on how to get rid of it (maybe we could make GREET pay attention to some stupid FLG which you could set in your init?)'
'
-------'
Date':  6 Sep 84 10':45 PDT'
From': Kaplan.pa'
Subject': Re': GREET/ LOAD SYSLOAD ?'
In-reply-to': Masinter.pa''s message of 6 Sep 84 09':33 PDT'
To': Masinter.pa'
cc': KAPLAN.pa, LispSupport.pa'
'
I looked at the AR''s.  The first 2 (122 and 638) are simply complaining about the fact that originally the INIT files coms existed even though the file had not been noticed.  The fix to this would have been either to run SMASHFILECOMS on the INIT as part of the old GREETLST mechanism, or to LOAD-SYSLOAD.    Either way, the filepkg would then be consistent.'
'
It is also consistent if you do LOAD-T, the only difference being that the INIT file is now on FILELST.'
'
Frankly, I don''t find Shrager''s arguments (#1822) compelling.  A simple note in the manual to the effect that you must LOADFROM your init file when you want to work on it, right at the point where it says that your INIT file exists, would be sufficient.  The user can make no mistaken edits, cause there will be nothing to edit if he does not do the LOADFROM.'
'
The most serious issue that Shrager raises is that doing the LOADFROM will actually cause some of the expressions to be re-evaluated, which perhaps the user doesn''t want.  But this is not a problem specifically related to INIT--the same is true for every file in the system.  '
'
There ought to be a general solution, not a kludge centered around INIT.  The general solution might be a special LDFLG that means notice the file by just getting the coms, not evaluating any of the expressions.  Or perhaps a separate function NOTICEFILE that makes the file known to the file package and available for editting, but with nothing except the coms loaded.'
'
I strongly advocate reverting to SYSLOAD; if you don''t agree, I think we should have a meeting and take a vote.  Perhaps we need some formal mechanism for adjudicating technical disputes, since these matters of taste seem to be arising more frequently now.'
'
-------'
'
But a question':  If either of the greetings is done SYSLOAD, will any undo information get saved so that ungreeting will work?  (I presume that the fooling around with GREETHIST in GREET is pulling the undo information out of the LISPXHIST so that the information for ungreeting is then later available.  But is anything saved under a SYSLOAD?)'
'
'
Date':  6 Sep 84 11':38 PDT'
From': Masinter.pa'
Subject': Re': GREET/ LOAD SYSLOAD ?'
In-reply-to': Kaplan.pa''s message of 6 Sep 84 10':45 PDT'
To': Kaplan.pa'
cc': Masinter.pa, LispSupport.pa'
'
no undo info is saved under SYSLOAD.'
'
I suggest you remark the AR as Open, and take the vote. I originally put in it as loading the file sysload, and got very strong pressure from Shrager and Gumby and a few others.'
'
I don''t know how to implement NOTICEFILE such that it does the "right" thing, i.e., loads in enough so that it is safe to do a makefile but doesn''t execute anything.'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 11-Sep-84 10':30':49