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

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 looke

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

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) $(LIBU

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

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 prefe

Re: [dev] why avoid install?

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 i

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

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 ch

Re: [dev] [sbase] style

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 r

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

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?

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

Re: [dev] why avoid install?

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] remove agetline

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 +

Re: [dev] why avoid install?

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?

> 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. W

Re: [dev] why avoid install?

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?

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-con

Re: [dev] why avoid install?

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 freed

Re: [dev] why avoid install?

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

Re: [dev] why avoid install?

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/

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

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?

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

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 Ga

Re: [dev] why avoid install?

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

Re: [dev] why avoid install?

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?

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 wid

Re: [dev] why avoid install?

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?

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?

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?

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 p

Re: [dev] why avoid install?

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.

Re: [dev] why avoid install?

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 tryi

[dev] why avoid install?

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 em

Re: [dev] [sbase] style

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] ht

Re: [dev] [sbase] style

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 fre

Re: [dev] [sbase] style

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 sys

Re: [dev] [sbase] style

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

Re: [dev] [sbase] style

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

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 existin

Re: [dev] [sbase] style

> 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.

Re: [dev] [sbase] style

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 stateme

Re: [dev] [sbase] style

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 > #inclu

Re: [dev] [sbase] style

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 o