Re: [dev] vimium extension for chromium
omg...and so does http://vimperator.org/vimperator ;) On Tue, May 18, 2010 at 11:44 PM, pancake wrote: > http://vimium.github.com/ > > bastards trying to cloning surf ;) > > --pancake > >
[dev] dmenu_path rewrite in C
Hi there.
I rewrote dmenu_path in C. It's an order of magnitude faster than the
shell script on cache misses and around 2 times faster on cache hits.
I'm attaching the code to this mail. I'd be glad to see it included in
dmenu.
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
#include
#include
#include
#include
#include
#include
#include
#include
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 char* get_cache_path()
{
const char* home = getenv("HOME");
char* path = (char*)malloc(strlen(home) + strlen("/.dmenu_cache") + 1);
strcpy(path, home);
strcat(path, "/.dmenu_cache");
return path;
}
static char* get_PATH()
{
const char* path = getenv("PATH");
char* copy_path;
if (path == NULL)
{
perror("getenv");
exit(1);
}
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);
while (dir != NULL)
{
dirs[i] = (char*)malloc(strlen(dir) + 1);
strcpy(dirs[i], dir);
dir = strtok(NULL, ":");
i++;
if (i == allocated)
{
allocated *= 2;
dirs = (char**)realloc(dirs, allocated * sizeof(char**));
}
}
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* dir, const char* file)
{
char* fname;
struct stat st;
int ret;
int success;
gid_t* grouplist;
fname = (char*)malloc(strlen(dir) + strlen(file) + 2);
strcpy(fname, dir);
strcat(fname, "/");
strcat(fname, file);
ret = stat(fname, &st);
free(fname);
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);
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 (prog != NULL)
{
(*progs)[progs_used] = (char*)malloc(strlen(prog) + 1);
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;
if (dirp == NULL)
{
if (errno != ENOENT)
perror("opendir");
return;
}
dp = readdir(dirp);
while (dp != NULL)
{
if (isexecutable(path, dp->d_name))
add(dp->d_name, progs);
dp = readdir(dirp);
}
closedir(dirp);
}
static int compare(const void* a, const void* b)
{
return strcmp(*(const char**)a, *(const char**)b);
}
static void sort(char*** progs
Re: [dev] dmenu_path rewrite in C
Hi Elmo, On 19 May 2010 09:04, Elmo Todurov wrote: > I rewrote dmenu_path in C. It's an order of magnitude faster than the shell > script on cache misses and around 2 times faster on cache hits. > > I'm attaching the code to this mail. I'd be glad to see it included in > dmenu. thanks for your effort. Though I'm a bit uneasy about it. First of all we had similar proposals in the past, so others did a similar thing in C already. However the main reason I'm a bit sceptic is this: I think the existing shell script based dmenu caching is already quite fast (assumed the cache exists) and I doubt that your native tool does make the cache propagation itself faster. 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. I can understand though that visiting, sorting and uniq'ing them inprocess is surely faster than an interpreted shell script. The question is though, if it really justifies a native tool in mainstream dmenu ;) 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. We also had solutions that used find which was considerable faster than current plain sh based approach, but for simplicity and clarity reasons we always reverted to the current solution. I think adding your tool to the patches section into the wiki for now is the right thing to do and we can collect more opinions. Cheers, Anselm
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 2>&1 > /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 2>&1 > /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] vimium extension for chromium
[2010-05-18 23:44] pancake > http://vimium.github.com/ > > bastards trying to cloning surf ;) Vimium and surf are very different; I see hardly any similarity. With s/surf/vimperator/ I can agree. meillo
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 > To: dev mail list > 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 > > 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 2>&1 > /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 2>&1 > /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 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 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 2>&1 > /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 2>&1 > /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:13 PM, Troels Henriksen wrote: 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. Sounds plausible. I'll try it when I get time. Elmo Todurov
Re: [dev] dmenu_path rewrite in C
On 05/19/2010 01:14 PM, Anselm R Garbe wrote: Well and these measures will differ quite a lot from system to system. Sure, they differ in magnitude, but the ratio should stay the same, I believe. For the time being I propose you to announce this tool on the wiki Okay. 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 ;) Nope.. Hard disks get faster over time, of course, but not much. We might see improvements with SSDs, of course, but that's another topic. Elmo Todurov
Re: [dev] dmenu_path rewrite in C
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. On Wed, 19 May 2010 12:09:33 +0200 Premysl Hruby wrote: > On (19/05/10 12:58), Elmo Todurov wrote: > > Date: Wed, 19 May 2010 12:58:16 +0300 > > From: Elmo Todurov > > To: dev mail list > > 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 > > > > 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 2>&1 > /dev/null > > > > For the C program I get typically > > real0m0.008s > > > > For the shell script I get typically > > real0m0.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 2>&1 > /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. > > 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 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 Wed, 19 May 2010 13:43:06 +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? > > Elmo Todurov > 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) the thing is that keeping a clean system you shouldn't have paths that big. 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. 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. 2) syntax is not following the suckless style, I would prefer to have all source files in suckless following the same rules. 3) There'r many places where you don't check for result of malloc/getenv is null. 4) many variables can be removed (like copy_path in get_PATH() 5) I would add 'die()' instead of perror+exit 6) use sizeof(buf) instead of hardcoded size (makes the code safer to changes) 7) I would change --force flag check to be just '-f' 8) why do you check for root? 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. 10) put ".dmenu_cache" path as define on top of C file. so you can change it easily.
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 12:24, pancake 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, pancake 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] [surf] User-Agent string.
On Wed, May 19, 2010 at 12:16:20PM +0100, Nick wrote: > 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. 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? I doubt there'll be fans of the first, when they run into sites where the UA is checked for. On top of that, i never asked if we really need some UA at all, but since we do (and there's probably a reason it has been changed in the past too) i was suggesting to change the string to something more sane. Again, i agree that the UA shouldn't be used. If we don't care about losing Surf users, or Surf users having a second browser for sites that do check for a UA, i'd say give it a go. But i doubt that's the idea Surf was written with. Me myself and i wish to keep it to one, Surf. -- Marvin Vek - /* Only Sun can take such nice parts and fuck up the programming interface * like this. Good job guys... */ linux-2.6.6/drivers/net/sunhme.c
Re: [dev] dmenu_path rewrite in C
Renick Bell 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 > To: dev mail list > Subject: Re: [dev] dmenu_path rewrite in C > List-Id: dev mail list > 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 Wed, May 19, 2010 at 02:57:49PM +0300, Dmitry Maluka wrote: > 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. Looks a bit like Allman style, where Suckless uses a combination of GNU and K&R. Don't see it as a limitation, getting a uniform look isn't that much work and doesn't create confusion for programmers. -- Marvin Vek - fprintf (stderr, "Not ELF nor a.out. Don't blame me. "); linux-2.6.19/arch/sparc64/boot/piggyback.c
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 > 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 > > 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 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 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 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 K&R. > 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 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 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 K&R 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 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. 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 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 K&R 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 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 Todurov 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 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 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
#include
#include
#include
#include
#include
#include
#include
#include
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 = readdir(dirp);
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 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 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] dmenu_path rewrite in C
On 05/19/2010 04:47 PM, Troels Henriksen wrote: Elmo Todurov 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. Do you realize how deep is 4096 characters? Have you tried to make a path that long? Have you ever seen the following error message? If cd fails, why expect dmenu_path would work? cd: error retrieving current directory: getcwd: cannot access parent directories: File name too long For your testing pleasure, here's a skript that creates a deep path. for i in `seq 1 100`;do mkdir thisisalonglongstringthisisalonglongst$i; cd thisisalonglongstringthisisalonglongst$i;done Elmo
Re: [dev] dmenu_path rewrite in C
Isn't all this the purpose of the 'lsx' tool? http://tools.suckless.org/lsx Admittedly it doesn't handle caching, but a hybrid between shell and the lsx tool might result in faster cache regeneration. Regards, Al Gest On 19 May 2010 09:04, Elmo Todurov wrote: > Hi there. > > I rewrote dmenu_path in C. It's an order of magnitude faster than the shell > script on cache misses and around 2 times faster on cache hits. > > I'm attaching the code to this mail. I'd be glad to see it included in > dmenu. > > Elmo Todurov >
Re: [dev] dmenu_path rewrite in C
On Wed, 19 May 2010 16:11:15 +0300
Elmo Todurov wrote:
> > 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.
and filesystem. in reiser there's some lag on first acceses.
> > 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.
i dont see the point of having:
char *moo(){
char *foo;
foo = strdup("bar");
return foo;
}
when you can have:
char *moo() {
return strdup ("bar");
}
> > 7)
> > I would change --force flag check to be just '-f'
>
> A matter of taste.
in suckless, getopt_long should not be used.
> > 8)
> > why do you check for root?
>
> Why do you use dmenu_path as root? I can't see any use cases for this.
I never use this as root, but why put a limitation, and have those bloated 5
LOCs? :)
> > 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).
it's not that 'complex'. code shouldnt look uglier with this change, it's just
to
replace current allocator, which you should do, because failed mallocs must
die().
Another optimization you can do is to remove the 'free()' part. It's useless and
slowdowns the execution. The kernel already frees the heap of the process on
exit(), and it's not a program that will run forever. Only until the end of the
execution.
This change will also speed up the execution.
> > 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.
>
no, I mean relative one from home. But this is just up to discussion, I would
probably
never change this, and probably most of the people will not do it, so it's ok
as is.
--pancake
Re: [dev] dmenu_path rewrite in C
GStreamer people resolved the indentation issue by writing gst-indent. Maybe we can just write a 'sl-indent' to run 'indent' with the right options, and use this in all the projects. IMHO It's just about consistency, not fascism. On Wed, 19 May 2010 16:44:21 +0300 Dmitry Maluka wrote: > On Wed, May 19, 2010 at 01:31:03PM +, Connor Lane Smith wrote: > > On 19/05/2010, Dmitry Maluka 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
On Wed, May 19, 2010 at 5:15 PM, pancake wrote:
> i dont see the point of having:
> char *moo(){
> char *foo;
> foo = strdup("bar");
> return foo;
> }
>
> when you can have:
>
> char *moo() {
> return strdup ("bar");
> }
Tail recursion indeed looks elegant, but doesn't check for NULL, so
you need a named variable anyway. You, however, want to use one
variable for different purposes. (What a hypocrite I am! I'm doing it
all the time in other places. Why do I keep arguing?) I guess I agree
with you.
>> > 7)
>> > I would change --force flag check to be just '-f'
>>
>> A matter of taste.
>
> in suckless, getopt_long should not be used.
Indeed I don't use getopt_long.
>> > 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).
>
> it's not that 'complex'. code shouldnt look uglier with this change, it's
> just to
> replace current allocator, which you should do, because failed mallocs must
> die().
Care to write a patch to prove your point? I must admit I've never
written my own allocators.
> Another optimization you can do is to remove the 'free()' part. It's useless
> and
> slowdowns the execution. The kernel already frees the heap of the process on
> exit(), and it's not a program that will run forever. Only until the end of
> the
> execution.
>
> This change will also speed up the execution.
Hmm. This claim sounded unfounded, so I just benchmarked it. I'm
surprised to admit that you were right.
The reason for free()s, however, was not conserving memory, but valgrindability.
Elmo
Re: [dev] dmenu_path rewrite in C
On 19 May 2010 15:55, Elmo Todurov wrote:
> On Wed, May 19, 2010 at 5:15 PM, pancake wrote:
>> it's not that 'complex'. code shouldnt look uglier with this change, it's
>> just to
>> replace current allocator, which you should do, because failed mallocs must
>> die().
>
> Care to write a patch to prove your point? I must admit I've never
> written my own allocators.
Something like this?
void *
emalloc(uint size) {
void *ret = malloc(size);
if(!ret)
die("malloc", size);
return ret;
}
Re: [dev] dmenu_path rewrite in C
On Wed, 19 May 2010 16:02:54 +0100
Anselm R Garbe wrote:
> On 19 May 2010 15:55, Elmo Todurov wrote:
> > On Wed, May 19, 2010 at 5:15 PM, pancake wrote:
> >> it's not that 'complex'. code shouldnt look uglier with this change, it's
> >> just to
> >> replace current allocator, which you should do, because failed mallocs
> >> must die().
> >
> > Care to write a patch to prove your point? I must admit I've never
> > written my own allocators.
>
> Something like this?
>
> void *
> emalloc(uint size) {
> void *ret = malloc(size);
> if(!ret)
> die("malloc", size);
> return ret;
> }
>
Here's a very generic version of what I proposed. In your case can be hardly
simplified.
http://radare.org/cgi-bin/hg/radare2/file/6c6000dd3695/libr/util/pool.c
The specific version can be found in:
hg clone http://hg.youterm.com/alt
8 static inline AltNode* node_alloc(AltTree *at) {
9 if (at->ncount >= ALLOC_POOL_SIZE) {
10 if (++at->npool >= ALLOC_POOL_COUNT ) {
11 fprintf (stderr, "FAIL: Cannot allocate more memory
in the pool\n");
12 exit(1);
13 }
14 at->nodes[at->npool] = malloc (sizeof
(AltNode)*ALLOC_POOL_SIZE);
15 at->ncount = 0;
16 }
17 return &at->nodes[at->npool][at->ncount++];
18 }
19
20 static AltNode *alt_node_new(AltTree *at) {
21 AltNode *node = node_alloc (at);
22 memset (node, 0, sizeof (AltNode));
23 return node;
24 }
The thing is how many pools you want to support. I would probably not support
more than
one pool.
This concept/implementation of a memory pool allocator is the same as glib
slices. But
smarter, because you can just adapt it to your needs.
--pancake
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" 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
[dev] Surf - simple bookmarking, redux
Hi,
I wanted to post this updated patch for Lorenzo Bolla's bookmark config for
anyone running surf from tip.
Incidentally, I did have to roll back one changeset, the AtomHiLight changes
were giving me trouble.
Overall though, starting to feel a lot faster and stabler - so thanks to
Enno and the rest.
Jeremiah
--- surf/config.def.h 2010-05-19 20:35:21.837581735 -0400
+++ config.def.h 2010-05-19 20:40:02.360892089 -0400
@@ -12,6 +12,18 @@ static time_t sessiontime = 3600;
"prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | dmenu`\" &&" \
"xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
p, q, winid, NULL } }
+
+#define BM_PICK(p, q) { .v = (char *[]){ "/bin/sh", "-c", \
+ "prop=\"`cat ~/.surf/bookmarks | dmenu `\" &&" \
+ "xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
+p, q, winid, NULL } }
+
+#define BM_ADD { .v = (char *[]){ "/bin/sh", "-c", \
+ "(echo `xprop -id $0 _SURF_URI | cut -d '\"' -f 2` && \
+ cat ~/.surf/bookmarks) | sort -u > ~/.surf/bookmarks_new && \
+ mv ~/.surf/bookmarks_new ~/.surf/bookmarks", \
+ winid, NULL } }
+
#define MODKEY GDK_CONTROL_MASK
static Key keys[] = {
/* modifier keyval functionarg Focus */
@@ -33,4 +45,6 @@ static Key keys[] = {
{ MODKEY, GDK_slash, spawn, SETPROP("_SURF_FIND", "_SURF_FIND") },
{ MODKEY, GDK_n, find, { .b = TRUE } },
{ MODKEY|GDK_SHIFT_MASK,GDK_n, find, { .b = FALSE } },
+ { MODKEY, GDK_b, spawn, BM_PICK("_SURF_URI", "_SURF_GO") },
+ { MODKEY|GDK_SHIFT_MASK,GDK_b, spawn, BM_ADD },
};
