Hello everyone,
This is email is to follow-up on David's November email regarding dependencies and with the discussion on
issue 301 regarding about reorganizing the code base.
Regarding dependencies I think David summed up the trade-offs fairly well. Although I think we are erring a little on the side of caution regarding Alexandria and split-sequence. Alexandria is almost part of CL and functionality it provides such as PARSE-BODY is essential to proper handling of declaration in macros such as DEFCOMMAND, which is currently assumes docstrings go before declarations.
Point 2 is generally true, but not in the case Alexandria and split-sequence as they are mostly done and change very little, if at all.
Point 3 is not generally true, because for a package to be accepted to quicklisp it has to run in more than one lisp implementations most libraries are work across all active implementations. Also some libraries provide cross-implementation shims (Bordeaux-threads, trivial-backtrance, etc.). But it is true that GUI libraries, especially common-qt can be tricky to get working.
Making StumpWM SBCL-only has benefits and drawbacks. I think however the benefit outweight any drawback at this point. Dropping support for other implementations would enable us to easily access OS functionality like pipe, select, etc. through sbcl's sb-posix and sb-unix packages.
Regarding the use of cl-ppcre, it is used in other places besides the CLX parsing, the function PARSE-DISPLAY-STRING can be removed, CLX:GET-DEFAULT-DISPLAY provides the same functionality. Or were you referring to its use in PARSE-XINERAMA-HEAD?
I think the most important concern we should keep in mind when adding a dependency is ease of packaging and distribution. I have no experience deploying lisp to users but we could look into Dimitri's
ql-to-deb to generate a deb file or cl-launch. IIUC ql-to-deb allows the creating of .deb files pulling the dependencies from quicklisp at build time so that the users don't need to have quicklisp themselves. This would allow us to leverage libraries from the ecosystem w/o worrying about impacting negatively distribution. cl-launch lets the us create executable lisp 'scripts' which can pull dependencies from quicklisp when run. I know it has a deb package for itself but I don't know if it expects the user to install quicklisp themselves or not. It would be a good idea to look into these options mid-term.
To sum up, I would be in favor of adding Alexandria at the very least (and split-sequence ideally) and depend only on SBCL.
Regarding modularization, We have to remember that taking chunks out of files to a new file makes it harder to access the pertinent information stored in the commit logs of the VCS regarding that chunk. But we should try to move stuff like timers, hooks and keymaps to their own file and package (and maybe ASDF system). If we end up using cl-launch it could even make sense to move them to their separate repository but otherwise it would be wiser to keep them in repository for ease of distribution.
In an experimental branch I moved
timers to its own package and file but now that we use locks for timers, which are defined on wrappers.lisp it would be more difficult to split-out. Also if we go SBCL this would be moot as we could use sb-timer, which have the advantage of using a priority queue to keep the timer list sorted on insertion instead of calling sort after each insertion.
Another priority for version 2 is to move logging to be filed based by default. In the same experimental branch as above I successfully used
Piping to do so, but it pulls to many dependencies so it would be better to provide the logging functionality ourselves. Note that although I haven't run into any issues myself, Robert Smith mentioned that Pipping conses to much, which makes sense as it makes heavy use of CLOS.
My 2c,
Javier Olaechea
--
"I object to doing things that computers can do." — Olin Shivers