Content from 2022-01
CL Community(?) Norms
posted on 2022-01-17 18:00:00 UTC
In case you haven't seen it, the ASDF maintainer is considering resigning. The reason is pretty straightforward: continued antagonization toward the ASDF team from a prominent CL developer (and maintainer of a number of widely used libraries) and the seeming acceptance of this by the CL community.
The only other forum I'm aware of that's discussing this is this Reddit thread. However, I found most of the conversation in that thread simultaneously depressing and wildly missing the point. So I decided to take advantage of this space to speak my thoughts clearly, plainly, and without interruption or other noise surrounding them.
Side note: if you know of some other place this is being discussed, I'd love to know. Bonus points if it's not a SOS's pool.
CL-TAR v0.2.0
posted on 2022-01-04 23:00:00 UTC
I just released the first version of
cl-tar
(previously). That I consider to have the minimum
set of features necessary to make it usable and useful.
Unfortunately, there seems to be something wrong with the Gitlab Pages setup for its documentation so you can't see the very beautiful docs :(. I'll update this post when it's fixed. For now, the README will likely give you everything you need to know, particularly the Quickstart section.
This release brings:
- transparent gzip compression and decompression
- convenience function for creating an archive from the file system, while preserving hard links, symlinks, block and character devices, fifos, and most metadata ({a,c,m}time, uname, gname, uid, gid). And, yes, sym and hardlinks are preserved even on Windows!
- A precompiled executable for Linux AMD64. This implements extraction and creation and could (if you're daring) replace GNU (or BSD) tar for those purposes.
It's still v0.2.0, so interfaces may break in the future. But, I'm going to do my best to prevent that (yay keyword args!).
You can find the new versions
at https://gitlab.common-lisp.net/cl-tar/cl-tar/-/releases/v0.2.0
and https://gitlab.common-lisp.net/cl-tar/cl-tar-file/-/releases/v0.2.0. I've
also requested that both cl-tar and cl-tar-file be added to Quicklisp.
Known Issues
- Sym and hard link extraction do not work on Windows (yet). This was just a matter of the amount of time I had to work on this (it was my xmas present to myself). It should not be technically hard to implement.
- Extracting to the file system can be pretty slow (regardless of compression). I've profiled it to see the hotspots and have a bit of an idea how to speed it up.
- Creation of archives from the file system on Windows requires https://github.com/osicat/osicat/pull/57. On another note: I barely use Windows, so if there's anyone with more Windows experience out there I'd appreciate it if you looked at the PR with a fresh set of eyes.
- I'd like to make more precompiled binaries. Again, this was mostly a matter of time (setting up all the correct CI runners and debugging them).
Roswell and Walled Gardens
posted on 2022-01-04 19:00:00 UTC
Recently, Eitaro Fukamachi has been sharing blog posts about Roswell, "a launcher for a major lisp environment that just works." Like many in the CL community, I've heard of Roswell and even dabbled with it a bit. I'm not sure how many people actually use Roswell, but I do know it's non-negligible.
Roswell certainly solves some real problems for folks, but I could never get into it myself. There are two primary reasons for that. First, I use a Linux distro with that a) stays relatively up to date with upstreams and b) makes it trivial to carry my own patches to CL implementations (which I frequently do). Second, Roswell feels like a walled garden to me (I doubt this was an intentional decision by its authors, however).
The purpose of this post is to dig more into the second reason. This is mostly for my own benefit. I have not really progressed beyond broad "feelings" on this subject and I'd be doing myself and the Roswell authors a disservice if I keep not using it based on mere feelings without some concrete issues backing it up. Perhaps it will benefit others as well by finding others with concerns similar to mine and getting a concrete set of issues laid out that we could work on contributing fixes for.
Roswell authors: If you read this, please know this isn't meant to be a dig at you. I'm writing this as a sincere effort at exploring why I don't like Roswell with an eye toward coming up with solutions that would make it more palatable to me and (hopefully) others with a similar mindset.
This blog covers asdf, blog, cl-docker-images, clpm, common-lisp, sbcl