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.
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.
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.
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.
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.
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.
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.
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.