On 27 January 2017 at 17:51, Michael Raskin <38a93...@rambler.ru> 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
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
