Closed YorkZ closed 4 years ago
Its usually a good idea to call modules in the end of your init.lisp file so it wont interfere loading all stumpwm builtin features.
As for the NIL error, im having that too. maybe something have changed in stumpwtray deps packages.
The error is due to xembed::*timestamp*
being nil
when fdo-tray-send-manager-notification
is called. It happens to me on one of my machines (Ubuntu 16.04) but not on the one with Ubuntu 18.04 🤷
If you insert (xembed:update-timestamp (tray-fpwin tray))
before sending the client message the error won't be signaled. But the tray still won't work. I haven't read up on xembed to properly understand what is going wrong though.
I just removed stumpwm
, and then re-installed it, but the problem is still there.
@YorkZ
Its not a StumpWM issue but on its module called StumpTray.
To solve that, one should inspect how that module call its deps.
@alexanderbarbosa I agree that it seems to be a problem of StumpTray not StumpWM. I reinstalled StumpWM because I read that one need to remove StumpWM and install it again if quicklisp was installed after StumpWM. I re-installed quicklisp yesterday.
BTW, I just uninstalled xembed
, and then installed it again by:
(ql:uninstall :xembed)
(ql:quickload :xembed)
But nothing changed. Is there a way in quicklisp to upgrade a package instead of uninstalling it and ql:quickload
again?
But nothing changed. Is there a way in quicklisp to upgrade a package instead of uninstalling it and ql:quickload again?
Run (ql:update-all-dists)
and quickload the systems you want again. There is no need to uninstall them using (ql:uninstall ..
). If you they have changed in the most recent quicklisp distribution they the would be 'auto upgraded'. If you are on the same distribution the same system would be installed.
But I don't think this is an issue with outdated dependency rather a bug in stumptray or xembed.
Thank you very much @PuercoPop. What's the difference between (ql:update-all-dists)
and (ql:update-dists)
? I didn't see (ql:update-all-dists)
mentioned at https://www.quicklisp.org/beta/, is there a better documentation for quicklisp?
So, should this issue be moved to stumpwm-contrib repo? If so, could one of the maintainers move it?
@YorkZ update-dist
requires you to specify a distribution, update-all-dists
doesn't. Although reading the documentation you linked to the recommended way to update would be (ql:update-dist "quicklisp")
. Given that ne comers are unlikely to have installed a different distribution than the one quicklisp provided there is no meaningful difference between them.
The only quicklisp distribution I'm aware of is the one provided by the Radiance Web framework but that is out of scope of installing StumpWM.
The docs you listed are the best documentation of quicklisp I'm aware of. The only command I use occasionally that is not listed there is (ql:register-local-projects) so that documentation should cover you needs. If it doesn't don't hesitate to ask here or over irc.
Thanks again for your explanation @PuercoPop . Hope this issue will get resolved soon.
@YorkZ
Compiling sbcl(upstream) anew fix stumptray error!
I just recompiled and installed StumpWM
a46080, with stump-contrib at a077bf4. Nothing changed!
I just tried downgrading stumpwm
to 4653857, and stumpwm-contrib
to 5124950 (Those should be the two versions I used before things "break") I. But the problem was still exactly the same. The following is my archlinux PKGBUILD file:
# Contributor: Chris Dunder <echo Y2R1bmRlckBnbWFpbC5jb20K | base64 -d>
# Contributor: M Rawash <mrawash@gmail.com>
# Contributor: olvar <beren dot olvar (at) gmail dot com>
# Contributor: Andrew Antle <andrew dot antle at gmail dot com>
# Contributor: joyfulgirl <joyfulgirl (at) archlinux.us>
# Contributor: Jonathan Friedman <jonf@gojon.com>
# Maintainer: Stefan Husmann <stefan-husmann@t-online.de>
pkgname=stumpwm-git
_pkgname=stumpwm
pkgver=18.11.61.g4653857
pkgrel=1
pkgdesc="A tiling, keyboard-driven window manager written in common lisp"
arch=('i686' 'x86_64')
url="https://stumpwm.github.io"
license=('GPL2')
conflicts=('stumpwm' 'stumpwm-contrib')
provides=('stumpwm' 'stumpwm-contrib')
source=(${_pkgname}::git+https://github.com/stumpwm/stumpwm#commit=4653857 stumpwm.desktop
${_pkgname}-contrib-git::git+https://github.com/stumpwm/stumpwm-contrib#commit=5124950)
md5sums=('SKIP'
'b5721de9b1cbdb4548d11570a512c5d4'
'SKIP')
makedepends=('common-lisp' 'cl-asdf' 'clx-git' 'cl-ppcre' 'cl-alexandria')
optdepends=('xorg-xprop: for stumpish (StumpWM Interactive Shell)'
'rlwrap: for stumpish completion and history'
'emacs: Edit and eval stumpwm code with M-x stumpwm-mode'
'alsa-utils: for amixer.lisp (control audio volume)'
'aumix: for aumix.lisp (control audio volume)'
'mpd: for mpd.lisp (control the mpd)'
'surfraw: for surfraw.lisp (surf the Internet)'
'clx-truetype: for ttf-fonts.lisp (Xft fonts)')
# Binary will not run other
options=('!strip' '!makeflags') # Thanks to sidereus for pointing this out
pkgver() {
cd ${_pkgname}
git describe --long --tags|tr - .
}
_contribdest=/usr/share/stumpwm/contrib
build() {
cd ${_pkgname}
autoconf
./configure --prefix=/usr --with-module-dir=${_contribdest}
make
}
package() {
cd ${_pkgname}
make destdir="$pkgdir/" install
install -Dm 644 sample-stumpwmrc.lisp \
${pkgdir}/usr/share/${_pkgname}/stumpwmrc.sample
# contrib modules
install -d "$pkgdir"/${_contribdest}
cp -dr --no-preserve=ownership ${srcdir}/${_pkgname}-contrib-git/* \
${pkgdir}${_contribdest}
# stumpish
install -Dm755 "$pkgdir"/${_contribdest}/util/stumpish/stumpish \
"$pkgdir"/usr/bin/stumpish
rm -rf "$pkgdir"/${_contribdest}/util/stumpish
# emacs mode
cd "$pkgdir"/${_contribdest}/util/swm-emacs
install -d "$pkgdir"/usr/share/emacs/site-lisp/
for _i in *.el
do
install -Dm644 ${_i} "$pkgdir"/usr/share/emacs/site-lisp/${_i}
done
install -Dm644 "$srcdir"/stumpwm.desktop "$pkgdir"/usr/share/xsessions/stumpwm.desktop
}
I then downgraded stumpwm
and stumpwm-contrib
by running:
makepkg -s
sudo pacman -U stumpwm-git-18.11.61.g4653857-1-x86_64.pkg.tar.xz
From my pacman log
[2019-08-10 22:50] [ALPM] upgraded sbcl (1.4.16-1 -> 1.5.3-1)
I did upgrad sbcl
from 1.4.16-1 to 1.5.3-1, so I will try downgrading my sbcl
. But before doing so, is there any other suggestions?
I dont think your error has anything with sbcl or stumpwm, or even how arch builds stumpwm.
It can be fasl files(~/.cache/common-lisp), stumptray depencies update...
Would be interesting if you install Stumpwm dependencies locally with QuickLisp, then build, manually, StumpWM bin to another folder and call that bin instead the global one.
I recall contrib modules having conflicts with stumpwm early builds a few months ago.
@alexanderbarbosa
Compiling sbcl(upstream) anew fix stumptray error!
Could you provide more details, for example, the git repo tag name etc.
I don't think your error has anything with sbcl or stumpwm, or even how arch builds stumpwm.
I agree those seem to be much less likely the cause. I listed the PKGBUILD file only to make sure no careless mistakes had been made along the way, and also give more details.
It can be fasl files(~/.cache/common-lisp), stumptray depencies update...
Interesting. There are two directories sbcl-1.4.16-linux-x64
and sbcl-1.5.3-linux-x64
under ~/.cache/common-lisp
, I'm studying those to see if there's anything I can try about them. Could you also give me more details?
@YorkZ
PKGBUILD seems correct. Might be a xlib conflict too.
Just remove it all. As you call for QuickLisp is regenerate all files.
a-sbcl-build ()
{
echo " -- Building SBCL"
echo " -- Cleaning"
(rm -rf "$HOME_LOCAL_LIB/sbcl"
rm -f "$HOME_LOCAL_BIN/sbcl"
rm -rf "$XDG_DATA_HOME/doc/sbcl")
(git clone git://git.code.sf.net/p/sbcl/sbcl "$PROJECTS/lisp/sbcl"
cd "$PROJECTS/lisp/sbcl" || echo "No $_ folder"
git clean -fdx
git pull
export -n SBCL_HOME
echo -e " -- Comping SBCL"
sh make.sh --fancy --prefix="$HOME_LOCAL"
INSTALL_ROOT="$HOME_LOCAL" sh install.sh
export SBCL_HOME="$HOME_LOCAL_LIB/sbcl")
echo -e " -- Done"
}
a-lisp-tools-build ()
{
if [ ! -d "$HOME/quicklisp" ]; then
echo -e " -- QuickLisp - Bootstrapping"
cd "$HOME" || echo "No /tmp /-__-\ "
"$DOWNLOADER" https://beta.quicklisp.org/quicklisp.lisp
echo -e " -- Installing QuickLisp and StumpWM deps"
$LISP --no-sysinit --no-userinit --load quicklisp.lisp \
--eval '(quicklisp-quickstart:install :path "quicklisp")' \
--eval "(ql:quickload '(:quicklisp-slime-helper :swank))" \
--eval "(ql:quickload '(:clx :cl-ppcre :alexandria))" \
--eval "(ql:quickload '(:clx-truetype :xembed :xml-emitter))" \
--eval "(ql:quickload '(:dbus :prove :swank))" \
--eval '(uiop:quit)'
echo -e " -- (DONE)"
fi
}
a-stumpwm-build ()
{
git clone https://github.com/stumpwm/stumpwm "$HOME/Projects/lisp/stumpwm"
git clone https://github.com/stumpwm/stumpwm-contrib \
"$HOME/Projects/lisp/stumpwm-contrib"
cd "$PROJECTS/lisp/stumpwm" || echo "$_ folder do not exist"
echo -e " -- Purging before Compiling"
if [ -e ./Makefile ]; then
make uninstall
make clean
git clean -fdx
fi
autoconf
./configure --prefix=$HOME_LOCAL
make && make install
echo -e " -- Done"
}
Thank you very much @alexanderbarbosa, I'll definitely try installing StupmWM locally instead of installing it system wide because StumpWM is in archlinux AUR, meaning that I have to rebuild and reinstall StumpWM each time if sbcl is upgraded. Now that I have to rebuild it, why not rebuild it locally in the HOME. However, I still feel more comfortable installing sbcl system wide. I noticed the latest sbcl version was 1.5.5, so I did a full system upgrade which brought the sbcl to 1.5.5. I then did the following in order:
cl-alexandria
, clx-git.git
, cl-ppcre.git
and aumix
system wide through AUR.quicklisp
in my HOME, updated all the packages I installed in quicklisp.stumpwm
and stumpwm-contrib
from git master, through archlinux AURI monitored the directory ~/.cache/common-lisp
, noticed that a new sub-directory called sbcl-1.5.5-linux-x64
was created. I then checked this directory, and found nothing unusual. Finally, unfortunately, the original problem was still there, nothing changes.
I think I'm going build and install system wide, through AUR, the latest sbcl from git master. If that still wouldn't make a difference, I'll downgrade sbcl to 1.4.16 to see if I would be any lucky.
After a lot of experimentation, I finally got it back working, so the following was what I tried:
~/.cache/common-lisp/sbcl-1.4.16-linux-x64
: WORKED!@alexanderbarbosa Thank you very much for mentioning about the fasl cache. I'll try using sbcl 1.4.16 + stumpwm (with contrib) from git master + deleting the fasl cache.
@YorkZ
Good to know. Time to hack StumpWM, aint? :D
Its not that dificult to recompile sbcl and stumpwm with aid of scripts... take no more than 1 minute in my old t430! :D
@alexanderbarbosa, just did two more experiments:
While I'm pretty sure the stumpwm commit used in the package I built on Apr. 30 was 4653857, I'm not 100% sure whether the stumpwm contrib commit was 5124950 because this commit was not recorded in the AUR pkgver
, unfortunately. Any chance to know exactly which commit it was?
Just tried sbcl 1.4.16 + stumpwm from git commit 4653857 + stumpwm contrib from git commit beac523 + deleting fasl cache, still didn't work. Any other stumpwm contrib commit to try? @alexanderbarbosa I'm pretty good at Emacs Lisp, but know very little about common lisp and stumpwm. Can you give me some suggestion as to where I can start if I have to hack StumpWM?
@YorkZ
That is so weird, you are unable to load stumptray correctly. I literally have no clue, what its about. What it is issuing now?
If you know your way with emacs-lisp, just skim through Paul Graham Ansi Common Lisp and Practical Common LIsp
Emacs Lisp and Common Lisp share a lot of their syntax inherited from MacLisp so its more about knowing in what they differ rather than knowing a new language!
You can make fixing that issue as your first Lisp adventure! :D
More at r/lisp and #lisp
@YorkZ I'm pretty sure the issue you are running into is not due to the version you are running. StumpTray works on only one of my machines and in the other I run into the same issue you report. So you don't need to keep trying different versions.
I'm pretty good at Emacs Lisp, but know very little about common lisp and stumpwm. Can you give me some suggestion as to where I can start if I have to hack StumpWM?
I'm somewhat certain the issue is in how xembed generates the CurrentTime
timestamp and that the that the bug is in either xembed or StumpTray.
After setting up Sly (or SLIME if you prefer) you can follow the instructions in the wiki to connect the process running StumpWM to a Sly REPL.
If you want to take a stab at this bug you should at least skim the relevant freedesktop specs to get a sense of how xembed and system trays work.
Besides #lisp@freenode
which is great for general lisp questions, for StumpWM specific questions #stumpwm@freenode
may be more helpful.
This turns out to be a very complicated problem because there are many variables come into play:
clx
must be commit 4b9c202 (maybe 3b37000, cf81a5a or 8381835)stumpwm
and stumpwm-contrib
can be the latest (5e1abc5 and a077bf4 respectively at the time of this test). However, even though no errors show up, and the system tray appears, the application slack
doesn't work properly. I.e., once inside the slack
window, there's no way to switch to other window except exiting from slack
.BTW, do I need to re-install quick lisp
(in HOME) and re-install all the packages installed by quicklisp
each time I install another sbcl
version? (given that I delete the fasl cache each time).
@PuercoPop Just saw your message, and thank you very much for your help. I'll definitely follow your suggestions once I get some time, but I'm afraid I won't have any time for this in the next two weeks.
Update: sbcl
doesn't have to be 1.4.16. I'm now using 1.5.5 which still fully works which is really nice. I've updated my previous post which serves as a documentation. I'm pretty sure that clx
is a key factor here.
Further update: the latest stumpwm-contrib (a077bf4 so far) works. What makes real difference is stumpwm, more specifically, stumpwm 4653857 works, but not 5e1abc5. So, maybe we should still move this issue back to stumpwm? I will do bi-sect to find out the culprit :) when I have some time again.
OK, finally, the bisect turns out that the commit 92922d4 in stumpwm introduced the problem.
bad @ 92922d49a5e66f7a0a71e21807a8bc416d335824
Author: admich <andrea.demichele@gmail.com>
AuthorDate: Sun May 26 10:55:02 2019 +0200
Commit: admich <andrea.demichele@gmail.com>
CommitDate: Sun May 26 10:55:02 2019 +0200
Parent: 4653857 Focus on click with sloppy mouse focus policy
Merged: (no branch, bisect started on master)
Contained: (no branch, bisect started on master) master
Follows: 18.11 (62)
Fix :configuration-notify event
Before this commit stumpwm send a :configuration-notify event to the
managed xwindow that doesn't take in account the border of the
xwindow, but only the position of the parent xwindow.
This is particular important for float windows where the border is not
zero by default and there is a high top border for title.
1 file changed, 4 insertions(+), 2 deletions(-)
window.lisp | 6 ++++--
modified window.lisp
@@ -341,8 +341,10 @@ _NET_WM_STATE_DEMANDS_ATTENTION set"
;; Send a synthetic configure-notify event so that the window
;; knows where it is onscreen.
(xwin-send-configuration-notify (window-xwin win)
- (xlib:drawable-x (window-parent win))
- (xlib:drawable-y (window-parent win))
+ (+ (xlib:drawable-x (window-parent win))
+ (xlib:drawable-x (window-xwin win)))
+ (+ (xlib:drawable-y (window-parent win))
+ (xlib:drawable-y (window-xwin win)))
(window-width win) (window-height win) 0))
;; FIXME: should we raise the window or its parent?
Hope this will be fixed soon.
I have the same problem but my experimentation have found that the problem is in clx and not in stumpwm.
The problem have started with the upgrade of quicklisp to version 2019-08-13.
I solved the problem changing clx version using the commit 8381835.
So the problem seems due to commit bef2661 of clx.
@admich yep, ive noticed that after quicklisp update some package broken, but after cleaning everything and recompiling it all, sbcl included, somewhat fixed that issue!
@admich Like I said previously:
clx must be commit 4b9c202 (maybe 3b37000, cf81a5a or 8381835)
However, with the clx
version prior to bef2661, stumpwm
commit 92922d4 still doesn't work properly. Even though you may not see any error message, if you use Slack
, you will find that the problem is so serious that Slack
becomes literally unusable. So I hope you could test it with Slack
.
My feeling is that the problem is in both clx
and stumpwm
92922d4. Either way, this problem seems to have nothing to do with stumpwm-contrib
. Therefore, I think it should be moved back to stumpwm
.
@admich I'm now pretty sure that the problem is in both clx
and stumpwm
commit 92922d4. What happens is that when switching to the Slack
window, the window size and position was wrong. The window should be maximized, but it was instead being "moved" towards the right side and down side, occupying the entire bottom right part of the screen, covering half of the mode line. I noticed that your commit seemed to have adjusted the window position and size, so IMO, it's very much like this commit is placing the window in the wrong position in some cases. I'm wondering if would be possible for you to install the Slack
and try it out yourself?
I wanted to post a screenshot here, but my Slack
screen is full of my company team members' names and conversation. Therefore, I'm sorry I really can't post it here.
Please let me know if you need my help.
@YorkZ what is Slack and how install it. I use arch linux.
@admich Slack is an instant messaging software widely used by many R&D teams. A few teams in our company, for example, use Slack at work to ask questions, exchange ideas and opinions etc. In the team I'm working for (a software and hardware development team), we use Slack extensively, and almost never use email. You can read more about this software on https://en.wikipedia.org/wiki/Slack_(software), and download Slack from https://slack.com/intl/en-ca/downloads/linux.
I think that I have a solution for the problem due to commit bef2661 of clx
. This commit enforce some type checking in clx
and so produce errors but the problem is not in clx
but in clx-xembed
that sometimes use a nil
value instead of an (unsigned-int 32)
. I modify clx-xembed in:
https://github.com/admich/clx-xembed
If you think that my modifications are right I will made a PR on the main repo of clx-xembed
.
About the stumpwm
commit 92922d4 I don't have any problem.
@YorkZ
I installed Slack
but without an account I only start the application, I see icon in the systemtray without problem.
The commit change only one function update-configuration
, try to see with some (log:error ....
. when it's called and what are the value of (xlib:drawable-x (window-parent win))
and (xlib:drawable-x (window-xwin win))
inside the function.
@admich Thank you for your help. But I really doubt that clx-xembed
sometimes using a nil
value instead of an unsigned-int
is causing the Slack window not showing up properly, because I haven't seen the "using nil value" error message since using clx
8381835 or earlier. I guess the nil
value problem might be another bug though.
Slack provides free account, so I'm wondering if it would be possible for you to register a free Slack account. And, yes, the Slack icon is on the tray, but the Slack window doesn't show up at the correct position with the correct size. Also, once you open up the Slack window, you won't be able to switch to other window, and your only choice is to exit Slack altogether.
I can try your commit in clx-xembed
, but maybe later when I get some time.
Hi @admich, my apology I missed that you mentioned in your previous message that you used archlinux. So since you use archlinux, I would install Slack from AUR to have it managed by pacman
. This is how I installed Slack
on my archlinux:
git clone https://aur.archlinux.org/slack-desktop.git
cd slack-desktop
makepkg -sic
I have the same problem but my experimentation have found that the problem is in clx and not in stumpwm.
@admich Commit bef2661 wouldn't introduce a bug, as all it does is change the compiler optimization settings, but reveal its presence. This would also explain why I only encounter the bug on one machine and not in the other. As one the one I encounter it I restrict-compiler-policy
to a minimum of 1, for safety, and 3 for debug.
Thanks for the PR fixing the bug!
Hi, I am facing this stumptray unsigned byte32 error. And stumptray does not show up anymore. I installed stumpwm from github and also sbcl and quicklisp from there. I am running the latest versions on my debian box Could you make a step-by-step tuto on fixing this bug? I have installed stumpwm about 4 times. Everything works fine, but stumptray By the way I have read the treads and came across with this slack. I have qtox < https://qtox.github.io/ >, wire < https://app.wire.com/ >, riot-web < https://riot.im/download/desktop/ https://www.npmjs.com/package/riot-web > and another one that I do not remember the name now.
@OrionRandD
The problem is the version of clx-xembed that is shipped with quicklisp.
I made some little modifications and they are here: https://github.com/admich/clx-xembed
I made a PR to the main repo: https://github.com/laynor/clx-xembed but until it is not merged and a new quicklisp version is released (each month), you need to use the version of clx-xembed in my github. Because you have installed stumpwm from github, I immagine that you know how to do it, anyway:
~/common-lisp
or ~/quicklisp/local-project
.
$ cd ~/common-lisp
$ git clonehttps://github.com/admich/clx-xembed
~/.cache/common-lisp
On Tue, Sep 03, 2019 at 11:22:31PM -0700, admich wrote:
Many, many thanks for your fix! It worked greatly. I just deleted the contents of
$HOME/quicklisp/dists/quicklisp/software/clx-xembed-20190307-git
and placed your "https://github.com/admich/clx-xembed" contents inside that.
:)
[1]@OrionRandD The problem is the version of clx-xembed that is shipped with quicklisp. I made some little modifications and they are here: [2]https://github.com/admich/clx-xembed I made a PR to the main repo: [3]https://github.com/laynor/clx-xembed but until it is not merged and a new quicklisp version is released (each month), you need to use the version of clx-xembed in my github. Because you have installed stumpwm from github, I immagine that you know how to do it, anyway:
- go to a directory where quicklisp/asdf can find the asdf-systems like ~/common-lisp or ~/quicklisp/local-project. $ cd ~/common-lisp
- clone my repow $ git clonehttps://github.com/admich/clx-xembed
- Try again stumpwm with stumptray
If you still have problems try to clean the common-lisp cache ~/.cache/common-lisp
— You are receiving this because you were mentioned. Reply to this email directly, [4]view it on GitHub, or [5]mute the thread.
References
- https://github.com/OrionRandD
- https://github.com/admich/clx-xembed
- https://github.com/laynor/clx-xembed
- https://github.com/stumpwm/stumpwm-contrib/issues/142?email_source=notifications&email_token=AKLPRKPALOTV3ZICE24IRC3QH5H2PA5CNFSM4IK5GPS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD52PUBI#issuecomment-527759877
- https://github.com/notifications/unsubscribe-auth/AKLPRKIWELSGPUNBXXFZCELQH5H2PANCNFSM4IK5GPSQ
@OrionRandD It's not necessary to delete $HOME/quicklisp/dists/quicklisp/software/clx-xembed-20190307-git contents and replace with mine. In this way in the future if you forgot what you have done you will think that you have the quicklisp version of clx-xembed
The directory $HOME/quicklisp/local-project is just for this kind of things. You can clone my repo there and quickload will load my version.
@admich Yes, it fixes the NIL issue. Thanks!
Just updated clx
, stump-wm
, stump-wm-controb
, Slack
and clx-xembed
to the latest. Confirmed that everything works now. Thanks @admich.
With november release of quicklisp the clx-xembed include my changes. So it is no more necessary to use a local version.
@admich At last, thanks!
After upgrading my
archlinux
system with:and re-installing the
StumpWM
fromAUR
, thestumptray
no longer works. In my~/.stumpwm.d/init.lisp
file, I have the following lines:If I remove the line:
The entire
init.lisp
file would be evaluated successfully, but with no system tray, of course. Then if I manually evaluate the above line, I got the following errors:Please help, thanks in advance!
P.S. stumpwm was upgraded from 18.11.61.g4653857-1 to 18.11.81.gf6966ca-1