Guide on how to add contrib modules to stumpwm after refactoring about stumpwm-contrib HOT 28 CLOSED

Many contrib modules haven't really been updated, so it could very well be a module-specific problem. In general a properly set-up *contrib-dir* together with (load-module ...) should be enough.I use the notifications and mpd modules, and they load fine. (MPD doesn't actually load cleanly, but it works.)

What contrib module are you trying to load?

from stumpwm-contrib.

Hi,

More details would help. I need to/am rewriting some of the load-module code to be more robust.

Basically the refactor took the existing contrib modules and put them in their own asdf packages (via quickproject:make-project). The net result is that stumpwm no longer knows about any contrib files. The configure script sets up /path/to/stump/sources/contrib as the default place to look for them, and then build-load-path traverses the first two levels of these and reports back a list of files with the .asd extension removed.

To be clear, are you packaging stumpwm-contrib as a package, or the main stumpwm repo?

If you could include some more steps including what you've tried and what happens as a result that would be very useful.

Yes: documentation is on its way!

from stumpwm-contrib.

@jorams mpd does not work here, either. *contrib-dir* seems to be set correctly, though.

@dbjergaard Of course, more details would help. Sorry. ;)

djbergaard wrote:

If you could include some more steps including what you've tried and what happens as a result that would be very useful.

To clarify what I am doing: I am packaging both stumpwm and stumpwm-contrib as one package. That is a stumpwm with a contrib directory in the stumpwm directory:

$ ls /path/to/stumpwm
bin contrib share

$ ls /path/to/stumpwm/contrib
media minor-mode modeline util

As said above, *contrib-dir* is set to /path/to/stumpwm/contrib. (find-module ...) returns the module name. (load-module ...) however leads to an error: Error: failed to find the TRUENAME of /tmp/.../package.lisp: no such file or directory.

Yes: documentation is on its way!

Fantastic :)

from stumpwm-contrib.

Hi, I've updated the README.org and the wiki with the latest module information.

I suspect that your issue may be a bug rather than lack of documentation. Stumpwm tries to set the *contrib-dir* to where asdf finds stumpwm, so if the git repo is ${HOME}/stumpwm/, then asdf will find it there and make *contrib-dir*=${HOME}/stumpwm/contrib/ and then build-load-path builds up a list of available modules from there. If you move the stumpwm binary somewhere else, I'm not sure what happens to the contrib-dir but I'm guessing it stays pointing to wherever you built stumpwm (somewhere in /tmp I'm guessing).

I think if you use ./configure --with-contrib-dir=/expected/path/to/contrib this will override the default to wherever you point it. Could you try that and let me know if it works?

Assuming it doesn't, (I'm a realist) could you tell me exactly how you're invoking load-module?

from stumpwm-contrib.

@dbjergaard

I already configure the build with --with-contrib-dir=/expected/path/to/contrib/.

I have the following code in my .stumpwmrc:

(setf *screen-mode-line-format* (list ">> "
                                      (format nil " ~a ~a" *contrib-dir* (find-module "cpu"))))

This yields the following mode-line output:

>> /path/to/stumpwm/contrib/ cpu

When I change this to the following

(load-module "cpu")
(setf *screen-mode-line-format* (list ">> %t "
                                      (format nil " ~a ~a" *contrib-dir* (find-module "cpu"))))

a loadrc will lead to the aforementioned error about not being able to find the TRUENAME in /tmp/...

from stumpwm-contrib.

@1126

Is the space before cpu in >> /path/to/stumpwm/contrib/ cpu actually there? If so, that could be the problem.

Could you try removing the trailing '/' from the --with-contrib-dir=/expected/path/to/contrib/ so that it reads --with-contrib-dir=/expected/path/to/contrib?

from stumpwm-contrib.

@jorams
Yes, it is actually there. As specified in the format string, or I am missing something here?

Actually, the call to ./configure looks like this:

   ./configure --prefix=$out --with-contrib-dir=$out/contrib

$out is in this case the directory into which Nix stores the package content after building it. And $out/contrib becomes /nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/ as stored in *contrib-dir*. I do not know how to remove the trailing / here.

from stumpwm-contrib.

@1126 I'm sorry, I misread the format string.

It seems as though $out, while building, is actually somewhere in /tmp. What are the contents of *load-path*?

from stumpwm-contrib.

@jorams
No problem ;)

Yep, that is true. However, contrib-dir is apparently set correctly. It points to the destination where stumpwm actually is copied to after the build.

*load-path* lists the contents of *contrib-dir* two levels down:

(/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/media/amixer/
/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/minor-mode/mpd/
...
/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/util/windowtags/)

from stumpwm-contrib.

Ahh, I see whats happening. load-path is the new way of actually
finding modules, contrib-dir is populating load-path during
compilation and then is never updated. We'll probably have to add some
lines to make-image.lisp to address this. Since I plan on moving the
default place for modules in the next release (coming up soon), it will
probably be then.

How time sensitive is this? If it needs to be out ASAP to make it into
the repos for a release we can try to address this separately.

Dave

Christian Lask [email protected] writes:

@jorams
No problem ;)

Yep, that is true. However, contrib-dir is apparently set correctly.
It points to the destination where stumpwm actually is copied to after
the build.

load-path lists the contents of contrib-dir two levels down:

(/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/media/amixer/
/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/minor-mode/mpd/
...
/nix/store/02c23igkja100mi94bl5dn0xynm0i043-stumpwm-2014-09-22/contrib/util/windowtags/)

—
Reply to this email directly or view it on GitHub.

from stumpwm-contrib.

@dbjergaard

Ahh, I see whats happening.

Oh, great! :) It is not my fault then? This is good news :P

How time sensitive is this? If it needs to be out ASAP to make it into the repos for a release we can try to address this separately.

No, it is not that time sensitive. I happily wait for the next release. At least as long as the soon in

(coming up soon)

is not ages away ;) But I doubt that.

from stumpwm-contrib.

I just pushed a commit to stumpwm that should address this. Can you confirm?

from stumpwm-contrib.

@dbjergaard
I gladly test this, of course. Alas, I am quite busy at work at the moment, so I am afraid that it will take some time. :(

from stumpwm-contrib.

@dbjergaard
I am happy to report that I finally found the time to test again. However, I am sad to report that nothing has changed as far as I can tell.

I built current master of both, stumpwm and stumpwm-contrib. Here is what I found:

• *contrib-dir* and *load-path* seem to be set correctly. The former is the correct path to where the content of stumpwm-contriblies, the latter is all the modules two leves down in that directory.
• (find-module "cpu") still returns cpu
• (load-module "cpu") however still leads to an error. It still is unable to find package.lisp in a directory in /tmp, the directory where NixOS presumably built stumpwm.

EDIT: By the way, stumpwm is compiled using sbcl 1.2.3.

from stumpwm-contrib.

@23a1a74
What is the result of (asdf:system-source-directory "cpu") ? I suspect it's somewhere in /tmp.

If so, could you try calling (asdf:initialize-source-registry) before (load-module "cpu") to see if that fixes it?

from stumpwm-contrib.

@jorams
The result of (asdf:system-source-directory "cpu") is /path/to/stumpwm-contrib/modeline/cpu.

Calling (asdf:initialize-source-registry) does not change the error I am receiving. stumpwm still complains about a failure to find the TRUENAME of something, which is quite obvious, since it is searching in a directory in /tmp.

from stumpwm-contrib.

I think it will be more productive for all of us if you give use a very detailed procedure for what you are doing so we can reproduce the issue. Be as detailed as possible, and then try to add more details :).

Ideally I would be able to copy-paste each step of the procedure and reproduce the issue.

from stumpwm-contrib.

@dbjergaard
Okay, sure. I gladly offer any help I can.

What I am trying to do is to refactor the package stumpwm for NixOS - it was packaged, but the package was outdated and too complex to update properly. Anyways. Currently, I am packaging the latest tagged release 0.9.8. stumpwm-contrib is with 0.9.8 still a part of the stumpwm repository. Since this is about to change with the next release, I already split those two packages up. You may find those two package expressions (that how they are called in NixOS) here.

During that process, stumpwm is compiled with the following configuration option:

--with-contrib-dir=${pkgs.stumpwmContrib}/contrib

stumpwm is compiled using sbcl, which currently is sbcl-1.2.3 on NixOS.

This should ensure that stumpwm knows where to find the extensions. ${pkgs.stumpwmContrib} is on my system currently the following path: /nix/store/ffp7nb5qd0780wya36jz1dky50ks7fy8-stumpwmContrib-0.9.8. This construct works as far as release 0.9.8 is concerned. (find-module ...) finds them and (load-module ...) sucessfully loads them.

When I update to latest master however - that is, after the actual split and the introduction of a asdf based organization of the extension modules, this does not work anymore. I package stumpwm and stumpwm-contrib the same way.

Before the update, the directory of /nix/store/ffp7nb5qd0780wya36jz1dky50ks7fy8-stumpwmContrib-0.9.8 would look something like this:

ll /nix/store/ffp7nb5qd0780wya36jz1dky50ks7fy8-stumpwmContrib-0.9.8/contrib
total 128
-r--r--r-- 1 root nixbld  2807 Jan  1  1970 amixer.lisp
-r--r--r-- 1 root nixbld  1031 Jan  1  1970 app-menu.lisp
-r--r--r-- 1 root nixbld  3796 Jan  1  1970 aumix.lisp
-r--r--r-- 1 root nixbld  5172 Jan  1  1970 battery.lisp
-r--r--r-- 1 root nixbld 13008 Jan  1  1970 battery-portable.lisp
-r--r--r-- 1 root nixbld  5716 Jan  1  1970 cpu.lisp
dr-xr-xr-x 2 root nixbld     3 Jan  1  1970 debian
-r--r--r-- 1 root nixbld  3240 Jan  1  1970 disk.lisp
-r--r--r-- 1 root nixbld  2777 Jan  1  1970 g15-keysyms.lisp
-r--r--r-- 1 root nixbld  4377 Jan  1  1970 maildir.lisp
-r--r--r-- 1 root nixbld  2935 Jan  1  1970 mem.lisp
-r--r--r-- 1 root nixbld 29962 Jan  1  1970 mpd.lisp
-r--r--r-- 1 root nixbld  4837 Jan  1  1970 net.lisp
-r--r--r-- 1 root nixbld  4510 Jan  1  1970 notifications.lisp
-r--r--r-- 1 root nixbld  2373 Jan  1  1970 passwd.lisp
-r--r--r-- 1 root nixbld  5494 Jan  1  1970 productivity.lisp
-r--r--r-- 1 root nixbld  4250 Jan  1  1970 sbclfix.lisp
-r-xr-xr-x 1 root nixbld  4114 Jan  1  1970 stumpish
-r--r--r-- 1 root nixbld  2288 Jan  1  1970 stumpwm-mode.el
-r--r--r-- 1 root nixbld  3719 Jan  1  1970 surfraw.lisp
-r--r--r-- 1 root nixbld  1512 Jan  1  1970 undocumented.lisp
-r--r--r-- 1 root nixbld  4645 Jan  1  1970 wifi.lisp
-r--r--r-- 1 root nixbld  9361 Jan  1  1970 window-tags.lisp
-r--r--r-- 1 root nixbld  2802 Jan  1  1970 wmii-like-stumpwmrc.lisp

After the update it looks like the following:

ll /nix/store/v8d1npg7svg5ss7d875im2pil6qscwpx-stumpwmContrib-2014-10-19/contrib/
total 39
dr-xr-xr-x  4 root nixbld    4 Jan  1  1970 media
dr-xr-xr-x  4 root nixbld    4 Jan  1  1970 minor-mode
dr-xr-xr-x 10 root nixbld   10 Jan  1  1970 modeline
-r--r--r--  1 root nixbld 2909 Jan  1  1970 README.org
dr-xr-xr-x 15 root nixbld   15 Jan  1  1970 util

In both cases, *contrib-dir* is correct and *load-path* seems to be correct, too. (find-module ...) works in both cases, (load-module ...) however only works with the 0.9.8 version and not with current master (after the split). It complains about not being able to find the TRUENAME and the reason for that is that ll /tmp/nix-build-stumpwm-2014-10-19.drv-0 is empty. I suspect this directory to be the one where the build takes place. I do not know however, why stumpwm is looking there for modules.

I hope this provides enough information to go on. If not, please ask, I will happily provide more.

from stumpwm-contrib.

Hi @23a1a74,

I've been pretty busy with non stumpwm related stuff lately, but this issue is still in the back of my mind. Is it fair to summarize the build process as:
compile in /tmp/
install in /usr/share/local

Also, I moved the default contrib dir (now called module dir) to ${HOME}/.stumpwm.d/modules/
Does this fix your issues at all?

from stumpwm-contrib.

@23a1a74 I tried playing with this a while back and I can't reproduce your issue, have you seen any progress on your end? It would be great if you could distill npm's package build process into a shell script or some shell code that I could run on my system.

Dave

from stumpwm-contrib.

@dbjergaard

Same here. I am sorry I neglected this issue for so long. :(

I did not, however, forget all about it. I am in active discussion with a co-worker who also uses stumpwm on NixOS and who thus should have the same problems I am experiencing. He might help me in better understanding what is going wrong. I come back at this as soon as we both found the time to investigate.

from stumpwm-contrib.

Just checking in on this issue, did you ever get it resolved?

from stumpwm-contrib.

Thinking outloud:
It appears the issue is more with asdf and some variable getting set during compile time and not during runtime. This causes your error, and for any use case where compile time and run time are the same directory, there is no error.

The "new" way of handling stumpwm for a package maintainer should be:

1. build/package stumpwm
2. package stumpwm-contrib
3. tell stumpwm where to pick up the modules packaged in 2

I just recently got bit by something like this switching to debian from ubuntu. I had to regenerate my makefile from scratch and everything worked as expected. Can you confirm this problem exists if you start completely fresh?

from stumpwm-contrib.

@dbjergaard I am sorry, again it took me way too long to respond. I was sick and busy and all. Well, the issue is still alive, but I managed to get friends to look at it, too. I failed. I keep you posted as soon as they achieve something.

It might just be the combination of asdf and NixOS that's not as easy as one might wish. Hm.

from stumpwm-contrib.

Heureka. A colleague did it. asdf apparently tried to reload all modules from the filesystem again. The path it tried was the path in which stumpwm was built, but it got moved afterwards. When asdf does not try to reload all the modules, everything's just fine.

from stumpwm-contrib.

@hiberno i'm running into the same problem with asdf looking in the /tmp directory for stumpwm's package.lisp. Can you tell me how you stopped asdf from reloading the modules?

from stumpwm-contrib.

@jqtruong I didn't fix that issue myself. The fix a colleague proposed was specific for the NixOS package of stumpwm. The fixing commit can be reviewed here.

What OS are you running stumpwm on?

from stumpwm-contrib.

I just opened stumpwm/stumpwm#283 which should fix this issue more generally.

from stumpwm-contrib.