[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
this doesn't have much to do with any new monitor, I suspect
- To: CPR at MIT-EECS
- Subject: this doesn't have much to do with any new monitor, I suspect
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Wed, 14 Jan 81 01:56:00 GMT
- Cc: BUG-LISP at MIT-MC, Keshav at MIT-XX
- Original-date: 13 January 1981 20:56-EST
Date: Tuesday, 13 January 1981 13:22-EST
From: Chris Ryland <CPR at MIT-EECS>
To: bug-lisp at mc
Subject: this doesn't have much to do with any new monitor, I suspect
cc: Keshav at MIT-XX
Date: Monday, 12 January 1981 17:03-EST
From: KESHAV at MIT-XX
To: cpr at MIT-XX
Re: A Bug
The function writeablep in Maclisp is defined in the fasl file <maclisp>purep.
fasl. My guess is that it checks for write protection violations. Until
yesterday, calling this function with an output file (in Maclisp) gave t(rue).
It still does so in Maclisp on ML. However, your new monitor gives a
write protection error.
One LISP program that shows this is -
(load '((dsk maclisp) purep fasl))
(setq outfilep (open '(my output) 'out))
This should return t.
Your example looks suspsiously like you think WRITEABLEP has something
to do with files. It does not. It's purpose is to determine if
operations like RPLACA will result in a write-protection violation.
I.e.E WRITABLEP should return T for INPUT files as well, because
file-arrays are never placed on unwritable pages. I cannot conceive of
a situation where you would legitamately be calling WRITABLEP on a file.
It is true, however, that WRITEABLEP does not yet work on TOPS-20. (It
never did, and if you think it did you're wrong). However, you can
write an acceptable substitute of (DEFUN WRITABLEP (X) (NOT (PUREP X))).