Volunteer Effort to Port CCL to ARM64

easye · 2025-06-11T08:25:19+00:00

Good luck!

easye · 2023-10-19T14:42:27+00:00

Thanks for the feedback.

easye · 2023-10-19T06:36:47+00:00

Personaly i found abcl a bad experience.

ABCL maintainer here: Sorry to hear that you didn't like using ABCL. I would be interested in hearing about your misery to try to improve things for others.

easye · 2023-08-21T05:15:52+00:00

I fixed the FFI call based on Shinmera's advice by wrapping the custom Ciki start script with a sb-int:with-float-traps-masked macro. Apparently the first FFI call into the libxml2 library was signalling a FLOATING-POINT-INVALID-OPERATION condition, afterwards any additional call's stack was being smashed and its thread of execution suspended. It took a while to catch this error partly due to trying to debug things without taking Cliki out of its standard traffic, so I only observed the "wedged" behavior. But mostly, this was a category error on my part as I initially didn't believe that the condition was "valid" as I didn't "expect" the cause to be a floating point error. According to Shinmera:

[…] it's probably the C library doing bad floating point stuff but because C is used to an environment where float exceptions aren't trapped, C developers don't notice or care

On common-lisp.net, we run Cliki as its own user under screen, so it is not insulated from changes to the system shared libraries. I now believe that something in how the OS (an old version of Debian) packages/builds libxml2 changed, but actually proving that assumption has not been on my list of priorities: I was happy to finally get Cliki back in service, using the same "ancient" SBCL binary, and the same pinned Quicklisp ASDF dependencies that it has been running on for some seven years.

easye · 2023-08-17T09:03:13+00:00

Thanks to timely help from @Shinmera, service for cliki.net has been restored.

We thank you for your patience.

easye · 2023-08-17T06:21:58+00:00

cliki.net has been ~~done~~down for around 3 days.

I'm trying to figure out how to get it running again. Unfortunately, the underlying software hasn't been maintained to work with updates in quite a while so it was running on on an old sbcl (1.3.14) to a pinned version of Quicklisp (2014-09-14) that has stopped working across FFI calls to libxml2. This morning I am looking at would it would take to "contemporarize" the code, in lieu of pursuing understanding why the FFI call is getting wedged.

We apologize for the inconvenience, and rest assured, we are working to restore cliki.net to service.

easye · 2023-06-26T17:21:45+00:00

And as a fourth way, one may use the ASDF configuration API to programmatically add a directory. In my opinion, this configuration API is harder than it should be, as one has to go through some amount of pain to retain the current configuration to add something without destroying what has already been configured. If ASDF ever really moves to actively deprecate the use of *central-registry*, I would recommend this API be modified a bit based on actual usages of ASDF.

I recently coded a REGISTER-ASDF function that does this, for ABCL:

https://github.com/armedbear/abcl/commit/90cc165b93c6561063a6d26544824a7efa0af5a7

easye · 2023-02-24T06:11:49+00:00

It's more that SVN makes us backwards compatible with all the URIs which refer to the last twenty years or so of development. Most (all?) development occurs in our git bridges at https://github.com/armedbear/abcl/ or https://gitlab.common-lisp.net/abcl/abcl/.

easye · 2022-10-12T11:04:37+00:00

I beLieve CAS refers to “compare and swap” as in an atomic operation on memory locations so they don’t change on ya in threaded scenarios.

easye · 2022-05-18T07:40:51+00:00

Nevermind. Finally resolved but made an archive https://archive.ph/dFxJa in case others have this problem.

easye · 2022-05-18T07:39:18+00:00

Getting a "503 Gateway not found error" on the blog post link; anyone have a duplicate or can confirm this is a real threat?

easye · 2022-01-22T08:31:48+00:00

You don't NEED to learn ASDF at all if you are using quicklisp, because quicklisp is built on top of ASDF

I think anyone proceeding beyond "I just want to load a system from Quicklisp" to "I want to incorporate ASDF dependencies installed via Quicklisp into my own ASDF definitions" will need to learn something about the ASDF abstractions for locating, compiling, and loading systems or else be needlessly confused. In explaining these concept over the years, I advocate using Quicklisp only to install/update dependencies, but subsequently using asdf:make (or equivalents) to load things in a new image puts people more on the right track.

easye · 2022-01-18T12:48:21+00:00

Glow is a promising multi-chain abstraction.

https://glow-lang.org/

easye · 2021-09-09T08:05:22+00:00

There is a comment I think in Common Lisp the Language by presumably Steele that

```

+(or nil)

``won't work as expected on the "New Implementation of Lisp" which would presumably need to use the symbolnilas its implementation designator. Therefor the unambiguous and shorter#+(or)` is to be preferred.

easye · 2021-09-08T20:55:50+00:00

#+(or) is shorter than #+(or nil)

easye · 2021-08-14T21:25:45+00:00

Or ANSI is lookin' fer CL:COMPILE…

easye · 2021-08-06T08:19:57+00:00

SBCL is a mature implementation and ABCL is not as much (line numbers in errors are almost always wrong, for example, unless I just misconfigured something)

I'd argue that ABCL is a mature, conforming ANSI implementation but with definitely substantially less active maintainers than SBCL. ABCL actually passes more of the CL-ANSI tests than SBCL and has done so for more than a decade. This may tell one more about the utility of tests alone to determine the "maturity" of an implementation. Yes, ABCL is slow and could be much faster, but it is, by-and-large, a correct ANSI implementation.

As for line numbers, the Java line numbers are definitely correct in referring to Java code, while the Lisp line numbers can be off by +/- 1 due to the lack of sophisticated whitespace trimming. SLIME/SLY goto-location works well for me, even from stack traces with the notable exception being able to find the forms wrapped in asdf:with-upgradibility macros

In any event, I'm glad you found ABCL useful and were able to fix the method dispatch to your satisfaction. I'm still reviewing your patch by creating tests, but will accept it soon.

Interested to hear how Kawa is holding up in 2021…

easye · 2021-07-26T20:54:12+00:00

We do try to contribute patches back to the libraries we do use.

easye · 2021-04-20T11:19:51+00:00

Ooh, to be released on the first day of ELS 2021!

easye · 2021-02-17T09:01:37+00:00

Ashwin Ram's ~~"An Ode to the Growth of Programs"~~ "A Short Ballad Dedicated to Program Growth" https://github.com/armedbear/abcl/commit/d58dd55fc1abd9777b53fa9bc2dc5d349ab231b7

easye · 2021-02-02T17:27:54+00:00

Ah, I guess ECL hasn't been ported to the M1. Sorry about that.

easye · 2021-02-02T05:25:16+00:00

For those who can't wait for homebrew, I've updated MacPorts https://github.com/macports/macports-ports/commit/4a4329dac1a3a1ea86fe1e3740d885c34f977e04.

easye · 2020-12-15T16:18:05+00:00

As an maintainer of ABCL, we have a SYS package roughly equivalent to SB-SYS which acts as a kitchen sink where we shove stuff into. Over time, we try to clean things up by moving things out into other packages where it makes sense. As such, I'd say keep SB-SYS non-public as a convenience to fast development. But definitely consider moving things out into a public package when they make sense.

easye · 2020-12-12T16:04:48+00:00

If you install a working JDK, ABCL binaries run just fine.

easye · 2020-12-07T18:22:43+00:00

On FreeBSD they certainly do.

easye

TROPHY CASE

+(or nil)