#481: Problems with differing *READ-BASE* values for COMPILE-FILE/LOAD -------------------------------+----------------------- Reporter: Mark Evenson | Owner: (none) Type: defect | Status: closed Priority: minor | Milestone: 1.8.1 Component: other | Version: 1.8.1-dev Resolution: fixed | Keywords: Parent Tickets: | -------------------------------+-----------------------
Comment (by etimmons):
I can still reproduce on commit 9c0a9693ea933309e503266255edcde5cc76257c. Here's a modified test procedure that gets rid of the *read-base* nonsense.
{{{ (defvar *file-name* "file-2")
(defun write-test-file (num) (let ((pn (merge-pathnames *file-name* (make-pathname :type "lisp")))) (with-open-file (f pn :direction :output :if-exists :supersede) (prin1 `(defun test () ,num) f)) pn))
(load (compile-file (write-test-file 10)))
(assert (= (test) 10) nil "Got ~D, expected 10" (test))
(delete-file (merge-pathnames *file-name* (make-pathname :type "abcl")))
(load (compile-file (write-test-file 11)))
(assert (= (test) 11) nil "Got ~D, expected 11" (test)) }}}
The extra weird thing is that if you spawn a new ABCL process and LOAD file-2.abcl, evaluating (TEST) produces the correct result (11), so the COMPILE-FILE works. It's acting like the first LOAD of an .abcl file caches the file handle, doesn't close it, and reuses it on subsequent LOADs.
Bisecting suggests this appeared in one of:
{{{ # only skipped commits left to test # possible first bad commit: [2a1e20db8cc46edb277d3415d9e6dbc0f65fa671] Ensure that we behave like previous implementation # possible first bad commit: [6824d00bb83a8032aa7716a211719118e6404614] Make Pathname.init() static method # possible first bad commit: [bd3e7de6aa87d1fdc6817ded0562c792ba4db247] Starting to hook jar/uri mechanisms up # possible first bad commit: [fc63b71217430274904eced6c333091d13980b4a] INCOMPLETE Hook up implementation of PathnameJar and PathnameURL }}}