pancake dixit (2010-05-19, 16:15):
> 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.
> >
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
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
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
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
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
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_pa
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 ab
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.
--
\
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 u
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_ca
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
> de
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 programm
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(Samsun
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 s
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
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 con
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 sing
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 industri
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 ca
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
> ht
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
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.
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 a
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 thor
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
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 differ
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.
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 +0
> 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.
--
R
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.
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 wante
> 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.
--
Re
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
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
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
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 sucklessne
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
gt; > 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:
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,
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
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 th
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) h
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
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
> L
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
practi
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 e
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 executa
48 matches
Mail list logo
