Re: Problem building dmenu tip

Hey,

On 30 November 2010 22:19, julien steinhauser
<julien.steinhauser <at> orange.fr> wrote:
> This is an old topic, I guess you solved it,
> but as I didn't see the answer on the list and met
> the same situation also on OpenBSD with latest dmenu tip :

> Revision 320 is in cause, reverting it fixes the issue.
> patch attached

What is the reason for the failure on OpenBSD? I ask because the given
patch bloats the dmenu_path binary with unnecessary X symbols. The
reason for individual declarations for dmenu and dmenu_path, btw, was
because otherwise GNU make decides that it can attempt to compile them
without any of the specified flags. Don't ask me why, it caused great
anger.

Thanks,
cls

Re: [hack] Having dmenu provide hints about current selected entry

Christophe-Marie Duquesne <chm.duquesne <at> gmail.com> wrote:

> On Mon, Nov 29, 2010 at 2:44 AM, Connor Lane Smith <cls <at> lubutu.com> 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 other cases. To fix that we'd have to
> > select between stdin and XConnectionNumber(dc->dpy).
>
> Here is a patch that implements this idea (still available on my
> bitbucket repo). It actually makes dmenu pretty slow to read stdin.
> comments/fix are welcome.

Attached patch against dmenu-4.2.1 is based on yours but with some
changes.

It reads stdin by blocks not by line that is noticeably reduces number
of invokes of readstdin() and whole select() machinery.
And 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.

From 57071c903d82ab9f7ea5184e2b974ce3e5d2ab21 Mon Sep 17 00:00:00 2001
From: Ramil Farkhshatov <ramil <at> gmx.co.uk>
Date: Wed, 1 Dec 2010 04:25:25 +0300
Subject: [PATCH] Added asynchronous.

---
 dmenu.c |   96 +++++++++++++++++++++++++++++++++++++++++++++++++++-----------

Re: [hack] Having dmenu provide hints about current selected entry

On Wed, Dec 1, 2010 at 2:34 AM, Ramil Farkhshatov <ramil <at> gmx.co.uk> 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 nothing left to
read on stdin (in your example, that would be when readstdin() returns
0)?

Re: [hack] Having dmenu provide hints about current selected entry

Christophe-Marie Duquesne <chm.duquesne <at> gmail.com> wrote:

> On Wed, Dec 1, 2010 at 2:34 AM, Ramil Farkhshatov <ramil <at> gmx.co.uk> 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 nothing left to
> read on stdin (in your example, that would be when readstdin() returns
> 0)?

If dmenu starts matching after exhausting of data then it will not
differ in behaviour from synchronous vanilla version. The condition may
be something like: 

(time_since_last_match_ms > threshold_ms 
|| items_since_last_match > threshold_nitems
|| data_exhausted)

Re: [hack] Having dmenu provide hints about current selected entry

On Wed, Dec 1, 2010 at 12:12 PM, Ramil Farkhshatov <ramil <at> gmx.co.uk> wrote:
> Christophe-Marie Duquesne <chm.duquesne <at> gmail.com> 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 more or less
the initial goal, wasn't it? This way, if data arrives on stdin, it is
read as fast as possible (blocking the user from typing stuff
meanwhile, but minimizing the time needed for reading) and if there is
no data left to read, dmenu will read X events. If there is not too
much data to read (in a case like a google_suggest script, which feeds
10 lines to stdin at each stroke) this should feel instantaneous.

Re: Problem building dmenu tip

On Wed, Dec 01, 2010 at 12:00:51AM +0000, Connor Lane Smith wrote:

> What is the reason for the failure on OpenBSD?

Before doing anything, I had the same message as Josh's :

make                                                                                                                                                                   
dmenu build options:
CFLAGS   = -std=c99 -pedantic -Wall -Os -I/usr/X11R6/include -D_BSD_SOURCE -DVERSION="4.2.1" 
LDFLAGS  = -s -L/usr/X11R6/lib -lX11 
CC       = cc
CC -c dmenu.c
CC -c draw.c
CC -o dmenu
/usr/X11R6/lib/libX11.so.13.0: warning: strcpy() is almost always misused, please use strlcpy()
/usr/X11R6/lib/libX11.so.13.0: warning: sprintf() is often misused, please use snprintf()
/usr/X11R6/lib/libX11.so.13.0: warning: strcat() is almost always misused, please use strlcat()
/usr/lib/crt0.o(.text+0x93): In function `___start':
: undefined reference to `main'
collect2: ld returned 1 exit status
*** Error code 1

> I ask because the given
> patch bloats the dmenu_path binary with unnecessary X symbols. The
> reason for individual declarations for dmenu and dmenu_path, btw, was
> because otherwise GNU make decides that it can attempt to compile them
> without any of the specified flags. 

I first just tried to revert 320 while keeping along
with the style of the current Makefile,

Re: [hack] Having dmenu provide hints about current selected entry

Ramil Farkhshatov <ramil <at> gmx.co.uk> wrote:

> The condition may > be something like: 
>
> (time_since_last_match_ms > threshold_ms 
> || items_since_last_match > threshold_nitems
> || data_exhausted)

Stupid me. We can just match added single item.

Re: Problem building dmenu tip

Isn't suckless supposed to use a portable subset of Makefile that's understood
by most make-programs?
Relying on gmake is usually a bad idea, even if it's present everywhere. I try
to keep my makefiles portable by - for instance - using 

.c.o:
	<rule>

instead of 

%.o: %.c
	<rule>

which would be a GNU extension.

Just sayin'. Writing portable makefiles is perfectly possible for our
simple needs. (In my opinion, it's even possible for projects far larger than
ours). Do yourself and us a favour and test your makefiles using bmake before
deploying. Packages exist for $LINUX_DISTRO!

Re: Problem building dmenu tip

Hey,

I've pushed a patch which should work to tip. Funnily enough if you
want an elegant solution you either have to use GNU make *or* BSD
make. To make them both happy you have to list every dependency twice.

No kidding.

Thanks,
cls

on screen keyboards and dwm, part II

Hi,

There's an old forum thread from last year that just seems to have died out
about the subject.  Did those patches ever get into main dwm?  If so, they
don't look anything like the one that, e.g., Gottox recommended.  As for the
Gottox patch (http://s01.de/~tox/hg/dwm/rev/d3c3a8018349) this didn't have 
any obvious effect when I added it to the latest hg tip.  I haven't had time 
to play too much here, but if anyone has some concrete instructions on how
to get dwm to play nice with on screen keyboards (svkbd, xvkbd, etc),
please, do, let me know.

Peter

                                                                                          
--

-- 
sic dicit magister P
PhD Candidate
Collaborative Programme in Ancient and Medieval Philosophy
University of Toronto
http://individual.utoronto.ca/peterjh