Number: 2240

Date: 24-Sep-84 13':12':07

Submitter: Masinter

Source: Masinter

Subject: RECOMPILE doesn''t check that .DCOM for copying compiled code from is correct

Assigned To: 

Attn: Masinter

Status: Open

In/By: 

Problem Type: Design - Impl

Impact: Serious

Difficulty: Easy

Frequency: Intermittent

Priority: Hopefully

System: Programming Environment

Subsystem: History

Machine: 

Disk: 

Lisp Version: 24-Sep-84 09':49':01

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: 

Description: [this was part of what was originally AR#2224]'
'
Date': 15 Sep 84 11':49 PDT'
From': Kaplan.pa'
Subject': FILEPKG SHOW STOPPER'
To': Lispsupport.PA, Lispcore^.PA'
'
'
...'
'
'
The current file package has screwed me and others in this way several times now, enough to suggest that it is not a cosmic ray.  Without any indication from the system, it has taken compiled code from a file of the appropriate name in my connected directory or on some random directory on DIRECTORIES instead of taking the compiled code that corresponded to the symbolics that I had loaded from one place and was dumping to another.'
'
(This is the common case when you want to remerge a forked development.  You loadfrom your forked directory, make a couple of edits, connect back to lispcore>sources>, then makefile/cleanup.  Result is that your .DCOM file has code drawn from the most recent version on sources, not from your forked directory .)'
'
'
In my opinion, this is dangerous enough to stop the release.  We must either move forward to make the filepkg behave properly in cases like this--make it less dependent on what happens to be where you are connected or what your search path is and more dependent on what and where you loaded things from--OR we must back up the filepkg to its previous behavior.  The previous behavior was ugly, but it was safe.'
'
--Ron'
'
Date': 15 Sep 84 13':19 PDT'
From': vanMelle.pa'
Subject': Re': FILEPKG SHOW STOPPER'
In-reply-to': Kaplan.pa''s message of 15 Sep 84 11':49 PDT'
To': Kaplan.pa'
cc': Lispsupport.PA, Lispcore^.PA'
'
As I read your complaint':'
'
   "Without any indication from the system, it has taken compiled code from a file of the appropriate name in my connected directory or on some random directory on DIRECTORIES instead of taking the compiled code that corresponded to the symbolics that I had loaded from one place and was dumping to another."'
'
...this is nothing new at all.  This, in fact, is the documented behavior.  The system NEVER has had a pointer from source to compiled code; it always takes from the connected directory (or punts to FINDFILE per normal file-not-found error handling).'
'
If you want to rejoin a fork, you have to be careful, and explicitly give a CFILE argument to BRECOMPILE pointing at the dcom you want to copy from, or else BCOMPL afresh.  I have done this numerous times.'
'
It would be nice if we made the filepkg smarter, or were perhaps more explicit in the documentation about this pitfall, but I fail to see the show stopper.'
'
	Bill'
'
-----'
'
From': masinter.pa'
Date': 16-Sep-84  0':22':10 PDT'
Subject': Re': FILEPKG SHOW STOPPER'
In-reply-to': vanMelle''s message of 15 Sep 84 13':19 PDT'
To': vanMelle'
cc': Kaplan, Lispsupport, Lispcore^'
'
my intention here, by the way, is to make RECOMPILE work like the CHECKSET library package': to look at the FILECREATED date of the (old) .DCOM to see what it was compiled on. If you are doing a recompile of a file, the "previous date': " of the source needs to match the "compiled on': " of the COM, otherwise, recompile everything (after printing message.)'
'
Safe, will usually only recompile what you need to, and if things are confused, will generate correct results .'
'
'


Workaround: 

Test Case: 

Edit-By: 

Edit-Date: