cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2024-03-24T15:09:54Zhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/288Re-enable deftransform for random integers2024-03-24T15:09:54ZRaymond ToyRe-enable deftransform for random integers## Describe the bug
We have a [`deftransform` for word-sized random
integers](src/compiler/float-tran.lisp#L279). This was used for the
MT19937 generator. I think we forgot about this when we implemented
the xoroshiro generator.
We ca...## Describe the bug
We have a [`deftransform` for word-sized random
integers](src/compiler/float-tran.lisp#L279). This was used for the
MT19937 generator. I think we forgot about this when we implemented
the xoroshiro generator.
We can see this if we place this code in a file and compile it to
produce a trace file:
```
(defun zot ()
(random 100000))
```
## To Reproduce
Steps to reproduce the behavior:
1. Compile the above code with `:trace-file t`
2. Look at the trace file. You can see a call to `truncate`.
## Expected behavior
We should be doing a multiply instead of a truncate. Note also that
this is a bug in that `random` uses a
[multiplication](src/code/rand-xoroshiro.lisp#L493). We need to be
consistent between the two code paths. I guess in practice, this is
not so easy to see, but we could probably create a simple test for
this.
## Desktop (please complete the following information):
- OS: All
- Version: Any version after xoroshiro was implemented.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/285Wrong vop used for integer-length of (unsigned-byte 31) number?2024-03-22T17:18:47ZRaymond ToyWrong vop used for integer-length of (unsigned-byte 31) number?## Describe the bug
For some reason we use the `signed-byte-32-int-len` vop when the arg
is an `(unsigned-byte 31)`. Here is a test function:
```
(defun baz (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
...## Describe the bug
For some reason we use the `signed-byte-32-int-len` vop when the arg
is an `(unsigned-byte 31)`. Here is a test function:
```
(defun baz (n)
(declare (type (unsigned-byte 32) n)
(optimize (speed 3)))
(let ((x (ash n -1)))
(values x
(integer-length x)
(integer-length n))))
```
## To Reproduce
Steps to reproduce the behavior:
1. Save the test function in a file and compile it with the
`:trace-file t` option.
2. Examine the trace file.
3. We can see in one case we use the `signed-byte-32-int-len` VOP
## Expected behavior
I was expecting to see the `unsigned-byte-32-int-len` VOP for both
cases.
## Screenshots
If applicable, add screenshots to help explain your problem.
## Desktop (please complete the following information):
- OS: x86
- Version: snapshot-2023-04 and probably earlier
## Additional context
The relevant part of the trace file is:
```
IR2 block start c1
L4:
0: SAP-MOVE t19[S1]>t23[EAX] => t24[S1]<t25[EAX]
1: NOTE-ENVIRONMENT-START {#<NEW-ASSEM:LABEL 5>}
2: FAST-ASH-RIGHT/UNSIGNED=>UNSIGNED N!14[EDX] '1!26 => t27[EAX]
3: WORD-MOVE t27[EAX] => t28[ECX]
4: SIGNED-BYTE-32-LEN t28[ECX] => t29[EDI]
5: UNSIGNED-BYTE-32-LEN N!14[EDX] => t30[ESI]
```
Maybe the solution is to get rid of `signed-byte-32-int-len` VOP and
have the compiler generate a `(lognot x)` when `x` is a negative
number? But I see that sparc and ppc already have both signed and
unsigned versions, so this approach would work for those other archs
as well.
I don't know why the compiler is choosing the signed version of the
vop when the arg type is an `(unsigned-byte 31)`. (You can see this
by doing `(describe 'baz)` and looking at the return types.)Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/282Random floats probably lose a bit of randomness2024-03-23T23:06:29ZRaymond ToyRandom floats probably lose a bit of randomness## Describe the bug
The code to generate random single-float and double-float values loses
a bit of randomness because they smash the bits of an integer into a
float and subtract that float from 1.
As mentioned in the section "Generati...## Describe the bug
The code to generate random single-float and double-float values loses
a bit of randomness because they smash the bits of an integer into a
float and subtract that float from 1.
As mentioned in the section "Generating uniform doubles in the unit
interval" from https://prng.di.unimi.it/, with this method
> *you will be generating half the values you could actually
> generate*.... All doubles generated will have the lowest significand
> bit set to zero
They recommend right shifting the 64-bit random integer by 11 and
multiplying by 2-53 (for doubles).
Since we've changed the generator in #276, perhaps this is also a good
time to change how floats are generated.
## Desktop (please complete the following information):
- OS: All
- Version: 21d and laterhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/280Ansi-test etypecase.15 fails on Darwin with xoroshiro128** RNG2024-03-13T02:32:36ZRaymond ToyAnsi-test etypecase.15 fails on Darwin with xoroshiro128** RNG## Describe the bug
When running the ansi-tests using the branch for !192, the ansi-tests
pass except for one new failure in `etypecase.15`.
## To Reproduce
Steps to reproduce the behavior:
1. Build the code for !192
2. `./bin/run-ansi...## Describe the bug
When running the ansi-tests using the branch for !192, the ansi-tests
pass except for one new failure in `etypecase.15`.
## To Reproduce
Steps to reproduce the behavior:
1. Build the code for !192
2. `./bin/run-ansi-tests.sh -l <lisp>`
3. Look at "../ansi-tests/test.out"
4. See error
## Expected behavior
This used to pass, but presumably this is failing now because the RNG
has changed so that different random tests are being run. For
whatever reason, we don't see this on Linux.
## Desktop (please complete the following information):
- OS: Darwin
- Version: !192
## Additional context
Here's the relevant section of the log:
```
Test ETYPECASE.15 failed
Form: (LET* ((U (COERCE *UNIVERSE* 'VECTOR))
(LEN1 (LENGTH U))
(TYPES (COERCE *CL-ALL-TYPE-SYMBOLS* 'VECTOR))
(LEN2 (LENGTH TYPES)))
(LOOP FOR N = (RANDOM 10)
FOR MY-TYPES = (LOOP REPEAT N COLLECT (ELT TYPES (RANDOM LEN2)))
FOR VAL = (ELT U (RANDOM LEN1))
FOR I = (POSITION VAL MY-TYPES :TEST #'TYPEP)
FOR FORM =
`#'(LAMBDA (X)
(HANDLER-CASE
(ETYPECASE X
(LISP::BACKQ-COMMA-AT
(LOOP FOR I FROM 0
FOR TYPE IN MY-TYPES
COLLECT `(,TYPE ,I))))
(TYPE-ERROR (C) (ASSERT (EQL X (TYPE-ERROR-DATUM C)))
(LET* ((EXPECTED (TYPE-ERROR-EXPECTED-TYPE C)))
(FORMAT T
,"expected ~S my-types ~S~%"
EXPECTED
'(OR ,@MY-TYPES))
(LET ((EQUIV
(CHECK-EQUIVALENCE EXPECTED
'(OR ,@MY-TYPES))))
(ASSERT (NULL EQUIV) NIL "EQUIV = ~A" EQUIV)))
NIL)))
FOR J = (FUNCALL (EVAL FORM) VAL)
REPEAT 200
UNLESS (EQL I J) COLLECT (LIST N MY-TYPES VAL I FORM J)))
Expected value:
NIL
Actual value:
#<SIMPLE-ERROR {4AD61D3D}> [
Error in function LISP::ASSERT-ERROR:
EQUIV = (((SUBTYPEP
'(NOT
(OR PATHNAME
BOOLEAN
STANDARD-CHAR
STANDARD-OBJECT
CHARACTER
FILE-ERROR))
'(NOT
(OR FILE-ERROR
CHARACTER
STANDARD-OBJECT
STANDARD-CHAR
BOOLEAN
PATHNAME)))
==> NIL T))]
```
I think this is a new legitimate failure; cmucl doesn't handle the
`subtypep` correctly. We do know that cmucl is not so good at
handling subtypes using `not`, although it's been a long time since I
looked at such things.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/279Extra instruction in generated code for (ldb (byte 3 29) x)2024-03-08T21:39:19ZRaymond ToyExtra instruction in generated code for (ldb (byte 3 29) x)## Describe the bug
There appears to be an extra instruction in computing `(ldb (byte 3
29) x)`, which gets the top 3 bits of a 32-bit number.
The test function is
```
(defun hi3 (x)
(declare (type (unsigned-byte 32) x)
(optimize...## Describe the bug
There appears to be an extra instruction in computing `(ldb (byte 3
29) x)`, which gets the top 3 bits of a 32-bit number.
The test function is
```
(defun hi3 (x)
(declare (type (unsigned-byte 32) x)
(optimize (speed 3) (safety 0)))
(ldb (byte 3 (- 32 3)) x))
```
## To Reproduce
Steps to reproduce the behavior:
1. Put the test function above in a file, say "hi3.lisp"
2. `(compile-file "hi3" :load t :trace-file t)
3. `(disassemble 'hi3)` or look at the trace file.
## Expected behavior
The disassembly shows, in part:
```
a6: L1: shr edx, #x1d ; No-arg-parsing entry point
; [:non-local-entry]
a9: and edx, #x7
ac: shl edx, #x2
```
So we correctly did a logical right shift of 29 bits to move the high
3 bits to the lowest 3 bits of the register. But then we `and` that
with 7. There's no need to do this `and` operation since we're
shifting out the top 3 bits of the 32-bit integer.
Probably a deficiency in `ldb` not recognizing that we've shifted in
zeroes. If, say, we weren't getting the top 3 bits, then the `and`
operation would be needed to clear out the bits we don't want.
Definitely needed for something like `(ldb (byte 3 20 x)`.
This is pretty minor micro optimization that we could do.
## Desktop (please complete the following information):
- OS: All x86
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/267walker:macroexpand-all doesn't macroexpand symbol-macros passed in environment2023-11-09T00:34:29ZAlexander Fedorovwalker:macroexpand-all doesn't macroexpand symbol-macros passed in environment## Description
`walker:macroexpand-all` doesn't expand symbol-macros when its definition is contained in the lexical environment passed (both global symbol-macros and local symbol-macros).
## "Mega" test
Here is a test for 6 possible ...## Description
`walker:macroexpand-all` doesn't expand symbol-macros when its definition is contained in the lexical environment passed (both global symbol-macros and local symbol-macros).
## "Mega" test
Here is a test for 6 possible cases where macro expansion should happen:
```common-lisp
;; utility macro
(defmacro at-compile-time ((&optional env) &body body)
(let ((capture (gensym)))
`(macrolet ((,capture (,@(when env `(&environment ,env)))
,@body))
(,capture))))
(defmacro NO-1 () ''YES-1)
(define-symbol-macro NO-4 'YES-4)
(macrolet ((NO-3 () ''YES-3))
(symbol-macrolet ((NO-6 'YES-6))
(at-compile-time (env)
`',(walker:macroexpand-all
'(macrolet ((NO-2 () ''YES-2))
(symbol-macrolet ((NO-5 'YES-5))
(values (NO-1) (NO-2) (NO-3) NO-4 NO-5 NO-6)))
env))))
```
The produced expansion:
```common-lisp
(MACROLET ((NO-2 ()
''YES-2))
(SYMBOL-MACROLET ((NO-5 'YES-5))
(VALUES 'YES-1 'YES-2 'YES-3 NO-4 'YES-5 NO-6)))
```
Expected expansion:
```common-lisp
(MACROLET ((NO-2 ()
''YES-2))
(SYMBOL-MACROLET ((NO-5 'YES-5))
(VALUES 'YES-1 'YES-2 'YES-3 'YES-4 'YES-5 'YES-6)))
```
## "Mini" tests
Smaller tests for those two cases where macroexpansion doesn't happen:
```common-lisp
(define-symbol-macro macroexpand-all-test-1 'expanded)
(walker:macroexpand-all 'macroexpand-all-test-1)
; => MACROEXPAND-ALL-TEST-1
```
```common-lisp
(symbol-macrolet ((macroexpand-all-test-2 'expanded))
(macrolet ((thunk (&environment env)
`',(walker:macroexpand-all
'macroexpand-all-test-2
env)))
(thunk)))
; => MACROEXPAND-ALL-TEST-2
```
## Additional information
Comparison of `macroexpand-all` provided by different implementations (using a portability layer, `trivial-macroexpand-all`): https://plaster.tymoon.eu/view/4009#4009
SBCL, CCL and ABCL expand (symbol-)macros in all 6 cases.
Allegro CL, LispWorks and CLISP expand macros in 4 cases; not accepting an additional environment argument.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/264Conformance issue: COMPILER-MACRO-FUNCTION2023-10-24T21:30:11ZAlexander FedorovConformance issue: COMPILER-MACRO-FUNCTION## Describe the bug
While it is documented that "if the name is ... declared NOTINLINE, NIL is returned" from the `compiler-macro-function`, it would seem that it is violates the standard.
The hyperspec page for notinline declaration sa...## Describe the bug
While it is documented that "if the name is ... declared NOTINLINE, NIL is returned" from the `compiler-macro-function`, it would seem that it is violates the standard.
The hyperspec page for notinline declaration says that
> a notinline declaration prevents that compiler macro from being used
But doesn't says that it shadows the compiler macro. So the *function name* that was declared notinline still should be naming both a *function* and a *compiler macro*; and thus `compiler-macro-function` should not return nil, as per entry for compiler-macro-function:
> A value of nil denotes the absence of a compiler macro function named name.
## To Reproduce
```lisp
(defun foo ())
; => FOO
(define-compiler-macro foo ())
; => FOO
(declaim (notinline foo))
; => NIL
(compiler-macro-function 'foo)
; => NIL
```
## Expected behavior
The call to `compiler-macro-function` should have returned a function.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
This change was introduced in commit https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/e69992175ccdcd7f895cff99752b809057c615df while fixing issue https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/3
This causes an issue in alexandria's tests: https://gitlab.common-lisp.net/alexandria/alexandria/-/issues/37
SBCL, CCL, Allegro CL, ECL, CLASP, ABCL, CLISP and LispWorks all return a function in this case.
CLHS links:
http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_ma.htm#compiler-macro-function
http://www.lispworks.com/documentation/HyperSpec/Body/d_inline.htm#notinlinehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/263:ALLOW-OTHER-KEYS in compiled code2023-10-17T13:34:31ZAlexander Fedorov:ALLOW-OTHER-KEYS in compiled code## Describe the bug
`:allow-other-keys` is not handled correctly in compiled code when a key argument with the name `allow-other-keys` is present.
## To Reproduce
```lisp
;; This should return 10, but signals an error:
(funcall (compile...## Describe the bug
`:allow-other-keys` is not handled correctly in compiled code when a key argument with the name `allow-other-keys` is present.
## To Reproduce
```lisp
;; This should return 10, but signals an error:
(funcall (compile nil '(lambda (&key allow-other-keys) allow-other-keys)) :allow-other-keys 10 :foo 20)
; Unknown keyword: :FOO
; [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
```
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/251c-call:char should have the same signedness as C char2023-09-05T00:06:05ZRaymond Toyc-call:char should have the same signedness as C char## Describe the bug
Currently `c-call:char` is a signed char. But to match C, `c-call:char` should have the same signedness as a C `char`. In particular, this means it should be unsigned for RISC-V, PowerPC, and ARM (among others). (S...## Describe the bug
Currently `c-call:char` is a signed char. But to match C, `c-call:char` should have the same signedness as a C `char`. In particular, this means it should be unsigned for RISC-V, PowerPC, and ARM (among others). (See https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/157#note_12484).
## Expected behavior
`c-call:char` should match C `char` signedness.
## Desktop (please complete the following information):
- OS: All
- Version: 21e (and earlier)https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/243Weak pointer to static array2024-03-13T23:00:31ZAlexander FedorovWeak pointer to static array## Describe the bug
Weak pointer to a static vector is not "broken" when the vector is deallocated.
## To Reproduce
```lisp
(defparameter *ref*
(let ((vec (make-array 1000000 :element-type '(unsigned-byte 8)
...## Describe the bug
Weak pointer to a static vector is not "broken" when the vector is deallocated.
## To Reproduce
```lisp
(defparameter *ref*
(let ((vec (make-array 1000000 :element-type '(unsigned-byte 8)
:initial-element 1
:allocation :malloc)))
(extensions:make-weak-pointer vec)))
; => *ref*
(gc :full T)
; => NIL
(setf *print-length* 10)
; => 10
(format t "~a~%" (extensions:weak-pointer-value *ref*))
; => error is signalled:
;; Error in function UNIX::SIGSEGV-HANDLER:
;; Segmentation Violation at #x10204283.
;; [Condition of type SIMPLE-ERROR]
```
## Expected behavior
Last form should output NIL.
## Desktop (please complete the following information):
- OS: Linux
- CPU: x86
- Version: 21eRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/241Bug in compiler/PCL2023-06-25T16:51:05ZAlexander FedorovBug in compiler/PCL## Describe the bug
Compiler fails to define a method for a class with undefined superclass.
## To Reproduce
Save the following code to file:
```lisp
;;;; clos-bug.lisp
(defclass a (b)
((x :initarg :x :reader x)))
(defmethod print-o...## Describe the bug
Compiler fails to define a method for a class with undefined superclass.
## To Reproduce
Save the following code to file:
```lisp
;;;; clos-bug.lisp
(defclass a (b)
((x :initarg :x :reader x)))
(defmethod print-object ((a a) stream)
(format stream "[~a]" (x a)))
```
In REPL:
```lisp
(compile-file "path/to/clos-bug.lisp")
(load "path/to/clos-bug.sse2f")
;; Signals error:
; The slot PCL:CLASS-PRECEDENCE-LIST is unbound in the object
; #<STANDARD-CLASS A {6007B63D}>.
; [Condition of type UNBOUND-SLOT]
;; After abort:
(compile-file "path/to/clos-bug.lisp")
(load "path/to/clos-bug.sse2f")
;; => T
```
## Expected behavior
It should not signal an error the first time.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21eJon BooneJon Boonehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/238Compiler bug2023-06-09T20:42:54ZAlexander FedorovCompiler bug## Describe the bug
When compiling the following code:
```lisp
(declaim (inline f))
(defun f (a)
(check-type a unsigned-byte)
a)
(defun g ()
(let ((a 0))
(flet ((h ())
(k (&optional b)
(f a)))
(h...## Describe the bug
When compiling the following code:
```lisp
(declaim (inline f))
(defun f (a)
(check-type a unsigned-byte)
a)
(defun g ()
(let ((a 0))
(flet ((h ())
(k (&optional b)
(f a)))
(h))))
```
Compiler signals an error:
```lisp
; Byte Compiling Top-Level Form:
; Byte Compiling Top-Level Form:
; Converted F.
; Compiling DEFUN F:
; Converted G.
Error in function LISP::ASSERT-ERROR:
The assertion (EQ (C::FUNCTIONAL-KIND (C::LAMBDA-HOME C::FUN))
:TOP-LEVEL) failed.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [CONTINUE] Retry assertion.
1: [ABORT ] Return to Top-Level.
Debug (type H for help)
(LISP::ASSERT-ERROR (EQ (C::FUNCTIONAL-KIND #) :TOP-LEVEL) NIL NIL)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/macros.lisp.
0]
```
## To Reproduce
Save the code above to a file (say "test.lisp") and run
```bash
cmucl -eval '(compile-file "cmucl-flet-bug.lisp")'
```
## Expected behavior
A clear and concise description of what you expected to happen.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e and 21dhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/237Can't inline structure slot accessor2023-06-09T20:43:12ZAlexander FedorovCan't inline structure slot accessor## Describe the bug
After the structure is defined, declaiming slot accessor to be inline signals an error:
```
Error in function C::NOTE-IF-ACCESSOR:
Redefining slot accessor STRUCT-SLOT for structure type STRUCT
```
This affects lo...## Describe the bug
After the structure is defined, declaiming slot accessor to be inline signals an error:
```
Error in function C::NOTE-IF-ACCESSOR:
Redefining slot accessor STRUCT-SLOT for structure type STRUCT
```
This affects loading systems with asdf since it compiles files and then loads them. If one declaims a structure slot accessor to be inline, the project can't be loaded with cmucl.
## To Reproduce
In REPL:
```lisp
(defstruct struct slot)
(declaim (inline make-struct struct-slot))
; Error in function C::NOTE-IF-ACCESSOR:
; Redefining slot accessor STRUCT-SLOT for structure type STRUCT
; [Condition of type SIMPLE-ERROR]
;
; Restarts:
; 0: [CONTINUE] Assume redefinition is compatible and allow it
; 1: [RETRY] Retry SLIME REPL evaluation request.
; 2: [*ABORT] Return to SLIME's top level.
; 3: [ABORT] Return to Top-Level.
;
; Backtrace:
; 0: (C::NOTE-IF-ACCESSOR STRUCT-SLOT)
; 1: (KERNEL:DEFINE-FUNCTION-NAME STRUCT-SLOT)
; 2: (PROCLAIM (INLINE STRUCT-SLOT))
; 3: (PROCLAIM 1 (INLINE STRUCT-SLOT))[:EXTERNAL]
; 4: (EVAL (DECLAIM (INLINE STRUCT-SLOT)))
; ... (swank/slime related)
```
## Expected behavior
The condition shouldn't be signaled, slot accessor should be declaimed inline.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/235Debugger uses :iso8859-12023-06-02T22:55:11ZRaymond ToyDebugger uses :iso8859-1## Describe the bug
The debugger apparently uses `:iso8859-1` for the external format.
## To Reproduce
Steps to reproduce the behavior:
1. See [debug.lisp#752](src/code/debug.lisp#L752)
## Expected behavior
Now that we have `:utf-8` b...## Describe the bug
The debugger apparently uses `:iso8859-1` for the external format.
## To Reproduce
Steps to reproduce the behavior:
1. See [debug.lisp#752](src/code/debug.lisp#L752)
## Expected behavior
Now that we have `:utf-8` builtin and is the default, we should consider switching the encoding to `:utf-8`. I guess another alternative is to use `:locale` instead to get whatever the locale is.
## Desktop (please complete the following information):
- OS: All
- Version: 21e and much earlier
## Additional context
Don't think I've ever run into a problem with this in the debugger, but maybe because I'm not using the debugger when non-ascii characters are used.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/230clear-input takes two args instead of one.2024-02-20T00:36:40ZRaymond Toyclear-input takes two args instead of one.## Describe the bug
`clear-input` accepts two args, but the spec says it takes exactly one
optional arg for the stream.
## To Reproduce
Steps to reproduce the behavior:
1. `(clear-input *standard-input* nil)`
2. This does not signal an ...## Describe the bug
`clear-input` accepts two args, but the spec says it takes exactly one
optional arg for the stream.
## To Reproduce
Steps to reproduce the behavior:
1. `(clear-input *standard-input* nil)`
2. This does not signal an error like it should.
## Expected behavior
This is basically the same issue as #143, except it's for
`clear-input` instead of `listen.` Presumably the same kind of
solution can be used.
## Desktop (please complete the following information):
- OS: All
- Version: 21e (and earlier)
## Additional context
This is from the
[ansi-tests](https://gitlab.common-lisp.net/cmucl/ansi-test) named
[`CLEAR-INPUT.ERROR.1`](https://gitlab.common-lisp.net/cmucl/ansi-test/-/blob/master/streams/clear-input.lsp#L44)
and
[`CLEAR-INPUT.ERROR.2`](https://gitlab.common-lisp.net/cmucl/ansi-test/-/blob/master/streams/clear-input.lsp#L49).
But note also that these tests are marked with the note
`:assume-no-simple-streams`. So we could easily fix the test failures
by disabling this note in the tests which would mean these tests would
not be run at all.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/227New ansi-test failures2023-05-20T23:40:44ZRaymond ToyNew ansi-test failures## Describe the bug
After updating ansi-tests from the upstream version, there are new test failures.
## To Reproduce
Steps to reproduce the behavior:
1. Check out the latest code from cmucl/ansi-tests
2. Run `make LISP="lisp -noinit -n...## Describe the bug
After updating ansi-tests from the upstream version, there are new test failures.
## To Reproduce
Steps to reproduce the behavior:
1. Check out the latest code from cmucl/ansi-tests
2. Run `make LISP="lisp -noinit -nositeinit"`
3. See the final output
## Expected behavior
No unexpected failures
## Screenshots
```
...
Test DEFINE-METHOD-COMBINATION-LONG.01.2 failed
Form: (PROGN
(EVAL
'(DEFMETHOD DMC-LONG-GF-01 ((X T) (Y T))
:FOO))
(HANDLER-CASE (EVAL '(DMC-LONG-GF-01 'A 'B)) (ERROR NIL :CAUGHT)))
Expected value:
:CAUGHT
Actual value:
NIL
est DEFINE-METHOD-COMBINATION-LONG.11.2 failed
Form: (PROGN
(EVAL
'(DEFMETHOD DMC-LONG-GF-11A ()
'A))
(VALUES (DMC-LONG-GF-11A)))
Expected value:
#(NIL :Y1 NIL NIL :Z1 NIL A)
Actual value:
#<UNBOUND-VARIABLE {624D13D5}> [Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable Y1-SUPPLIED is unbound.]
Test DEFINE-METHOD-COMBINATION-LONG.11.3 failed
Form: (PROGN
(EVAL
'(DEFMETHOD DMC-LONG-GF-11B ((X (EQL 1)) &OPTIONAL Y &KEY Z1)
'A))
(EVAL
'(DEFMETHOD DMC-LONG-GF-11B ((X INTEGER) &OPTIONAL (Y 2) &KEY Z1)
'B))
(VALUES (DMC-LONG-GF-11B 0)
(DMC-LONG-GF-11B 1)
(DMC-LONG-GF-11B 0 0)
(DMC-LONG-GF-11B 1 1)
(DMC-LONG-GF-11B 1 1 :Z1 4)))
Expected values:
#(0 :Y1 NIL NIL :Z1 NIL B)
#(1 :Y1 NIL NIL :Z1 NIL A B)
#(0 0 T NIL :Z1 NIL B)
#(1 1 T NIL :Z1 NIL A B)
#(1 1 T (:Z1 4) 4 T A B)
Actual value:
#<UNBOUND-VARIABLE {61D5824D}> [Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable Y1-SUPPLIED is unbound.]
Test DEFINE-METHOD-COMBINATION-LONG.11.4 failed
Form: (PROGN
(EVAL
'(DEFMETHOD DMC-LONG-GF-11C ((X (EQL 1)) &OPTIONAL Y &REST R1)
'A))
(EVAL
'(DEFMETHOD DMC-LONG-GF-11C ((X INTEGER) &OPTIONAL (Y 2) &REST R1)
'B))
(VALUES (DMC-LONG-GF-11C 0)
(DMC-LONG-GF-11C 1)
(DMC-LONG-GF-11C 0 0)
(DMC-LONG-GF-11C 1 1)
(DMC-LONG-GF-11C 1 1 2 3)))
Expected values:
#(0 :Y1 NIL NIL :Z1 NIL B)
#(1 :Y1 NIL NIL :Z1 NIL A B)
#(0 0 T NIL :Z1 NIL B)
#(1 1 T NIL :Z1 NIL A B)
#(1 1 T (2 3) :Z1 NIL A B)
Actual value:
#<UNBOUND-VARIABLE {61DC80BD}> [Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable Y1-SUPPLIED is unbound.]
...
4 unexpected failures: DEFINE-METHOD-COMBINATION-LONG.01.2,
DEFINE-METHOD-COMBINATION-LONG.11.2, DEFINE-METHOD-COMBINATION-LONG.11.3,
DEFINE-METHOD-COMBINATION-LONG.11.4.
No unexpected successes.
```
## Desktop (please complete the following information):
- OS: [e.g. Linux]
- Version: 21e
## Additional context
These new failures are being marked as expected failures in ansi-tests
for now. But we should investigate why these tests are failing; it
could be a simple fix.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/225create-target.sh doesn't update setenv with the appropriate OS features.2023-05-17T23:53:39ZRaymond Toycreate-target.sh doesn't update setenv with the appropriate OS features.## Describe the bug
At the end of `bin/create-target.sh` there's a bit of code that copies
`linux-features.lisp` (or `freebsd-features.lisp`) to `setenv.lisp` in
the target directory. This isn't working.
## To Reproduce
Steps to reprod...## Describe the bug
At the end of `bin/create-target.sh` there's a bit of code that copies
`linux-features.lisp` (or `freebsd-features.lisp`) to `setenv.lisp` in
the target directory. This isn't working.
## To Reproduce
Steps to reproduce the behavior:
1. Run `bin/create-target.sh test-target x86_linux`
2. Examine `test-target/setenv.lisp`
3. Compare this with `src/tools/setenv-scripts/linux-features.lisp`
4. The contents of `linux-features.lisp` aren't anywhere in `setenv.lisp`.
## Expected behavior
Based on the code, the file should be copied. But note that
`linux-features.lisp` doesn't really do anything except remove
`:glib2.1` from `*features*`.
One item to note is that `create-target.sh` adds `:gencgc` to
`*features*`, apparently to enable gencgc. This bit is commented out,
however, so it doesn't actually add it. x86 uses gencgc by default
and has for at least decade.
## Desktop (please complete the following information):
- OS: Linux, FreeBSD, Solaris
- Version:
## Additional context
Not sure what to do here. Fix it so that the files are copied. This
is easily done by remove the part `>> setenv.lisp`. Or just remove
this and the corresponding feature files. The latter is appealing.
It's been so long that I've had to touch these, I don't really
remember what to do with them. However, this might be an easy way to
re-enable cgc (see #224) instead of having to do a full cross-compile.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/223cmucl.pot and cmucl-unix.pot conflict when built on darwin and linux2023-06-17T23:00:50ZRaymond Toycmucl.pot and cmucl-unix.pot conflict when built on darwin and linux## Describe the bug
The cmucl.pot and cmucl-unix.pot files conflict when built on Darwin and Linux, possibly other OSes.
## To Reproduce
Steps to reproduce the behavior:
1. Build cmucl on Darwin
2. Build cmucl on Linux
3. Compare cmucl....## Describe the bug
The cmucl.pot and cmucl-unix.pot files conflict when built on Darwin and Linux, possibly other OSes.
## To Reproduce
Steps to reproduce the behavior:
1. Build cmucl on Darwin
2. Build cmucl on Linux
3. Compare cmucl.pot and cmucl-unix.pot
4. The two builds want to change cmucl.pot and cmucl-unix.pot in
different places
## Expected behavior
Building on Darwin and Linux should not cause conflicting contents for
cmucl.pot and cmucl-unix.pot. Perhaps the solution is adding new pot
files for OS-specific differences for cmucl.pot and cmucl-unix.pot.
## Desktop (please complete the following information):
- OS: Darwin and Linux
- Version: snapshot-2023-04
## Additional context
We could just choose to make one of Darwin or Linux have the canonical
version. This is kind of ok. I think the issue would be that there
would either be no translation of other OSes or an incorrect
translation at all. Of course, this doesn't matter too much because
we don't really have any translations except for the machine-generated
pig-latin translation.
The other issue is if we choose, say, Linux, then building on Darwin
creates modified cmucl.pot and cmucl-unix.pot files which causes
`git describe` (used for determining the version string) to say
"dirty". The version string has to be specified manually or the
modified files need to be reverted and run load-world.sh again. (I
think).https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/194Error when trying to load a Quicklisp library using the byte code compiler2023-05-05T19:16:53ZAlejandro Zamora FonsecaError when trying to load a Quicklisp library using the byte code compilerWhen trying to load a Quicklisp library (for the example I'm using _cl-ppcre_, but couldn't run any other library) I got this error:
With the native compiler I can load the libraries without any issue
```
alejandrozf@ThinkBook-15-G2-IT...When trying to load a Quicklisp library (for the example I'm using _cl-ppcre_, but couldn't run any other library) I got this error:
With the native compiler I can load the libraries without any issue
```
alejandrozf@ThinkBook-15-G2-ITL:~$ cmucl
; Loading #P"/home/alejandrozf/.cmucl-init.lisp".
;; Loading #P"/home/alejandrozf/quicklisp/setup.lisp".
;;; Loading #P"/home/alejandrozf/Downloads/cmucl-21d-x86-linux/lib/cmucl/lib/contrib/asdf/asdf.sse2f".
CMU Common Lisp 21d (21D Unicode), running on ThinkBook-15-G2-ITL
With core: /home/alejandrozf/Downloads/cmucl-21d-x86-linux/lib/cmucl/lib/lisp-sse2.core
Dumped on: Sat, 2018-12-08 15:04:17-03:00 on lorien3
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.6
* c::*byte-compile*
T
* c::*byte-compile-default*
T
* c::*byte-compiling*
T
* (ql:quickload :cl-ppcre)
To load "cl-ppcre":
Load 1 ASDF system:
asdf
Install 1 Quicklisp release:
cl-ppcre
; Fetching #<URL
"http://beta.quicklisp.org/archive/cl-ppcre/2022-02-20/cl-ppcre-20220220-git.tgz">
; 153.70KB
==================================================
157,392 bytes in 0.10 seconds (1537.03KB/sec)
; Loading "cl-ppcre"
[package cl-ppcre].
Error in function LISP::ASSERT-ERROR:
The assertion (ZEROP
(HASH-TABLE-COUNT (C::FASL-FILE-PATCH-TABLE C::FILE))) failed.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [CONTINUE ] Retry assertion.
1: [RETRY ] Retry
compiling #<CL-SOURCE-FILE "cl-ppcre" "specials">.
2: [ACCEPT ] Continue, treating
compiling #<CL-SOURCE-FILE "cl-ppcre" "specials">
as having been successful.
3: Retry ASDF operation.
4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
configuration.
5: [ABORT ] Give up on "cl-ppcre"
6: [REGISTER-LOCAL-PROJECTS ] Register local projects and try again.
7: Return to Top-Level.
Debug (type H for help)
(LISP::ASSERT-ERROR (ZEROP (HASH-TABLE-COUNT #)) NIL NIL)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/macros.lisp.
0]
```https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/188Inconsistency in disassembler printing numbers for error traps2023-04-19T15:17:02ZRaymond ToyInconsistency in disassembler printing numbers for error traps## Describe the bug
We are somewhat inconsistent in how the error trap codes are always printed in hex, with `#x` marker.
## To Reproduce
Steps to reproduce the behavior:
1. Compile this: `(defun bar (x) (declare (double-float x)) (sin ...## Describe the bug
We are somewhat inconsistent in how the error trap codes are always printed in hex, with `#x` marker.
## To Reproduce
Steps to reproduce the behavior:
1. Compile this: `(defun bar (x) (declare (double-float x)) (sin x))`
2. `(disassemble 'bar)`
3. Look at the end of the disassembly to see the `.byte`:
```
c060: L3: ud1 ecx, edx ; Trap 10: Error trap
c063: .byte #x02
c064: .byte #x1a ; INVALID-ARGUMENT-COUNT-ERROR
c065: .byte #x4f ; ECX
```
4. Now try `(disassem:disassemble 'bar :base 8)`
5. The error trap doesn't honor the base; it's always printed as hex.
The other numerical constants in the disassembly are printed in
octal. Almost. We do have:
```
c019: call #o13700000010 ; #x5f000008: alloc_overflow_sse2
```
## Expected behavior
I think we purposely decided (when adding ud1 support) to print the
bytes in hex with a radix marker. I think historically they were
always printed this way. It was in 18d.
But should the base be honored?
Note that if !135 lands, then the radix marker will be printed by default.
## Desktop (please complete the following information):
- OS: Linux (and probably all others)
- Version: snapshot-2021-07 to at least 18d.
## Additional context
Should we honor the base for printing out the error trap constants?
Should notes also honor the base?