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/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/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/224Consider building with cgc instead of gencgc for x86.2023-05-17T23:53:41ZRaymond ToyConsider building with cgc instead of gencgc for x86.## Describe the feature
Consider building x86 with cgc instead of gencgc.
## Is there a prototype?
Yes, there is a working prototype. Before gencgc, x86 used cgc to
implement the garbage collector. Perhaps it would be useful to verify...## Describe the feature
Consider building x86 with cgc instead of gencgc.
## Is there a prototype?
Yes, there is a working prototype. Before gencgc, x86 used cgc to
implement the garbage collector. Perhaps it would be useful to verify
that this still works.
## Describe the feature in more detail
Enable building cmucl/x86 using the cgc garbage collector. I think
this will require a cross-compile, possibly, to switch the GC because
we need to remove FEATURE_GENCGC from internals.h so that we'll build
with cgc.c instead of gencgc.c. But maybe a special bootstrap file
will be enough.
I don't think we'll generally ship a binary with cgc, but we can have
CI build this and run tests, just to make sure cgc still works.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/181Consider moving unidata.bin into (read-only) C memory2023-03-31T14:30:34ZRaymond ToyConsider moving unidata.bin into (read-only) C memory## Describe the feature
Move unidata.bin into C to make more of unicode available in kernel.core.
## Is there a prototype?
None. This is a fairly large change.
## Describe the feature in more detail
This was mentioned in https://gitla...## Describe the feature
Move unidata.bin into C to make more of unicode available in kernel.core.
## Is there a prototype?
None. This is a fairly large change.
## Describe the feature in more detail
This was mentioned in https://gitlab.common-lisp.net/cmucl/cmucl/-/merge_requests/113#note_11026 as a way to make the unicode database available early in the build process to simplify the support of Darwin file name normalization.
The current issue is that the unicode functions aren't compiled in the kernel.core which would need to be available to support Darwin pathnames. Moving unidata.bin to C resolves that issue. Then we'd only need to have relatively simple functions to access the C structures as needed to get the unicode stuff needed in the kernel.core. The remaining stuff can be loaded with the full core.Provide more information to describe the feature.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/158Filename encodings on Darwin2023-03-24T15:19:41ZRaymond ToyFilename encodings on Darwin## Describe the feature
Use correct filename encoding on Darwin
## Is there a prototype?
No.
## Describe the feature in more detail
I think the general plan is to change the default filename encoding
from `:iso8859-1` to `:utf-8` every...## Describe the feature
Use correct filename encoding on Darwin
## Is there a prototype?
No.
## Describe the feature in more detail
I think the general plan is to change the default filename encoding
from `:iso8859-1` to `:utf-8` everywhere. This should work fine on
Linux, FreeBSD, and Solaris.
But Darwin is quite complicated.
Some links explaining how it's done:
1. https://developer.apple.com/library/archive/technotes/tn/tn1150.html#UnicodeSubtleties
1. https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html
1. https://web.archive.org/web/20140812023313/http://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/Articles/FileEncodings.html
1. https://eclecticlight.co/2021/05/08/explainer-unicode-normalization-and-apfs/
In particular the third link says
> Mac OS Extended (HFS+) uses canonically decomposed Unicode 3.2 in UTF-16 format, which consists of a sequence of 16-bit codes. (Characters in the ranges U2000-U2FFF, UF900-UFA6A, and U2F800-U2FA1D are not decomposed.)
Presumably on x86 machines it's UTF-16 little-endian.
The first link says
> In addition, the Korean Hangul characters with codes in the range
> u+AC00 through u+D7A3 are illegal and must be replaced with the
> equivalent sequence of conjoining jamos, as described in the Unicode
> 2.0 book, section 3.10.
This makes it pretty complicated. For now maybe it's good enough just
to do UTF-16.
However, I think we're using `:iso8859-1` which seems to work, so I'm
not really sure how this works at all....https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/144String comparison functions vs user manual2022-10-14T22:43:29ZRaymond ToyString comparison functions vs user manual## Describe the feature
In the [user manual for unicode strings](https://cmucl.common-lisp.dev/docs/cmu-user/html/Methods-for-Strings.html), the functions `string=` and friends use codepoints for comparison. However, the actual implemen...## Describe the feature
In the [user manual for unicode strings](https://cmucl.common-lisp.dev/docs/cmu-user/html/Methods-for-Strings.html), the functions `string=` and friends use codepoints for comparison. However, the actual implementation, for example, [`string=*`](src/code/string.lisp#L253) appears to just use the 16-bit code unit instead. I'm guessing that when we moved the additional functionality of string casing function from the CL package to the Unicode package, we lost this.
If that is true (or not), we should probably add versions to compare via codepoints. If we don't, then characters beyond the BMP may compare in a funny way, and equivalent surrogates may compare as different because surrogate pairs can be in either order.
Similar problems occur for `string-equal` and friends. We should also support a `:casing` keyword to allow simple or full downcasing of the strings before comparing.
Lastly, the section says `string-trim` and friends handle surrogates. But this seems not the case, looking at the functions in [string.lisp](src/code/string.lisp#L923).
## Is there a prototype?
No prototype is available, unless we accidentally removed it as mentioned above.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/139Change default to utf8 for external formats and file encodings2023-03-25T23:43:57ZRaymond ToyChange default to utf8 for external formats and file encodings## Describe the feature
Change the default external format from `:iso8859-1` to `:utf-8`. Same for the filename encoding.
## Is there a prototype?
There's no prototype, but I think this should work since we've
included `:utf-8` as part...## Describe the feature
Change the default external format from `:iso8859-1` to `:utf-8`. Same for the filename encoding.
## Is there a prototype?
There's no prototype, but I think this should work since we've
included `:utf-8` as part of the default image now for quite some time.
Could probably be done by changing the default values of
`*default-external-format*` and `*filename-encoding*` to `:utf-8`.
## Describe the feature in more detail
I think it's time to use utf8 everywhere in cmucl now instead of
`:iso8859-1`. We just have to make sure that when this change is made,
cmucl can still build itself from a binary with this change.snapshot-2023-04Raymond ToyRaymond Toyhttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/126Simplifying unix interface2022-08-04T01:56:27ZRaymond ToySimplifying unix interface## Describe the feature
The unix interface in "unix.lisp" is really complicated and depends a lot on carefully defined structures that are system-dependent. It would simplify things a lot if we had a simple C interface that called the u...## Describe the feature
The unix interface in "unix.lisp" is really complicated and depends a lot on carefully defined structures that are system-dependent. It would simplify things a lot if we had a simple C interface that called the unix function and returned various slots directly. Then we can rip out a lot of the complexity in "unix.lisp" and make the file much shorter and much simpler that works for all OSes.
## Is there a prototype?
You can find a prototype in !85 where we take care of `stat` and friendshttps://gitlab.common-lisp.net/cmucl/cmucl/-/issues/114clm and hemlock uses tiny fonts2021-09-20T23:46:02ZRaymond Toyclm and hemlock uses tiny fonts## Describe the feature
Using hemlock or clm, the fonts for the window is pretty small when running on a 4K monitor. Probably pretty small even for a full HD display. Perhaps it's time to make the default fonts larger. Or maybe detect...## Describe the feature
Using hemlock or clm, the fonts for the window is pretty small when running on a 4K monitor. Probably pretty small even for a full HD display. Perhaps it's time to make the default fonts larger. Or maybe detect the display size and user a larger font.https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/83Use SSSE3 instructions2020-04-19T17:40:48ZRaymond ToyUse SSSE3 instructionsSSSE3 was introduced in 2006, 14 years ago. Let's require SSSE3 when running cmucl now. We can then use a few new instructions that are beneficial like popcnt (for logcount) and horizontal add/sub (for complex double-float multiply).SSSE3 was introduced in 2006, 14 years ago. Let's require SSSE3 when running cmucl now. We can then use a few new instructions that are beneficial like popcnt (for logcount) and horizontal add/sub (for complex double-float multiply).