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
>
>
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
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
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
[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
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 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
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 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
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 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,
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
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
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
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
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 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 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
> 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 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
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
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.
> 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 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 a
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:
> >
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: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
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 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 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 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, 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
--
Jonas
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 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 05/19/2010 02:36 PM, Jonas H. wrote:
wutt, doesn't this work on this installation?
anyways, please unsubscribe me.
Jonas
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, Jonas H. wrote:
> wutt, doesn't this work on this installation?
>
> anyways, please unsubscribe me.
dev+unsubscr...@suckless.org
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
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 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 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 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?
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
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 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
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
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 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
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 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
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 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
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, 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
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, 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
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
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:/
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
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
61 matches
Mail list logo
