Re: [STUMP] Stumpwm-devel Digest, Vol 136, Issue 9

[Elias Mårtenson]

On 27 January 2017 at 17:51, Michael Raskin <address@hidden> wrote:

>Now, there are other reasons why CLISP in particular will not be supported.
>There is a desire to be able to use other mainstream CL libraries, such as
>Alexandria. Most libraries these days does not support CLISP, since it's an
>obsolete version, and has had no releases in the last 7 years.

Well, mentioning specifically Alexandria (which can be installed with
QuickLisp on both the latest release and recent repository checkout
versions) doesn't give a good example. I checked — with a minimal care
(well, you need to explicitly load ASDF3 before QuickLisp) I can run
Bordeaux-Threads just fine on the latest CLISP release.

Right, and the reason you have to jump through hoops to get something as basic as ASDF working just shows on it's started to suffer from severe bitrot.

That's not to say that it wouldn't be useful to at least try to make it work on one more implementation (probably CCL), at the very least, it would help keep the code reasonably portable.

It may be that if StumpWM starts using enough dependencies to outsource
portability wrappers it may by mere chance start supporting CLISP. After
all, CLISP stagnated in a relatively good state (and then there are
updates even if there is no release). I do hope CLISP gets a release at
some point, though.

You and me both. CLISP was the first implementation I used, and it's sad that the project died (or at least fell into a very deep sleep). It doesn't seem likely though. I think the crown for being the most portable implementation is being taken over by ECL now.

 

>StumpWM is not a pure CL application, and it can't be, for reasons outlined
>above.

I would also add that being surprised about _both_ adding dependencies
and dropping support for other implementations doesn't get you anywhere…

The big issue is low-level IO. The alternative to going platform-specific would be to use IOLIB. I use it myself for my portable code, but it does have the drawback of depending on libfixposix.

 

I guess bugs in 1.0 could be fixed in a portable way; but all the ideas
for future improvement I have seen include doing more system interaction
in various ways, which means that implementation wrappers become more
and more costly to maintain.

Right. Custom implementation wrappers is where the problem lies. As of version 1.0 I believe that all the platform-specific stuff could be handled by a few libraries, such as bordeaux-threads and IOLIB. However, the maintainers have chosen to avoid thinking about the compatibility libraries, and I can't say I blame them. Even if you were using compatibility libraries, you'd still need to test on lots of different implementations and I don't think there is nearly enough willing developers to do this.

 

>The fact that none of them do proves that there is a very limited need for
>it. If you really want to use SBCL without SLIME, you can always use rlwrap.

Interesting that in discussion of StumpWM you managed not to mention
stumpish.

I don't know what that is, so it's not surprising at all.

Regards,

Elias