Very well put, Joram. On Dec 9, 2014 11:48 AM, "Joram Schrijver" <i...@joram.io> wrote:
> Hi, > > As I see it, there are two things involved here: > > 1. Moving some of the elsewhere useful functionality into libraries > 2. Refactoring internals to improve decoupling of mostly-unrelated > functionality. > > I'll first address the second point, since I see it as somewhat of a > prerequisite for the first. > > As it is right now, closely related functionality is often implemented > in different parts of the codebase. This makes changes harder than > needed because you'll have to first find out what assumptions the > different users of the code make. It makes maintenance hard and new > development harder. > > This is a lot of work to fix, because it requires changes to practically > the entire codebase. I think it's worth it though. > > An approach that could work is to use one package per file. I've seen it > used quite a bit recently and ASDF supports it through its > package-inferred-system extension.[1][2] Doing this basically forces > thinking about an API for the different types of functionality that are > implemented. There are, right now, a group API and a window management > API in the codebase, but because everything is in the same package > there's no obvious separation between implementation and interface. > > I hope to have some time in the next few weeks in order to try this > approach and see if it helps. It doesn't need to happen all in one go, > so experimentation is possible. > > When the StumpWM codebase is less coupled, turning parts of it into > separate libraries should be a lot easier. Then including those > libraries in the build process is the next problem. > > Right now StumpWM only uses Quicklisp on LispWorks, to try to install > it. For other implementations there's no dependency on Quicklisp, only a > recommendation in README.md. The loading of dependencies is not handled > any further. The simplest way to go about an increase in dependencies is > probably to use the same approach we're using right now: mostly ignore > it. Most Common Lisp projects don't really do anything more, depending > on the user to figure it out by using Quicklisp or some other means. > > For a project like StumpWM, that isn't aimed just at Common Lisp > programmers, adding more dependencies might make this approach too much > of a hassle, because every dependency would make installing StumpWM > more work. That could be solved by including any dependencies in the > release somehow (git submodules?), or by downloading them during the > build process. > > Of course at that point we're in Quicklisp territory. I personally think > it might be interesting to see if including Quicklisp is feasible. > There's the potential of using a custom "dist" to load modules and > dependencies from the internet. I have no idea if this is actually > possible and/or a good idea, but I think it's worth looking into. > > Long story short, I think a first priority should be to organize the > StumpWM codebase better. It makes the code more maintainable and makes > it easier to turn parts of it into separate libraries. This is a bit of > a big project, but it can probably be done piece by piece once an > approach is chosen. For installing dependencies multiple approaches can > be chosen and I don't think we should dismiss Quicklisp just yet. > > -- > Joram > > [1]: > > http://common-lisp.net/project/asdf/asdf/The-package_002dinferred_002dsystem-extension.html#The-package_002dinferred_002dsystem-extension > [2]: > > http://davazp.net/2014/11/26/modern-library-with-asdf-and-package-inferred-system.html > > > On Tue, Dec 9, 2014, at 04:35 PM, David Bjergaard wrote: > > Hi All, > > > > There was some talk on the issue tracker a while back about factoring > > out StumpWM's useful bits so they could be used in other projects. In > > addition there are some parts of stumpwm which have obvious boundaries > > (floating vs tiled groups). > > > > The arguments for are obvious. The arguments against are: > > - Increases StumpWM's external dependencies > > - Complicates the build process > > - Increases barrier for people packaging StumpWM for distros > > > > I'm thinking that most of the arguments against could be glossed over > > with appropriate Makefile rules. I'm open to other suggestions. I > > suppose some sort of lispy solution might be in order. I think we would > > have to handle the following cases: > > > > - users already have dependencies installed via quicklisp > > - users have dependencies installed via distro's package manager > > - users don't have any dependencies and need them checked out. > > > > I don't want to reimplement quicklisp in stumpwm. I don't want to > > depend on quicklisp for the actual build process. (Right now its used > > to get dependencies, but as part of the pre-reqs not the actual build > > that is driven by make). > > > > I'm hoping we can have a discussion here to help codify a way forward, > > because I think there is great value in having the packages available > > for other lisp hackers (myself included for a project I have cooking). > > > > Dave > > > > _______________________________________________ > > Stumpwm-devel mailing list > > Stumpwm-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel >
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
