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

Re: [armedbear] #391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\*
by armedbear 28 May '21

28 May '21

#391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\* -------------------------+------------------------------------------------- Reporter: Mark | Owner: Mark Evenson Evenson | Type: defect | Status: accepted Priority: | Milestone: 1.8.1 critical | Component: | Version: 1.5.0-dev interpreter | Keywords: cl:probe-file ext:probe-directory Resolution: | cl:directory Parent Tickets: | -------------------------+------------------------------------------------- Comment (by Mark Evenson): Don Morrison notes in <https://mailman.common-lisp.net/pipermail /armedbear-devel/2021-May/004197.html> {{{ I don’t think I have the ability to comment on bugs in the issue tracker, or, if I do, I’ve not figured out how to do it. I hope sending mail to this list for the purpose is acceptable; apologies if not. I note that #391 was opened six years ago, but remains unfixed, and, apart from apparently being pushed off from release to release, seems not to have received any love for four years. I just wanted to add a note to it that it is still being encountered in the wild, and is, at least in one user’s case, causing some pain. File names containing asterisks may not be a good idea, but sometimes we have no control over the names of files we are given. It also means at least one (uiop:subdirectories), and probably many, UIOP functions sometimes fail in what can appear to be mysterious ways on ABCL, but not other implementations. }}} -- Ticket URL: <https://abcl.org/trac/ticket/391#comment:17> armedbear <https://abcl.org> armedbear

1 0

[armedbear] #486: Deployments from abcl-aio.jar can't find ABCL-CONTRIB
by armedbear 10 May '21

10 May '21

#486: Deployments from abcl-aio.jar can't find ABCL-CONTRIB -------------------------------+---------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: other Version: 1.8.1-dev | Keywords: abcl-aio Parent Tickets: | -------------------------------+---------------------- <https://github.com/armedbear/abcl/issues/372> {{{ I ran into this when I combined abcl.jar and abcl-contrib.jar together on the classpath via Maven, but it's more directly reproduced with an AIO jar: ant -f build.xml abcl-aio.jar ... java -jar dist/abcl-aio.jar --noinform CL-USER(1): (require :abcl-contrib) ("uiop" "UIOP" "asdf" "ASDF" "JAVA" "ABCL-CONTRIB") CL-USER(2): (require :jss) #<THREAD "interpreter" {66BA4A3B}>: Debugger invoked on condition of type SIMPLE-ERROR Don't know how to REQUIRE JSS. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): My suspicion is that the resolution of the JSS system is dependent on the colocation of abcl.jar and abcl-contrib.jar on the filesystem. When I run ABCL via java -jar abcl.jar in a directory that also contains abcl- contrib.jar, it works. }}} -- Ticket URL: <https://abcl.org/trac/ticket/486> armedbear <https://abcl.org> armedbear

1 1

[armedbear] #484: Restore asdf:bundle-op
by armedbear 19 Feb '21

19 Feb '21

#484: Restore asdf:bundle-op -------------------------------+---------------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: ASDF Version: 1.8.1-dev | Keywords: asdf:bundle-op Parent Tickets: | -------------------------------+---------------------------- charles reports on irc that <https://gist.github.com/charJe/cffca389c5e6ffcd65c07a171ae2f5f6#file- asdf-monolith> is an example of how badly ASDF bundle-op is failing. -- Ticket URL: <https://abcl.org/trac/ticket/484> armedbear <https://abcl.org> armedbear

1 2

[armedbear] #483: Failed JVM:OFFSET assertion compiling Maxima <file:///maxima-code/share/odepack/load-dlsode.lisp>
by armedbear 23 Dec '20

23 Dec '20

#483: Failed JVM:OFFSET assertion compiling Maxima <file:///maxima- code/share/odepack/load-dlsode.lisp> -------------------------------+---------------------- Reporter: Mark Evenson | Type: defect Status: new | Priority: major Milestone: 1.8.1 | Component: compiler Version: 1.8.1-dev | Keywords: Parent Tickets: | -------------------------------+---------------------- In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2020-December/004192.html> Robert Dodier writes: {{{ I know it may be hard to see what's going on but, I'm trying to load a lisp file into Maxima compiled with ABCL, and I get the error shown below: The assertion (<= -32768 JVM::OFFSET 32767) failed. I've also included a stack trace if that helps. I can supply more info if you tell me what to look for. Thanks so much for your help, Robert Dodier PS. This is in a Maxima session after compiling and launching Maxima. (%i1) :lisp (load "../share/odepack/load-dlsode.lisp") ; (IN-PACKAGE "ODEPACK") ; (LET (# # ...) ...) Error loading /Users/dodier/tmp/maxima-code/share/odepack/load-dlsode.lisp at line 25 (offset 770) #<THREAD "interpreter" {19E01A93}>: Debugger invoked on condition of type SIMPLE-ERROR The assertion (<= -32768 JVM::OFFSET 32767) failed. Restarts: 0: CONTINUE Retry assertion. 1: MACSYMA-QUIT Maxima top-level 2: TOP-LEVEL Return to top level. [1] ODEPACK(5): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<SIMPLE-ERROR {6789AA04}>) 2: (ERROR #<SIMPLE-ERROR {6789AA04}>) 3: (SYSTEM::ASSERT-ERROR (<= -32768 JVM::OFFSET 32767) NIL NIL) 4: (JVM::CODE-BYTES #<(VECTOR T 18397) {4783535E}>) 5: (JVM::FINALIZE-CODE-ATTRIBUTE #<JVM::CODE-ATTRIBUTE {43CBA720}> NIL #<JVM::ABCL-CLASS-FILE {67BB799A}>) 6: (JVM::FINALIZE-ATTRIBUTES (#<JVM::CODE-ATTRIBUTE {43CBA720}>) NIL #<JVM::ABCL-CLASS-FILE {67BB799A}>) 7: (JVM::FINALIZE-METHOD #<JVM::JVM-METHOD {72946D27}> #<JVM::ABCL-CLASS-FILE {67BB799A}>) }}} -- Ticket URL: <https://abcl.org/trac/ticket/483> armedbear <https://abcl.org> armedbear

1 0

[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