Re: [dwm] dwm-5.3
On 12/13/08, James Turner ja...@bsdgroup.org wrote: man signal on OpenBSD also states to #include signal.h, it's just signal.h includes sys/signal.h and for the function used by dwm sys/signal.h is all that is required on OpenBSD. I don't run any other systems so if signal.h is more portable then go with it. for the record: signal.h is in c89, c99 and various unix/posix standards sys/signal.h is not http://www.unix.org/version3/apis/headers.html
Re: [dwm] dwm-5.3
2008/12/13 James Turner ja...@bsdgroup.org: After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h which contains additional functions. -- James Turner BSD Group Consulting http://www.bsdgroup.org Hello, Same for FreeBSD (and probably all other *BSD). Would it be possible to include this one line mainstream? Fred
Re: [dwm] dwm-5.3
2008/12/13 Frederic Chardon chardon.frede...@gmail.com: 2008/12/13 James Turner ja...@bsdgroup.org: After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h which contains additional functions. Same for FreeBSD (and probably all other *BSD). Would it be possible to include this one line mainstream? Fred Yes, will do that. Kind regards, --Anselm
Re: [dwm] dwm-5.3
James Turner ja...@bsdgroup.org writes: After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h which contains additional functions. My man page (Linux) says to #include signal.h. I don't have any of my books nearby, nor do I have access to any of my older boxen (SunOS, HP/UX, etc.) but I suspect signal.h is the portable way to do it. I'm not sure what the motivation is for changing this. If the concern is size of the compiled binary, consider that including prototypes for additional functions shouldn't change anything about the output binary; it still links against libc6, and since #define is just a C preprocessor directive, unused #defines won't affect the binary either. Neale
Re: [dwm] dwm-5.3
On Sat, Dec 13, 2008 at 10:34:28AM -0700, Neale Pickett wrote: James Turner ja...@bsdgroup.org writes: After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h which contains additional functions. My man page (Linux) says to #include signal.h. I don't have any of my books nearby, nor do I have access to any of my older boxen (SunOS, HP/UX, etc.) but I suspect signal.h is the portable way to do it. I'm not sure what the motivation is for changing this. If the concern is size of the compiled binary, consider that including prototypes for additional functions shouldn't change anything about the output binary; it still links against libc6, and since #define is just a C preprocessor directive, unused #defines won't affect the binary either. Neale man signal on OpenBSD also states to #include signal.h, it's just signal.h includes sys/signal.h and for the function used by dwm sys/signal.h is all that is required on OpenBSD. I don't run any other systems so if signal.h is more portable then go with it. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] dwm-5.3
After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h which contains additional functions. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] dwm-5.3
On 12/8/08, Neale Pickett [EMAIL PROTECTED] wrote: I sort of like the idea of using X properties. You could use xprop to one of the most ununixy interfaces man XGetWindowProperty
Re: [dwm] dwm-5.3
2008/12/9 Szabolcs Nagy [EMAIL PROTECTED]: On 12/8/08, Neale Pickett [EMAIL PROTECTED] wrote: I sort of like the idea of using X properties. You could use xprop to one of the most ununixy interfaces man XGetWindowProperty I agree 100%. The idea of X properties can seem appealing at first, but it is a pain to use them. I really doubt you can remove loc with it. Anyway, I feel curiosity for a patch in this direction, it could be good to have it for reference, to compare. If you don't try, you'll never know for sure. -- - yiyus || JGL .
Re: [dwm] dwm-5.3
Anselm R Garbe [EMAIL PROTECTED] writes: I don't like the alternatives very much, I dislike popen() some status feed process, or creating a fifo, or reading from some status text file, or using X properties (like larsremote). I sort of like the idea of using X properties. You could use xprop to set some string on the root window: xprop -root -f DWM_STATUS 8s -set DWM_STATUS whatever It might even result in a significant SLOC reduction, since it'd just be another X event, and wouldn't have to parse text for newlines. I'll work on a patch to use X properties and we can see what everyone thinks. Neale
Re: [dwm] dwm-5.3
On Mon, Dec 8, 2008 at 10:40 PM, Neale Pickett [EMAIL PROTECTED] wrote: I sort of like the idea of using X properties. You could use xprop to set some string on the root window: xprop -root -f DWM_STATUS 8s -set DWM_STATUS whatever It might even result in a significant SLOC reduction, since it'd just be another X event, and wouldn't have to parse text for newlines. I'll work on a patch to use X properties and we can see what everyone thinks. I like the idea as well, go ahead it worth testing! -- Sidney Amani
Re: [dwm] dwm-5.3
On Sun, Dec 07, 2008 at 11:06:59AM +, Anselm R Garbe wrote: 2008/12/7 Neale Pickett [EMAIL PROTECTED]: Guillaume Quintin [EMAIL PROTECTED] writes: But now, when I reinstall dwm-5.2 I get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork, simple-fork and re-double-fork. I don't understand why. This makes me happy, not only because my spawn function wasn't the problem, but also because I can feel again like I know how Unix works :) I now think it is the open file descriptor causing the problem. The SIGCHLD or double-fork would both cause this behavior; the problem is that the shell running .xinitrc is waiting for an EOF on the pipe it created for STD(IN|OUT|ERR), and is never getting it because you still have some X clients with it open. Afair running exec dwmstatus in .xinitrc should delegate this issue to dwmstatus, because the problem of running some loop | dwm in .xinitrc existed since the very first dwm version and there is no real solution to this problem unless the feed process is replaced by something more appropriate which uses a fifo redirection. I advise against closing STDOUT or STDERR in the spawn function: that's how error messages make it in to .xsession-errors. So far it was only about closing stdin. I don't like the alternatives very much, I dislike popen() some status feed process, or creating a fifo, or reading from some status text file, or using X properties (like larsremote). Reading from stdin in dwm is the simpliest and most elegant solution imho. Amen to that, please keep it the way it currently is. Communication should be done over stdin/stdout. Cheers, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] dwm-5.3
2008/12/7 Neale Pickett [EMAIL PROTECTED]: Guillaume Quintin [EMAIL PROTECTED] writes: But now, when I reinstall dwm-5.2 I get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork, simple-fork and re-double-fork. I don't understand why. This makes me happy, not only because my spawn function wasn't the problem, but also because I can feel again like I know how Unix works :) I now think it is the open file descriptor causing the problem. The SIGCHLD or double-fork would both cause this behavior; the problem is that the shell running .xinitrc is waiting for an EOF on the pipe it created for STD(IN|OUT|ERR), and is never getting it because you still have some X clients with it open. Afair running exec dwmstatus in .xinitrc should delegate this issue to dwmstatus, because the problem of running some loop | dwm in .xinitrc existed since the very first dwm version and there is no real solution to this problem unless the feed process is replaced by something more appropriate which uses a fifo redirection. I advise against closing STDOUT or STDERR in the spawn function: that's how error messages make it in to .xsession-errors. So far it was only about closing stdin. I don't like the alternatives very much, I dislike popen() some status feed process, or creating a fifo, or reading from some status text file, or using X properties (like larsremote). Reading from stdin in dwm is the simpliest and most elegant solution imho. Kind regards, --Anselm
Re: [dwm] dwm-5.3
I reverted the old spawn in the 5.3.1 release I'm currently uploading, until this issue gets sorted. But this proofs again never change a running system, especially I believe we experienced exactly the same 4 years ago when we switched back and forth to double-forks and signal handlers. Unix is a mess... ;) Kind regards, Anselm 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 15:52:26 +0100 yy [EMAIL PROTECTED] wrote: 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 08:33:44 + Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm A bit off-topic, but, why the echo? A simple date should do it. Yes a simple date makes it. -- Kind regards, Guillaume Quintin.
Re: [dwm] dwm-5.3
I reprodeced this problem with dwm-4.7 and also dwm 5.3.1.
Neale's spawn() change is not guilty.
I think that fork() copy fd and pipe survive.
Please try this patch:
diff -r 94032e7d3943 dwm.c
--- a/dwm.c Sat Dec 06 11:22:30 2008 +
+++ b/dwm.c Sat Dec 06 22:57:46 2008 +0900
@@ -1396,6 +1396,7 @@
if(fork() == 0) {
if(dpy)
close(ConnectionNumber(dpy));
+ fclose (stdin);
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char **)arg-v)[0]);
--
Yamada Yohei (山田洋平) [EMAIL PROTECTED]
Re: [dwm] dwm-5.3
This was my hunch too, glad someone got it before me though. This
patch fixes the problem with 5.3. Probably the same with the double-
fork version too.
Jeremy
On Sat 06 Dec 2008 - 11:14PM, yamada yohei wrote:
I reprodeced this problem with dwm-4.7 and also dwm 5.3.1.
Neale's spawn() change is not guilty.
I think that fork() copy fd and pipe survive.
Please try this patch:
diff -r 94032e7d3943 dwm.c
--- a/dwm.c Sat Dec 06 11:22:30 2008 +
+++ b/dwm.c Sat Dec 06 22:57:46 2008 +0900
@@ -1396,6 +1396,7 @@
if(fork() == 0) {
if(dpy)
close(ConnectionNumber(dpy));
+ fclose (stdin);
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char
**)arg-v)[0]);
--
Yamada Yohei (?$B;3EDMNJ?) [EMAIL PROTECTED]
Re: [dwm] dwm-5.3
2008/12/6 Jeremy Jay [EMAIL PROTECTED]: This was my hunch too, glad someone got it before me though. This patch fixes the problem with 5.3. Probably the same with the double- fork version too. Glad you investigated further ;) I will test this and wait some days, looks like there will be some 5.3.2 soon ;) Kind regards, --Anselm
Re: [dwm] dwm-5.3
Jeremy Jay [EMAIL PROTECTED] writes: This was my hunch too, glad someone got it before me though. This patch fixes the problem with 5.3. Probably the same with the double- fork version too. The open FD was my first guess too, but the double-fork version didn't close any fds either, so I assumed it must be something else. Guillaume, if you apply the close(0) patch, does the problem go away? I'm away from my dwm computer right now, or I'd try it myself. Neale
Re: [dwm] dwm-5.3
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
Jeremy Jay [EMAIL PROTECTED] writes:
This was my hunch too, glad someone got it before me though. This
patch fixes the problem with 5.3. Probably the same with the
double- fork version too.
The open FD was my first guess too, but the double-fork version didn't
close any fds either, so I assumed it must be something else.
Guillaume, if you apply the close(0) patch, does the problem go
away?
I'm away from my dwm computer right now, or I'd try it myself.
Neale
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork,
simple-fork and re-double-fork. I don't understand why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can change
the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 19:20:58 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
Jeremy Jay [EMAIL PROTECTED] writes:
This was my hunch too, glad someone got it before me though. This
patch fixes the problem with 5.3. Probably the same with the
double- fork version too.
The open FD was my first guess too, but the double-fork version
didn't close any fds either, so I assumed it must be something else.
Guillaume, if you apply the close(0) patch, does the problem go
away?
I'm away from my dwm computer right now, or I'd try it myself.
Neale
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. But now, when I reinstall
dwm-5.2 I get the same problem than in dwm-5.3 and dwm-5.3.1,
double-fork, simple-fork and re-double-fork. I don't understand
why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
This is more simple with the popen() function. We could simply get the
shell commands to execute from the arguments passed to dwm or read them
from any file or from stdin only once.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork,
simple-fork and re-double-fork. I don't understand why.
Is there any chance you may have recently updated your version of
xorg-server? I know the change just got pushed out recently on
Archlinux, and it seems to have changed some corner cases that people
previously took for granted.
In response to your idea for executing status scripts, that's roughly
how my patched version of dwm does it, though mine takes the status
script name (or possibly even the content) as an argument, and stores
the entirety of argv so that dwm can re-exec itself to restart/change
the script. In any case, the function you're looking for to replace a
fid with another is 'dup2(replacement, to_replace)'.
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork,
simple-fork and re-double-fork. I don't understand why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can change
the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 14:40:47 -0400
Brendan MacDonell [EMAIL PROTECTED] wrote:
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. But now, when I
reinstall dwm-5.2 I get the same problem than in dwm-5.3 and
dwm-5.3.1, double-fork, simple-fork and re-double-fork. I
don't understand why.
Is there any chance you may have recently updated your version of
xorg-server? I know the change just got pushed out recently on
Archlinux, and it seems to have changed some corner cases that people
previously took for granted.
In response to your idea for executing status scripts, that's roughly
how my patched version of dwm does it, though mine takes the status
script name (or possibly even the content) as an argument, and stores
the entirety of argv so that dwm can re-exec itself to restart/change
the script. In any case, the function you're looking for to replace a
fid with another is 'dup2(replacement, to_replace)'.
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. But now, when I
reinstall dwm-5.2 I get the same problem than in dwm-5.3 and
dwm-5.3.1, double-fork, simple-fork and re-double-fork. I
don't understand why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more
quitting problem. This is just an idea, forgive me not to propose
some real code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Yes I pacmaned a new xorg-server and I move from 32 bits to 64 bits
recently.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 19:38:16 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008 19:20:58 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
Jeremy Jay [EMAIL PROTECTED] writes:
This was my hunch too, glad someone got it before me though.
This patch fixes the problem with 5.3. Probably the same with
the double- fork version too.
The open FD was my first guess too, but the double-fork version
didn't close any fds either, so I assumed it must be something
else.
Guillaume, if you apply the close(0) patch, does the problem go
away?
I'm away from my dwm computer right now, or I'd try it myself.
Neale
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. But now, when I
reinstall dwm-5.2 I get the same problem than in dwm-5.3 and
dwm-5.3.1, double-fork, simple-fork and re-double-fork. I
don't understand why.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more
quitting problem. This is just an idea, forgive me not to propose
some real code. Well tell me what you think of this idea.
This is more simple with the popen() function. We could simply get the
shell commands to execute from the arguments passed to dwm or read
them from any file or from stdin only once.
This is a little very basic patch that does what I asked above. I tried
this using the SIGALRM signal but I randomly got fatal errors about
memory (un)locks.
I have a dwmstatus script :
~/.dwmstatus
#!/bin/sh
date
and my .xinitrc is :
~/.xinitrc
exec dwm -s ./dwmstatus
And every second I get the status bar text updated. Tell me what you
think about it.
--
Kind regards,
Guillaume Quintin.
--- org/dwm.c 2008-12-06 19:53:57.0 +0100
+++ dwm-5.3/dwm.c 2008-12-06 21:50:55.0 +0100
@@ -23,6 +23,7 @@
*
* To understand everything else, start reading main().
*/
+#define _POSIX_C_SOURCE 2
#include errno.h
#include locale.h
#include stdarg.h
@@ -30,6 +31,7 @@
#include stdlib.h
#include string.h
#include unistd.h
+#include time.h
#include sys/select.h
#include sys/types.h
#include sys/wait.h
@@ -204,8 +206,10 @@
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
+static void getstatustext(void);
/* variables */
+static char sscript[256];
static char stext[256];
static int screen;
static int sx, sy, sw, sh; /* X display screen geometry x, y, width, height */
@@ -1184,55 +1188,16 @@
void
run(void) {
- char *p;
- char sbuf[sizeof stext];
- fd_set rd;
- int r, xfd;
- unsigned int len, offset;
+ int t,xfd;
XEvent ev;
/* main event loop, also reads status text from stdin */
XSync(dpy, False);
xfd = ConnectionNumber(dpy);
- offset = 0;
- len = sizeof stext - 1;
- sbuf[len] = stext[len] = '\0'; /* 0-terminator is never touched */
+ getstatustext();
+ t = time(0) + 1;
while(running) {
- FD_ZERO(rd);
- if(readin)
- FD_SET(STDIN_FILENO, rd);
- FD_SET(xfd, rd);
- if(select(xfd + 1, rd, NULL, NULL, NULL) == -1) {
- if(errno == EINTR)
-continue;
- die(select failed\n);
- }
- if(FD_ISSET(STDIN_FILENO, rd)) {
- switch((r = read(STDIN_FILENO, sbuf + offset, len - offset))) {
- case -1:
-strncpy(stext, strerror(errno), len);
-readin = False;
-break;
- case 0:
-strncpy(stext, EOF, 4);
-readin = False;
-break;
- default:
-for(p = sbuf + offset; r 0; p++, r--, offset++)
- if(*p == '\n' || *p == '\0') {
- *p = '\0';
- strncpy(stext, sbuf, len);
- p += r - 1; /* p is sbuf + offset + r - 1 */
- for(r = 0; *(p - r) *(p - r) != '\n'; r++);
- offset = r;
- if(r)
- memmove(sbuf, p - r + 1, r);
- break;
- }
-break;
- }
- drawbar();
- }
+ if ( time(0) = t ) { t = time(0) + 1; getstatustext(); }
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 10:20 AM, Guillaume Quintin wrote: Why don't we change the way dwm gets its status text ? For example we could use the SIGALRM signal to call a spawn2 : --snip-- This will take only a few LOC, because all the reading p[0] part will be in fact the reading-stdin code from the run() function which will not be needed anymore. This has the advantages that one can change the status when dwm is running and there are no more quitting problem. This is just an idea, forgive me not to propose some real code. Well tell me what you think of this idea. I'm not sure that changing the status script when dwm is running is a big advantage. I'm already used to recompiling if I want to change any setting. :) The disadvantage of this approach is that the status script would have to do a lot of work to maintain any state. Most people run date, acpi and other commands once a second, this would be fine for them. My status text includes the weather (updated only every 15min to avoid hammering their servers), and the time (updated once a minute, on the minute, to reduce my wakeups-per-second in PowerTOP). For me, this SIGALRM and spawn2 would require that I store some temporary data somewhere between invocations. Here's my status script in case anyone would be interested. It basically merges different status areas with arbitrary update intervals for each. status.lua Description: Binary data
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 14:52:55 -0800 Donald Chai [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 10:20 AM, Guillaume Quintin wrote: Why don't we change the way dwm gets its status text ? For example we could use the SIGALRM signal to call a spawn2 : --snip-- This will take only a few LOC, because all the reading p[0] part will be in fact the reading-stdin code from the run() function which will not be needed anymore. This has the advantages that one can change the status when dwm is running and there are no more quitting problem. This is just an idea, forgive me not to propose some real code. Well tell me what you think of this idea. I'm not sure that changing the status script when dwm is running is a big advantage. I'm already used to recompiling if I want to change any setting. :) The disadvantage of this approach is that the status script would have to do a lot of work to maintain any state. Most people run date, acpi and other commands once a second, this would be fine for them. My status text includes the weather (updated only every 15min to avoid hammering their servers), and the time (updated once a minute, on the minute, to reduce my wakeups-per-second in PowerTOP). For me, this SIGALRM and spawn2 would require that I store some temporary data somewhere between invocations. Here's my status script in case anyone would be interested. It basically merges different status areas with arbitrary update intervals for each. Then use another solution. I posted a patch some hours ago, which requires the time.h and execute a script every second but you choose to execute it every hour if you like you just have to modify : int what_you_want; t = time(0) + what_you_want; Moreover I thought of another solution more simple for which you won't to modify any status script or store any data between calls. It is late, I am tired so I won't write a patch but I think we proceed as follow : You don't need any time.h functions. Before the main loop in the run() function you call popen(yourscript,r); and within the main loop, you keep select(); and fgets(); when necessary and display it. On breaking the main loop you pclose(); Tomorrow I will try this unless someone write it during the night. -- Kind regards, Guillaume Quintin.
Re: [dwm] dwm-5.3
That's how my version currently works. Unfortunately, mine likely
wouldn't be much good to you because there is a massive amount of
overhead that I added to fine-tune process controls - and I can't
merge into my github repository to demonstrate until the daily
mercurial mirror updates. Of course, your idea is actually as simple
as using popen, the non-standard function fileno, and dup2 to replace
stdin if you wanted to minimize the amount of code you touch, ie.
(somewhere in main()):
FILE *dwmhelper;
...
if(argc == 2) {
dwmhelper = popen(argv[1], r);
if(f) dup2(fileno(dwmhelper), STDIN_FILENO);
}
run();
pclose(dwmhelper);
Actually, I'm unsure that dwm didn't actually work this way by default
at one point. I seem to recall finding it somewhere in the source in
some long-lost revision once when I went repository-diving.
On Sat, Dec 6, 2008 at 10:44 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
Then use another solution. I posted a patch some hours ago, which
requires the time.h and execute a script every second but you choose to
execute it every hour if you like you just have to modify :
int what_you_want;
t = time(0) + what_you_want;
Moreover I thought of another solution more simple for which you won't
to modify any status script or store any data between calls. It is
late, I am tired so I won't write a patch but I think we proceed as
follow :
You don't need any time.h functions. Before the main loop in the run()
function you call popen(yourscript,r);
and within the main loop, you keep select(); and fgets(); when
necessary and display it. On breaking the main loop you pclose();
Tomorrow I will try this unless someone write it during the night.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 1:02 PM, Guillaume Quintin wrote: This is a little very basic patch that does what I asked above. I tried this using the SIGALRM signal but I randomly got fatal errors about memory (un)locks. Your code looks like an idle loop; I recommend you read the man page for select(). The last argument is a timeout, which is what you want to use instead of alarm(1), and will avert the random errors.
Re: [dwm] dwm-5.3
Guillaume Quintin [EMAIL PROTECTED] writes: But now, when I reinstall dwm-5.2 I get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork, simple-fork and re-double-fork. I don't understand why. This makes me happy, not only because my spawn function wasn't the problem, but also because I can feel again like I know how Unix works :) I now think it is the open file descriptor causing the problem. The SIGCHLD or double-fork would both cause this behavior; the problem is that the shell running .xinitrc is waiting for an EOF on the pipe it created for STD(IN|OUT|ERR), and is never getting it because you still have some X clients with it open. I advise against closing STDOUT or STDERR in the spawn function: that's how error messages make it in to .xsession-errors. I'll keep looking into ways to solve your particular problem. Guillaume. Neale
Re: [dwm] dwm-5.3
2008/12/5 Neale Pickett [EMAIL PROTECTED]: Neale Pickett [EMAIL PROTECTED] writes: Would you mind sharing how you launch dwm? It might also be helpful to share your status script. If you launch your status script like this: status | dwm and status forks, the parent may not be exiting. If the status program never exits, X won't terminate when you kill dwm. To test if yours operates this way, try the following experiment: xterm1$ status | cat xterm2$ kill (pid of cat) My status program at least keeps on running even though it can no longer write to stdout. I think it's because the parent shell, the one outside the loop, never gets the SIGPIPE and keeps on running. I'll play with it and report back. This problem isn't related to the recent fork patch, tough; you can reproduce this behavior without ever calling spawn. The reason this doesn't stop X is because your .xsession (or .xinitrc) is waiting for all subprocesses to exit. As long as status keeps running, .xsession won't exit, and the X server startup script won't kill the X server. Here's something you can put in .xsession to run status as a background process and cause your .xsession to exit when dwm exits: XSTATUS=$HOME/.status.$(hostname).$DISPLAY mkfifo -m 600 $XSTATUS status $XSTATUS STATUS_PID=$! dwm $XSTATUS kill $STATUS_PID rm $XSTATUS I also think this is rather related to the status feed. Kind regards, --Anselm
Re: [dwm] dwm-5.3
2008/12/5 James Turner [EMAIL PROTECTED]: Great! Thank you for dwm-5.3. I think that it's needed to #include signal.h, infact without it I couldn't compile on NetBSD. #include signal.h is also required on OpenBSD. Oh yes, I missed that. I will re-issue dwm-5.3.1 with this fix tonight. Kind regards, --Anselm
Re: [dwm] dwm-5.3
On Fri, 5 Dec 2008 08:33:44 + Anselm R Garbe [EMAIL PROTECTED] wrote: 2008/12/5 Neale Pickett [EMAIL PROTECTED]: Neale Pickett [EMAIL PROTECTED] writes: Would you mind sharing how you launch dwm? It might also be helpful to share your status script. If you launch your status script like this: status | dwm and status forks, the parent may not be exiting. If the status program never exits, X won't terminate when you kill dwm. To test if yours operates this way, try the following experiment: xterm1$ status | cat xterm2$ kill (pid of cat) My status program at least keeps on running even though it can no longer write to stdout. I think it's because the parent shell, the one outside the loop, never gets the SIGPIPE and keeps on running. I'll play with it and report back. This problem isn't related to the recent fork patch, tough; you can reproduce this behavior without ever calling spawn. The reason this doesn't stop X is because your .xsession (or .xinitrc) is waiting for all subprocesses to exit. As long as status keeps running, .xsession won't exit, and the X server startup script won't kill the X server. Here's something you can put in .xsession to run status as a background process and cause your .xsession to exit when dwm exits: XSTATUS=$HOME/.status.$(hostname).$DISPLAY mkfifo -m 600 $XSTATUS status $XSTATUS STATUS_PID=$! dwm $XSTATUS kill $STATUS_PID rm $XSTATUS I also think this is rather related to the status feed. Kind regards, --Anselm Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm This is exactly the same .xinitrc I used with dwm-5.2, and it worked fine with dwm-5.2. -- Kind regards, Guillaume Quintin.
Re: [dwm] dwm-5.3
2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 08:33:44 + Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm A bit off-topic, but, why the echo? A simple date should do it. -- - yiyus || JGL .
Re: [dwm] dwm-5.3
I have the same problem, although my status feed setup is nearly identical to the one Neale shows. I use 'tail -f $XSTATUS | dwm' instead of 'dwm $XSTATUS' because for some reason dwm always showed EOF the other way. Anyways, my .xinitrc is simply 'exec dwm-launch' and dwm-launch does the fifo mess, starts the status script in bg, and starts up stalonetray and nm-applet also in the background. No pid tracking or 'kill' commands. When I quit with nothing but these running, X closes fine. but when I quit with an xterm running, X blocks until I close the xterm. So, I don't think this is the problem. Jeremy On Fri 05 Dec 2008 - 08:33AM, Anselm R Garbe wrote: 2008/12/5 Neale Pickett [EMAIL PROTECTED]: Neale Pickett [EMAIL PROTECTED] writes: Would you mind sharing how you launch dwm? It might also be helpful to share your status script. If you launch your status script like this: status | dwm and status forks, the parent may not be exiting. If the status program never exits, X won't terminate when you kill dwm. To test if yours operates this way, try the following experiment: xterm1$ status | cat xterm2$ kill (pid of cat) My status program at least keeps on running even though it can no longer write to stdout. I think it's because the parent shell, the one outside the loop, never gets the SIGPIPE and keeps on running. I'll play with it and report back. This problem isn't related to the recent fork patch, tough; you can reproduce this behavior without ever calling spawn. The reason this doesn't stop X is because your .xsession (or .xinitrc) is waiting for all subprocesses to exit. As long as status keeps running, .xsession won't exit, and the X server startup script won't kill the X server. Here's something you can put in .xsession to run status as a background process and cause your .xsession to exit when dwm exits: XSTATUS=$HOME/.status.$(hostname).$DISPLAY mkfifo -m 600 $XSTATUS status $XSTATUS STATUS_PID=$! dwm $XSTATUS kill $STATUS_PID rm $XSTATUS I also think this is rather related to the status feed. Kind regards, --Anselm
Re: [dwm] dwm-5.3
On Fri, 5 Dec 2008 15:52:26 +0100 yy [EMAIL PROTECTED] wrote: 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 08:33:44 + Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm A bit off-topic, but, why the echo? A simple date should do it. Yes a simple date makes it. -- Kind regards, Guillaume Quintin.
Re: [dwm] dwm-5.3
Hello Anselm, On Thu, Dec 04, 2008 at 08:37:38PM +, Anselm R Garbe wrote: Let me know any issues. Great! Thank you for dwm-5.3. I think that it's needed to #include signal.h, infact without it I couldn't compile on NetBSD. I just updated the pkgsrc package[0] too and added the signal.h patch as wip/dwm/patches/patch-aa[1]. [0]: http://pkgsrc.se/wip/dwm [1]: http://pkgsrc-wip.cvs.sourceforge.net/viewvc/*checkout*/pkgsrc-wip/wip/dwm/patches/patch-aa Ciao, Leonardo -- Leonardo Taccari | Peace, love and NetBSD. | http://leot.netsons.org/ pgpBAkHiGZafL.pgp Description: PGP signature
Re: [dwm] dwm-5.3
Greetings, option which allows to set use server grabs during mouse based resizals/movements. now i'm using a computer where this is again an issue, except much more so, and not only with GL windows (big shared framebuffer mode with intel 945gm). I tried hacking server grabs into dwm 5.2 myself previously, but that didn't help (even without redrawing, the repositioning of the window is slow enough). However, ignoring all MotionNotifys until the last one in the queue does help (using XCheckMaskEvent). Strangely, this doesn't seem to be such an issue with resizing; only window moving is (very) slow. Mate
Re: [dwm] dwm-5.3
Also released: dwm-gtx-5.3 * patch: http://s01.de/~gottox/files/dwm/dwm-gtx-5.3.diff * tarball: http://s01.de/~gottox/files/dwm/dwm-gtx-5.3.tar.gz * website: http://s01.de/~gottox/index.cgi/proj_dwm regards Gottox -- http://www.gnuffy.org - Real Community Distro http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
Re: [dwm] dwm-5.3
On Thu, 4 Dec 2008 20:37:38 +
Anselm R Garbe [EMAIL PROTECTED] wrote:
Hi,
there was some silence during the last weeks, simply because I am/was
rather busy but also because I'm working on a secret surprise project
(yes it's st related). But I won't tell anything about it yet -- I
hope to disclose the details at 25C3 in Berlin in a couple of weeks ;)
Anyway, it's time for a new dwm release, you can fetch it from
http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz
This release contains the spawn() version of Neale and several
bugfixes regarding the NOBORDER handling in 5.2, and a new config.h
option which allows to set use server grabs during mouse based
resizals/movements.
Let me know any issues.
Kind regards,
--Anselm
Hi,
As usual this is the dwmii patch for dwm-5.3.
I think I have an issue when quitting dwm : If windows are openned
(xterm, claws-mail, firefox, pidgin for example) then X won't shut down
until I close (when possible) the windows. Does this have to do with
the new simple-fork ? I did not havs that issue with the previous
version of dwm.
--
Kind regards,
Guillaume Quintin.
/*
* I used WMII and found it too heavy. So I switched to dwm but I
* quickly missed the possibilities of having several columns,
* several windows in each column and moving the windows from a
* column into another or change the windows' order within a column.
* As there were no patch (or layout) providing that, I wrote one.
* I also added a layout that does the same thing but arrange the
* windows by rows.
*
* The col dwmii layout :
*
* +--+--+--+
* | | | |
* +--+ | |
* | +--+ |
* +--+ | |
* | | | |
* +--+--+--+
*
* The row dwmii layout :
*
* +--+---+--+
* | | | |
* +--+-+-+--+
* |||
* +++
* | |
* +-+
*
* You can move a window to the next/previous columnn, after the next
* window or before the previous window within a column by simple
* combination of keys (the same as in WMII). Moreover, you can choose
* the layout to respect the mfact or not. By default it does not, and
* MODKEY + SHIFT + M will change this behavior.
*
* To get the dwmii layouts working you have to :
* - have DWM version 5.3
* - add these lines in the config.h file :
* - just before the layouts array :
*
* #include dwmii.c
*
* - in the layouts array :
*
* { COL, dwmiilayoutcol },
* { ROW, dwmiilayoutrow },
*
* - in the keys array :
*
* { MODKEY, XK_c, setlayout, {.v = layouts[1]} },
* { MODKEY, XK_r, setlayout, {.v = layouts[2]} },
* { MODKEY|ShiftMask, XK_Up, dwmiikeypressed, {.i = XK_Up} },
* { MODKEY|ShiftMask, XK_Left, dwmiikeypressed, {.i = XK_Left} },
* { MODKEY|ShiftMask, XK_Down, dwmiikeypressed, {.i = XK_Down} },
* { MODKEY|ShiftMask, XK_Right, dwmiikeypressed, {.i = XK_Right} },
* { MODKEY|ShiftMask, XK_n, dwmiitoggle, {0} },
* { MODKEY|ShiftMask, XK_m, dwmiimfact, {0} },
*
* - add this line in the Client struct definition in the dwm.c file :
*
* int dwmii;
*
* - compile and it should work !
*
* The dwmiitoggle sets the dwmii variable of a window, when
* the dwmii is non zero then the window marks the start of a
* new column/row depending on the layout used.
*
* Enjoy it and feel free to send me all your comments !
*
* QUINTIN Guillaume
*/
static void dwmiitoggle(const Arg *);
static void dwmiisetmfact(const Arg *);
static void dwmiiinsertafter(Client *,Client *,int);
static void dwmiikeypressed(const Arg *);
static void dwmiiresize(Client *,int,int,int *,int *,int,int);
static void dwmiilayoutcol(void);
static void dwmiilayoutrow(void);
int dwmiimfact = 0;
void dwmiitoggle(const Arg *arg)
{
if ( !lt[sellt]-arrange || (sel sel-isfloating) ) { return; }
Client *firstclients = nexttiled(clients);
if ( sel == firstclients ) { return ; }
if ( sel-dwmii ) { sel-dwmii = 0; return; }
sel-dwmii = 1;
arrange();
}
void dwmiisetmfact(const Arg *arg)
{
dwmiimfact = !dwmiimfact;
arrange();
}
void dwmiiinsertafter(Client *c,Client *after,int dwmii)
{
if ( !c || !after ) { return; }
detach(c);
c-dwmii = dwmii;
c-next = after-next;
after-next = c;
}
void dwmiikeypressed(const Arg *arg)
{
if ( !lt[sellt]-arrange || (sel sel-isfloating) ) { return; }
Client* firstclients = nexttiled(clients);
if ( ( (arg-i == XK_Up) (lt[sellt]-arrange == dwmiilayoutcol) ) ||
( (arg-i == XK_Left) (lt[sellt]-arrange == dwmiilayoutrow) ) )
{
if ( sel-dwmii ) { return; }
Client *t = firstclients,*s = 0;
for( ; t != sel ; s = t,t = nexttiled(t-next) );
sel-dwmii = s-dwmii;
dwmiiinsertafter(s,sel,0);
}
if ( ( (arg-i == XK_Right) (lt[sellt]-arrange == dwmiilayoutcol) ) ||
( (arg-i == XK_Down) (lt[sellt]-arrange == dwmiilayoutrow) ) )
{
Client *t = nexttiled(sel-next),*s = 0;
if ( !t ) { sel-dwmii = 1; arrange(); return; }
int
Re: [dwm] dwm-5.3
Great! Thank you for dwm-5.3. I think that it's needed to #include signal.h, infact without it I couldn't compile on NetBSD. #include signal.h is also required on OpenBSD. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] dwm-5.3
Guillaume Quintin [EMAIL PROTECTED] writes: As usual this is the dwmii patch for dwm-5.3. I think I have an issue when quitting dwm : If windows are openned (xterm, claws-mail, firefox, pidgin for example) then X won't shut down until I close (when possible) the windows. Does this have to do with the new simple-fork ? I did not havs that issue with the previous version of dwm. That certainly sounds like it's being caused by the new forking technique. Would you mind sharing how you launch dwm? (.xsession or whatever). I'd very much like to help you get X11 to exit when you quit dwm. Neale
