#481 closed defect (fixed)

Problems with differing *READ-BASE* values for COMPILE-FILE/LOAD

Reported by: Mark Evenson Owned by:
Priority: minor Milestone: 1.8.1
Component: other Version: 1.8.1-dev
Keywords: Cc:
Parent Tickets:

Description

Eric Timmons reports

For file-2.test

(defun test () 10)

exercised with

(in-package :cl-user)

(let ((*read-base* 2))
  (compile-file "file-2.lisp"))

(load "file-2.abcl")

(format t "Got ~D, expected 2~%" (test))

(fmakunbound 'test)

(let ((*read-base* 9))
  (compile-file "file-2.lisp"))

(load "file-2.abcl")

(format t "Got ~D, expected 9~%" (test))

Change History (5)

comment:1 Changed 10 months ago by Mark Evenson

Resolution: fixed
Status: newclosed

Fixed in abcl-1.8.1-dev with recent work on the loader.

comment:2 Changed 10 months ago by Eric Timmons

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

EDIT:

CL-USER> (lisp-implementation-version)
"1.8.1-dev"
"OpenJDK_64-Bit_Server_VM-AdoptOpenJDK-1.8.0_272-b10"
"amd64-Linux-5.4.73-gentoo"
Last edited 10 months ago by Eric Timmons (previous) (diff)

comment:3 Changed 10 months ago by Mark Evenson

Resolution: fixed
Status: closedreopened

comment:4 in reply to:  2 Changed 10 months ago by Mark Evenson

Replying to 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.

comment:5 Changed 10 months ago by Mark Evenson

Resolution: fixed
Status: reopenedclosed

Finished adding Github Actions for CI, and merged the relevant patches.

With <https://abcl.org/trac/changeset/15494> your test code now works.

Closing again, but please re-open with more comments if this is still broken somehow.

Note: See TracTickets for help on using tickets.