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

[Elias Mårtenson]

On 27 January 2017 at 13:49, Jean Louis <address@hidden> wrote:

 

> Fair enough, but just because you use CLISP as a terminal doesn't mean that
> your StumpWM has to use the same implementation.

It that logical? StumpWM was running on Common Lisp, now it is running
on one implementation, specifically. Does it deviate from standard or
what is the technical reason behind it, that I may understand?

It does. It's impossible to implement a window manager using a pure standard Common Lisp implementation, since Common Lisp does not specify a way to open a network connection.

Now, not so long ago the main ioloop of StumpWM was rewritten into something that works a lot better than before. However, this new ioloop will only be used if you're on SBCL. It's technically possible to implement backends for other CL's but so far no one has put in the effort to do so.

Even version 1.0 which ostensibly does support other Lisps, will not work as well as it does on SBCL because these platforms use the old ioloop. If you're interested to look at the code, it's in ioloop.lisp.

I implemented the support for proper timers as well as a thread-safe way to call StumpWM commands. This feature required both access to the pipe() system call as well as the new ioloop. None of these works on CLISP. I did all the necessary work to have it work correctly on CCL, so if someone ports the new ioloop to that Lisp, it'll work out of the box.

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.

> After all, I use zsh as my shell, and I don't expect my WM to run in
> it. :-)

That is Lisp, not just Window Manager, and also that statement is not
logical, especially to StumpWM, the programmable window manager.

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

 

The reason why GCL and CLISP use readline is due to their licensing,
they are compatible with the readline library. SBCL cannot implement
the readline due to licensing issues, and so many other
implementations.

Originally, perhaps. However, if any of the existing implementations cared about that they could easily link with editline or linenoise, both of which has a more liberal license.

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.

 

Somebody writing about that, should always know about Emacs and SLIME,
and I am certainly using it, however your impression of how Lisp
should be used does not make REPL un-usable, quite contrary,
especially with the readline and completion built-in REPL in CLISP is
increasing productivity, as one cannot do everything with Emacs.

No one stops you from using CLISP as your shell. You can still do that while at the same time running StumpWM on SBCL.

Now, it seems to me as your reasons for not wanting to use SBCL are not technical but rather emotional. I can actually understand your Github argument, but your arguments against the use of SBCL has been all over the place. If your issue is that you don't want to use SBCL simply because you don't like it I would respect your position much more.

Regards,

Elias