Re: [dev] dwm patch: saveinfo
hi On Sun, Aug 28, 2011 at 11:27:57AM +0100, Connor Lane Smith wrote: > On 28 August 2011 11:23, Benoit T wrote: > > BTW., i am not sure which branch i should follow right now. Someone > > should close or merge the dangling head at rev 1565:ee4aa582320a at > > http://hg.suckless.org/dwm > > That branch is a feature branch for 6.0, whereas trunk is 5.9.1. They > aren't ready to be merged. I suspect you want the default, 'default'. ok i make a note that i don't need to worry and will stay on "default". considering the justification you give, i completely understand why you did not use a named branch, but i understand that the right thing to do with mercurial in that case would be to set up a separate clone to handle the 6.0 devel branch. is that not feasible in anselm's webserver? cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] dwm patch: saveinfo
hello all, On Sun, Aug 28, 2011 at 10:34:05AM +0200, Anselm R Garbe wrote: > On 27 August 2011 00:40, Ladd Hoffman wrote: > > This patch enables saving tags to disk when dwm exits, > > and loading from disk on startup. I don't like a wm writing to permanent storage, especially for this. Over time it tends to lead to a mess of permanent (app settings) vs. transient (window position and all) storage as found directly in some apps or through gconfd or the similar crap they have in kde. > > (especially useful when you need to recompile and restart dwm.) > > I think this patch seems quite useful and suggest you should add this > patch to the patches section. > > See http://suckless.org/wiki/ for instructions about how to commit > your changes to the wiki. > > Btw. there are other possibilities to restore the tag state than > persistation to a file. Esp. if your X was restarted your approach > could have weirdo side effects. A better way would be to store the tag > info in a property for each window in unmanage(), which is cleared > during manage() again. This would not lead to such X restart side > effects. This has been implemented already. i posted a 11-line patch doing that: http://lists.suckless.org/dev/1106/8301.html I record tags continuously rather than in unmanage() so that tags are still there in case dwm should crash or when i restart dwm over itself (to switch to a new build) with the respawn patch, also in the above message. BTW., i am not sure which branch i should follow right now. Someone should close or merge the dangling head at rev 1565:ee4aa582320a at http://hg.suckless.org/dwm cheers, -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] run a program and display on a specific tab
hello,
if you were referring to dwm rather than wmii...
On Mon, Jun 06, 2011 at 02:49:57PM +0100, Piotr Zalewa wrote:
> >>I want to create a script which will load my default setup (quite a
> >>few programs).
> >
> >I use .xinitrc for this.
... or .xsession
> I don't want to do it every time
then create a script that launches your programs and launch that script
from an xterm, dmenu or a shortcut in your dwm.h
> >>How to run a program so it will be displayed on a desired tab? (view,
> >>workspace - I always had a problem with that lingo)
> >
> >I assign programs to tags in config.h.
>
> It's more complicated as xterms are on many tags
it is still the right way to do what you ask for with dwm and anyway
it's the only way at least with a stock dwm.
as others suggested, you can match on several properties in rules[] in
config.h and they are not difficult to set from the command line for
your xterms.
one annoyance with the whole dwm concept is that you have to restart dwm
to try new rules, since you need to recompile.
with attached respawn.patch patch, you won't need to exit your X
session, rather dwm will respawn over itself - but with the new version
of itself as found on disk. of course if the new version crashes your X
session will terminate and if it does not work somehow, you may have to
forcibly terminate it, but if your changes are sane, you will be fine,
and anyway, hey, you have to try out the new build at some point (one
alternative being to try the new build in a nested X server such as
xephyr+xoo).
if you are interested in the respawn patch, then you will find that when
dwm starts in lieu of any other WM, including itself, all clients for
which there is no rule move to the 1st tag.
attached remember_tags.patch will solve that problem by recording tags
in an xprop for each X client, which is remembered through dwm restarts.
note: these are patches from a mercurial queue over my dwm repo, not
revisions against the dwm repo itself. apply them as unversioned diffs
or import them into your own mercurial queue and then "hg qpush" them.
most likely you found out that you don't want to install to /usr/bin/dwm
nor /usr/local/bin/dwm everytime you edit your config.h so you probably
have your own makefile variant that will install to ~/bin or something.
if you don't, well, i have a patch for that but it's a bit convoluted
due to supporting install over the same home directory for multiple
machines with different architectures, so i am not providing _that_ part
of my patch queue at this time.
cheers
--
Benoit Triquet
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
diff -r c19e2f20ca69 config.def.h
--- a/config.def.h Thu Oct 29 15:39:12 2009 +0100
+++ b/config.def.h Thu Oct 29 15:43:42 2009 +0100
@@ -80,7 +80,8 @@
TAGKEYS(XK_7, 6)
TAGKEYS(XK_8, 7)
TAGKEYS(XK_9, 8)
- { MODKEY|ShiftMask, XK_q, quit, {0} },
+ { MODKEY|ShiftMask|ControlMask, XK_q, quit, {.i = 0 } },
+ { MODKEY|ShiftMask, XK_q, quit, {.i = 1 } },
};
/* button definitions */
diff -r c19e2f20ca69 dwm.c
--- a/dwm.c Thu Oct 29 15:39:12 2009 +0100
+++ b/dwm.c Thu Oct 29 15:43:42 2009 +0100
@@ -270,6 +270,7 @@
static Monitor *mons = NULL, *selmon = NULL;
static Window root;
+static char **args;
/* configuration, allows nested code to access above variables */
#include "config.h"
@@ -1292,6 +1293,8 @@
void
quit(const Arg *arg) {
+ if(arg->i) /* restart dwm, if fails just fall through and exit */
+ execv(args[0], args);
running = False;
}
@@ -2008,6 +2011,7 @@
fputs("warning: no locale support\n", stderr);
if(!(dpy = XOpenDisplay(NULL)))
die("dwm: cannot open display\n");
+ args = argv;
checkotherwm();
setup();
scan();
# HG changeset patch
# Parent 3b5f9910413a84c53905b237e5fbf0728bb1081c
diff -r 3b5f9910413a dwm.c
--- a/dwm.c Wed Oct 27 15:43:16 2010 +0200
+++ b/dwm.c Wed Oct 27 15:46:10 2010 +0200
@@ -275,6 +275,7 @@
static Monitor *mons = NULL, *selmon = NULL;
static Window root;
static char **args;
+static Atom dwmatom_tags;
/* configuration, allows nested code to access above variables */
#include "config.h"
@@ -1104,8 +1105,15 @@
c->tags = t->tags;
}
else {
+ Atom atom; int format; unsigned long n, extra; unsigned int *ptags;
c->mon = selmon;
- applyrules(c);
+ if(XGetWindowProperty(dpy, w, dwmatom_tags, 0L, 1L, False, XA_CARDINAL,
+ &atom, &format, &n, &extra, (unsigned char **)&ptags)==Success && n==1 && *ptags!=0)
+ c->tags = *ptags; /* override rule tags with memorized tags */
+ else {
+ applyrules(c);
+ XChangeProperty(dpy, w, dwmatom_tags, XA_CARDINAL, 32, PropModeReplace, (unsigned char *)&c->tags, 1);
+ }
}
Re: [dev] dwm does something bad to X.org 1.7.6
On Tue, Apr 13, 2010 at 09:24:43PM -0400, Andrew Antle wrote: > On Tue, Apr 13, 2010 at 6:58 PM, Anselm R Garbe wrote: > > Can you use hg tip dwm and redirect its output to some file and send > > me the output, perhaps that gives us an idea what is going on in this > > new xorg server. > > Hello Anselm - > > Attached is my log from dwm hg tip, and my xorg-server info. Please > let me know if you need any more information. not sure anselm meant for everyone to answer his request :-P however my output looks similar to yours. tons of expose events, some (null) events, some propertynotify events (that must be xsetroot -name) and pretty much nothing else (i don't micro-manage my windows much, that's why being forced to use another WM than dwm hurts so much!) cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] hg path to suckless
good evening On Wed, Apr 14, 2010 at 08:47:40AM +0100, Anselm R Garbe wrote: > On 14 April 2010 01:39, Benoit T wrote: > > when was http://code.suckless/hg/dwm decommissioned in favor of > > http://hg.suckless.org/dwm ? > > I wish we had the tld suckless ;) ha, that would be a good one. who do you ask new TLDs from? ;-) that was http://code.suckless.org/hg/ of course. > But thanks for the hint, I re-instated the redirect. btw. where does that run? do you have control over your DNS record? cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
[dev] hg path to suckless
hello when was http://code.suckless/hg/dwm decommissioned in favor of http://hg.suckless.org/dwm ? cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] dwm does something bad to X.org 1.7.6
On Tue, Apr 13, 2010 at 11:58:58PM +0100, Anselm R Garbe wrote: > On 13 April 2010 23:29, Benoit T wrote: > > On Tue, Apr 13, 2010 at 03:55:46PM +0600, mikhail maluyk wrote: > >> I have the same problem. After latest update on development version of > >> debian, Xorg behaviour is insane. I'm not sure dwm is causing the trouble > > > > insane how? cpu consomption? event lagging? those are what i saw. > > > >> though. > > > > neither am i, i have no evidence of that, all i know is that dwm is > > triggering something in xserver-xorg, that wmii seems to as well and > > the other WMs i tried don't, including awesome (which has code from dwm) > > > > at any rate either dwm is doing unjustified amounts of requests - i > > don't believe so - or xserver-xorg is compelled into doing something > > stupid and that would be an xorg bug plain and simple, no matter what > > dwm does exactly. > > Can you use hg tip dwm and redirect its output to some file and send > me the output, perhaps that gives us an idea what is going on in this > new xorg server. I always use hg tip (as long as i don't see anything frightening in hg incoming of course) plus my patch queue - nothing spectacular and nothing that I believe could cause breakage. Anyway as mentioned in my first message, I tested a pristine hg tip build and observed the phenomenon as well. When I discovered that tip was logging multi-megabytes to .xsession-errors, I disabled the trace. I did not care to leave it enabled because I did not see anything interesting (with my limited knowledge of X) in that log of X events. As there are no timestamps, I did nothing to compute their rate of arrival. I'll reenable the trace and send you a log. I'd be glad if you come up with things to try, because i have run out of ideas. I'll summarize my most recent observations anyway, will try to get that done tomorrow evening. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] dwm does something bad to X.org 1.7.6
On Tue, Apr 13, 2010 at 03:55:46PM +0600, mikhail maluyk wrote: > I have the same problem. After latest update on development version of > debian, Xorg behaviour is insane. I'm not sure dwm is causing the trouble insane how? cpu consomption? event lagging? those are what i saw. > though. neither am i, i have no evidence of that, all i know is that dwm is triggering something in xserver-xorg, that wmii seems to as well and the other WMs i tried don't, including awesome (which has code from dwm) at any rate either dwm is doing unjustified amounts of requests - i don't believe so - or xserver-xorg is compelled into doing something stupid and that would be an xorg bug plain and simple, no matter what dwm does exactly. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] dwm does something bad to X.org 1.7.6
On Mon, Apr 12, 2010 at 01:29:23PM +0200, Uriel wrote: > Doing something bad to X.org is a good thing. fair enough. i have additional data about the phenomenon but nothing conclusive yet. i will share this shortly, in case anybody has an idea. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
[dev] dwm does something bad to X.org 1.7.6
Hello, Debian testing has replaced Xorg 1.7.5 with 1.7.6 about 3 days ago. Because i had not logged out of my X session in between, i picked up the new X server only today. dwm does something very wrong to it, causing it to consume a lot of cpu (say 25-50% according to top with 3s interval) and making X clients sluggish to unusable. I would not bet my life that the effect was not there with 1.7.5, but I had noticed nothing at all, I mean it's only today that firefox got very more sluggish than usual. Experimental evidence: - It is clearly dwm and not another client: the effect is there even when no other clients run but a lame xterm with top or ps inside. - It happens not only with my personal build and patches, but with just about every revision, from tag 0.1 to pristine tip. - I disabled the debug traces we get in the latest revisions from hg, to no avail (btw. thanks for nothing for leaving that on, i had not noticed how huge my .xsession-errors had grown) - It does not happen with any other WM i had on hand (icewm, twm, olvwm, mwm) At this point I don't know if it has anything to do with the graphics driver (intel in X, i915 in kernel) as I have only my laptop at hand. I shall try on my server later tonight. Don't know if that has anything to do either, but with the most recent 2.6.32 kernel in debian testing, I had to disable kernel mode setting in i915 as it was a cause of memory corruption after resume from disk. Because I did not bother to reenable a vga= argument in Grub, I have been running consoles in real text mode for the last few weeks. Oh, and X.org locks up the display from time to time when switching between X and consoles, anyway. At any rate there is no clear indication that there is a new frank bug in X.org, rather there must be something that dwm does or quite possibly does not do (wrt. other WMs) on the X wire, that keeps X.org busy. At least, the X.org folks say that when the X server eats a lot of cpu time, it's not necessarily an indication of an X.org bug (Uriel, *shut up*) but rather that some X clients bomb the server with more or less appropriate requests. What's for sure is that I am not embarking on a gdb/profiling session of the X.org process on my own - but advice and procedures are welcome. I will also try another bunch of tiling WMs among those readily available in debian testing, including dwm derivatives. We'll see who triggers the "bug". In the meantime i have no other option but to revert to icewm, my former favorite, and, man, does it suck compared with dwm... Please help me bring the arch-WM back to its senses !!! ;-) Cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] [OT]: Go programming language
On Sun, Nov 15, 2009 at 06:29:01AM +0100, Uriel wrote: > Go is the only hope for the future of the software industry, the only > weapon with a chance of killing the abominable mutant monster of C++ > and the double-headed zombie of Java/C#. hear hear! there has to be a better way :) > Having Go, there is no excuse to write user space code in C ever > again; as for kernel space, we will see (specially once they deploy > the new concurrent garbage collector), rob said he would like somebody > to try building a kernel in Go, this would be fun, and might even > produce something quite useful. This is happening already (although "happening" might depend on how you judge the progress of a project) : http://www.bitc-lang.org and http://www.coyotos.org Actually, if someone can offer an opinion on Go vs. BitC, that would be interesting to hear. I vaguely suspect that BitC takes a bit more away than Go (and vastly less than Haskell) for the sake of analyzable semantics. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] [OT] SLOC-counters, take this!
On Fri, Sep 11, 2009 at 09:43:25AM +0200, Antoni Grzymala wrote: > All the mad SLOC-counters, see this: > > http://pouet.net/prod.php?which=53816 greatness in 256 bytes :) included asm source file is 256 lines with comments that do not even look artificial. now that's taste. > (No, it doesn't run very well under dosbox.) it runs very slow under dosbox or qemu on my 4-year old pentium M, but fine under dosemu (dosemu will require temporarily setting /proc/sys/vm/mmap_min_addr set to 0, though). also the windows version works fine under wine. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dev] A lightwieight and working typesetting system.
On Wed, Sep 02, 2009 at 01:56:38PM +0200, QUINTIN Guillaume wrote: > Hi, > > Do you guys know a (working) typesetting system other than latex ? After years of WYSIWIG and a good deal of Latex (and unconvincing attemps at WYSIWIG Latex, i.e. Lyx, and useless Latex IDEs that bring nothing over vim/emacs), I ended up wondering if DocBook is so evil after all. I mean, not saying that DocBook toolchains are easily procured for multiple Unix variants, but no 2 installations of Latex have the same packages so i end up storing latex styles inside my document sources anyway, what a waste. But my main grief is that Latex and CTAN are a mess of presentation- and semantic-level mark-up. Thus, just like you seem to be doing, I hunted for simpler stuff: - Zoem and PUD, quite suckless and rather lean yet extensible thanks to being a Turing-complete language - which is wrong in my opinion, as I am rather sold to the stringtemplate philosophy of restricted languages. Down the drain, zoem. - Markdown, small and simple but does not do that much and still a mess of presentation- and semantic-level mark-up. - Pandoc, a more fully-featured reincarnation of Markdown in haskell, plus multiple output formats, still too presentation-level, but may be worth a look again. - My current favorite is asciidoc, still a mess like the above, just quick-and-easy. For me, asciidoc is a workable but interim solution: because it is a mess that produces useful results, it makes me want to take a closer look at plain DocBook - but that is a whole lot more of work than learning asciidoc. No silver bullets, I guess. Since I cite DocBook and your question is about actual implementations rather than formats, know that DocBook toolchains are many and there is a great deal in the freely available books "DocBook: the definitive guide" and "DocBook XSL: the definitive guide", and the DocBook demystification howto by Eric Raymond. > And a good soft to make presentations ? Assuming you dismissed latex-beamer, and want a batch system, s5 is good. I am impressed at the output capabilities of s5 with a plain web browser. I have yet to look at docbook-slides. Cheers, -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
