1. 14

  2. 3

    Seems odd to announce intention to add more dependencies without stating what those dependencies are, and to say it’ll only support sbcl without a list of issues / problems that they’ll get to close.

    I appreciate a maintainer’s need for sanity (WONTFIX4LIFE) but it seems odd that it’s a project’s stated goal to do things that are largely seen as negative. Less compatibility. More interdependent.

    Does anyone have other resources, ml posts, etc about this? I switched back to Ion after playing with stumpwm for a few months.

    1. 5

      sbcl is the consensus standard libre Common Lisp on Linux. It’s not a bad thing to support other implementations, but when your time is limited, locking to SBCL is absolutely the right thing to do.

      1. 5

        One dependency I’ve been trying to add for a long time is Alexandria. So we can use parse-body to correctly process the declaration and documentation string in defcommand

        If you look into the code base you’ll find a worse (re)-implementation of split-sequence (split-seq) and other utilities in Alexandria

        SBCL only will simply the event-loop implementation, which currently is separated in SBCL and it will allow easy access to OS features through sb-unix and sb-posix. Another way to achieve this would be using iolib but that requires the installation of libfixposix which would bea burden on users.

        1. 5

          Well, as a StumpWM user and Common Lisp developer, I welcome both of these changes. They make it much more likely that I’ll contribute to the project in the future.

          I follow StumpWM development a little bit on GitHub, and I really don’t think these changes are a surprise to anybody or will affect very many people.

          I’m pretty sure all of the Linux distros that have StumpWM in their repositories already build with SBCL anyway.