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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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 .
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
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
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
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
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
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
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
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
39 matches
Mail list logo
