cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2021-02-06T20:01:26Zhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/101Maxima gets overflow with latest snapshot 2021-012021-02-06T20:01:26ZRaymond ToyMaxima gets overflow with latest snapshot 2021-01Building maxima with the latest snapshot-2021-01 works fine, but
running the testsuite produces 3 errors that didn't happen with
snapshot 2020-04. The overflow comes from `airy_ai(2.0)`, which calls
`slatec::daie`. The error is
```
Ari...Building maxima with the latest snapshot-2021-01 works fine, but
running the testsuite produces 3 errors that didn't happen with
snapshot 2020-04. The overflow comes from `airy_ai(2.0)`, which calls
`slatec::daie`. The error is
```
Arithmetic error FLOATING-POINT-OVERFLOW signalled.
Operation was *, operands (1.7976931348623157e308 NIL).
[Condition of type FLOATING-POINT-OVERFLOW]
Restarts:
0: [MACSYMA-QUIT] Maxima top-level
```
The backtrace points to
```
(EXPT (F2CL-LIB:D1MACH 2) 0.6666)
```
This can be reproduced by:
```
(require :f2cl)
(make-package "SLATEC")
(setf *read-default-float-format* 'double-float)
(dolist (f '("initds" "dcsevl" "d9aimp" "daie"))
(compile-file f :load t))
(slatec::daie 2d0)
```
The listed files come from the `src/numerical/slatec` directory from
maxima's sources.
A disassemble of`slatec::daie` appears to be essentially the same
between snapshot 2020-04 and 2021-01. The differences are the
address of the static vars for allocation, and the addresses of the
code constants. 2021-01 removed some static symbols so the address
changes are expected.
I have no idea what the problem could be; there weren't that many
changes between 2020-04 and 2021-01.Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/47Backquote and multiple splices2018-12-17T02:50:09ZMark CoxBackquote and multiple splicesThere is a bug in how backquote processes multiple splices.
```lisp
(read-from-string "`(,@vars ,@vars)")
=>
`((,@vars) (,@vars))
16
```
```
$ cmucl
CMU Common Lisp snapshot-2017-10 (21b Unicode), running on something
With core: /opt/...There is a bug in how backquote processes multiple splices.
```lisp
(read-from-string "`(,@vars ,@vars)")
=>
`((,@vars) (,@vars))
16
```
```
$ cmucl
CMU Common Lisp snapshot-2017-10 (21b Unicode), running on something
With core: /opt/lisps/lib/cmucl/lib/lisp-sse2.core
Dumped on: Tue, 2017-10-10 12:08:17+10:00 on gondor.local
See <http://www.cmucl.org/> for support information.
Loaded subsystems:
Unicode 1.29 with Unicode version 6.2.0
Python 1.1, target Intel x86/sse2
CLOS based on Gerd's PCL 2010/03/19 15:19:03
ASDF 3.3.0
$ uname -v
Darwin Kernel Version 16.7.0: Wed Oct 4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64
```Snapshot 2018-02https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/45Handling of relative paths in `ext:run-program`2017-12-30T06:20:50ZElias PippingHandling of relative paths in `ext:run-program`- Such invocations work because the executable is given as an absolute path:
```common-lisp
* (ext:run-program "/bin/ls" '("tmp") :wait t :output t)
ls_copy ls_link
#<EXTENSIONS::PROCESS 30087 :EXITED :EXIT-CODE 0 {58152ADD}>
```
- S...- Such invocations work because the executable is given as an absolute path:
```common-lisp
* (ext:run-program "/bin/ls" '("tmp") :wait t :output t)
ls_copy ls_link
#<EXTENSIONS::PROCESS 30087 :EXITED :EXIT-CODE 0 {58152ADD}>
```
- Such invocations work because the executable is a single word that can be found via lookup
```common-lisp
* (ext:run-program "ls" '("tmp") :wait t :output t)
ls_copy ls_link
#<EXTENSIONS::PROCESS 30088 :EXITED :EXIT-CODE 0 {581566DD}>
```
- Such invocations **however do not work** because they contain a relative path to an executable and (...?)
```common-lisp
* (ext:run-program "./tmp/ls_copy" '("tmp") :wait t :output t)
Error in function RUN-PROGRAM: No such program: "./tmp/ls_copy"
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(RUN-PROGRAM "./tmp/ls_copy" ("tmp/ls_copy" "tmp") :ENV NIL ...)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/run-program.lisp.
0] 0
*
```
This is rather odd in that cmucl appears to be the only implementation I tested to have trouble with this case.
@frideau and I had already talked about it here: https://bugs.launchpad.net/asdf/+bug/171367221cRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/41Report proper process status2017-12-30T06:20:50ZElias PippingReport proper process statusNow that #26 is taken care of (I tested that the behaviour is now as expected), one might want to try and make `process-status` useful.
Here's a bit of code that repeatedly sends a process to sleep and wakes it up again:
```common-lisp
...Now that #26 is taken care of (I tested that the behaviour is now as expected), one might want to try and make `process-status` useful.
Here's a bit of code that repeatedly sends a process to sleep and wakes it up again:
```common-lisp
;; CMUCL: make sure to use a version >21b (not yet released as of 2017-94-04)
;; because of https://gitlab.common-lisp.net/cmucl/cmucl/issues/26
;; ECL: make sure to use a version >16.1.3 (not yet released as of 2017-09-04)
;; because of https://gitlab.com/embeddable-common-lisp/ecl/issues/273
#+clozure (use-package :ccl)
#+sbcl (use-package :sb-ext)
#+cmu (use-package :ext)
#+mkcl (use-package :mk-ext)
#+clozure (setf (fdefinition 'process-output) #'external-process-output-stream)
#+ecl (setf (fdefinition 'process-output) #'ext:external-process-output)
(defun my-run-program (&rest rest)
#+ecl (nth-value 2 (apply #'ext:run-program rest))
#+mkcl (nth-value 1 (apply #'mk-ext:run-program rest))
#-(or ecl mkcl) (apply #'run-program rest))
(defconstant +sigstop+
#+clozure (symbol-value (read-from-string "#$SIGSTOP"))
#+cmu unix:sigstop
#+ecl ext:+sigstop+
#+sbcl (progn (require :sb-posix)
(symbol-value (find-symbol (symbol-name :sigstop)
(find-package :sb-posix))))
#-(or clozure cmu ecl sbcl) (or #+darwin 17 #-darwin 19)) ; FIXME
(defconstant +sigtstp+
#+clozure (symbol-value (read-from-string "#$SIGTSTP"))
#+cmu unix:sigtstp
#+ecl ext:+sigtstp+
#+sbcl (progn (require :sb-posix)
(symbol-value (find-symbol (symbol-name :sigtstp)
(find-package :sb-posix))))
#-(or clozure cmu ecl sbcl) (or #+darwin 18 #-darwin 20)) ; FIXME
(defconstant +sigcont+
#+clozure (symbol-value (read-from-string "#$SIGCONT"))
#+cmu unix:sigcont
#+ecl ext:+sigcont+
#+sbcl (progn (require :sb-posix)
(symbol-value (find-symbol (symbol-name :sigcont)
(find-package :sb-posix))))
#-(or clozure cmu ecl sbcl) (or #+darwin 19 #-darwin 18)) ; FIXME
(defun internal-status (process)
#+clozure (external-process-status process)
#+(or sbcl cmu) (process-status process)
#+ecl (ext:external-process-status process)
#+mkcl (mk-ext:process-status process))
(defun external-kill (pid signal)
(my-run-program "/usr/bin/env" (list "kill"
(format nil "-~a" signal)
(format nil "~a" pid))))
(defun get-pid (process)
#+clozure (ccl::external-process-pid process)
#+ecl (ext:external-process-pid process)
#+(or sbcl cmu) (process-pid process)
#+mkcl (mkcl:process-id process))
(let* ((p (my-run-program "/bin/sleep" '("5") :wait nil))
(pid (get-pid p)))
(format t "internal status: ~a (expected: running)~%" (internal-status p))
(external-kill pid +sigstop+)
(sleep 1)
(format t "internal status: ~a (expected: stopped)~%" (internal-status p))
(external-kill pid +sigcont+)
(sleep 1)
(format t "internal status: ~a (expected: running/resumed)~%" (internal-status p))
(external-kill pid +sigstop+)
(sleep 1)
(format t "internal status: ~a (expected: stopped)~%" (internal-status p))
(external-kill pid +sigcont+)
(sleep 1)
(format t "internal status: ~a (expected: running/resumed)~%" (internal-status p))
(sleep 5)
(format t "internal status: ~a (expected: exited)~%" (internal-status p)))
```
A recent git checkout (from the *develop* branch) of ECL e.g. handles this as expected:
```
internal status: RUNNING (expected: running)
internal status: STOPPED (expected: stopped)
internal status: RESUMED (expected: running/resumed)
internal status: STOPPED (expected: stopped)
internal status: RESUMED (expected: running/resumed)
internal status: EXITED (expected: exited)
```
CMUCL, meanwhile, unfortunately does not:
```
internal status: RUNNING (expected: running)
internal status: STOPPED (expected: stopped)
internal status: STOPPED (expected: running/resumed)
internal status: STOPPED (expected: stopped)
internal status: STOPPED (expected: running/resumed)
internal status: EXITED (expected: exited)
```https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/26The cmucl that never sleeps2017-09-04T14:43:52ZElias PippingThe cmucl that never sleepsThere's something odd going on with `ext:run-program` and `sleep`. Please consider the following snippet (considerably reduced from what I started with):
```common-lisp
#+clozure (use-package :ccl)
#+cmu (use-package :ext)
#+sbcl (us...There's something odd going on with `ext:run-program` and `sleep`. Please consider the following snippet (considerably reduced from what I started with):
```common-lisp
#+clozure (use-package :ccl)
#+cmu (use-package :ext)
#+sbcl (use-package :sb-ext)
(time (sleep 5))
(let ((p (run-program "/usr/bin/env" '("sleep" "1") :wait nil)))
(declare (ignore p))
(time (sleep 5)))
```
For me, this prints:
```
; Evaluation took:
; 5.01 seconds of real time
; 0.0 seconds of user run time
; 0.0 seconds of system run time
; 16,479,138,228 CPU cycles
; 0 page faults and
; 0 bytes consed.
;
; Evaluation took:
; 1.02 seconds of real time
; 0.0 seconds of user run time
; 0.0 seconds of system run time
; 3,340,346,852 CPU cycles
; 0 page faults and
; 8 bytes consed.
;
```
But that doesn't make any sense. A 5-second sleep should always take 5 seconds. Somehow the background process is interfering with `sleep`. The issue is with `sleep`, not with `time` here: The whole script returns a lot earlier than it should. With SBCL and Clozure CL, both sleeps take 5 seconds each.snapshot-2016-12https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/2Coercing lambda forms to functions and compilation.2017-07-08T07:17:48ZMark CoxCoercing lambda forms to functions and compilation.Compile time and coercing lambda forms to functions.
The CMUCL compiler signals an error when compiling code that coerces a
lambda form to a function. The compiler appears to perform the
coercion at compile time and then fails to du...Compile time and coercing lambda forms to functions.
The CMUCL compiler signals an error when compiling code that coerces a
lambda form to a function. The compiler appears to perform the
coercion at compile time and then fails to dump the resulting function
in to the fasl file.
The code below illustrates the issue.
;; /tmp/cmucl.lisp
;; $ cmucl -noinit -eval '(compile-file "/tmp/cmucl.lisp")'
(defun my-funcall (a)
(print a))
(my-funcall (coerce '(lambda () (print "hello'"))
'function))
;; Output
; Python version 1.1, VM version Intel x86/sse2 on 2015-03-21 08:58:17.
; Compiling: /private/tmp/cmucl.lisp 2015-03-21 08:58:11
; Converted MY-FUNCALL.
; Compiling DEFUN MY-FUNCALL:
; Byte Compiling Top-Level Form:
;
;
; File: /private/tmp/cmucl.lisp
; In: MY-FUNCALL (COERCE '(LAMBDA # #) 'FUNCTION)
; (COERCE '(LAMBDA # #) 'FUNCTION)
; --> VALUES PROG1 LET
; ==>
; '#<Interpreted Function (LAMBDA # #) {480513E9}>
; Error: Cannot dump objects of type EVAL:INTERPRETED-FUNCTION into fasl files.
;
; (MY-FUNCALL (COERCE '# 'FUNCTION))
; Note: Deleting unreachable code.
;
; Compilation unit finished.
; 1 error
; 1 note
; /tmp/cmucl.sse2f written.
; Compilation finished in 0:00:00.
CMU Common Lisp snapshot-2014-12 (20F Unicode), running on me.local
With core: /home/me/local/lib/cmucl/lib/lisp-sse2.core
Dumped on: Sat, 2015-01-03 21:50:20+10:00 on me.local
See <http://www.cmucl.org/> for support information.
Loaded subsystems:
Unicode 1.29 with Unicode version 6.2.0
Python 1.1, target Intel x86/sse2
CLOS based on Gerd's PCL 2010/03/19 15:19:03
*
Thanks
Mark
https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/23Function with declared result type NIL returned.2017-07-08T07:17:48ZMark CoxFunction with declared result type NIL returned.I think there may be an issue with the way CMUCL handles return values.
I'm having trouble developing a reduced test case so I have attached the code I encountered the issue with. The code relies on an external library titled externa...I think there may be an issue with the way CMUCL handles return values.
I'm having trouble developing a reduced test case so I have attached the code I encountered the issue with. The code relies on an external library titled external-program.
I'm using cumcl-2016-06-x86-darwin.
I can't find any proclamations, declamations, declarations or THE forms associated with the generic function external-program:start.
Thanks
[issue.lisp](/uploads/b44453deac900d2a48bc482e8f29dc9e/issue.lisp)https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/20building from source2017-03-27T06:32:35ZDaniel Kochmańskibuilding from sourceI had a problem when building CMUCL from source (following "simple builds" from `BUILDING`) , because it requires `Xm/Xm.h` header. Installing `openmotif` fixed the problem.
Steps to reproduce:
build CMUCL from source without openmot...I had a problem when building CMUCL from source (following "simple builds" from `BUILDING`) , because it requires `Xm/Xm.h` header. Installing `openmotif` fixed the problem.
Steps to reproduce:
build CMUCL from source without openmotif headers
Proposed solution:
mention the dependency in `BUILDING` or remove that dependencyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/22Incorrect coercion to float2017-03-27T06:32:35ZRaymond ToyIncorrect coercion to floatConsider
```
(defun c (x)
(coerce x 'float))
(compile 'c)
```
Then `(c 4d0)` returns `4.0`. But since `4d0` is already a `float`, the correct answer should be `4d0`. Same thing happens with `(c 4w0)`.Consider
```
(defun c (x)
(coerce x 'float))
(compile 'c)
```
Then `(c 4d0)` returns `4.0`. But since `4d0` is already a `float`, the correct answer should be `4d0`. Same thing happens with `(c 4w0)`.snapshot-2016-06Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/24Compilation of (compile 'foo).2017-03-27T06:32:35ZMark CoxCompilation of (compile 'foo).The form `(compile 'foo)`in the code below appears to be compiled as `(compile foo)`.
```lisp
;; $ cmucl -noinit -eval '(load (compile-file "issue.lisp"))'
(defun foo ()
(print "Hello world"))
(compile 'foo)
;; Generates ...The form `(compile 'foo)`in the code below appears to be compiled as `(compile foo)`.
```lisp
;; $ cmucl -noinit -eval '(load (compile-file "issue.lisp"))'
(defun foo ()
(print "Hello world"))
(compile 'foo)
;; Generates the following error.
;;
;; Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable FOO is unbound.
;; [Condition of type UNBOUND-VARIABLE]
;; Lisp implementation type CMU Common Lisp
;; Lisp implementation version snapshot-2016-02 (21a Unicode)
;; Machine type X86
;; Machine version X86
;; Software type Darwin
;; Software version 14.5.0
```https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/25Issue with ext:run-program and string streams (related to character sizes?)2017-03-27T06:32:35ZElias PippingIssue with ext:run-program and string streams (related to character sizes?)I’ve been trying to launch an external process and pass input to it from a string.
I’ve ended up with the following code which I think qualifies as a minimal
example if you don’t count the debugging statements:
```common-lisp
(let* (...I’ve been trying to launch an external process and pass input to it from a string.
I’ve ended up with the following code which I think qualifies as a minimal
example if you don’t count the debugging statements:
```common-lisp
(let* ((in-string (format nil "A line.~%And another.~%")))
(with-output-to-string (out-stream nil)
(with-input-from-string (in-stream in-string)
(ext:run-program "cat" nil
:wait t
:input in-stream
:output out-stream))
(let ((out-string (get-output-stream-string out-stream)))
(format t "Do the lengths match? ~a~%"
(= (length in-string) (length out-string)))
(format t "Do the contents match? ~a~%"
(string= in-string out-string))
(format t "Type of the in-string: ~a~%" (type-of in-string))
(format t "Type of the out-string: ~a~%" (type-of out-string))
(format t "This is what we sent:~%=====~%~a=====~%" in-string)
(format t "This is what we received:~%=====~%~a=====~%" out-string))))
```
What it’s supposed to do is pass the string
```
A line.
And another.
```
to `cat` and print out the result, which should be the same string. That works for the
most part but not entirely. The output I get is:
```
Do the lengths match? T
Do the contents match? NIL
Type of the in-string: (SIMPLE-BASE-STRING 21)
Type of the out-string: (SIMPLE-BASE-STRING 21)
This is what we sent:
=====
A line.
And another.
=====
This is what we received:
=====
A li
And an
=====
```
Two lines are received, but only their first half. Indeed, if I make that input lines longer,
the output lines become longer as well. I would assume that this is down to a mix of
character types of different sizes somewhere but I’ve been unable to get this code to
work. So in particular I’m not sure if I’m doing something wrong or if this is a bug in
cmucl (the example works with sbcl and ccl but I might still be doing something wrong).Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/27Regression: ASDF test failures2017-03-27T06:32:34ZElias PippingRegression: ASDF test failuresI have not had the time to look into what goes wrong here but I've just found that two ASDF tests are failing with today's master branch of cmucl (revision 5beb6431855908e9010c36bc9aeaa57b0daebcf3) that pass with cmucl-21a.
Please exp...I have not had the time to look into what goes wrong here but I've just found that two ASDF tests are failing with today's master branch of cmucl (revision 5beb6431855908e9010c36bc9aeaa57b0daebcf3) that pass with cmucl-21a.
Please expect more information shortly, I'm just hoping for this to block any release that might be in the making.
The failing tests are `asdf-pathname-test.script` and `test-logical-pathname.script`. They can be run from within an ASDF checkout e.g. via
```shell
make; make ext; CMUCL=cmucl-21a ./test/run-tests.sh cmucl asdf-pathname-test.script test-logical-pathname.script
```
where `cmucl-21a` is the name of the cmucl executable in my case.
**Update**: In both cases, the test fails because of a *Control stack overflow*.snapshot-2016-09Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/15Failure to print floating-point-inexact exception2016-05-08T16:12:04ZRaymond ToyFailure to print floating-point-inexact exceptionOn OSX, with current HEAD (with arithmetic-error printer that disables exceptions),
```
(ext:with-float-traps-enabled (:inexact)
(asinh least-positive-double-float))
```
Causes the following error message:
```
Unable to displa...On OSX, with current HEAD (with arithmetic-error printer that disables exceptions),
```
(ext:with-float-traps-enabled (:inexact)
(asinh least-positive-double-float))
```
Causes the following error message:
```
Unable to display error condition
[Condition of type FLOATING-POINT-INEXACT]
```
Strangely, if I recompile the define-condition, the error is handled correctly:
```
Arithmetic error FLOATING-POINT-INEXACT signalled.
Operation was +, operands (1.7014118e38 1.0).
[Condition of type FLOATING-POINT-INEXACT]
```
https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/14(asinh 0d0) signals inexact on linux2016-05-08T16:12:04ZRaymond Toy(asinh 0d0) signals inexact on linuxThe following should not signal inexact but it does:
```
(let ((x 0d0))
(ext:with-float-traps-enabled (:inexact)
(asinh x)))
```
The following should not signal inexact but it does:
```
(let ((x 0d0))
(ext:with-float-traps-enabled (:inexact)
(asinh x)))
```
https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/12unable to build master/$HEAD with 2015-12 darwin snapshot2016-05-08T16:12:03ZJon Booneunable to build master/$HEAD with 2015-12 darwin snapshotHost: MacBook Pro running Mac OS X 10.11.2 (El Capitan, with XCode 7.2)
* Issued the following command: bin/build.sh -C "" -o "$HOME/bin/cmucl/bin/lisp"
* It built darwin-2 with no problems, but during the darwin-3, attempting to ...Host: MacBook Pro running Mac OS X 10.11.2 (El Capitan, with XCode 7.2)
* Issued the following command: bin/build.sh -C "" -o "$HOME/bin/cmucl/bin/lisp"
* It built darwin-2 with no problems, but during the darwin-3, attempting to load irrat.sse2f, yielded this error:
```/$HOME/src/cmucl/darwin-3/code/irrat.sse2f
Error in function LISP::FOP-EVAL-FOR-EFFECT:
Attempt to load a file having a compile-time read error.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [CONTINUE] Skip this form.
1: Return NIL from load of #<Stream for file "/$HOME/src/cmucl/darwin-3/code/irrat.sse2f">.
2: Return NIL from load of "target:tools/worldbuild".
3: [ABORT ] Return to Top-Level.
Debug (type H for help)
(LISP::FOP-EVAL-FOR-EFFECT)
Source:
; File: target:code/load.lisp
(EVAL (POP-STACK))
0]https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/4ELT on lists does not signal an error when given an invalid index.2015-08-01T20:24:20ZMark CoxELT on lists does not signal an error when given an invalid index.The accessor ELT does not signal an error when given an invalid
index.
(let ((f (compile nil '(lambda (list)
(declare (type list list)
(optimize (speed 1) (saf...The accessor ELT does not signal an error when given an invalid
index.
(let ((f (compile nil '(lambda (list)
(declare (type list list)
(optimize (speed 1) (safety 1) (compilation-speed 1) (space 1) (debug 1)))
(elt list 3)))))
(funcall f (list 0 1 2)))
=> nil
An error is signalled when performing one of the following:
1. SAFETY is changed to 3.
2. The type LIST is changed to SEQUENCE.
Thanks
Mark