Re: [dwm] ntags initialization
On Fri, Oct 05, 2007 at 23:33:44 CEST, Anselm R. Garbe wrote:
> You miss that seltags and Client->tags are both globally defined
> in the same context as the tags definition. Afaik you can't
> evaluate the sizeof operator and you can't perform a division
> operation in a non-functional scope, so I don't see how you
> would like to replace the allocation of seltags and Client->tags
> using emallocz.
sizeof is a compile-time constant, and any expression containing only
compile-time constants (literal numbers, sizeof, etc; no variables or
functions) can be evaluated at compile time. To demonstrate, consider
the attached patch against changeset 1025 (written in standard, albeit
little-used, C) which removes the dynamic allocation of seltags and
Client->tags and replaces it with constant initialization. Due to
added whitespace where some declarations were rearranged, and a
comment, the number of LOC decreased only by 2.
--- dwm.c.old 2007-10-06 10:02:01.680419843 -0300
+++ dwm.c 2007-10-06 11:28:34.323541304 -0300
@@ -57,21 +57,6 @@
/* typedefs */
typedef struct Client Client;
-struct Client {
- char name[256];
- int x, y, w, h;
- int rx, ry, rw, rh; /* revert geometry */
- int basew, baseh, incw, inch, maxw, maxh, minw, minh;
- int minax, maxax, minay, maxay;
- long flags;
- unsigned int border, oldborder;
- Bool isbanned, isfixed, ismax, isfloating, wasfloating;
- Bool *tags;
- Client *next;
- Client *prev;
- Client *snext;
- Window win;
-};
typedef struct {
int x, y, w, h;
@@ -195,7 +180,7 @@
double mwfact;
int screen, sx, sy, sw, sh, wax, way, waw, wah;
int (*xerrorxlib)(Display *, XErrorEvent *);
-unsigned int bh, bpos, ntags;
+unsigned int bh, bpos;
unsigned int blw = 0;
unsigned int ltidx = 0; /* default */
unsigned int nlayouts = 0;
@@ -218,7 +203,6 @@
Atom wmatom[WMLast], netatom[NetLast];
Bool otherwm, readin;
Bool running = True;
-Bool *seltags;
Bool selscreen = True;
Client *clients = NULL;
Client *sel = NULL;
@@ -232,6 +216,26 @@
/* configuration, allows nested code to access above variables */
#include "config.h"
+/* Statically define the number of tags. */
+unsigned int ntags = sizeof tags / sizeof tags[0];
+Bool seltags[sizeof tags / sizeof tags[0]] = {[0] = True};
+
+struct Client {
+ char name[256];
+ int x, y, w, h;
+ int rx, ry, rw, rh; /* revert geometry */
+ int basew, baseh, incw, inch, maxw, maxh, minw, minh;
+ int minax, maxax, minay, maxay;
+ long flags;
+ unsigned int border, oldborder;
+ Bool isbanned, isfixed, ismax, isfloating, wasfloating;
+ Bool tags[sizeof tags / sizeof tags[0]];
+ Client *next;
+ Client *prev;
+ Client *snext;
+ Window win;
+};
+
/* functions*/
void
applyrules(Client *c) {
@@ -393,7 +397,6 @@
XFreeCursor(dpy, cursor[CurMove]);
XSetInputFocus(dpy, PointerRoot, RevertToPointerRoot, CurrentTime);
XSync(dpy, False);
- free(seltags);
}
void
@@ -1006,7 +1009,6 @@
XWindowChanges wc;
c = emallocz(sizeof(Client));
- c->tags = emallocz(ntags * sizeof(Bool));
c->win = w;
c->x = wa->x;
c->y = wa->y;
@@ -1467,9 +1469,6 @@
/* init tags */
compileregs();
- ntags = sizeof tags / sizeof tags[0];
- seltags = emallocz(sizeof(Bool) * ntags);
- seltags[0] = True;
/* init appearance */
dc.norm[ColBorder] = getcolor(NORMBORDERCOLOR);
@@ -1703,7 +1702,6 @@
focus(NULL);
XUngrabButton(dpy, AnyButton, AnyModifier, c->win);
setclientstate(c, WithdrawnState);
- free(c->tags);
free(c);
XSync(dpy, False);
XSetErrorHandler(xerror);
Re: [dwm] new setgeom in hg tip
On Sat, Mar 15, 2008 at 5:30 PM, Johannes Hofmann <[EMAIL PROTECTED]> wrote: > Huh? That's a config parser in dwm! Luckily I'd say, since otherwise we'd seem to be stuck hardcoding values for screen sizes as 24-line functions for each set of geoms. This config parser isn't really much different from the regexes that were used in config.h for matching windows, nor is it difficult to understand, so I have no objections. Brendan
Re: [dwm] regression in 5.0.1
On Sat, Sep 6, 2008 at 10:35 AM, bill lam <[EMAIL PROTECTED]> wrote: > I added that but have no idea where the error log resided. > Nevertheless, I simplified that line to > > if(!XGetWMNormalHints(dpy, c->win, &size, &msize))return; > > and the issue is also fxied. My theory is that if XGetWMNormalHints > fails then information returned in size is rubbish, and set that flag to > PSize can help to prevent incorrectly change anything. That is pretty much correct. According to the Xlib programming manual: > If the property is of type WM_SIZE_HINTS, is of format 32, and is long enough > to contain > either an old (pre-ICCCM) or new size hints structure, XGetWMNormalHints() > sets the > various fields of the XSizeHints structure, sets the supplied_return argument > to the list of > fields that were supplied by the user (whether or not they contained defined > values), and > returns a nonzero status. Otherwise, it returns a zero status." Ie., if a zero status is returned, then the variable size remains uninitialized, and will contain whatever garbage was in that stack segment when the function was called.
Re: [dwm] malloc'ed client in manage()
I'm not sure I understand the point of this patch. calloc is defined in both C89 and C99, and is both fairly generic and very widely used, so I fail to see anything safer or more portable about this approach. Not to mention that fact that most people prefer not to use structure assignments... Brendan MacDonell
Re: [dwm] malloc'ed client in manage()
On Sun, Sep 7, 2008 at 5:25 AM, Szabolcs Nagy <[EMAIL PROTECTED]> wrote: > is it because of null pointer might not be represented as zeros? > > the point is good, but i doubt X would run on such platform ;) Unfortunately, the patch uses structure assignment from an unmodified static variable, so everything just gets set to 0 anyway. Brendan MacDonell
Re: [dwm] SLiM login themes for dwm users
Is that section copied and pasted from your configuration file? If so, it's probably the typo where you have 'exex' instead of 'exec' that's doing it, instead of any real issue with your configuration. > I have changed the following in /etc/slim.conf: > > #login_cmd exec /bin/bash -login /etc/X11/Xsession %session > login_cmd exex /bin/bash -login ~/.xinitrc %session > > #sessionsstartxfce4,openbox,ion3,icewm,wmaker,blackbox > sessionsdwm > > Am I doing something wrong here?
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
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] Re: dwm-5.4 stdin; cycle tags
On Sat, Dec 13, 2008 at 2:26 PM, henry atting wrote: > Patching works without problems but I get this warnings: > >dwm.c:1640: warning: 'viewnext' defined but not used >dwm.c:1657: warning: 'viewprevious' defined but not used > > And, what should I say, it *is* not used ;) > > henry That's because you haven't bound those functions to any keys in your config.h. ;)
Re: [dwm] Crash-only software
> What do you think about the concept of crash-only software? While I'm certain that it's great for large, complex, high-availability applications which infrequently write persistent state to disk, I don't think it's of much use for small software components. Such programs are unlikely to be able to architecturally differentiate between micro-reboots and macro-reboots, not to mention that the average consumer-grade application already supports auto-saving and can start up cleaning in a short period of time - even moreso for suckless programs. > What about removing the running flag from dwm and replacing quit() > with kill(pid)? My interpretation of the original paper's statement that 'stop=crash' was that a crash and a stop instruction are considered equivalent, ie. that there is no path dedicated to storing resources on shutdown which would be unavailable in the case of a crash, and not that an application should have no method to cleanly exit and require the use of kill. The collection of articles seems to imply that 'crash-only' refers to the usage of rebootable components and frequent saving of persistent state to cope with errors instead of using more complex error recovery mechanisms. In fact, since dwm doesn't have any persistent state and consists of a single logical module, Neale's script _would_ arguably make it crash only software. Brendan MacDonell
Re: [dwm] Suckess Code Management
I'll only bother to mention here what utilities/applications I use that might be considered unusual, as repeating the same set of browsers / chat clients / DCVS tools ad infinitum would likely become tedious. Without further preamble, I think the following might be worth mentioning: * WM: a forked dwm-5.3.1 (I altered it slightly to allow process management and on-the-fly reloading.) * Shell: rc or bash, depending on whether I'm working heavily with scripting or interactive use. * File Manager: I've come to prefer the shell. * Text Editor: vile. I prefer the statically compiled lexers for syntax highlighting as it means that I never have to contend with the limited context and broken highlighting caused by starting vim at a line in the middle of a large function. The binary is still smaller than vim, @ 1.4MB with all of the filters compiled in, and there's few configuration files to load. * TODO/Bug tracking/Notes: I keep track of my Todo list and other info with a 1.3KLOC (C++) utility I wrote to handle tagged notes from the command line. Maybe I'll get around to writing up a readme and releasing it soon. * Compilers: GCC/G++/Gambit-C (scheme). Brendan MacDonell
Re: [dwm] Suckess Code Management
On Fri, Mar 13, 2009 at 4:46 AM, Amit Uttamchandani wrote: > I just looked at vile...very cool app. Haven't figured out all the > commands yet but I'm quite happy that it supports verilog syntax > highlighting. Can you do vertical splits or file browsing within vile? Vile unfortunately has no present vertical split capability, though there is a file management interface via the hypertext capability (which you has no default binding, so you have to bind in your vilerc) and directory.pm via the perl interface if you use it. There are apparently also some gdb and shell bindings via perl, but YMMV. I'm afraid I don't know much more than that about it, because I've never felt the need to make use of them. >> * TODO/Bug tracking/Notes: I keep track of my Todo list and other info >> with a 1.3KLOC (C++) utility I wrote to handle tagged notes from the >> command line. Maybe I'll get around to writing up a readme and >> releasing it soon. > I'd very interested in this. I'll see what I can do about finishing up the unit / integration tests and releasing it. The only thing that makes me hesitate to do so is the fact that someone will likely build a feature-comparable (albeit slower for large databases and without the query DSL) version using sh and grep. :-) Brendan MacDonell
Re: [dwm] musca wm
On Fri, 15 May 2009, Mate Nagy wrote: Minimalism is a good thing to consider while developing software, but obsessing about it is no better than with anything else. I'm as annoyed with huge monstrous software like OpenOffice or Gnome or even Firefox as anyone, but wanting to take away the features of the CLI userland that make it comfortable is mad. I was just about to write the exact same thing. However, coreutils could likely use some love to cut down on functionality duplicated across binaries, not to mention some extraneous options which few people ever use. In my opinion, it's about finding the balance between simplicity (so that people can hold the entire model of a command/utility in their head) and features (to allow users to achieve something without spending all of their time trying to fill in the gaps with awk.) I say dwm (for example) is good because it's good, not because it's suckless. The sucklessness is certainly part of its goodness, but not all. If it was uncomfortable, would anyone use it? and it's still only marginably usable with a multi-monitor configuration - proper handling of this would require adding of this "bloat" everyone hates so much. Exactly. dwm was largely well-adopted initially because there were no alternatives for dynamically managing windows. Since then, awesome and xmonad have largely poached the people looking for features and extensibility, while dwm has remained the ideal minimal core to play with and experiment on. People advocating for the recreation of cut-down versions of things just to be suckless fail to see that these will suck just as much, only there will be fewer useful _and_ extraneous features. Take it from me: I hate Wirth's Law, and I try to implement minimal, well-specified utilities myself, but I try to do this in a way which _improves_ on existing models instead of wasting my time duplicating existing efforts. Brendan MacDonell
