November 2020 - armedbear-ticket - mailman3.common-lisp.net

[armedbear] #479: CLOS MOP bug in 1.8.0
by armedbear 19 Dec '20

19 Dec '20

#479: CLOS MOP bug in 1.8.0 -------------------------------+-------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: (A)MOP Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+-------------------- Pascal Costanza reports in <https://mailman.common-lisp.net/pipermail /armedbear-devel/2020-November/004189.html>: {{{ I have encountered a bug in 1.8.0 when doing my regular Closer to MOP checks. This must be a new bug, because 1.7.1 was fine. Here is the case that triggers the problem: (use-package :mop) (defclass test-direct-slot-definition (standard-direct-slot-definition) ()) (defclass test-effective-slot-definition (standard-effective-slot-definition) ()) (defclass test-class (standard-class) ()) (defmethod validate-superclass ((class test-class) (superclass standard-class)) t) (defmethod direct-slot-definition-class ((class test-class) &rest initargs) (declare (ignore initargs)) (find-class 'test-direct-slot-definition)) (defmethod effective-slot-definition-class ((class test-class) &rest initargs) (declare (ignore initargs)) (find-class 'test-effective-slot-definition)) (defclass test-object () ((some-slot :accessor some-slot :initarg :some-slot :initform 'some-slot :type symbol :allocation :class :documentation "a slot")) (:metaclass test-class)) (unless (class-finalized-p (find-class 'test-object)) (finalize-inheritance (find-class 'test-object))) Armed Bear Common Lisp 1.8.0 Java 15.0.1 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.134 seconds. Startup completed in 0.65 seconds. Loading /Users/costanza/.abclrc completed in 6.061 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "test.lisp") Error loading /Users/costanza/Temp/test.lisp at line 36 (offset 943) #<THREAD "interpreter" {1970D65C}>: Debugger invoked on condition of type UNBOUND-SLOT The slot LOCATION is unbound in the object #<TEST-EFFECTIVE-SLOT- DEFINITION {556F331F}>. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-SLOT {67D22A29}>) 2: (ERROR UNBOUND-SLOT :INSTANCE #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> :NAME SYSTEM::LOCATION) 3: (#<FUNCTION #<FUNCTION {22446549}> {22446549}> (#<STANDARD-CLASS TEST-EFFECTIVE-SLOT-DEFINITION {6670307A}> #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> SYSTEM::LOCATION)) 4: (SLOT-VALUE #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> SYSTEM::LOCATION) 5: (SLOT-DEFINITION-LOCATION #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}>) 6: (MOP::STD-FINALIZE-INHERITANCE #<TEST-CLASS TEST-OBJECT {67510DAF}>) 7: (#<FUNCTION #<FUNCTION {2C5408FE}> {2C5408FE}> (#<TEST-CLASS TEST-OBJECT {67510DAF}>)) I believe the bug is triggered by find-class or class-finalized-p, but not sure. }}} -- Ticket URL: <https://abcl.org/trac/ticket/479> armedbear <https://abcl.org> armedbear

1 4

[armedbear] #481: Problems with differing *READ-BASE* values for COMPILE-FILE/LOAD
by armedbear 30 Nov '20

30 Nov '20

#481: Problems with differing *READ-BASE* values for COMPILE-FILE/LOAD -------------------------------+-------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: minor Milestone: 1.8.1 | Component: other Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+-------------------- 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)) }}} -- Ticket URL: <https://abcl.org/trac/ticket/481> armedbear <https://abcl.org> armedbear

1 5

[armedbear] #482: LOADing .abcl file with *READ-BASE* bound fails
by armedbear 29 Nov '20

29 Nov '20

#482: LOADing .abcl file with *READ-BASE* bound fails ----------------------------+-------------------- Reporter: etimmons | Type: defect Status: new | Priority: minor Milestone: | Component: other Version: 1.8.1-dev | Keywords: Parent Tickets: | ----------------------------+-------------------- Full disclosure: I don't have any code actually affected by this. I just ran into it while trying to better figure out #481. Test procedure: {{{ (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)) (let ((pn (write-test-file 10)) (*read-base* 2)) (load (compile-file pn))) (assert (= (test) 2) nil "Got ~D, expected 2" (test)) }}} Results in: {{{ The variable |43| is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE |43| {6545B09F}>) 1: (SYSTEM::%LOAD #P"/tmp/abcl/file-2.abcl" NIL NIL T :DEFAULT) 2: (LOAD #P"/tmp/abcl/file-2.abcl") 3: (SYSTEM::%LOAD #P"/tmp/abcl/file-1.lisp" NIL NIL T :DEFAULT) 4: (LOAD "file-1.lisp") 5: (SYSTEM::%EVAL (LOAD "file-1.lisp")) 6: (EVAL (LOAD "file-1.lisp")) }}} Looks like it's choking on the literal number in the SYS:INIT-FASL form in {{{__loader__._}}} -- Ticket URL: <https://abcl.org/trac/ticket/482> armedbear <https://abcl.org> armedbear

1 0

[armedbear] #480: SYS:PROCESS-PID fails
by armedbear 28 Nov '20

28 Nov '20

#480: SYS:PROCESS-PID fails -------------------------------+-------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: minor Milestone: 1.8.1 | Component: java Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+-------------------- Eric Timmons pointed out in Freenode #lisp that this no longer works with abcl-1.8.0 {{{ (let ((proc (sys:run-program "sleep" '("60") :wait nil))) (sys:process-pid proc)) }}} -- Ticket URL: <https://abcl.org/trac/ticket/480> armedbear <https://abcl.org> armedbear

1 0

[armedbear] #478: Command-line option to terminate process on unhandled errors
by armedbear 27 Nov '20

27 Nov '20

#478: Command-line option to terminate process on unhandled errors -------------------------------+------------------------- Reporter: Mark Evenson | Type: enhancement Status: new | Priority: minor Milestone: 1.8.1 | Component: other Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+------------------------- In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2020-November/004187.html> Robert Munyer requests: {{{ Many Lisp implementations (including CCL, CLISP and SBCL) have a command-line option that causes unhandled errors to terminate the Lisp process instead of invoking the debugger. This option is useful for programs that don't have irreplaceable valuable state in the heap, and that have users whose reaction upon seeing a debug REPL would be "How do I get out of this!?". Also, a few days ago someone on IRC mentioned having the problem that "if there is an error in the expression" the server thread "gets locked in the ABCL repl". I think his or her use-case might also benefit from a debugger-disabling switch. }}} -- Ticket URL: <https://abcl.org/trac/ticket/478> armedbear <https://abcl.org> armedbear

1 0

[armedbear] #477: COMPILE-FILE not doing minimal compilation in DEFCONSTANT/DEFPARAMETER/DEFVAR
by armedbear 16 Nov '20

16 Nov '20

#477: COMPILE-FILE not doing minimal compilation in DEFCONSTANT/DEFPARAMETER/DEFVAR -------------------------------+---------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: compiler Version: 1.7.1-dev | Keywords: Parent Tickets: | -------------------------------+---------------------- In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2020-November/004185.html> Robert Munyer reports {{{ COMPILE-FILE is supposed to expand all macros in such a way that they will not be expanded again when the compiled file is loaded. (3.2.2.2) The file below has 4 output lines that start with "*** Expanding macro". None of those lines should be printed when the compiled file is loaded. ------- begin test-min-compilation.lisp ------- (macrolet ((m1 () (format t "~&*** Expanding macro 1.~%") '(format t "~&Output of macro 1.~%"))) (m1)) (defconstant +dc+ (macrolet ((m2 () (format t "~&*** Expanding macro 2 inside DEFCONSTANT.~%") '(format t "~&Output of macro 2.~%"))) (m2))) (defparameter *dp* (macrolet ((m3 () (format t "~&*** Expanding macro 3 inside DEFPARAMETER.~%") '(format t "~&Output of macro 3.~%"))) (m3))) (defvar *dv* (macrolet ((m4 () (format t "~&*** Expanding macro 4 inside DEFVAR.~%") '(format t "~&Output of macro 4.~%"))) (m4))) ------- end test-min-compilation.lisp ------- CCL, CLISP, ECL and SBCL print none of the 4, ABCL prints 3 of the 4. This one might be relatively easy, because ABCL is already handling #1 correctly, and just needs to handle #2/3/4 in the same way as #1. The rest of this message is the transcript. $ java -jar abcl-344b4f66.jar Armed Bear Common Lisp 1.8.1-dev Java 1.8.0_272 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.183 seconds. Startup completed in 0.837 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "test-min-compilation.lisp") ; Compiling /tmp/foo/test-min-compilation.lisp ... ; (M1) *** Expanding macro 1. ; (DEFCONSTANT +DC+ ...) *** Expanding macro 2 inside DEFCONSTANT. Output of macro 2. ; (DEFPARAMETER *DP* ...) ; (DEFVAR *DV* ...) ; Wrote /tmp/foo/test-min-compilation.abcl (0.163 seconds) #P"/tmp/foo/test-min-compilation.abcl" NIL NIL CL-USER(2): (load "test-min-compilation.abcl") Output of macro 1. *** Expanding macro 2 inside DEFCONSTANT. Output of macro 2. *** Expanding macro 3 inside DEFPARAMETER. Output of macro 3. *** Expanding macro 4 inside DEFVAR. Output of macro 4. T CL-USER(3): }}} -- Ticket URL: <https://abcl.org/trac/ticket/477> armedbear <https://abcl.org> armedbear

1 1

[armedbear] #476: Wrong file type returned by COMPILE-FILE-PATHNAME
by armedbear 11 Nov '20

11 Nov '20

#476: Wrong file type returned by COMPILE-FILE-PATHNAME -------------------------------+---------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: minor Milestone: 1.8.0 | Component: compiler Version: 1.7.1-dev | Keywords: Parent Tickets: | -------------------------------+---------------------- <https://mailman.common-lisp.net/pipermail/armedbear- devel/2020-October/004147.html> {{{ The code below returns "lx64fsl" in CCL, "fas" in CLISP, and "fasl" in SBCL, but returns "lisp" in ABCL. I think it should return "abcl" in ABCL. $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_272 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.586 seconds. Startup completed in 1.336 seconds. Type ":help" for a list of available commands. CL-USER(1): (pathname-type (compile-file-pathname (make-pathname :name "foo" :type "lisp") :output-file (make-pathname :name "bar"))) "lisp" CL-USER(2): }}} -- Ticket URL: <https://abcl.org/trac/ticket/476> armedbear <https://abcl.org> armedbear

1 6

[armedbear] #475: Loading a FASL into a package which doesn't import SETQ
by armedbear 11 Nov '20

11 Nov '20

#475: Loading a FASL into a package which doesn't import SETQ -------------------------------+--------------------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.0 | Component: compiler Version: 1.7.1-dev | Keywords: fasl loader package Parent Tickets: | -------------------------------+--------------------------------- <https://mailman.common-lisp.net/pipermail/armedbear- devel/2020-October/004145.html> -- Ticket URL: <https://abcl.org/trac/ticket/475> armedbear <https://abcl.org> armedbear

1 5