Re: [dev] dmenu_path rewrite in C
On 05/19/2010 12:42 PM, Anselm R Garbe wrote: I think the existing shell script based dmenu caching is already quite fast (assumed the cache exists) The reason I wrote this is occasional lag when executing dmenu. I'm not sure I've fixed the problem, though (= Consider it an exercise in practical tool programming. and I doubt that your native tool does make the cache propagation itself faster. What does propagation mean here? It _does_ make reading the cache faster. Let me paste my unscientific tests: When cache is up-to-date: $ time ./dmenu_path_c 21 /dev/null For the C program I get typically real0m0.008s For the shell script I get typically real0m0.032s When cache is old: rm ~/.dmenu_cache; time ./dmenu_path_sh 21 /dev/null For the C program I get typically real0m0.047s For the shell script I get typically real0m0.700s Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Also I need to convince myself that your cache creation is really that much faster, simply because the bottleneck I remember a long time ago was rather how many executables and PATH directories were visited and overall filesystem performance. First, see above. Second, the shell script checks every $PATH item, but on my (poorly configured?) shell I have duplicates in $PATH. Eliminating duplicates of course reduces the number of files stat()ed. The question is though, if it really justifies a native tool in mainstream dmenu ;) You're the judge... As a side note: did you test it with following symbolic links etc? I very darkly remember a bunch of issues with symbolic links if they aren't dealt with properly. Yep. Symlinks are treated transparently, except when they're bad. for simplicity and clarity reasons we always reverted to the current solution. A noble cause. Elmo
Re: [dev] dmenu_path rewrite in C
On (19/05/10 12:58), Elmo Todurov wrote: Date: Wed, 19 May 2010 12:58:16 +0300 From: Elmo Todurov todu...@gmail.com To: dev mail list dev@suckless.org Subject: Re: [dev] dmenu_path rewrite in C User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Shredder/3.0.4 List-Id: dev mail list dev.suckless.org On 05/19/2010 12:42 PM, Anselm R Garbe wrote: I think the existing shell script based dmenu caching is already quite fast (assumed the cache exists) The reason I wrote this is occasional lag when executing dmenu. I'm not sure I've fixed the problem, though (= Consider it an exercise in practical tool programming. and I doubt that your native tool does make the cache propagation itself faster. What does propagation mean here? It _does_ make reading the cache faster. Let me paste my unscientific tests: When cache is up-to-date: $ time ./dmenu_path_c 21 /dev/null For the C program I get typically real 0m0.008s For the shell script I get typically real 0m0.032s That's such a small difference... current shell solution caching is IMHO fast enought. When cache is old: rm ~/.dmenu_cache; time ./dmenu_path_sh 21 /dev/null For the C program I get typically real 0m0.047s For the shell script I get typically real 0m0.700s Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) So, I see no reason to have it mainline. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 12:09:33PM +0200, Premysl Hruby wrote: Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) I have cache misses rather often, and the delay *is* annoying. I'd be a happy user of the C rewrite. Regards, Mate
Re: [dev] dmenu_path rewrite in C
Mate Nagy mn...@port70.net writes: On Wed, May 19, 2010 at 12:09:33PM +0200, Premysl Hruby wrote: Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) I have cache misses rather often, and the delay *is* annoying. I'd be a happy user of the C rewrite. I'm wondering, would it speed up the program if the script spawned a background process for every entry in $PATH? I imagine quite a lot of the runtime is spent waiting for I/O, so simple threading would be a win. That said, I don't think I've ever tried parallelising a shell script. -- \ Troels /\ Henriksen
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 10:58, Elmo Todurov todu...@gmail.com wrote: On 05/19/2010 12:42 PM, Anselm R Garbe wrote: I think the existing shell script based dmenu caching is already quite fast (assumed the cache exists) The reason I wrote this is occasional lag when executing dmenu. I'm not sure I've fixed the problem, though (= Consider it an exercise in practical tool programming. and I doubt that your native tool does make the cache propagation itself faster. What does propagation mean here? It _does_ make reading the cache faster. Yes I meant reading the cache. Let me paste my unscientific tests: When cache is up-to-date: $ time ./dmenu_path_c 21 /dev/null For the C program I get typically real 0m0.008s For the shell script I get typically real 0m0.032s The cache is up-to-date is the usual case I would say. The the difference isn't huge. When cache is old: rm ~/.dmenu_cache; time ./dmenu_path_sh 21 /dev/null For the C program I get typically real 0m0.047s For the shell script I get typically real 0m0.700s Well and these measures will differ quite a lot from system to system. Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Also I need to convince myself that your cache creation is really that much faster, simply because the bottleneck I remember a long time ago was rather how many executables and PATH directories were visited and overall filesystem performance. First, see above. Second, the shell script checks every $PATH item, but on my (poorly configured?) shell I have duplicates in $PATH. Eliminating duplicates of course reduces the number of files stat()ed. I understand that, though one could argue poor user setup if path contains duplicates ;) The question is though, if it really justifies a native tool in mainstream dmenu ;) You're the judge... Heh, well I'm happy to put everything into mainstream dmenu that makes sense and keeps it simple and brings a noticable difference and improvement. For the time being I propose you to announce this tool on the wiki and ask more people to test it, just to see if there are issues and we can decide at a later point what to do, especially if it has a bigger userbase ;) Another headache I have about it is perhaps the too-many special-purposefulness of it, but on the other hand reinventing find would also be pointless. Having said that, one of my least worries is about performance after all. Theoretically dmenu_cache becomes 2 or 3 times faster every 18months or so without changing it ;) As a side note: did you test it with following symbolic links etc? I very darkly remember a bunch of issues with symbolic links if they aren't dealt with properly. Yep. Symlinks are treated transparently, except when they're bad. Ok for simplicity and clarity reasons we always reverted to the current solution. A noble cause. Yes ;) Cheers, Anselm
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 01:32 PM, pancake wrote: i would probably even improve the heap usage of this .c, but it's better solution than the shellscript one IMHO. How? Elmo Todurov
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 01:43:06PM +0300, Elmo Todurov wrote: On 05/19/2010 01:32 PM, pancake wrote: i would probably even improve the heap usage of this .c, but it's better solution than the shellscript one IMHO. How? I believe usability is a factor as important as general sucklessness. If the shell script version is annoyingly slow, and there is a comparatively simple .c version that's much faster, I'd go for the .c version... regardless of religious issues (although if the faster version was 5000 lines of c++, I'd think twice about it) Regards, Mate
Re: [dev] [surf] User-Agent string.
Quoth Marvin Vek: It may be be a stupid requirement, the sad fact is that many websites expect it, or act on it. I've been using uzbl without much in the user agent field for a month or two now (since finding eff's panopticlick info), and haven't noticed any site fail for me. Granted I don't use many ajax-heavy sites such as gmail which might be expected to do more checks. To me it looks like not sending the string seems most reasonable. pgp04hFBnH7IX.pgp Description: PGP signature
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 12:24, pancake panc...@youterm.com wrote: 10) put .dmenu_cache path as define on top of C file. so you can change it easily. Nah, change the semantic slightly and pass the cache path in as argument instead. --Anselm
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 02:40 PM, Anselm R Garbe wrote: On 19 May 2010 12:24, pancakepanc...@youterm.com wrote: 10) put .dmenu_cache path as define on top of C file. so you can change it easily. Nah, change the semantic slightly and pass the cache path in as argument instead. Actually, originally I did this, but then I thought, why copy the pointer every time, it's unique and won't change anyway. Elmo
Re: [dev] dmenu_path rewrite in C
Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) So, I see no reason to have it mainline. However, dmenu is very slow when dealing with the history file in uzbl. I have frequently wanted a faster replacement. -- Renick Bell http://the3rd2nd.com
Re: [dev] dmenu_path rewrite in C
Renick Bell ren...@gmail.com writes: Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) So, I see no reason to have it mainline. However, dmenu is very slow when dealing with the history file in uzbl. I have frequently wanted a faster replacement. Slow how? How large is this history file? -- \ Troels /\ Henriksen
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 01:24:46PM +0200, pancake wrote: 2) syntax is not following the suckless style, I would prefer to have all source files in suckless following the same rules. To me it's a silly limitation. The style is clean and uniform across the program, that's all what's needed.
Re: [dev] dmenu_path rewrite in C
Slow how? How large is this history file? Sorry, I am exaggerating. My patience gets ever shorter: a bit over a second for a file for a 49,856 line file at the moment. Maybe I should prune my history. Subjectively, I often feel annoyed by it though, so a faster version is welcome for me. -- Renick Bell http://the3rd2nd.com
Re: [dev] vimium extension for chromium
On Wed, May 19, 2010 at 12:07:31PM +0200, markus schnalke wrote: Vimium and surf are very different; I see hardly any similarity. With s/surf/vimperator/ I can agree. Vimperator had version 0.4 released 30th of April 2007. First Surf commit i see was 11 months ago. I'd say the Surf people are cloning Vimperator. -- Marvin Vek - printk(KERN_CRIT How did I get here? ); linux-2.6.19/arch/mips/kernel/syscall.c
Re: [dev] dmenu_path rewrite in C
On (19/05/10 12:11), Mate Nagy wrote: Date: Wed, 19 May 2010 12:11:38 +0200 From: Mate Nagy mn...@port70.net To: dev mail list dev@suckless.org Subject: Re: [dev] dmenu_path rewrite in C List-Id: dev mail list dev.suckless.org User-Agent: Mutt/1.5.20 (2009-06-14) On Wed, May 19, 2010 at 12:09:33PM +0200, Premysl Hruby wrote: Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) I have cache misses rather often, and the delay *is* annoying. I'd be a happy user of the C rewrite. If you do upgrade your system such often, wouldn't be better to hook-up cache regeneration to your package system? :-) Also, as work-around, it is possible in cache-miss to use older cache, and regenerate new in a background job (which is still as fast as no cache miss occured, but there's problem with running new thingie just right after it's installation) -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dev] dmenu_path rewrite in C
On (19/05/10 12:32), pancake wrote: Date: Wed, 19 May 2010 12:32:06 +0200 From: pancake panc...@youterm.com To: dev@suckless.org Subject: Re: [dev] dmenu_path rewrite in C X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) List-Id: dev mail list dev.suckless.org in my laptop difference is between 0.4s and 0.02s which is enought important performance change for me. I also suffer this slow down in the shellscript version..but sometimes it gets about 5 or 10 seconds to complete (at first boot, or after updating the system). which is really anoying. i would probably even improve the heap usage of this .c, but it's better solution than the shellscript one IMHO. 0.4s and 0.02s are runtimes of what, shell(no-miss) and c(no-miss) respectively, or ... -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dev] dmenu_path rewrite in C
On 19/05/2010, Dmitry Maluka dmitrymal...@gmail.com wrote: To me it's a silly limitation. The style is clean and uniform across the program, that's all what's needed. I find it extremely confusing to read - but maybe I'm just not used to the style. Regardless, it's not uniform across the program if it aspires to be a part of dmenu. At the moment it seems a little rough around the edges. I don't think it should replace the shell version unless it becomes comparatively clean and simple; the speed increase doesn't seem worth the complexity. cls
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 03:23 PM, Connor Lane Smith wrote: I find it extremely confusing to read - but maybe I'm just not used to the style. Well, that's the style I'm used to. I tried to find the style guidelines, but the only thing I found is http://suckless.org/devel/style_guide which is pretty thoroughly unhelpful. Anyway, isn't style just figuring out the right parameters for indent (the program)? At the moment it seems a little rough around the edges. I agree. I'm working on some suggested improvements. I don't think it should replace the shell version unless it becomes comparatively clean and simple It will never become simple -- making that uniq() work right can never be as simple as piping data to uniq the program.
Re: [dev] dmenu_path rewrite in C
On Wed, 19 May 2010 21:01:54 +0900 Renick Bell ren...@gmail.com wrote: Slow how? How large is this history file? Sorry, I am exaggerating. My patience gets ever shorter: a bit over a second for a file for a 49,856 line file at the moment. Maybe I should prune my history. Subjectively, I often feel annoyed by it though, so a faster version is welcome for me. note that this thread is about dmenu_path, not dmenu. Dieter
Re: [dev] dmenu_path rewrite in C
On 19/05/2010, Elmo Todurov todu...@gmail.com wrote: Well, that's the style I'm used to. I tried to find the style guidelines, but the only thing I found is http://suckless.org/devel/style_guide which is pretty thoroughly unhelpful. Yeah, that page is sort of lacking. What I did is just read dmenu.c a lot. fwiw the style used for dmenu is almost identical to KR. It will never become simple -- making that uniq() work right can never be as simple as piping data to uniq the program. I meant as simple as the current script's C cousin can be. Still, it might be naturally complex, in which case I'd argue for keeping the shell version... cls
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 02:10:41PM +0200, Marvin Vek wrote: Don't see it as a limitation, getting a uniform look isn't that much work and doesn't create confusion for programmers. But it creates a feeling of the Third Reich. We're not industrial monkeys, are we? Formal things like indentation have nearly nothing in common with code quality and other Suckless goals. Suckless should not become a club like GNU.
[dev] unsubscribe
-- Jonas
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 13:28, Elmo Todurov todu...@gmail.com wrote: On 05/19/2010 03:23 PM, Connor Lane Smith wrote: I find it extremely confusing to read - but maybe I'm just not used to the style. Well, that's the style I'm used to. I tried to find the style guidelines, but the only thing I found is http://suckless.org/devel/style_guide which is pretty thoroughly unhelpful. Sorry that's on my TODO list always in the bottom area ;)
Re: [dev] dmenu_path rewrite in C
On 19/05/2010, Dmitry Maluka dmitrymal...@gmail.com wrote: But it creates a feeling of the Third Reich. Godwin! Formal things like indentation have nearly nothing in common with code quality and other Suckless goals. Code quality is for the programmer as well as the computer. Basically it's really nice if we can read the program easily. You might say that different styles are equal in their readability (though I personally think KR trumps), but do we really have to learn a hundred different dialects? If we use similar styles it makes it a lot easier to contribute to new projects. Being helpful isn't Nazism, surprisingly. cls
Re: [dev] unsubscribe
On 05/19/2010 02:36 PM, Jonas H. wrote: wutt, doesn't this work on this installation? anyways, please unsubscribe me. Jonas
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 13:38, Dmitry Maluka dmitrymal...@gmail.com wrote: On Wed, May 19, 2010 at 02:10:41PM +0200, Marvin Vek wrote: Don't see it as a limitation, getting a uniform look isn't that much work and doesn't create confusion for programmers. But it creates a feeling of the Third Reich. We're not industrial monkeys, are we? Formal things like indentation have nearly nothing in common with code quality and other Suckless goals. Suckless should not become a club like GNU. I'm very pedantic about code style/formatting, so I think it should be consistent with the other dmenu code. I can't see the relation to the Third Reich though, the code isn't written in German ;)) Cheers, Anselm
Re: [dev] unsubscribe
On 19/05/2010, Jonas H. jo...@lophus.org wrote: wutt, doesn't this work on this installation? anyways, please unsubscribe me. dev+unsubscr...@suckless.org
Re: [dev] vimium extension for chromium
On Wed, May 19, 2010 at 8:02 AM, Marvin Vek l...@onedot.nl wrote: On Wed, May 19, 2010 at 12:07:31PM +0200, markus schnalke wrote: Vimium and surf are very different; I see hardly any similarity. With s/surf/vimperator/ I can agree. Vimperator had version 0.4 released 30th of April 2007. First Surf commit i see was 11 months ago. I'd say the Surf people are cloning Vimperator. I think he meant that vimium was copying vimperator, as s// typically overwrites the former with the latter.
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 02:24 PM, pancake wrote: 1) In unix there's a MAXPATH variable.. in fact GNU does not have this limit, but in unix is 4096 and in plan9 256 (afaik) Actually, PATH_MAX. the thing is that keeping a clean system you shouldn't have paths that big. agreed So you can define a single buffer of this size to strcpy/memcpy/strcat the paths you need to construct the executable paths you need. this will reduce the heap usage a lot. This approach would also add complexity. I would guess that disk IO is the limiting factor to the speed, not malloc. the memory accesses will be hardly reduced because you can keep the basedir on the buffer on all iterations for each directory. only changing filename. Hmm, this is a good point. I think I'll implement (at least some of) it. 2) syntax is not following the suckless style, I would prefer to have all source files in suckless following the same rules. That's easy to fix, and arguably unnecessary. 3) There'r many places where you don't check for result of malloc/getenv is null. Now I do. Haven't finished the cleanup yet, though. 4) many variables can be removed (like copy_path in get_PATH() The question is not whether they can be removed. SHOULD they be removed, this is the question for me. 5) I would add 'die()' instead of perror+exit Done 6) use sizeof(buf) instead of hardcoded size (makes the code safer to changes) Fixed 7) I would change --force flag check to be just '-f' A matter of taste. 8) why do you check for root? Why do you use dmenu_path as root? I can't see any use cases for this. 9) as all filepaths are of similar size you can just allocate blocks of this size and index by using a multiplier which results faster than having many chunks (with some tests i did in 'alt' (hg.youterm.com/alt) this kind of optimizations result in 3-5x faster execution. And would also add much confusion to the reader (and, judging by the mailing list, our readers seem to have sensitive eyes). 10) put .dmenu_cache path as define on top of C file. so you can change it easily. Full path? No thanks, it better sit at $HOME.
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 12:45:42PM +, Connor Lane Smith wrote: You might say that different styles are equal in their readability (though I personally think KR trumps), but do we really have to learn a hundred different dialects? If we use similar styles it makes it a lot easier to contribute to new projects. There's nothing to learn. And we need to discover the code in any way, indentation is nothing. Being helpful isn't Nazism, surprisingly. But there's always a danger of drifting from usefulness into bureaucracy.
Re: [dev] dmenu_path rewrite in C
On 19/05/2010, Elmo Todurov todu...@gmail.com wrote: 7) I would change --force flag check to be just '-f' A matter of taste. Long flags are irritating on the command line, and no other suckless tools use it. It's a matter of taste until it's a matter of consistency. Unix utils would be easier to use without their legacy syntactic differences. 8) why do you check for root? Why do you use dmenu_path as root? I can't see any use cases for this. UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. -- Dennis Ritchie Besides, it's a waste of code. cls
Re: [dev] [surf] User-Agent string.
On Wed, May 19, 2010 at 01:56:22PM +0200, Marvin Vek wrote: Hang on, do you suggest the code for sending the User-Agent string should be removed, or have the User-Agent string empty by default? Is it possible to remove User-Agent completely without patching WebKit?
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 04:23 PM, Connor Lane Smith wrote: On 19/05/2010, Elmo Todurovtodu...@gmail.com wrote: 7) I would change --force flag check to be just '-f' 8) why do you check for root? Why do you use dmenu_path as root? I can't see any use cases for this. UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. -- Dennis Ritchie Besides, it's a waste of code. Heh, OK. You convinced me on both cases. Also, the checking for root sits there for historical reasons. A 2-day-old program can also have historical reasons!
Re: [dev] dmenu_path rewrite in C
Thank you Elmo! On Wed, May 19, 2010 at 12:09:33PM +0200, Premysl Hruby wrote: Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) mine do about three times a week. I use a source based distro over here on my netbook(Samsung NC10), so I'm often working while updating and nearly every compiled packet changes some binary in PATH so it's /quite/ annoying over here to wait about 1.5 seconds for dmenu during that time... Now it's just 0.05 seconds! So, I see no reason to have it mainline. Well, since the shellscript got a noticeable lag that shouldn't exist in any graphical software after all, I suppose speed is a criterion for being suckless in this case. So imho the c-version should be mainline, even if the source should be cleaned before(\t - ' ', source style?, ...) pgpVJecYxpJtY.pgp Description: PGP signature
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 01:46:18PM +0100, Anselm R Garbe wrote: On 19 May 2010 13:38, Dmitry Maluka dmitrymal...@gmail.com wrote: On Wed, May 19, 2010 at 02:10:41PM +0200, Marvin Vek wrote: Don't see it as a limitation, getting a uniform look isn't that much work and doesn't create confusion for programmers. But it creates a feeling of the Third Reich. We're not industrial monkeys, are we? Formal things like indentation have nearly nothing in common with code quality and other Suckless goals. Suckless should not become a club like GNU. I'm very pedantic about code style/formatting, so I think it should be consistent with the other dmenu code. That's OK inside a single project. But you wrote: When it comes to code style questions, it is very likely that individual programmers will disagree. It is absolutely fine to use an individual style for individual projects, especially if only one developer is involved.
Re: [dev] dmenu_path rewrite in C
On 19/05/2010, Dmitry Maluka dmitrymal...@gmail.com wrote: That's OK inside a single project. But you wrote: When it comes to code style questions, it is very likely that individual programmers will disagree. It is absolutely fine to use an individual style for individual projects, especially if only one developer is involved. So are dmenu and dmenu_path separate projects now? Better break out a new hg repo... cls
Re: [dev] dmenu_path rewrite in C
Okay, here's the new version.
Changes:
* no root check
* -f instead of --force
* less mallocs, less copying strings around (no noticeable change in
speed, though)
* die()
Elmo Todurov
/*
* dmenu_path
* This program dumps all executables in $PATH to stdout.
* It uses the file $HOME/.dmenu_cache as a cache.
*
* This program is released under the X11 license (sometimes known as the MIT
* license), which basically means that you can do whatever you want with it.
*
* Sorry for the hairy code. I didn't know how to make it simpler and still
* as generic. Valgrind claims it's correct and doesn't leak, but I'm sure you
* can find a couple of ways to make it crash.
*
* I'd appreciate, but I don't require, that you mail me any improvements or
* comments on the code.
*
* Elmo Todurov todurov+dm...@gmail.com
* 2010-05-19 09:55
*/
#include sys/stat.h
#include stdlib.h
#include stdio.h
#include string.h
#include errno.h
#include malloc.h
#include unistd.h
#include dirent.h
#include assert.h
static uid_t uid;
static gid_t gid;
static char* cache_path;
static int uptodate(char** paths)
{
struct stat dirstat;
time_t cache_time;
char** dirs;
if (stat(cache_path, dirstat))
{
if (errno != ENOENT)
{
perror(stat);
}
return 0;
}
cache_time = dirstat.st_mtime;
dirs = paths;
while (*dirs != NULL)
{
if (stat(*dirs, dirstat))
{
if (errno != ENOENT)
perror(stat);
return 0;
}
if (cache_time dirstat.st_mtime)
return 0;
dirs++;
}
return 1;
}
static void die(const char* msg)
{
perror(msg);
exit(EXIT_FAILURE);
}
static char* get_cache_path()
{
const char* home;
char* path;
home = getenv(HOME);
if (home == NULL)
die(getenv);
path = (char*)malloc(strlen(home) + strlen(/.dmenu_cache) + 1);
if (path == NULL)
die(malloc);
strcpy(path, home);
strcat(path, /.dmenu_cache);
return path;
}
static char* get_PATH()
{
const char* path = getenv(PATH);
char* copy_path;
if (path == NULL)
die(getenv);
copy_path = strdup(path);
return copy_path;
}
static void split_PATH(char* PATH, char*** dirs_in)
{
char** dirs;
const char* dir = strtok(PATH, :);
size_t i = 0;
size_t allocated = 10;
dirs = (char**)malloc(sizeof(char*) * allocated);
if (dirs == NULL)
die(malloc);
while (dir != NULL)
{
dirs[i] = (char*)malloc(strlen(dir) + 1);
if (dirs[i] == NULL)
die(malloc);
strcpy(dirs[i], dir);
dir = strtok(NULL, :);
i++;
if (i == allocated)
{
allocated *= 2;
dirs = (char**)realloc(dirs, allocated * sizeof(char**));
if (dirs == NULL)
die(realloc);
}
}
dirs[i] = NULL;
*dirs_in = dirs;
}
static void free_charpp(char** in)
{
char** ptr = in;
while (*ptr != NULL)
{
free(*ptr);
ptr++;
}
free(in);
}
static void fprint_charpp(char** in, FILE* out)
{
char** ptr = in;
while (*ptr != NULL)
{
fputs(*ptr, out);
fputc('\n', out);
ptr++;
}
}
static size_t count_charpp(char** in)
{
char** ptr = in;
size_t count = 0;
while (*ptr != NULL)
{
count++;
ptr++;
}
return count;
}
static int isexecutable(const char* fname)
{
struct stat st;
int ret;
int success;
gid_t* grouplist;
ret = stat(fname, st);
if (ret != 0)
return 0;
if (!S_ISREG(st.st_mode)) /* this catches regular files and symlinks as well */
return 0;
if ((st.st_uid == uid (st.st_mode S_IXUSR) != 0)
|| (st.st_uid != uid st.st_gid != gid (st.st_mode S_IXOTH) != 0))
{
return 1;
}
/* check secondary groups */
if (st.st_mode S_IXGRP)
{
success = 0;
ret = getgroups(0, 0);
grouplist = (gid_t*)malloc(sizeof(gid_t) * ret);
if (grouplist == NULL)
die(malloc);
ret = getgroups(ret, grouplist);
while (ret != 0)
{
ret--;
if (st.st_uid != uid /* for group to match, user must not match. */
st.st_gid == grouplist[ret])
{
success = 1;
break;
}
}
free(grouplist);
return success;
}
return 0;
}
static void add(const char* prog, char*** progs)
{
static unsigned progs_allocated = 0;
static unsigned progs_used = 0;
if (progs_used == progs_allocated)
{
progs_allocated = progs_allocated == 0 ? 256 : progs_allocated * 2;
*progs = (char**)realloc(*progs, sizeof(char*) * progs_allocated);
if (*progs == NULL)
die(realloc);
}
if (prog != NULL)
{
(*progs)[progs_used] = (char*)malloc(strlen(prog) + 1);
if ((*progs)[progs_used] == NULL)
die(malloc);
strcpy((*progs)[progs_used], prog);
progs_used++;
}
else
{
(*progs)[progs_used] = NULL;
}
}
static void refresh_path(const char* path, char*** progs)
{
DIR* dirp = opendir(path);
struct dirent* dp;
char fullpath[PATH_MAX];
char* end;
strcpy(fullpath, path);
end = fullpath + strlen(fullpath);
if (dirp == NULL)
{
if (errno != ENOENT)
perror(opendir);
return;
}
dp
Re: [dev] dmenu_path rewrite in C
On Wed, May 19, 2010 at 01:31:03PM +, Connor Lane Smith wrote: On 19/05/2010, Dmitry Maluka dmitrymal...@gmail.com wrote: That's OK inside a single project. But you wrote: When it comes to code style questions, it is very likely that individual programmers will disagree. It is absolutely fine to use an individual style for individual projects, especially if only one developer is involved. So are dmenu and dmenu_path separate projects now? Better break out a new hg repo... I was talking generally on the harm of indenting fascism. I'm OK with fixing the codestyle of Elmo's dmenu_cache, let's just not be formalists.
Re: [dev] dmenu_path rewrite in C
Elmo Todurov todu...@gmail.com writes: * less mallocs, less copying strings around (no noticeable change in I really think this MAX_PATH thing is a bad idea. You can argue that a system with paths that deep is broken, but I think a suckless program should be able to work in sucky environments as well. -- \ Troels /\ Henriksen
Re: [dev] philosophy
I think, the suckless project is favourable for what is painless for the mind. And that, in the perspective of the machine doesn't have to impose the habits to man. Man have to decide which behaviour is the best in relation with is environment. This ideal can look drastic for somebody, but for me is only a question of taste. Sébastien Lacombe
Re: [dev] vimium extension for chromium
On Tue, May 18, 2010 at 11:44:08PM +0200, pancake wrote: http://vimium.github.com/ It's a nice extension which I use since I started using Google Chrome as my daily web browser. Though some features I use much are not present so I forked the project on github. You may find it interesting: http://wiki.github.com/clamiax/vimium/ bastards trying to cloning surf ;) Nobody want to clone anything; we just would like to use our own browsers in a more comfortable way. Regards, Claudio M. Alessi
Re: [dev] vimium extension for chromium
On May 20, 2010, at 12:14 AM, Claudio M. Alessi smo...@gmail.com wrote: On Tue, May 18, 2010 at 11:44:08PM +0200, pancake wrote: http://vimium.github.com/ It's a nice extension which I use since I started using Google Chrome as my daily web browser. Though some features I use much are not present so I forked the project on github. You may find it interesting: http://wiki.github.com/clamiax/vimium/ bastards trying to cloning surf ;) Nobody want to clone anything; we just would like to use our own browsers in a more comfortable way. It was a joke Regards, Claudio M. Alessi
