Number: 10

Date: 16-Mar-84 23':55':07

Submitter: lispar.auto

Source: JonL.pa

Subject: LISPSOURCEFILEP can''t work on OPENP non-RANDACCESSP

Lisp Version: Fugue

Description: see last paragraph'
Date':  8 MAR 84 10':29 PST'
From': JONL.PA'
Subject': Re': LISPSOURCEFILEP (and WHEREIS)'
To':   kaplan'
cc':   burton, lispsupport'
'
In response to the message sent   2-Jan-01  7':36':02 PST from kaplan.pa'
'
You''re absolutely right that WHEREISNOTICE should be calling LISPSOURCEFILEP.'
A next, coordinated-with-<LispCore> version of WHEREIS could do so.'
'
I''ve been working on merging the "SYNOPSIS" stuff I mentioned before'
with the hashfile version of WHEREIS -- current intermediate state is'
on <LispCore>Library>NEWHASHWHEREIS.  It will compile the synopsis but'
stash it in a hashfile rather than on the property list.'
'
This "compilation" process is somewhat similar to the analysis that the'
extension to SINGLEFILEINDEX does -- I''m wondering if the lower-level'
support ought not to go into the system (in FILEPKG).'
'
'
Incidentally, I forgot to mention that the one lacuna in LISPSOURCEFILEP is'
this': a non-RANDACCESSP file *** which is already OPENP *** can''t be hacked.'
A little thought about lacunae in NS filing will show why (GETFILEPTR '
fails, in addition to SETFILEPTR''s problems).'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 27-Jun-84 14':02':30

Attn: 

Assigned To: 

In/By: 

Disposition: 

System: Programming Environment

Subsystem: File Package

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: Impossible

Frequency: Intermittent

Impact: Annoying

Priority: Unlikely

Status: Declined

Problem Type: Design - Impl

Source Files: MISC