#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 }}}

#481: Problems with differing *READ-BASE* values for COMPILE-FILE/LOAD -------------------------------+----------------------- Reporter: Mark Evenson | Owner: (none) Type: defect | Status: reopened Priority: minor | Milestone: 1.8.1 Component: other | Version: 1.8.1-dev Resolution: | Keywords: Parent Tickets: | -------------------------------+-----------------------

Comment (by Mark Evenson):

Replying to [comment:2 Eric Timmons]:

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.

The failure to re-load FASLs is an artifact of the a bug with the zip cache that I have been working on fixing. Unfortunately, I didn't note this as a problem publicly, so apologize for not having all the information available for you.

I think the zip cache is now fixed with https://github.com/armedbear/abcl/pull/357 which is more-or-less ready to be merged. But first, I am transitioning to Github Actions for CI away from Travis due to their recent limitations on macOS runners for open source projects which I easily blew away in a day's worth of CI.