|Subject:||Re: [STUMP] Stumpwm-devel Digest, Vol 136, Issue 9|
|Date:||Fri, 27 Jan 2017 18:54:36 +0800|
>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.
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.
>StumpWM is not a pure CL application, and it can't be, for reasons outlined
I would also add that being surprised about _both_ adding dependencies
and dropping support for other implementations doesn't get you anywhere…
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.
>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
|[Prev in Thread]||Current Thread||[Next in Thread]|