cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2024-03-25T15:48:02Zhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/292Add interface to mkstemp2024-03-25T15:48:02ZRaymond ToyAdd interface to mkstemp## Describe the feature
Add an interface to [mkstemp](https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html)
## Is there a prototype?
None currently, but shouldn't be too hard to make one.
## Describe the feature in mo...## Describe the feature
Add an interface to [mkstemp](https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html)
## Is there a prototype?
None currently, but shouldn't be too hard to make one.
## Describe the feature in more detail
It would be useful to provide this interface. Both clisp and ecl
provide such a Lisp function. Maybe also include an interface to
[tempnam](https://pubs.opengroup.org/onlinepubs/009604599/functions/tempnam.html)
too? Neither clisp nor ecl appear to provide `tempnam`.
Turns out that in the embedded-c contrib, there is an example of using
embedded C with `tempnam`. It also defines `mkdtemp` too.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/291Pprint handler-case better?2024-03-27T14:20:21ZRaymond ToyPprint handler-case better?## Describe the feature
Consider the form:
```
(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%...## Describe the feature
Consider the form:
```
(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%~A"
condition))))
```
When cmucl pprints it, we get:
```
* (pprint '(defun careful-expand-macro (fun form)
(handler-case (invoke-macroexpand-hook fun form *lexical-environment*)
(error (condition)
(compiler-error "(during macroexpansion)~%~A"
condition)))))
(DEFUN CAREFUL-EXPAND-MACRO (FUN FORM)
(HANDLER-CASE (INVOKE-MACROEXPAND-HOOK FUN FORM *LEXICAL-ENVIRONMENT*)
(ERROR (CONDITION)
(COMPILER-ERROR "(during macroexpansion)~%~A" CONDITION))))
```
I think it looks better if the result were:
```
(DEFUN CAREFUL-EXPAND-MACRO (FUN FORM)
(HANDLER-CASE (INVOKE-MACROEXPAND-HOOK FUN FORM *LEXICAL-ENVIRONMENT*)
(ERROR (CONDITION)
(COMPILER-ERROR "(during macroexpansion)~%~A" CONDITION))))
```
That is, the body of the `error` shouldn't be lined up with the arg. It should be indented 2 spaces.
Looking at some examples in the code base, there's a mixe of styles. Some is like the former and some like the latter.
## Is there a prototype?
No. But it should be hard to create a pprinter for this.Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/289Unboxed 64-bit arithmetic2024-03-26T05:06:30ZCarl ShapiroUnboxed 64-bit arithmetic## Describe the feature
CMUCL has support for unboxed arithmetic including values of type `(signed-byte 32)` and `(unsigned-byte 32)`. This support should be extended to include `(signed-byte 64)` and `(unsigned-byte 64)`.
## Is there ...## Describe the feature
CMUCL has support for unboxed arithmetic including values of type `(signed-byte 32)` and `(unsigned-byte 32)`. This support should be extended to include `(signed-byte 64)` and `(unsigned-byte 64)`.
## Is there a prototype?
There is no complete prototype but the support for 32-bit is a partial prototype.
## Describe the feature in more detail
The basic idea is to add compiler transformations to support unboxed double word arithmetic. Looking toward the future, this could be used to support unboxed 128-bit arithmetic on a 64-bit machine. This will benefit any application that needs to perform successive operations on 64-bit values and the performance overhead of allocating bignum objects for the intermediate values is undesirable.https://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/28664-bit cmucl2024-03-22T22:24:13ZRaymond Toy64-bit cmucl## Describe the feature
Make cmucl be a 64-bit app so it can run on modern OSes without having to load 32-bit libraries and tools.
## Is there a prototype?
No.## Describe the feature
Make cmucl be a 64-bit app so it can run on modern OSes without having to load 32-bit libraries and tools.
## Is there a prototype?
No.https://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/281Optimize xoroshiro128** generator2024-03-15T20:50:36ZRaymond ToyOptimize xoroshiro128** generatorAs mentioned in https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/192#note_13890 and nearby comments, our implementation via the VOP is quite a bit slower than the equivalent C code.
We should look into seeing if we can speed ...As mentioned in https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/192#note_13890 and nearby comments, our implementation via the VOP is quite a bit slower than the equivalent C code.
We should look into seeing if we can speed up the implementation. The C code generates reasonably compact code that is quite a bit faster than our SSE2 implementation.
The pure Lisp implementation is about 4.5 times slower than the VOP. Not great but not terrible, considering that I didn't really try too hard to optimize the speed. It would be nice if the pure Lisp version were comparable to the VOP.https://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/262[arch_skip_inst invalid code -55 ]2023-09-09T02:32:37ZRaymond Toy[arch_skip_inst invalid code -55 ]This message appears when I run maxima (using cmucl of course) and start swank and connect to maxima so I can use slime to work easily with lisp code in maxima.
This seems like a pretty serious issue, although I've never run into any pr...This message appears when I run maxima (using cmucl of course) and start swank and connect to maxima so I can use slime to work easily with lisp code in maxima.
This seems like a pretty serious issue, although I've never run into any problems with maxima or slime when this warning occurs. It usually shows up, but not always. I don't know what the conditions are to trigger this message.
To be clear, are the the steps:
1. Start maxima
2. Enter `swank();` (see the script below)
3. In emacs, run `M-x slime-connect` and choose the defaults.
This produces the message where maxima is running.
The script I'm using (place it ~/.maxima/.maxima-init.lisp):
```
(defmfun $swank (&optional (port 4005))
(unless swank-started-p
(setf swank-started-p t)
(let ((slime-dir (merge-pathnames ".emacs.d/elpa/slime-20221003.936/" (user-homedir-pathname))))
(load (merge-pathnames "swank-loader.lisp" slime-dir))
(funcall (intern "INIT" "SWANK-LOADER")
:delete nil ; delete any existing SWANK packages
:reload nil ; reload SWANK, even if the SWANK package already exists
:load-contribs nil) ; load all contribs
(funcall (intern "CREATE-SERVER" "SWANK")
:port port
;; if non-nil the connection won't be closed
;; after connecting
:dont-close nil))))
```
You need to have slime and swank available. I use the version of slime from elpa.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/257Lots of warnings and notes compiling cmucl2023-09-08T16:18:56ZRaymond ToyLots of warnings and notes compiling cmuclThere are lots of warnings and notes when compiling the compiler:
```
; Compilation unit finished.
; 5 warnings
; 76 notes
```
the lisp code:
```
; Compilation unit finished.
; 22 warnings
; 261 notes
```
and pcl code:
```
; Comp...There are lots of warnings and notes when compiling the compiler:
```
; Compilation unit finished.
; 5 warnings
; 76 notes
```
the lisp code:
```
; Compilation unit finished.
; 22 warnings
; 261 notes
```
and pcl code:
```
; Compilation unit finished.
; 2 warnings
; 23 notes
```
Some of these are hard to fix and are actually valid (boxing of numbers), but some could probably be fixed.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/255Consider adding sacla tests2023-09-05T00:06:11ZRaymond ToyConsider adding sacla tests## Describe the feature
Add the sacla tests as shown at http://minejima.jp/lisp/sacla/index-en.html
## Is there a prototype?
No prototype yet.
## Describe the feature in more detail
Sacla has a large set of tests for various lisp funct...## Describe the feature
Add the sacla tests as shown at http://minejima.jp/lisp/sacla/index-en.html
## Is there a prototype?
No prototype yet.
## Describe the feature in more detail
Sacla has a large set of tests for various lisp functions. They seem pretty comprehensive. Clisp has a copy of sacla tests although I did not check to see if the tests are actually used or not.
It's also not clear what kind of overlap we might have with ansi-tests or our own lisp-unit tests, but glancing over some of the files shows that they seem to test a lot of cases.
I did do a simple implementation by reading each form from
[must-cons.lisp](http://minejima.jp/lisp/sacla/html/lisp/test/must-cons.lisp.html)
and wrapped each form in a `define-test` form so that the test can be
run using lisp-unit. This worked for the one file and we passed all
the tests. This would be a good way to include sacla tests within our
test infrastructure.https://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/246Bug in compiler: DEFUN + LET + FUNCTION2023-08-23T02:53:18ZAlexander FedorovBug in compiler: DEFUN + LET + FUNCTION## Describe the bug
`(FUNCTION FOO)` is treated as a constant reference during compilation if there is a `(DEFUN FOO ...)` form inside of the `LET`.
Because of that a variable with a value `#'FOO` is being substituted and thus such a var...## Describe the bug
`(FUNCTION FOO)` is treated as a constant reference during compilation if there is a `(DEFUN FOO ...)` form inside of the `LET`.
Because of that a variable with a value `#'FOO` is being substituted and thus such a variable can "magically change its value without being modified" if `FOO` is redefined inside of the body of the `LET`.
## To Reproduce
In REPL:
```lisp
(funcall (compile
nil
(lambda ()
(defun foo () 'old)
(let ((old-foo #'foo))
(format t "~a vs " (funcall old-foo))
(defun foo () 'new)
(format t "~a~%" (funcall old-foo))))))
; >> OLD vs NEW
```
## Expected behavior
Should've printed "OLD vs OLD"
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
See also SBCL's bug which was inherited from CMUCL [ https://bugs.launchpad.net/sbcl/+bug/1653370 ]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 Boone