cmucl issueshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues2024-03-13T02:32:36Zhttps://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/278Add some more debugging prints to gencgc2024-03-08T15:32:08ZRaymond ToyAdd some more debugging prints to gencgcWhile debugging !188, more prints in gencgc were useful. I think they're generally useful for debugging, so let's add these prints.While debugging !188, more prints in gencgc were useful. I think they're generally useful for debugging, so let's add these prints.SnapshotRaymond ToyRaymond Toyhttps://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/232Add wiki entry for how to create a downloadable patch2024-02-20T00:35:38ZRaymond ToyAdd wiki entry for how to create a downloadable patchA long time ago we used to support downloadable patches that could be installed in a running lisp. IIRC, you would download the patch, and add it to your init file to be loaded on startup.
Per https://gitlab.common-lisp.net/cmucl/cmucl...A long time ago we used to support downloadable patches that could be installed in a running lisp. IIRC, you would download the patch, and add it to your init file to be loaded on startup.
Per https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/230#note_12088, we should revive this feature and document how to do it.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/271Update to ASDF 3.3.72024-02-14T19:46:53ZRaymond ToyUpdate to ASDF 3.3.7ASDF 3.3.7 has just been released. Time to update our copy.ASDF 3.3.7 has just been released. Time to update our copy.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/256(loop for var nil from 1 to 2 ...) signals error2024-02-14T19:46:53ZRaymond Toy(loop for var nil from 1 to 2 ...) signals error## Describe the bug
`(loop for var nil from 1 to 2 collect var)` signals an error but the
equivalent `(loop for var of-type nil from 1 to 2 collect var)` does not.
## To Reproduce
Steps to reproduce the behavior:
1. Evaluate `(loop for...## Describe the bug
`(loop for var nil from 1 to 2 collect var)` signals an error but the
equivalent `(loop for var of-type nil from 1 to 2 collect var)` does not.
## To Reproduce
Steps to reproduce the behavior:
1. Evaluate `(loop for var nil from 1 to 2 collect var)` to see the error
2. Evaluate `(loop for var of-type nil from 1 to 2 collect var)` which
produces `(1 2)`.
## Expected behavior
Both should work.
## Desktop (please complete the following information):
- OS: All
- Version: 21e
## Additional context
It's not really clear what a type of `NIL` means in the context of
loop. But since `of-type` works, we should be consistent since the
forms are supposed to be equivalent.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/272Move GC code for static vectors to its own function2024-02-14T19:46:53ZRaymond ToyMove GC code for static vectors to its own functionIn `scavenge`, the last clause handles static vectors (arrays). It would be nicer if this bit of code was moved to its own function to clean things up and make the scavenging of static vectors self-contained.In `scavenge`, the last clause handles static vectors (arrays). It would be nicer if this bit of code was moved to its own function to clean things up and make the scavenging of static vectors self-contained.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/273REBOOT2024-02-03T00:37:30ZAlexander FedorovREBOOThttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/260Command line options -edit and -slave no longer available for Hemlock2024-01-04T16:48:17ZRaymond ToyCommand line options -edit and -slave no longer available for HemlockAs reported on cmucl-help list on 2023/08/31, the `-edit` and `-slave` command line options no longer exist. But as mentioned in [Hemlock user manual](https://cmucl.org/docs/hem/user/hemlock-user.html#edit_002dswitch), they should.
The...As reported on cmucl-help list on 2023/08/31, the `-edit` and `-slave` command line options no longer exist. But as mentioned in [Hemlock user manual](https://cmucl.org/docs/hem/user/hemlock-user.html#edit_002dswitch), they should.
The last version I can test is 18c on linux, and these command-line options don't exist there.
As reported, these are important to running Hemlock.Snapshothttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/190Move unix-setlocale and friends to os.lisp?2023-12-26T23:57:14ZRaymond ToyMove unix-setlocale and friends to os.lisp?As mentioned in #189 and #180, we will or have already moved some items from unix.lisp to os.lisp. A while back we added `unix-setlocale` and friends. The functions call into our C routines instead of directly calling the unix function...As mentioned in #189 and #180, we will or have already moved some items from unix.lisp to os.lisp. A while back we added `unix-setlocale` and friends. The functions call into our C routines instead of directly calling the unix functions.
Should we consider moving these to os.lisp too? This probably also means moving them from the unix package to the system package and renaming the functions to remove the "unix-" prefix.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/266Support "~" in pathnames2023-12-08T21:40:21ZRaymond ToySupport "~" in pathnames## Describe the feature
Add support for "\~" in pathnames, like how shells handle "\~".
This feature was requested by Madhu in a private email to @rtoy (because he also no has access to the mailing list).
## Is there a prototype?
Mad...## Describe the feature
Add support for "\~" in pathnames, like how shells handle "\~".
This feature was requested by Madhu in a private email to @rtoy (because he also no has access to the mailing list).
## Is there a prototype?
Madhu sent a patch for this.
[0001-expand-in-pathnames.patch](/uploads/9992dfad49f5a343e94bd0fb75e99750/0001-expand-in-pathnames.patch)
## Describe the feature in more detail
The basic idea is to have "\~" at the start of a pathname be equivalent to the user's home directory, like how shells work. Madhu says ecl, mkcl, clisp, ccl, and lispworks, at least, support this. It would be a bonus to support "\~user" like shells do, but my own experiments show that ccl just returns `$HOME` and ecl produces some weird error about an unknown user. clisp appears to do the expected thing. This was tested using `(directory "\~games")`, where "games" is a valid user on my linux system.Snapshothttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/261Remove get-system-info from bsd-os.lisp2023-12-08T21:40:20ZRaymond ToyRemove get-system-info from bsd-os.lispbsd-os.lisp still defines `get-system-info`, but the code was moved to
C in #179. Seems like we forgot to remove this version. A
disassembly of `system:get-system-info` on darwin shows that we're
actually using the C function `os_get_s...bsd-os.lisp still defines `get-system-info`, but the code was moved to
C in #179. Seems like we forgot to remove this version. A
disassembly of `system:get-system-info` on darwin shows that we're
actually using the C function `os_get_system_info` as expected.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/252Add script to run ansi-tests2023-12-08T21:40:19ZRaymond ToyAdd script to run ansi-testsWe currently have no easy way to run the ansi-tests locally. You have to know to check out the ansi-test repo, switch to the right branch, and run make in the right way. This is all in .gitlab-ci.yml of course, but it would be nice to ...We currently have no easy way to run the ansi-tests locally. You have to know to check out the ansi-test repo, switch to the right branch, and run make in the right way. This is all in .gitlab-ci.yml of course, but it would be nice to have a script to run these locally.
The issue is where to checkout the ansi-test repo. I think it should **not** be checked out in the cmucl repo. Perhaps `../ansi-tests`.Snapshot-2023-08Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/249Replace (some) uses of LEA instruction with appopriate MOV/SHL2023-12-08T21:40:18ZRaymond ToyReplace (some) uses of LEA instruction with appopriate MOV/SHLConsider replacing LEA instructions with the equivalent MOV/SHL instructions.
The LEA instruction is often used to convert a raw (small) integer to a boxed fixnum by multiplying the integer by 4. The LEA instruction is quite long; it c...Consider replacing LEA instructions with the equivalent MOV/SHL instructions.
The LEA instruction is often used to convert a raw (small) integer to a boxed fixnum by multiplying the integer by 4. The LEA instruction is quite long; it can be replaced by the much shorter sequence of MOV (if necessary) ahd SHL. This is also much easier to understand than the LEA instruction. The MOV can often be free due to register renaming.Snapshot-2023-08Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/247ld warning when making a Linux executable on Fedora 382023-12-08T14:10:04ZRaymond Toyld warning when making a Linux executable on Fedora 38## Describe the bug
Creating a lisp executable on Fedora 38 prints a warning from ld about
deprecated behavior.
## To Reproduce
Steps to reproduce the behavior:
1. Run `lisp -noinit`
2. `(save-lisp "foo" :executable t)
3. See the warnin...## Describe the bug
Creating a lisp executable on Fedora 38 prints a warning from ld about
deprecated behavior.
## To Reproduce
Steps to reproduce the behavior:
1. Run `lisp -noinit`
2. `(save-lisp "foo" :executable t)
3. See the warning that is printed
```
/usr/bin/ld: warning: CORDYN.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: warning: foo has a LOAD segment with RWX permissions
```
## Expected behavior
No warnings should printed
## Desktop (please complete the following information):
- OS: Linux
- Version: 21ehttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/269Add function to OS interface to get a user's home directory2023-11-30T14:57:39ZRaymond ToyAdd function to OS interface to get a user's home directory## Describe the feature
Add function to return user's home directory so can support "\~" and "\~user" in pathnames mentioned in #266.
## Is there a prototype?
No actual prototype is available, but we can unify the OS-dependent parts i...## Describe the feature
Add function to return user's home directory so can support "\~" and "\~user" in pathnames mentioned in #266.
## Is there a prototype?
No actual prototype is available, but we can unify the OS-dependent parts into C.
## Describe the feature in more detail
While we can use `unix-getpwnam` to get the needed information, it
seems a bit overkill to use that when what we really just want is the
home directory. So it's probably best to add an OS function to do
just that. Of course, this function will need to use `getpwnam` to
get the info, but we don't need to expose the full generality of
`getpwnam` for this. And @cshapiro says this makes a lot of sense
since win32 has provided such a function for a long time.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/270Simplify os_file_author interface2023-11-29T23:55:31ZRaymond ToySimplify os_file_author interfaceIn `file-author` we call the alien function `os_file_author` expecting
to an `(alien:* c-call:c-string)` type. But `os_file_author` returns
a C string or NULL. I think we can just use `c-call:c-string` as the
return type instead.
If s...In `file-author` we call the alien function `os_file_author` expecting
to an `(alien:* c-call:c-string)` type. But `os_file_author` returns
a C string or NULL. I think we can just use `c-call:c-string` as the
return type instead.
If so, this gets rid of the compiler note about being unable to
optimize away %SAP-ALIEN and forced to do runtime allocation.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/259system::*software-version* undefined when compiling on linux2023-11-29T22:42:02ZRaymond Toysystem::*software-version* undefined when compiling on linux## Describe the bug
`system::*software-version*` is undefined when compiling on Linux.
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl on linux
2. Look at compile-lisp.log at the end for the warning about the
define...## Describe the bug
`system::*software-version*` is undefined when compiling on Linux.
## To Reproduce
Steps to reproduce the behavior:
1. Compile cmucl on linux
2. Look at compile-lisp.log at the end for the warning about the
defined variable.
## Expected behavior
There should be no warning.
## Desktop (please complete the following information):
- OS: Linux
- Version: 21e
## Additional context
linux-os.lisp accesses `*software-version*` in `os-init`. The package
is "SYSTEM", so `os-init` is setting `system::*software-version*`.
However, we should probably be setting `lisp::*software-version*`
instead.
But also note that in many foo-os.lisp files, there's a `defvar` for
`*software-version*`. We probably didn't update those files when
fixing #120 because we had no way to test them. Notably bsd-os.lisp,
linux-os.lisp and sunos-os.lisp don't have a `defvar`.SnapshotRaymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/265CI for mac os broken2023-11-17T02:44:30ZRaymond ToyCI for mac os brokenNot sure what happened, but CI for mac os is broken. For example, https://gitlab.common-lisp.net/cmucl/cmucl/-/pipelines/9291 no longer passes. But it did pass in https://gitlab.common-lisp.net/cmucl/cmucl/-/pipelines/9243.
I don't kn...Not sure what happened, but CI for mac os is broken. For example, https://gitlab.common-lisp.net/cmucl/cmucl/-/pipelines/9291 no longer passes. But it did pass in https://gitlab.common-lisp.net/cmucl/cmucl/-/pipelines/9243.
I don't know why; there weren't any real changes between the two pipeline runs, and I didn't change the Mac runner.Raymond ToyRaymond Toy