The only sentence I don't like in the wikipedia article is "JSON
syntax is a subset of YAML version 1.2".
If json is only a subset of YAML, it means the potential bloat is much
more important in YAML than in json.
Apart from that, I found the stuff in this page very readable (more
readable in com
Sorry, I know this topic is old, but I was wondering: Why is YAML
considered harmful? It's on http://harmful.cat-v.org/software/, but I
can't find references about why I should not use it. Do you guys have
documents or readings to provide about this?
Hi there,
I wanted a menu that would allow me to select entries both from the
uzbl history and from google suggest 'as you type' (like in firefox).
While dmenu allows selecting entries in a static list (like uzbl
history) easily, modifying this list and providing hints to google
suggest did not se
On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck wrote:
> the delay caused by dmenu waiting for stdin input to be complete
> is noticeable.
Actually, while performance also matters, the thread thing is not
primarily a matter of fast processing. It is just that if you wait for
the input to finish
On Fri, Nov 26, 2010 at 4:36 PM, Anselm R Garbe wrote:
> With vanilla dmenu
>
> seq 10 | dmenu
>
> works instantaneously for me. I see some 2s lack if I increase to seq
> 100 | dmenu though.
> But is 1M items a usual scenario? I kind of doubt that and the 2s
> penalty doesn't sound too bad
Hi,
I rewrote my proposal with select(). Now readstdin() will return if it
cannot read data from stdin during more than 1 u_sec. It will set the
static flag 'eof' to 1 if it has read the end of file character. This
way while eof is 0, you know you should call readstdin() again.
Attached is a patc
On Mon, Nov 29, 2010 at 2:44 AM, Connor Lane Smith wrote:
> Great, it's a lot cleaner this way. One problem with this approach,
> though, is that if data is written to stdin it isn't displayed until
> the next X event. This is likely fine for your use case, and
> dmenu_run, but perhaps not for oth
On Mon, Nov 29, 2010 at 2:44 AM, Connor Lane Smith wrote:
> Great, it's a lot cleaner this way. One problem with this approach,
> though, is that if data is written to stdin it isn't displayed until
> the next X event. This is likely fine for your use case, and
> dmenu_run, but perhaps not for oth
On Wed, Dec 1, 2010 at 2:34 AM, Ramil Farkhshatov wrote:
> it doesn't run match() on each item, that increases speed and
> reduces cpu usage. But conditions to run match() must be reconsidered:
> in this patch it is called once a second.
Would it make sense to call match() only when there is not
On Wed, Dec 1, 2010 at 12:12 PM, Ramil Farkhshatov wrote:
> Christophe-Marie Duquesne wrote:
> If dmenu starts matching after exhausting of data then it will not
> differ in behaviour from synchronous vanilla version.
Except it won't block if it does not read EOF, which was mo
The following patch does what I proposed. 'seq 1 100 | ./dmenu'
just feels as fast as the vanilla dmenu. After each select(), the file
descriptors are read until there is no data left on them (and match()
is called only once all the data in stdin has been read).
Cheers,
Christophe-Marie
diff -
This patch includes a small correction I forgot to put in the previous
patch. There is no need to specify a timeval to wait for (select
should block until some data arrives either on stdin or on the x11
file descriptor, as recommended by the select() man page).
diff -r 2b9683c50723 dmenu.c
--- a/dm
Hi,
awesome wm lets me spawn uzbl clients "in background". I use the following rule:
{ rule = { class = "Uzbl" },
focus = false,
lower = true } },
- 'lower = true' is for preventing the newly spawned clients to go on
top of the currently seen client.
- 'focus = false' is for pr
I now realize I made this mail a bit too long about awesome and not
long enough about wmii.
tl;dr, I just do want uzbl clients not to automatically go in /client/sel
Looking at http://www.uzbl.org/wiki/wmii, it seems that Dieter has the
same problem as me. Did you fix that?
I would personally be glad to have this feature. It could be cool to
be able to specify that as a rule, like:
wmiir write /rules <
If your program needs UML diagrams documentation, it sucks by
definition. IMHO building such a tool would go against the suckless
philosophy. Good code is supposed to be readable, and should need no
UML diagram (and probably very few comments).
On Wed, May 11, 2011 at 11:42 PM, Nicolai Waniek wrote:
> On 05/10/2011 04:57 PM, Christophe-Marie Duquesne wrote:
>> Good code is supposed to be readable, and should need no
>> UML diagram (and probably very few comments).
>
> Though you're right that it should not _n
I think you sumarized the situation pretty well: All smartphone suck.
Even though they switched to windows mobile, Nokia is supposed to
release a MeeGo compatible device this year (called n950/n9 whatever).
For me it's wait and see.
--
Christophe-Marie Duquesne
On Mon, Mar 10, 2014 at 6:33 AM, Christoph Lohmann <2...@r-36.net> wrote:
> Stop spreading this screencast crap. Use some expressive
> language, maybe a screenshot and _text_ to describe what you are doing.
> This is easier to read, can be easier stored, searched / grepped, trans‐
> lated, changed
> # auto startx if logging in at VC/1
> if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then
> startx >& ~/.myXLog
> logout
> fi
I do the same. Fastest login manager I know. If you have anything
faster to suggest, I'll take it.
Hi,
Why not zeromq? It seems to be light, simple and performant. It also
has extended documentation, and a large community to support it.
Tof
On Tue, Nov 20, 2012 at 2:07 PM, hiro <23h...@gmail.com> wrote:
> I block only in my DNS. I think it's the most important feature of my
> home network. Not only because it blocks ads, but also because it
> block fads.
How do you proceed? Do you actually blackhole blocked domains, or do
you redirec
22 matches
Mail list logo
