Re: [dev] Patches to fix . for insert and change commands

[random832]

On Tue, Nov 18, 2014, at 17:59, Stephen Paul Weber wrote:
> I've written up patches to make it so that I, a, A, s, ce, etc can be 
> repeated properly with .  -- not sure if I'm doing this the Right Way,
> but 
> it seems to work in my tests.  Feedback appreciated.  Patches attached.

Haven't looked at your patch, but vim stores the inserted keystrokes
(not text - it'll happily let you repeat an inserted sequence of
backspaces that deleted over the beginning of the insertion region,
arrows that moved the cursor, etc) in a read-only register named with
the period character. Pasting it with ^R. or ^A in insert-mode plays
back the keystrokes and adds them to the text which will be in the
register the next time you leave insert mode. I don't know offhand if
this register is used for the . command or not.

[dev] [sbase][patch] make libutf.a and libutil.a different

[Jean-Philippe Gagné Guay]

The Makefile made libutil.a and libutf.a identical. Here is a patch to fix this.
diff --git a/Makefile b/Makefile
index 1f01866..9143406 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,11 @@ $(OBJ): $(HDR) config.mk
 .c.o:
 	$(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $<
 
-$(LIB): $(LIBUTFOBJ) $(LIBUTILOBJ)
+$(LIBUTF): $(LIBUTFOBJ)
+	$(AR) -r -c $@ $?
+	$(RANLIB) $@
+
+$(LIBUTIL): $(LIBUTILOBJ)
 	$(AR) -r -c $@ $?
 	$(RANLIB) $@
 

[dev] Patches to fix . for insert and change commands

[Stephen Paul Weber]

I've written up patches to make it so that I, a, A, s, ce, etc can be 
repeated properly with .  -- not sure if I'm doing this the Right Way, but 
it seems to work in my tests.  Feedback appreciated.  Patches attached.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
From 06e04fa98dda188c440604d457c6497e78873d00 Mon Sep 17 00:00:00 2001
From: Stephen Paul Weber 
Date: Tue, 18 Nov 2014 17:56:19 -0500
Subject: [PATCH 1/2] Allow repeatable insert-after-move

Previously we forgot what move was made when repeating an insert.
No more!
---
 config.def.h |  5 +
 vis.c| 20 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/config.def.h b/config.def.h
index f41dd81..160edfc 100644
--- a/config.def.h
+++ b/config.def.h
@@ -390,7 +390,7 @@ static KeyBinding vis_mode_normal[] = {
 	{ { NONE('J')   }, join,   { .i = MOVE_SCREEN_LINE_DOWN} },
 	{ { NONE('x')   }, delete, { .i = MOVE_CHAR_NEXT   } },
 	{ { NONE('r')   }, replace,{ NULL  } },
-	{ { NONE('i')   }, switchmode, { .i = VIS_MODE_INSERT  } },
+	{ { NONE('i')   }, insertmode, { .i = MOVE_NO_MOVE } },
 	{ { NONE('v')   }, switchmode, { .i = VIS_MODE_VISUAL  } },
 	{ { NONE('V')   }, switchmode, { .i = VIS_MODE_VISUAL_LINE } },
 	{ { NONE('R')   }, switchmode, { .i = VIS_MODE_REPLACE } },
@@ -561,9 +561,6 @@ static void vis_mode_insert_idle(void) {
 
 static void vis_mode_insert_input(const char *str, size_t len) {
 	editor_insert_key(vis, str, len);
-	/* make sure we can repeat the last insert */
-	action_reset(&action_prev);
-	action_prev.op = &ops[OP_REPEAT_INSERT];
 }
 
 static KeyBinding vis_mode_replace[] = {
diff --git a/vis.c b/vis.c
index 696d0f2..66d4b5a 100644
--- a/vis.c
+++ b/vis.c
@@ -193,6 +193,7 @@ static Operator ops[] = {
 
 /* these can be passed as int argument to movement(&(const Arg){ .i = MOVE_* }) */
 enum {
+	MOVE_NO_MOVE,
 	MOVE_SCREEN_LINE_UP,
 	MOVE_SCREEN_LINE_DOWN,
 	MOVE_SCREEN_LINE_BEGIN,
@@ -272,6 +273,7 @@ static size_t window_lines_middle(const Arg *arg);
 static size_t window_lines_bottom(const Arg *arg);
 
 static Movement moves[] = {
+	[MOVE_NO_MOVE] = { },
 	[MOVE_SCREEN_LINE_UP]  = { .win = window_line_up   },
 	[MOVE_SCREEN_LINE_DOWN]= { .win = window_line_down },
 	[MOVE_SCREEN_LINE_BEGIN]   = { .win = window_line_begin,.type = CHARWISE   },
@@ -635,8 +637,10 @@ static void op_case_change(OperatorContext *c) {
 static void op_repeat_insert(OperatorContext *c) {
 	const char *content;
 	size_t len = text_last_insertion(vis->win->text, &content);
-	editor_insert(vis, c->pos, content, len);
-	window_cursor_to(vis->win->win, c->pos + len);
+	size_t pos = c->pos == c->range.start ? c->range.end : c->range.start;
+
+	editor_insert(vis, pos, content, len);
+	window_cursor_to(vis->win->win, pos + len);
 }
 
 static void op_join(OperatorContext *c) {
@@ -909,8 +913,18 @@ static void zero(const Arg *arg) {
 }
 
 static void insertmode(const Arg *arg) {
+	bool old_linewise = action.linewise;
+
 	movement(arg);
 	switchmode(&(const Arg){ .i = VIS_MODE_INSERT });
+
+	/* So we can repeat the insert with movement */
+	action_reset(&action_prev);
+	action_prev.op = &ops[OP_REPEAT_INSERT];
+	if (old_linewise && arg->i < LENGTH(moves_linewise))
+		action_prev.textobj = moves_linewise[arg->i];
+	else
+		action_prev.movement = &moves[arg->i];
 }
 
 static void change(const Arg *arg) {
@@ -1090,7 +1104,7 @@ static void action_do(Action *a) {
 pos = a->movement->txt(txt, pos);
 			else if (a->movement->win)
 pos = a->movement->win(win);
-			else
+			else if (a->movement->cmd)
 pos = a->movement->cmd(&a->arg);
 			if (pos == EPOS || a->movement->type & IDEMPOTENT)
 break;
-- 
1.9.1

From 1e5c8f49d3eafcb3a31e68ad83310546141bd697 Mon Sep 17 00:00:00 2001
From: Stephen Paul Weber 
Date: Tue, 18 Nov 2014 17:57:02 -0500
Subject: [PATCH 2/2] Allow repeatable change operations

Previously we only repeated the insert.  Then we only repeated the
delete.
This change repeats both the delete and the insert.
---
 vis.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/vis.c b/vis.c
index 66d4b5a..0282678 100644
--- a/vis.c
+++ b/vis.c
@@ -161,6 +161,7 @@ static void op_shift_right(OperatorContext *c);
 static void op_shift_left(OperatorContext *c);
 static void op_case_change(OperatorContext *c);
 static void op_repeat_insert(OperatorContext *c);
+static void op_repeat_change(OperatorContext *c);
 static void op_join(OperatorContext *c);
 
 /* these can be passed as int argument to operator(&(const Arg){ .i = OP_*}) */
@@ -173,6 +174,7 @@ enum {
 	OP_SHIFT_LEFT,
 	OP

Re: [dev] why avoid install?

[pancake]

install does this in a shot, using 'cp' is just a 20% of what install does:

rm  -> to ensure that the file is not being used
mkdir
cp
chmod
chown

the rm part is important, because otherwise the cp may fail if the 
prorgam is running.


also, a useful install target ihave in some programs of me is doing a 
"symstall",
which does ln -fs instead of cp. that is useful when you dont want to 
run 'make install'
every time you build. i know thats insecure and that the files can only 
be used by
the current user and root, but it can be also installed on a different 
path. but i
this this is not a problem for suckless software and probably not 
interesting to have

it in that slinstall thing

On 11/18/2014 09:56 PM, FRIGN wrote:

On Tue, 18 Nov 2014 15:49:36 -0500
Wolfgang Corcoran-Mathe  wrote:
  

There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
install-ing to a package directory, and (b) isn't this what
POSIX cp -f is for?

Exactly!

[dev] [sbase][patch]cat stdin if arg is exactly "-" not begins with '-'

[Evan Gates]

This patch makes
cat -- -foo
cat the file ./foo and not stdin.

emg
From 71b02bf573c5345ee0994192ad74d591dc89a7d4 Mon Sep 17 00:00:00 2001
From: Evan Gates 
Date: Tue, 18 Nov 2014 13:41:52 -0800
Subject: [PATCH] read stdin if arg is exactly "-" not just begins with '-'

---
 cat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cat.c b/cat.c
index a7842c8..fbf8069 100644
--- a/cat.c
+++ b/cat.c
@@ -30,7 +30,7 @@ main(int argc, char *argv[])
concat(stdin, "", stdout, "");
} else {
for (; argc; argc--, argv++) {
-   if (argv[0][0] == '-')
+   if (argv[0][0] == '-' && !argv[0][1])
argv[0] = "/dev/fd/0";
if (!(fp = fopen(argv[0], "r"))) {
weprintf("fopen %s:", argv[0]);
-- 
2.1.3

Re: [dev] [sbase] style

[M Farkas-Dyck]

On 18/11/2014, Louis Santillan  wrote:
> Returning error code doesn't work well for many asynchronous calls (aio_*) 
> [0].

Why? aio_error indeed returns an error code, and separate aio_return
and aio_error would not even be needed if read, write, etc returned as
I proposed, as one call could so return:
• EINPROGRESS: not yet complete
• ECANCELED: canceled
• other: return value of synchronous operation

Re: [dev] [sbase][patch] remove agetline

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 12:51:32PM -0800, Evan Gates wrote:
> agetline was a straight passthrough to getline, here's a patch to remove it.
> emg

Applied, thanks!

Re: [dev] why avoid install?

[pancake]

another anoying thing of pkg-config is that it uses longopt

--libs can be -l
--cflags can be -c
--list-all can be -a
--version can be -v
...

but if we want it to be compatible we should handle the longopt ones :(

the only "complicated" part is the version number comparison, because
its not just a number vs number, some packages use a very fucked up
version number. but i doubt we should support them. version numbers
should be *easy* to read and parse.

On 11/18/2014 09:49 PM, Wolfgang Corcoran-Mathe wrote:

Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:

Well, install doesn't do any magic.


There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
install-ing to a package directory, and (b) isn't this what
POSIX cp -f is for?

Re: [dev] why avoid install?

[FRIGN]

On Tue, 18 Nov 2014 15:49:36 -0500
Wolfgang Corcoran-Mathe  wrote:
 
> There is this.[1] But if the issue is unlinking a running target,
> (a) how often is this an issue, considering one will often be make
> install-ing to a package directory, and (b) isn't this what
> POSIX cp -f is for?

Exactly!

-- 
FRIGN 

[dev] [sbase][patch] remove agetline

[Evan Gates]

agetline was a straight passthrough to getline, here's a patch to remove it.
emg
From cffea4efd18fc818b1529f8276a688f5a77fc93a Mon Sep 17 00:00:00 2001
From: Evan Gates 
Date: Tue, 18 Nov 2014 12:49:30 -0800
Subject: [PATCH] remove agetline

---
 Makefile   |  1 -
 cut.c  |  2 +-
 fold.c |  2 +-
 grep.c |  2 +-
 head.c |  2 +-
 libutil/agetline.c | 13 -
 libutil/crypt.c|  2 +-
 libutil/getlines.c |  2 +-
 nl.c   |  2 +-
 tail.c |  4 ++--
 text.h |  1 -
 tr.c   |  2 +-
 uniq.c |  2 +-
 uudecode.c |  4 ++--
 14 files changed, 13 insertions(+), 28 deletions(-)
 delete mode 100644 libutil/agetline.c

diff --git a/Makefile b/Makefile
index f60985c..1f01866 100644
--- a/Makefile
+++ b/Makefile
@@ -27,7 +27,6 @@ LIBUTFSRC =\
 LIBUTIL = libutil.a
 LIBUTILSRC =\
libutil/agetcwd.c\
-   libutil/agetline.c\
libutil/apathmax.c\
libutil/concat.c\
libutil/cp.c\
diff --git a/cut.c b/cut.c
index 97d2f2a..0206e47 100644
--- a/cut.c
+++ b/cut.c
@@ -121,7 +121,7 @@ cut(FILE *fp)
ssize_t len;
Range *r;
 
-   while ((len = agetline(&buf, &size, fp)) != -1) {
+   while ((len = getline(&buf, &size, fp)) != -1) {
if (len && buf[len - 1] == '\n')
buf[len - 1] = '\0';
if (mode == 'f' && !strchr(buf, delim)) {
diff --git a/fold.c b/fold.c
index 92585af..735b53b 100644
--- a/fold.c
+++ b/fold.c
@@ -64,7 +64,7 @@ fold(FILE *fp, long width)
char *buf = NULL;
size_t size = 0;
 
-   while (agetline(&buf, &size, fp) != -1)
+   while (getline(&buf, &size, fp) != -1)
foldline(buf, width);
free(buf);
 }
diff --git a/grep.c b/grep.c
index dc379d5..08d0b0a 100644
--- a/grep.c
+++ b/grep.c
@@ -132,7 +132,7 @@ grep(FILE *fp, const char *str)
struct pattern *pnode;
int match = NoMatch;
 
-   for (n = 1; (len = agetline(&buf, &size, fp)) != -1; n++) {
+   for (n = 1; (len = getline(&buf, &size, fp)) != -1; n++) {
/* Remove the trailing newline if one is present. */
if (len && buf[len - 1] == '\n')
buf[len - 1] = '\0';
diff --git a/head.c b/head.c
index 6f32177..f2c6206 100644
--- a/head.c
+++ b/head.c
@@ -56,7 +56,7 @@ head(FILE *fp, const char *str, long n)
ssize_t len;
unsigned long i = 0;
 
-   while (i < n && ((len = agetline(&buf, &size, fp)) != -1)) {
+   while (i < n && ((len = getline(&buf, &size, fp)) != -1)) {
fputs(buf, stdout);
if (buf[len - 1] == '\n')
i++;
diff --git a/libutil/agetline.c b/libutil/agetline.c
deleted file mode 100644
index 0953dac..000
--- a/libutil/agetline.c
+++ /dev/null
@@ -1,13 +0,0 @@
-/* See LICENSE file for copyright and license details. */
-#include 
-#include 
-#include 
-
-#include "../text.h"
-#include "../util.h"
-
-ssize_t
-agetline(char **p, size_t *size, FILE *fp)
-{
-   return getline(p, size, fp);
-}
diff --git a/libutil/crypt.c b/libutil/crypt.c
index 458f11c..2d2ab39 100644
--- a/libutil/crypt.c
+++ b/libutil/crypt.c
@@ -51,7 +51,7 @@ cryptcheck(char *sumfile, int argc, char *argv[],
else if (!(cfp = fopen(sumfile, "r")))
eprintf("fopen %s:", sumfile);
 
-   while (agetline(&line, &bufsiz, cfp) != -1) {
+   while (getline(&line, &bufsiz, cfp) != -1) {
if (!(file = strstr(line, "  "))) {
formatsucks++;
continue;
diff --git a/libutil/getlines.c b/libutil/getlines.c
index df64544..55e9bf4 100644
--- a/libutil/getlines.c
+++ b/libutil/getlines.c
@@ -13,7 +13,7 @@ getlines(FILE *fp, struct linebuf *b)
size_t size = 0, linelen;
ssize_t len;
 
-   while ((len = agetline(&line, &size, fp)) != -1) {
+   while ((len = getline(&line, &size, fp)) != -1) {
if (++b->nlines > b->capacity) {
b->capacity += 512;
nline = erealloc(b->lines, b->capacity * 
sizeof(*b->lines));
diff --git a/nl.c b/nl.c
index 3557362..17e4177 100644
--- a/nl.c
+++ b/nl.c
@@ -69,7 +69,7 @@ nl(FILE *fp)
long n = 0;
size_t size = 0;
 
-   while (agetline(&buf, &size, fp) != -1) {
+   while (getline(&buf, &size, fp) != -1) {
if ((mode == 'a')
|| (mode == 'p'
&& !regexec(&preg, buf, 0, NULL, 0))
diff --git a/tail.c b/tail.c
index b53ec8d..b399cf2 100644
--- a/tail.c
+++ b/tail.c
@@ -61,7 +61,7 @@ dropinit(FILE *fp, const char *str, long n)
ssize_t len;
unsigned long i = 0;
 
-   while (i < n && ((len = agetline(&buf, &size, fp)) != -1))
+   while (i < n && ((len = getline(&buf, &size, fp)) != -1))
if (len && buf[len - 1] == '\n')
i++;
free(buf);
@

Re: [dev] why avoid install?

[Wolfgang Corcoran-Mathe]

Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:

Well, install doesn't do any magic.


There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
install-ing to a package directory, and (b) isn't this what
POSIX cp -f is for?

--
Wolfgang Corcoran-Mathe

[1] http://en.chys.info/2009/05/install-vs-cp-and-mmap/

Re: [dev] why avoid install?

[Dimitris Papastamos]

> Provided that suckless.org does not provide many needed tools, and that
> writing suckless code to replace everything that actually needs
> replacement takes long, I gather that such suckless pkg-config should
> happen.  More so if it can replace tools that suck even more, like
> GNU autocrap.

Waiting for patches in silent excitement.

Re: [dev] why avoid install?

[Dmitrij D. Czarkoff]

pancake said:
> oh. that's why ldd was telling me that there was no glib
> 
>   --with-internal-glibuse internal glib

Nice they didn't bundle glibc and linux kernel as well.

-- 
Dmitrij D. Czarkoff

Re: [dev] why avoid install?

[Dmitrij D. Czarkoff]

pancake said:
> I didnt knew that pkg-conf thing, but perl or 900 lines seems still
> too bloated for me.

I agree.

> i have a two line shellscript that can replace 99% use of pkg-config,
> because its just grep and cut with few conditionals. that's why i was
> proposing to have a suckless pkg-config.

I don't have such script, but I suppose that all of pkg-config can be
implemented in awk or in shell+grep.  That would be suckless.

Provided that suckless.org does not provide many needed tools, and that
writing suckless code to replace everything that actually needs
replacement takes long, I gather that such suckless pkg-config should
happen.  More so if it can replace tools that suck even more, like
GNU autocrap.

-- 
Dmitrij D. Czarkoff

Re: [dev] why avoid install?

[pancake]

oh. that's why ldd was telling me that there was no glib

  --with-internal-glibuse internal glib


On 11/18/2014 09:21 PM, Wander Nauta wrote:


On 11/18/2014 09:16 PM, pancake wrote:

nope. it doesnt depends on anything, just libc. but its half a megabyte
of code

As far as I know, the freedesktop implementation at least depends on
(and bundles) a copy of glib. The BSD implementation probably doesn't.

http://www.freedesktop.org/wiki/Software/pkg-config/

Re: [dev] why avoid install?

[pancake]

i have a two line shellscript that can replace 99% use of pkg-config, 
because its just grep and
cut with few conditionals. that's why i was proposing to have a suckless 
pkg-config. I know
that that suckless tends to prefer people doing static linking or no 
linking at all and having
everything on fixed paths. But srsly, pkg-config is a nice way to allow 
people find libs and
includes for a project. even if you want multiple versions of them you 
can select them by

changing the PKG_CONFIG_PATH for example which i find it handy.

I didnt knew that pkg-conf thing, but perl or 900 lines seems still too 
bloated for me.


On 11/18/2014 09:13 PM, Dmitrij D. Czarkoff wrote:

pancake said:

Just read the src. Last time i saw it ... It was about 38kloc

Wander Nauta said:

It also depends on glib, which is at the top of the sucks list.

I don't care this particular implementation.  All I care is the idea of
pkg-config.  On OpenBSD there is another implementation, which is not
suckless (~900 lines of Perl), but it does not depend on glib.

Re: [dev] why avoid install?

[Wander Nauta]

On 11/18/2014 09:16 PM, pancake wrote:
> nope. it doesnt depends on anything, just libc. but its half a megabyte
> of code

As far as I know, the freedesktop implementation at least depends on
(and bundles) a copy of glib. The BSD implementation probably doesn't.

http://www.freedesktop.org/wiki/Software/pkg-config/

Re: [dev] [sbase][patch] clear and reorder suffix list

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 12:15:37PM -0800, Evan Gates wrote:
> Small patch to first clear the suffix list then add only the .o and .c
> suffixes in that order. I've included it inline and attached as I'm
> still using gmail and I don't trust it to leave inline text alone.

Thanks, applied :)

Re: [dev] why avoid install?

[pancake]

nope. it doesnt depends on anything, just libc. but its half a megabyte 
of code


On 11/18/2014 08:35 PM, Wander Nauta wrote:

On 11/18/2014 08:18 PM, pancake wrote:

Just read the src. Last time i saw it ... It was about 38kloc

It also depends on glib, which is at the top of the sucks list.

[dev] [sbase][patch] clear and reorder suffix list

[Evan Gates]

Small patch to first clear the suffix list then add only the .o and .c
suffixes in that order. I've included it inline and attached as I'm
still using gmail and I don't trust it to leave inline text alone.

emg



>From 051f20fe06e03dd265122854d733241a7c618923 Mon Sep 17 00:00:00 2001
From: Evan Gates 
Date: Tue, 18 Nov 2014 12:12:14 -0800
Subject: [PATCH] clear suffix list then add only .o and .c in that order to
 avoid use of builtin .c inference rule skipping .c.o

---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 5357bca..f60985c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,7 @@
 include config.mk

-.SUFFIXES: .c .o
+.SUFFIXES:
+.SUFFIXES: .o .c

 HDR =\
  arg.h\
-- 
2.1.3
From 051f20fe06e03dd265122854d733241a7c618923 Mon Sep 17 00:00:00 2001
From: Evan Gates 
Date: Tue, 18 Nov 2014 12:12:14 -0800
Subject: [PATCH] clear suffix list then add only .o and .c in that order to
 avoid use of builtin .c inference rule skipping .c.o

---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 5357bca..f60985c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,7 @@
 include config.mk
 
-.SUFFIXES: .c .o
+.SUFFIXES:
+.SUFFIXES: .o .c
 
 HDR =\
arg.h\
-- 
2.1.3

Re: [dev] why avoid install?

[Dmitrij D. Czarkoff]

pancake said:
> Just read the src. Last time i saw it ... It was about 38kloc

Wander Nauta said:
> It also depends on glib, which is at the top of the sucks list.

I don't care this particular implementation.  All I care is the idea of
pkg-config.  On OpenBSD there is another implementation, which is not
suckless (~900 lines of Perl), but it does not depend on glib.

-- 
Dmitrij D. Czarkoff

Re: [dev] why avoid install?

[Wander Nauta]

On 11/18/2014 08:18 PM, pancake wrote:
> Just read the src. Last time i saw it ... It was about 38kloc

It also depends on glib, which is at the top of the sucks list.

Re: [dev] why avoid install?

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 07:51:10PM +0100, pancake wrote:
> What about a suckless install and a suckless pkgconfig? Both are bloated in 
> nature but can be implemented in a very simple way to replace easily the gnu 
> or bsd implementations

I am planning to add install(1) in sbase.  It is used widely enough
that will make porting easier.

Re: [dev] why avoid install?

[pancake]

Just read the src. Last time i saw it ... It was about 38kloc



> On 18 Nov 2014, at 20:03, Dmitrij D. Czarkoff  wrote:
> 
> FRIGN said:
>> We could discuss install, but there's nothing suckless about pkgconfig.
> 
> What is wrong with pkg-config?
> 
> -- 
> Dmitrij D. Czarkoff
> 

Re: [dev] why avoid install?

[Dmitrij D. Czarkoff]

FRIGN said:
> We could discuss install, but there's nothing suckless about pkgconfig.

What is wrong with pkg-config?

-- 
Dmitrij D. Czarkoff

Re: [dev] why avoid install?

[Felix Janda]

pancake wrote:
> What about a suckless install and a suckless pkgconfig? Both are
> bloated in nature but can be implemented in a very simple way to
> replace easily the gnu or bsd implementations

You are aware of pkg-conf?

Re: [dev] why avoid install?

[FRIGN]

On Tue, 18 Nov 2014 19:51:10 +0100
pancake  wrote:

> What about a suckless install and a suckless pkgconfig? Both are bloated in 
> nature but can be implemented in a very simple way to replace easily the gnu 
> or bsd implementations

We could discuss install, but there's nothing suckless about pkgconfig.

-- 
FRIGN 

Re: [dev] why avoid install?

[pancake]

What about a suckless install and a suckless pkgconfig? Both are bloated in 
nature but can be implemented in a very simple way to replace easily the gnu or 
bsd implementations



> On 18 Nov 2014, at 19:30, FRIGN  wrote:
> 
> On Tue, 18 Nov 2014 13:25:06 -0500
> Greg Reagle  wrote:
> 
>> Hello.  Is there a particular reason that a combination of cp, mkdir,
>> and chmod are used rather than the install command, in several suckless
>> projects (in the install target of Makefile)?  
>> 
>> Sorry if the answer is obvious.  I am trying to learn.  Thanks.
> 
> Well, install doesn't do any magic. The main reason to avoid is that it
> is not POSIX, and if you do the mkdir and chmod right, why use a non-
> standard tool for it which could have arbitrary implementations on
> different systems?
> 
> 
> -- 
> FRIGN 
> 

Re: [dev] why avoid install?

[FRIGN]

On Tue, 18 Nov 2014 13:25:06 -0500
Greg Reagle  wrote:

> Hello.  Is there a particular reason that a combination of cp, mkdir,
> and chmod are used rather than the install command, in several suckless
> projects (in the install target of Makefile)?  
> 
> Sorry if the answer is obvious.  I am trying to learn.  Thanks.

Well, install doesn't do any magic. The main reason to avoid is that it
is not POSIX, and if you do the mkdir and chmod right, why use a non-
standard tool for it which could have arbitrary implementations on
different systems?


-- 
FRIGN 

[dev] why avoid install?

[Greg Reagle]

Hello.  Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the install target of Makefile)?  

Sorry if the answer is obvious.  I am trying to learn.  Thanks.

-- 
http://www.fastmail.com - The way an email service should be

Re: [dev] [sbase] style

[Louis Santillan]

Returning error code doesn't work well for many asynchronous calls
(aio_*) [0].  It also makes errno (possibly) inconsistent, but I
didn't come up with that standard.  I guess someone decided that
making errno inconsistent is less of an issue than make the return
code of libc inconsistent.

[0] 
http://www.gnu.org/software/libc/manual/html_node/Asynchronous-Reads_002fWrites.html#Asynchronous-Reads_002fWrites

On Tue, Nov 18, 2014 at 8:47 AM, Dimitris Papastamos  wrote:
> On Tue, Nov 18, 2014 at 11:35:04AM -0500, M Farkas-Dyck wrote:
>> On 18/11/2014, Dimitris Papastamos  wrote:
>> > On a side note here, for a failing syscall or similar, I think the
>> > idea is to check for < 0 rather than == -1.  I am not opposed to the
>> > latter except that is already used less frequently in sbase.
>>
>> On an edge note, it would be much saner for many syscalls and libc
>> functions to return minus the error code rather than return -1 and set
>> errno, and in the future suckless-dominated world we could do so. The
>> OpenBSD kernel already often does so internally. To check < 0 rather
>> than == -1 would ease transition.
>
> Yes I've always wondered.
>

Re: [dev] [sbase] style

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 11:35:04AM -0500, M Farkas-Dyck wrote:
> On 18/11/2014, Dimitris Papastamos  wrote:
> > On a side note here, for a failing syscall or similar, I think the
> > idea is to check for < 0 rather than == -1.  I am not opposed to the
> > latter except that is already used less frequently in sbase.
> 
> On an edge note, it would be much saner for many syscalls and libc
> functions to return minus the error code rather than return -1 and set
> errno, and in the future suckless-dominated world we could do so. The
> OpenBSD kernel already often does so internally. To check < 0 rather
> than == -1 would ease transition.

Yes I've always wondered.

Re: [dev] [sbase] style

[M Farkas-Dyck]

On 18/11/2014, Dimitris Papastamos  wrote:
> On a side note here, for a failing syscall or similar, I think the
> idea is to check for < 0 rather than == -1.  I am not opposed to the
> latter except that is already used less frequently in sbase.

On an edge note, it would be much saner for many syscalls and libc
functions to return minus the error code rather than return -1 and set
errno, and in the future suckless-dominated world we could do so. The
OpenBSD kernel already often does so internally. To check < 0 rather
than == -1 would ease transition.

Oh, and MAP_FAILED == 0 ought.

Re: [dev] [sbase] style

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 09:53:33AM -0500, Greg Reagle wrote:
> Another way to provide style guidance is to refer to a particular source
> file or project as an epitome or paragon, if such a paragon exists  That
> takes much less time than explicitly developing a style guide.

Yes my initial idea is to refer to style(9) on OpenBSD.  This was suggested
on the IRC channel.

Re: [dev] [sbase] style

[Greg Reagle]

Another way to provide style guidance is to refer to a particular source
file or project as an epitome or paragon, if such a paragon exists  That
takes much less time than explicitly developing a style guide.

-- 
http://www.fastmail.com - Does exactly what it says on the tin

Re: [dev] [sbase] style

[Dimitris Papastamos]

Just a general remark on style guides.

The guide should be followed for all submissions but deviation
is allowed as long as it can be justified or it is clear that
it makes sense.

Given that getting sbase to the point of usability is a difficult
and time consuming task especially with the existing manpower I'd
like to see people focus on fixing bugs, integrating it into an
existing distribution (Alpine Linux or sabotage?) and implementing
missing tools and features.  Reworking sbase to fit these guidelines
is time consuming and not sure it is worth the effort at this point.
All new code submissions should follow the guide as close possible.
We can periodically sweep through sbase and fix these things but there
are more important tasks to focus on at present.

Most of the people who contribute to sbase come from a Plan9 or BSD
or similar background and already are familiar with most of the style
guidelines we are proposing here.  The important consequence is that
they will often _design_ things differently or in a simpler manner.
This approach to solving problems cannot be put down in a guide and it
is far more important in my view than bitching about inconsistencies
in syntax.  Including STYLE in sbase can help contributors to get more
familiar with the accepted style and rather focus on the semantic level
when dealing with patches on the mailing list.

For this reason, I'd like to propose inlining the patches as opposed to
attaching them as that makes it easier to comment inline.  You can still
save it in a file and apply it with git am so it doesn't really add
any burden on the maintainer.

Re: [dev] [sbase] style

[Dimitris Papastamos]

> no block for single statement (optional block? always block? discuss)

It depends.  The following are valid.

if (v) {
bla;
} else {
bla;
bla;
}

if (v) {
bla;
bla;
} else {
bla;
}

if (v)
bla;
else
bla;

The following are invalid.

if (v) {
bla;
bla;
} else
bla;

if (v)
bla;
else {
bla;
bla;
}

Of course use of the ternary operator can be applied wherever it
makes sense.

> (what if inner statement uses block, braces outside? what if one of
> two branches uses block?)
> 
> branches
> 
> if (cond)
> foo();
> else {
> bar();
> baz();
> }
> 
> or
> 
> if (cond) {
> foo();
> } else {
> bar();
> baz();
> }

The latter.

> inner statement block
> -
> if (p)
> while (cond) {
> foo();
> bar();
> }
> 
> or
> 
> if (p) {
> while (cond) {
> foo();
> bar();
> }
> }

The latter.

> headers
> ===
> system headers (#include <...>) in alphabetical order
> empty line
> local headers (#include "...") in alphabetical order
> if there is any reason to change order, comment to explain

system headers first, then a newline, then libc headers, then a
newline then local headers.

libc headers are sorted lexicographically, system and local headers are
included in the proper order.  No preprocessor guards for local headers.

> variadic macros
> ===
> yay or nay?

yes.

> file layout
> ===
> check dwm.c for example
> leading comment with LICENSE notice and short explanation of file
> headers
> macros
> types
> function declarations
> global variables
> function definitions
> main

I propose:

LICENSE header
headers
macros
types
function declarations
global vars
usage /* this could also go below for consistency but I like it here */
main
function definitions

> functions
> =
> declarations at top of file
> declarations, definitions, in alphabetical order (except main, at end of file)
> static if not used outside current file (what's the right term?
> compilation unit?)
> definitions have modifiers and return type on own line
> { on own line (function definitions are special case of block as they
> cannot be nested)

Also parameters should not be named in function declarations.

> C version
> =
> use C99 (why not C11? I really like anonymous unions/structs)

C99.

> do not use for loop initial declarations (why?)

Declare variables at the function level.

> types
> =
> user defined types start with a capital letter
> when possible typedef struct {} Name;

Debatable.  I'd like to hear more opinions on this.

> line length
> ===
> we aren't limited to 80 columns in our terminals anymore, no need to
> pretend we are
> if using more columns makes code more readable, do so
> it also means we can fit more code on a single screen, less scrolling
> (some hard limit so we don't have 300 character lines?)

No.  80 columns per line is sane.  This is not a hard rule and you can
easily have printf() or similar spanning that limit.
The idea is that heavily indented code is probably broken in the first
place and that all good, sane and elegant code should really fit in 80
columns per line.  This implies sane naming conventions and proper use
of continue and break.

> tests (boolean)
> ===
> do not test against 0 explicitly (e.g.  if (!strcmp(p, q)) instead of
> if (strcmp(p, q) == 0)) (discuss)

It should be the latter.  See my other post here for details.

> do use compound assignment and test (e.g. if (!(p =

Debatable.  I prefer this to be on separate lines.

> malloc(sizeof(Type ...; )

p = malloc(sizeof(*p));

> early returns/exits
> ===
> if needed use label + goto for cleanup instead of multiple nested
> levels, however this can normally be avoided (discuss)

No it cannot be avoided easily.

> return/exit/fail early instead of using multiple levels of tests

I am inclined to use exit() everywhere, even in main().  Do not
use EXIT_SUCCESS or EXIT_FAILURE.

> do not clean up on fatal errors (just enprintf())

Other than reporting the correct exit status as specified in POSIX
it should be ok.  Please note that if the output device is full we
need to correctly exit with a failure status if the program has still
output data to be flushed.  This is only a concern in cases where the
program will terminate successfully but failing to print its output.

For large tools, we probably do want to clean up.  I can elaborate
on this further if you are interested but we did have a discussion on
IRC about this.

> remove linebreaks
> -
> switch (a) {
> case '1': foo(b); break;
> case '2': bar(c); break;
> case '3': baz(d); break;
> default :
> enprintf(2, "RTFM\n");
> }

Agreed.  This is to be done on a case by case basis.  We do not need
to worry about consistency if it makes a particular piece of code
more readable.  Sometimes elegance comes as a consequence of not
applying consistency principles blindly.

> more align

Re: [dev] [sbase] style

[Dimitris Papastamos]

On Mon, Nov 17, 2014 at 11:18:36PM +0100, FRIGN wrote:
> On Mon, 17 Nov 2014 14:10:49 -0800
> Bobby Powers  wrote:
> 
> > By default I read  if (!functioncall()) as 'if the function call
> > failed'.  I like the (strcmp(p, q) == 0) idiom because I don't fall
> > into the trap of reading the statement as 'if the string comparison
> > failed'.  It is the one case I can think of where I prefer an explicit
> > comparison to zero.
> 
> De gustibus non est disputandum.
> 
> However, given strcmp is such a special case, I was used to the == 0
> idiom as well.
> However, the more I used the ! the easier it was to read it.

No.  The idea is that if you are comparing pointers or functions/variables
that obviously return 0 or 1 (like isspace() or bflag or similar) then you
can use !v and v.

If you are comparing anything else then you should explicitly check
for it.  strcmp() has 3 classes of return values < 0, == 0 and > 0.

On a side note here, for a failing syscall or similar, I think the
idea is to check for < 0 rather than == -1.  I am not opposed to the
latter except that is already used less frequently in sbase.

Re: [dev] [sbase] style

[Dimitris Papastamos]

On Tue, Nov 18, 2014 at 02:04:30AM +0100, koneu wrote:
> Hi,
> 
> FRIGN wrote:
> > If headers depend on order, the headers are broken. Dismissed.
> 
> Most headers I write are plan9 style[0] headers. "The files are not
> protected against multiple inclusion and themselves contain no nested
> #includes. Instead the programmer is expected to sort out the
> requirements and to #include the necessary files once at the top of each
> source file." It is actually really elegant for small scale projects
> (unless you write C++ and have to manually include 30 layers of
> templates ofcourse).

Yes I second this.  Our local headers do not use preprocessor guards
and we are expected to include them in the appropriate order.  This is
the sane thing to do here.

The libc does make the guarantee that the headers will work in any
include order so they can be sorted lexicographically.

Re: [dev] [sbase] style

[Dimitris Papastamos]

On Mon, Nov 17, 2014 at 10:47:31PM +0100, FRIGN wrote:
> > headers
> > ===
> > system headers (#include <...>) in alphabetical order
> > empty line
> > local headers (#include "...") in alphabetical order
> > if there is any reason to change order, comment to explain
> 
> If headers depend on order, the headers are broken. Dismissed.

system headers should come first, then a newline, then libc headers
then a newline then local headers.

the libc headers are guaranteed to work regardless of the order of
inclusion but need to come after the system headers.  From what I
recall this is not the case with system headers and you might have
to include them in a certain order (i.e. sys/types.h might need to come
first let's say).