Re: [dev] [ubase] compile using musl

On Fri, 15 Mar 2024 16:22:19 -0300 Brian Mayer wrote: > Hi, I'm Brian, I'm trying to compile ubase using musl as libc on > buildroot. I use a Pinebook Pro, so aarch64 is my arch. > > By just running make I get this error: > >

Re: [dev] [sbase] Defining scope of sbase and ubase

On Sat, 09 Mar 2024 17:28:49 +0100 Elie Le Vaillant wrote: > Страхиња Радић wrote: > > Compiling all programs into one binary is currently an option, and IMHO it > > should remain an option. > > I fully agree. However, the single binary situation should be improved. > > > Great, combine

Re: [dev] [sbase] Defining scope of sbase and ubase

On Sat, 9 Mar 2024 14:53:07 +0100 Страхиња Радић wrote: > On 24/03/09 12:59AM, Mattias Andrée wrote: > > I agree, a single repo (or alternatively making libutil it's own repo) is > > necessary if we want one binary, and I think we do. > > Compiling all programs into on

Re: [dev] [sbase] Defining scope of sbase and ubase

On Sat, 09 Mar 2024 12:10:28 +0100 Eolien55 wrote: > Mattias Andrée wrote: > > I think there should be one directory called "portable" containing only > > tools > > from sbase, and one directory called "linux" containing the tools from ubase

Re: [dev] [sbase] Defining scope of sbase and ubase

ot sure this is preferable over a single Makefile in the root directory. As mentioned in an other branch of this conversation, I think we should have a base with only the POSIX tools but than have additional optional tools, which could be group into overlapping categories, as you can select what you want on your system. Best regards, Mattias Andrée

Re: [dev] [sbase] Defining scope of sbase and ubase

setting BIN when running make(1) or by saying "yes" or "no" to each category (of course each category would have a default option), e.g. POSIX=yes INTERACTIVE=no. Best regards, Mattias Andrée On Fri, 08 Mar 2024 11:36:27 +0100 Elie Le Vaillant wrote: > Hi, > > I th

Re: [dev] getting rid of cmake builds

On Fri, 22 Sep 2023 15:54:59 +0200 Laslo Hunhold wrote: > On Thu, 21 Sep 2023 16:05:17 +0200 > David Demelier wrote: > > Dear David, > > > It's near to impossible to convert a CMake project to make > > automatically, CMake is almost like a scripting language given the > > numerous of things

Re: [dev] Minimalist software. Should I care?

On Wed, 5 Jul 2023 10:04:47 -0500 Dave Blanchard wrote: > On Thu, 06 Jul 2023 00:01:43 +1200 > Miles Rout wrote: > > > There is a page on the website advertising all the many patches available > > to improve st and dwm. > > Few if any other software projects provide that these days, and are

Re: [dev] Minimalist software. Should I care?

On Wed, 5 Jul 2023 10:19:36 -0500 Dave Blanchard wrote: > On Wed, 5 Jul 2023 10:23:57 +0200 (CEST) > Sagar Acharya wrote: > > > That is exactly what I'm trying to achieve. Capital is whatI lack. Soon I > > will be releasing Libre-Ads, a random non-targeted ads system specially for > >

Re: [hackers] [libgrapheme] Use (size_t)(-1) instead of SIZE_MAX and fix style || Laslo Hunhold

Why wouldn't SIZE_MAX be the maximum of size_t? On Sun, 31 Jul 2022 11:47:40 +0200 wrote: > commit 25d89e6e460e68329e7a3f388fe3e150a8f5474a > Author: Laslo Hunhold > AuthorDate: Sun Jul 31 11:46:48 2022 +0200 > Commit: Laslo Hunhold > CommitDate: Sun Jul 31 11:46:48 2022 +0200 > >

Re: [hackers] [libgrapheme] Add reallocarray implementation || robert

On Sun, 31 Jul 2022 11:47:40 +0200 wrote: > commit bdf42537c5792f6beb0360517ff378834cfd8a68 > Author: robert > AuthorDate: Sat Jul 30 14:29:05 2022 -0700 > Commit: Laslo Hunhold > CommitDate: Sun Jul 31 11:41:08 2022 +0200 > > Add reallocarray implementation > >

Re: [dev] diff and patch

On Wed, 2 Feb 2022 07:48:39 -0500 LM wrote: > I've been looking at non-GNU implementations of diff and patch. The > BSD systems, Plan 9 and toybox all have their own implementations. > Has anyone found other non-GNU licensed Open Source alternatives for > these programs? Does anyone else use

Re: [dev] Special target ".POSIX" in Makefiles

On Mon, 3 Jan 2022 11:16:48 +0100 Markus Wichmann wrote: > On Sat, Jan 01, 2022 at 08:09:38PM +0100, Mattias Andrée wrote: > > .POSIX: > > > > CC = c99 > > # Required as POSIX doesn't mandate that it is defined by default > > > > OBJ =\ > >

Re: [dev] Special target ".POSIX" in Makefiles

.POSIX: CC = c99 # Required as POSIX doesn't mandate that it is defined by default OBJ =\ alpha.o\ beta.o\ gamma.o LINUX_AMD64_OBJ = $(OBJ:.o=.linux-amd64-o) OPENBSD_AMD64_OBJ = $(OBJ:.o=.openbsd-amd64-o) all: myproj-linux-amd64 myproj-openbsd-amd64 myproj-linux-amd64:

Re: [dev] Special target ".POSIX" in Makefiles

On Sat, 1 Jan 2022 13:01:05 +0100 Laslo Hunhold wrote: > On Sat, 1 Jan 2022 10:33:22 +0100 > Mattias Andrée wrote: > > Dear Mattias, > > first off, happy new year to all of you! > > > Thanks for pointing that it, I didn't find it in my search. > > I renamed

Re: [dev] Special target ".POSIX" in Makefiles

Thanks for pointing that it, I didn't find it in my search. I renamed it to mklint. Regards, Mattias Andrée On Sat, 1 Jan 2022 14:43:15 +0600 NRK wrote: > On Fri, Dec 31, 2021 at 11:29:11PM +0100, Mattias Andrée wrote: > > I just started implementing a linter[0]. Even thou

Re: [dev] Special target ".POSIX" in Makefiles

I just started implementing a linter[0]. Even though I just started it today, I think that's enough for this year. Happy New Year! Mattias Andrée [0] https://github.com/maandree/makelint/ On Thu, 30 Dec 2021 21:17:32 +0100 Mattias Andrée wrote: > On Thu, 30 Dec 2021 21:07:06 +0100 >

Re: [dev] Special target ".POSIX" in Makefiles

many own projects and a garbage implementation for when I compile software I download (of course the minimal would do in some cases, but if I build from the AUR, what would happen is that it would be used for every AUR package I download). Regards, Mattias Andrée [0] Minimal only run when b

Re: [dev] Special target ".POSIX" in Makefiles

On Thu, 30 Dec 2021 23:07:35 +0100 Laslo Hunhold wrote: > On Thu, 30 Dec 2021 21:17:32 +0100 > Mattias Andrée wrote: > > Dear Mattias, > > > I've actually being thinking of writing a makefile linter. > > How interested would people be in such a tool? > > v

Re: [dev] Special target ".POSIX" in Makefiles

On Thu, 30 Dec 2021 21:07:06 +0100 Laslo Hunhold wrote: > On Thu, 30 Dec 2021 17:49:23 +0100 > crae...@gmail.com wrote: > > Dear craekz, > > > As far as I can see, we could add `.POSIX` to the following programs: > > dwm, dmenu, dwmstatus, sent and tabbed > > I've just looked over the

Re: [dev] Special target ".POSIX" in Makefiles

, and should be removed assuming it is redundant given the inferred prerequisite of inference rules. Regards, Mattias Andrée On Thu, 30 Dec 2021 15:58:33 +0100 crae...@gmail.com wrote: > Hi, > > I'm wondering why the Makefiles of some suckless programs (and libs) have the > special ta

Re: [hackers] [libgrapheme] Use SIZE_MAX instead of (size_t)-1 || Laslo Hunhold

for it.) On Sat, 18 Dec 2021 15:07:30 -0500 Ethan Sommer wrote: > On Sat, Dec 18, 2021 at 3:02 PM Mattias Andrée wrote: > > > (size_t)-1 is also undefined behaviour. > > > It isn't, wrap-around with unsigned types is defined, it's only signed > overflow that isn't.

Re: [hackers] [libgrapheme] Use SIZE_MAX instead of (size_t)-1 || Laslo Hunhold

(size_t)-1 is also undefined behaviour. On Sat, 18 Dec 2021 20:21:42 +0100 wrote: > commit cb7e9c00899ae0ed57a84991308b7f880f4ddef6 > Author: Laslo Hunhold > AuthorDate: Sat Dec 18 20:21:04 2021 +0100 > Commit: Laslo Hunhold > CommitDate: Sat Dec 18 20:21:04 2021 +0100 > > Use

Re: [hackers] [libgrapheme] Rename API functions to improve readability || Laslo Hunhold

I would prefer the “libgrapheme_” prefix, so that it is obvious that the functions belong to the libgrapheme library. Regards, Mattias Andrée On Sat, 18 Dec 2021 19:54:57 +0100 wrote: > commit 4483b44e8444d4a57bcbb31dbe9eac3e6b80c1ad > Author: Laslo Hunhold > AuthorDate: Sat

Re: [hackers] A very unconventional unit testing library

Hi Thomas, On Wed, 11 Aug 2021 13:42:25 +0200 Thomas Oltmann wrote: > Hi Andrée, > > Am Mi., 11. Aug. 2021 um 13:12 Uhr schrieb Mattias Andrée : > > This looks like a very neat test framework. I would however like > > the file name to be printed in addition to line numbe

Re: [dev] Ada not Rust

On Mon, 26 Apr 2021 10:10:20 -0400 Ross Mohn wrote: > On 4/23/21 10:12 PM, Jeremy wrote: > > On 04/20/21 10:23AM, Greg Reagle wrote: > >> On Tue, Apr 20, 2021, at 09:45, Jeremy wrote: > >> I gave up on using dvtm a while ago (now I use tmux which is good) because > >> it > >> would keep

Re: [dev] Ada not Rust

On Mon, 19 Apr 2021 16:19:18 -0400 Greg Reagle wrote: > On Sat, Apr 17, 2021, at 11:57, Laslo Hunhold wrote: > > Anyway, I can't say it enough: Check out Ada 2012 (and the SPARK > > subset) if you care about "secure" languages. It's not as lean as C, but > > you end up solving so many problems

Re: [dev] Checksums and Sig files for release gzip

On Sat, 17 Apr 2021 20:38:51 +0200 Mattias Andrée wrote: > On Sat, 17 Apr 2021 21:30:58 +0300 > Sergey Matveev wrote: > > > *** Mattias Andrée [2021-04-17 20:08]: > > >No one has an OCaml compiler. > > > > Same applies to Rust. > > And to Go too

Re: [dev] Checksums and Sig files for release gzip

On Sat, 17 Apr 2021 21:30:58 +0300 Sergey Matveev wrote: > *** Mattias Andrée [2021-04-17 20:08]: > >No one has an OCaml compiler. > > Same applies to Rust. > And to Go too, but it is easy bootstrappable with the C compiler, taking > just several minutes on modest h

Re: [dev] Checksums and Sig files for release gzip

On Sat, 17 Apr 2021 20:50:50 +0300 Sergey Matveev wrote: > *** Mattias Andrée [2021-04-17 18:57]: > >This self-hosted nonsense is ludicrous. > > Not agree. > > >It's understandable for C compilers > > Rust, as far as I heard/remember, was written on OCaml,

Re: [dev] Checksums and Sig files for release gzip

This self-hosted nonsense is ludicrous. It's understandable for C compilers, it's an old language that everyone has a compiler for and there are many implementations, and even if you wrote it in assembly, you will just shift the problem to the assembler. So there must be one blessed language, and

Re: [dev] Checksums and Sig files for release gzip

On Sat, 17 Apr 2021 16:30:15 +0200 Laslo Hunhold wrote: > On Wed, 14 Apr 2021 09:05:01 +0300 > Sergey Matveev wrote: > > Dear Sergey, > > > If we a talking here about checking software integrity, then speed is > > important. Millions of people check the hash of downloaded files -- if > > it

Re: [dev] Checksums and Sig files for release gzip

On Tue, 13 Apr 2021 20:17:37 +0200 Markus Wichmann wrote: > On Tue, Apr 13, 2021 at 05:08:31PM +0200, Mattias Andrée wrote: > > On Tue, 13 Apr 2021 16:57:39 +0200 > > Sagar Acharya wrote: > > > > > Sure, any good signature. SHA512 is stronger than SHA1, MD5 a

Re: [dev] Checksums and Sig files for release gzip

On Tue, 13 Apr 2021 16:57:39 +0200 Sagar Acharya wrote: > Sure, any good signature. SHA512 is stronger than SHA1, MD5 and SHA256. It > shouldn't take a second more than others. Why use a weaker checksum? SHA512 is actually more than twice as fast as SHA256 on 64-bit machines. (I don't know

Re: [dev] Completeness suckless

On Fri, 9 Apr 2021 12:13:23 -0700 Jeremy wrote: > On 04/09/21 08:24PM, Sagar Acharya wrote: > > > > >I think, the user's turn to try to understand them to the fullest, even > > if it means learning a bit of a programming language. - Laslo > > Majority of users in this world would never

Re: [dev] [sbase][tar] GNU tar support

On Wed, 25 Nov 2020 16:28:02 -0500 Cág wrote: > Hi all, > > Laslo Hunhold wrote: > > Dear Cág, > > Even if a suckless implementation of GNU tar was possible, would you > > really want it to be included? I'd rather like to encourage people to > > use standard non-proprietary file formats. > >

Re: [dev] Culling all the way down

re how other programs react to it. They will probably block > > waiting for the write(2) syscall to return instead of continuing to > > do work in the background. > > Trying this manually had exactly the desired outcome: CPU usage dropped > to 0. Nice! > > On 06/09/2020 09.48, Mattias An

Re: [dev] Culling all the way down

On Mon, 7 Sep 2020 10:13:26 +0300 Alexander Krotov wrote: > > What you could do is to patch a terminal to allow programs to because > > paused via SIGSTOP when invisible and continued via SIGCONT when > > visible. Then your program would only need to write some string to > > the terminal when it

Re: [dev] Culling all the way down

On Sun, 6 Sep 2020 09:48:06 +0200 Mattias Andrée wrote: > On Sun, 6 Sep 2020 08:21:45 +0200 > Tobias Bengfort wrote: > > > Hi, > > > > I am currently creating a curses application that is updated > > independently of user input. Think of something like `top`

Re: [dev] Culling all the way down

t either. You would just be adding unneeded work and complexity for next to no gain. I would only think about this for intensive programs. Regards, Mattias Andrée

Re: [hackers] setsid: add optional -f to force fork()

Hi, Is there any reason you would want to force it? Regards, Mattias Andrée On Tue, 14 Jul 2020 10:15:43 +0200 Hiltjo Posthuma wrote: > Hi, > > The below patch adds an -f flag to force fork(2)ing and creating a new > process. > > > From a75ef384c11b64732dd6a3adc92

Re: [dev] Re: [slstatus] temperature module acts wierd on OpenBSD

to `int` because only the type of the first argument is specified in its declaration. Regards, Mattias Andrée On Tue, 16 Jun 2020 20:42:08 +0200 Laslo Hunhold wrote: > On Tue, 16 Jun 2020 17:55:03 + > messw1thdbest wrote: > > Dear messw1thdbest, > > > <

[hackers] A (much) simpler syscall tracer

to add, hint, hint), and continue on with my next project, which was the reason I made this in the first place: a fakeroot(1)-like utility for package managers and static linking. Best regards, Mattias Andrée

Re: [hackers] [libgrapheme][PATCH] Simplify cp_decode and be more strict

On Thu, 28 May 2020 19:33:12 +0200 Laslo Hunhold wrote: > On Thu, 28 May 2020 16:49:22 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > > > So would you recommend an explicit cast to uint32_t, i.e. > > > > > > > >

Re: [hackers] [libgrapheme][PATCH] Simplify cp_decode and be more strict

On Thu, 28 May 2020 16:45:20 +0200 Mattias Andrée wrote: > Hi Laslo, > > On Thu, 28 May 2020 15:53:32 +0200 > Laslo Hunhold wrote: > > > On Thu, 28 May 2020 13:48:18 +0200 > > Mattias Andrée wrote: > > > > Dear Mattias, > > > > >

Re: [hackers] [libgrapheme][PATCH] Simplify cp_decode and be more strict

Hi Laslo, On Thu, 28 May 2020 15:53:32 +0200 Laslo Hunhold wrote: > On Thu, 28 May 2020 13:48:18 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > Looks good, and I especially like the simplification it brings for > > using partially loaded strings. > &

Re: [hackers] [libgrapheme][PATCH] Simplify cp_decode and be more strict

earer than `!BETWEEN(s[i], 0x80, 0xBF)`, but since you changed this I assume you disagree. Regards, Mattias Andrée On Thu, 28 May 2020 13:07:21 +0200 Laslo Hunhold wrote: > On Wed, 27 May 2020 15:22:35 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > > >

[hackers] Re: [libgrapheme][PATCH] Simplify cp_decode and be more strict

outside the string. Regards, Mattias Andrée On Wed, 27 May 2020 15:22:35 +0200 Mattias Andrée wrote: > No special cases for NUL and ASCII. > > Simplified check of overencoded codepoints: > lowest non-overencoded codepoints are stored in the lookup table > > Do not acc

[hackers] [libgrapheme][PATCH] Simplify cp_decode and be more strict

No special cases for NUL and ASCII. Simplified check of overencoded codepoints: lowest non-overencoded codepoints are stored in the lookup table Do not accept surrogate code points. >From RFC 3629: The definition of UTF-8 prohibits encoding character numbers between U+D800 and

Re: [hackers] [libgrapheme][PATCH] Expose cp_decode and boundary (both renamed) to the user

On Sat, 9 May 2020 07:25:41 +0200 Laslo Hunhold wrote: > On Thu, 7 May 2020 18:32:23 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > Perhaps, but do you I wouldn't expect anyone that don't understand > > the difference to even use libgrapheme. But you would a

Re: [hackers] [libgrapheme][PATCH] Expose cp_decode and boundary (both renamed) to the user

Hi Laslo, On Thu, 7 May 2020 15:15:24 +0200 Laslo Hunhold wrote: > On Sat, 25 Apr 2020 23:03:56 +0200 > Mattias Andrée wrote: > > Dear Mattias, > > > cp_decode has been renamed to grapheme_decode > > I personally don't like that change. It's already diffi

[hackers] [libgrapheme][PATCH] Expose cp_decode and boundary (both renamed) to the user

cp_decode has been renamed to grapheme_decode and boundary has been renamed to grapheme_boundary. The purpose of this is to allow faster text rendering where both individual code points and grapheme clusters boundaries are of interest, but it also (1) makes it easy to do online processing of

Re: [dev] [libgrapheme] announcement

On Fri, 27 Mar 2020 22:24:22 + wrote: > On Fri, Mar 27, 2020 at 10:24:52PM +0100, Laslo Hunhold wrote: > > ... This will cover 99.5% of all cases... > > What do you mean? They managed to add in grapheme cluster definition some > weird > edge cases up to 0.5%?? > > About string

Re: [dev] Superservers: Yay or Nay?

they are always the right option. You need to consider system boot time, subserver start time, memory usage, and activity. A positive side-effect of superservers is that you do not need to remember to restart the server when you update its software. A superserver is basically a workaround for shortcomings. Clean your hands, wear an unventilated FFP3 face mask, Mattias Andrée > > With best regards > > Laslo >

[hackers] [ubase][PATCH] df: Fix value in Avail column

be /( + ) and it is maid explicitly clear that + shall not be : [...] This percentage may be greater than 100 if is less than zero [...] Signed-off-by: Mattias Andrée --- df.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/df.c b/df.c index 4d595d6

[hackers] [ubase][PATCH v2] Add vmstat

Signed-off-by: Mattias Andrée --- LICENSE | 1 + Makefile | 1 + TODO | 2 +- vmstat.c | 322 +++ 4 files changed, 325 insertions(+), 1 deletion(-) create mode 100644 vmstat.c diff --git a/LICENSE b/LICENSE index 76cf9ea..8b8e1ee

Re: [hackers] [ubase][PATCH] Add vmstat

On Tue, 5 Nov 2019 12:03:04 -0800 Michael Forney wrote: > On 2019-11-05, Mattias Andrée wrote: > > On Sat, 2 Nov 2019 12:33:58 -0700 > > Michael Forney wrote: > > > >> I've never used vmstat before, but this looks pretty good overall and > >> seem

[hackers] [ubase][PATCH] vmstat.c: fix typo in comment

Signed-off-by: Mattias Andrée --- vmstat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vmstat.c b/vmstat.c index d97ee10..4c809bb 100644 --- a/vmstat.c +++ b/vmstat.c @@ -282,7 +282,7 @@ main(int argc, char *argv[]) timestamp = 1; break

Re: [hackers] [ubase][PATCH] Add vmstat

On Sat, 2 Nov 2019 12:33:58 -0700 Michael Forney wrote: > I've never used vmstat before, but this looks pretty good overall and > seems to work well. > > On 2019-10-05, Mattias Andrée wrote: > > + goto beginning; > > + for (; argc && (argc < 2 || i <

Re: [dev] unsubscribe

On Wed, 30 Oct 2019 13:02:53 -0400 Yih Lerh Huang wrote: > unsubscribe > dev+unsubscr...@suckless.org Tip: You can almost always find the address to send it in the List-Unsubscribe header in the e-mail.

[hackers] [ubase][PATCH] Add vmstat

Signed-off-by: Mattias Andrée --- Makefile | 1 + TODO | 2 +- vmstat.c | 321 +++ 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 vmstat.c diff --git a/Makefile b/Makefile index b526421..e1dab9b 100644

Re: [dev] SYNChronous SendMail

to it (as both was listed as futures). Although I do not expect you to do so. I would break out the libc to a standalone project or, depending on how well it would work (and if most of it could be done with a script), fork musl-libc and make it a header-only (+crt) library. Regards, Mattias Andrée On Tue

Re: [dev] SYNChronous SendMail

Hi, What is the point of doing your own mini-libc within the program? Aren't you just making it less portable and adding more code to read? Regards, Mattias Andrée On Tue, 10 Sep 2019 15:49:19 + wrote: > Hi, > > For those who might be interested: > > I did write a le

Re: [hackers] [sbase][PATCH] which: check AT_EACCESS

On Mon, 29 Jul 2019 18:46:25 -0700 Michael Forney wrote: > On 2019-07-27, Mattias Andrée wrote: > > A file is executable only if the effective user > > have permission to execute it. The real user's > > permissions do not matter. > > Thanks for the patch,

[hackers] [sbase][PATCH] which: check AT_EACCESS

A file is executable only if the effective user have permission to execute it. The real user's permissions do not matter. Signed-off-by: Mattias Andrée --- which.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/which.c b/which.c index cc93361..42ed095 100644 --- a/which.c

[hackers] [sbase][PATCH] which: remove unnecessary third parameter in O_RDONLY call to open(3)

Signed-off-by: Mattias Andrée --- which.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/which.c b/which.c index cc93361..3f9af6e 100644 --- a/which.c +++ b/which.c @@ -43,7 +43,7 @@ which(const char *path, const char *name) if (ptr[i] != ':' && ptr[i

Re: [dev] Re: json

On Sat, 15 Jun 2019 22:11:13 +0200 Wolf wrote: > Hello, > > On , Mattias Andrée wrote: > > Wouldn't it just complicate matters if you needed to specify whether a > > number is an integer or a real value; > > Could you not just consider sequence of [0-9]+ to b

Re: [dev] Re: json

precise? In most cases, the program know what size and precision is required. Regards, Mattias Andrée On Sat, 15 Jun 2019 20:37:34 +0200 Wolf wrote: > On , sylvain.bertr...@gmail.com wrote: > > json almost deserves a promotion to suckless format. > > Except for not putting any

Re: [dev] Learn C

and with time you will pick up one the more advanced topics. Regards Mattias Andrée On Sun, 24 Mar 2019 10:28:35 +0100 Thuban wrote: > Hi, > I want to learn C. I mean, sane C. > What i read before was based on big IDE such as codeblocks. So, I don't > know how to write Makefiles from sc

Re: Incorrect path canonicalisation at autocompletion

On Mon, 3 Dec 2018 09:58:33 -0500 Chet Ramey wrote: > On 12/3/18 9:49 AM, Mattias Andrée wrote: > > On Mon, 3 Dec 2018 09:33:48 -0500 > > Chet Ramey wrote: > > > >> On 12/1/18 3:12 PM, Mattias Andrée wrote: > >>> Using Bash 4.4.023, type > >&

Re: Incorrect path canonicalisation at autocompletion

On Mon, 3 Dec 2018 09:33:48 -0500 Chet Ramey wrote: > On 12/1/18 3:12 PM, Mattias Andrée wrote: > > Using Bash 4.4.023, type > > > > cd > > mkdir -p 1/2 > > cd 1/2 > > touch ../../3 > > ln -s ~ 4 > > touch 5 > >

Incorrect path canonicalisation at autocompletion

Using Bash 4.4.023, type cd mkdir -p 1/2 cd 1/2 touch ../../3 ln -s ~ 4 touch 5 ls 4/../ without pressing enter at the last line, instead press twice. 4/ and 5 will be suggested, but if you press you will see that it should suggest the

Re: [dev] Re: diff -x

Why would you? You can just as well write a script a new directory with hard links to all files that should be included in the diff. On Fri, 28 Sep 2018 17:49:25 +0300 Adrian Grigore wrote: > In a diff -ur situation? > On Fri, Sep 28, 2018 at 5:48 PM Adrian Grigore > wrote: > > > > How would

Re: [hackers] [sbase][PATCH v2] Add tests for some utilities

On Wed, 1 Aug 2018 22:07:33 +0200 Mattias Andrée wrote: > On Wed, 1 Aug 2018 21:16:26 +0200 > Silvan Jegen wrote: > > > On Wed, Aug 01, 2018 at 07:53:18PM +0200, Mattias Andrée wrote: > > > Thank you for your time! > > > > Thank you for all

Re: [hackers] [sbase][PATCH v2] Add tests for some utilities

print_failure: It's probably enough to add some empty lines add a few short comments. The other parts are pretty straight forward. Regard, Mattias Andrée On Wed, 1 Aug 2018 16:36:35 +0200 Silvan Jegen wrote: > Hi Mattias! > > On Wed, Jul 11, 2018 at 09:39:23PM +02

[hackers] [sbase][PATCH v2] Add tests for some utilities

re patches submitted for most of them. There are not patches submitted for fixing the "#ifdef TODO"s in expand.test.c and unexpand.test.c. Signed-off-by: Mattias Andrée --- Makefile| 45 - basename.test.c | 68 +++ dirname.test.c | 55 ++ echo.test.c | 51 +

[hackers] [sbase][PATCH v2] Support -- in all utilities except echo(1)

In POSIX-2017 it was clarified via the documentation for basename(1) and dirname(1) that all programs should support -- unless specified otherwise. Signed-off-by: Mattias Andrée --- chroot.c | 5 - cksum.c| 11 ++- expr.c | 11 ++- hostname.c | 5 - link.c

[hackers] [sbase][PATCH v2] Support -- in all utilities except echo(1)

In POSIX-2017 it was clarified via the documentation for basename(1) and dirname(1) that all programs should support -- unless specified otherwise. Signed-off-by: Mattias Andrée --- chroot.c | 5 - cksum.c| 11 ++- expr.c | 11 ++- hostname.c | 5 - link.c

[hackers] [sbase][PATCH] Support -- in all utilities except echo(1)

In POSIX-2017 it was clarified via the documentation for basename(1) and dirname(1) that all programs should support -- unless specified otherwise. Signed-off-by: Mattias Andrée --- arg.h | 13 + basename.c | 5 + chroot.c | 2 +- cksum.c| 8 +++- dirname.c

Re: [hackers] [sbase][PATCH] Add test framework with a test for tty(1)

On Sun, 8 Jul 2018 10:06:14 +0100 Dimitris Papastamos wrote: > On Sun, Jul 08, 2018 at 01:12:59AM +0200, Mattias Andrée wrote: > > On Sat, 7 Jul 2018 23:29:53 +0100 > > Dimitris Papastamos wrote: > > > > > On Sun, Jul 08, 2018 at 12:12:08AM +0200, Mattias And

Re: [hackers] [sbase][PATCH] Add test framework with a test for tty(1)

On Sat, 7 Jul 2018 23:29:53 +0100 Dimitris Papastamos wrote: > On Sun, Jul 08, 2018 at 12:12:08AM +0200, Mattias Andrée wrote: > > On Sat, 7 Jul 2018 22:55:28 +0100 > > Dimitris Papastamos wrote: > > > > > This is too intrusive, what's wrong wit

[hackers] [sbase][PATCH] Add test framework with a test for tty(1)

Signed-off-by: Mattias Andrée --- Makefile | 20 +- test-common.c | 823 ++ test-common.h | 190 ++ tty.test.c| 26 ++ 4 files changed, 1055 insertions(+), 4 deletions(-) create mode 100644 test-common.c create mode

[hackers] [sbase][PATCH] basename: support --

POSIX-2017 clarifies that -- and normal option parsing must be supported. See EXAMPLES in basename(1p). Signed-off-by: Mattias Andrée --- basename.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/basename.c b/basename.c index d211799..94a2848 100644 --- a/basename.c

[hackers] [sbase][PATCH] dirname: support --

POSIX-2017 clarifies that -- and normal option parsing must be supported. See EXAMPLES in basename(1p) Signed-off-by: Mattias Andrée --- dirname.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/dirname.c b/dirname.c index 8392bc0..45e1a7e 100644 --- a/dirname.c +++ b

[hackers] [ubase][PATCH] ps: fix argv0 position in usage line

Signed-off-by: Mattias Andrée --- ps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ps.c b/ps.c index 114983b..00405a5 100644 --- a/ps.c +++ b/ps.c @@ -145,7 +145,7 @@ psr(const char *file) static void usage(void) { - eprintf("usage: [-aAdef] %s\n&qu

[valgrind] [Bug 392118] unhandled amd64-linux syscall: 332 (statx) [KDE executables]

https://bugs.kde.org/show_bug.cgi?id=392118 Mattias Andrée changed: What|Removed |Added CC||maand...@kth.se --- Comment #2 from Mattias

Re: [dev] [PATCH][blind] alloca #include for BSDs

made necessary changes (such as add flags for specific OSes), add the package managers flags, and invoke make(1) with those values. However, if the package maintainer is comfortable with assuming make(1) supports ?= and +=, use sed(1) on config.mk, and he will not have to change if config.mk has changed when a new version is published. Mattias Andrée pgpauSci7jrCw.pgp Description: OpenPGP digital signature

Re: [dev] [PATCH][blind] alloca #include for BSDs

include >  #include >  #include > > Thanks again! I will be fixing this, but probably via config.mk. Mattias Andrée

Re: [dev] [BUG REPORT] blind: clang-40 warning: variable 'frames' is uninitialized when used here

s (if I haven't already fixed it that is), but it will take some times before you will see it. Mattias Andrée pgp5Qhv6VjDKd.pgp Description: OpenPGP digital signature

Re: [hackers] [blind] update todo: tee is too slow || Mattias Andrée

You will be glad to know I will be removing `float` support. It didn't provide the performance boost I was hoping for. On Wed, 13 Dec 2017 08:31:21 +0100 Mattias Andrée <maand...@kth.se> wrote: > I'm not convinced, but since you guys disagree I will not implement this. > > On W

Re: [hackers] [blind] update todo: tee is too slow || Mattias Andrée

y obvious to me > that what you're proposing is totally anathema to suckless philosophy. > > On Tue, Dec 12, 2017 at 02:49:34PM +, Mattias Andrée wrote: > > It may look insane on the surface level. I am not commited to changes > > listed in the TODO, most of them are just ideas t

RE: [hackers] [blind] update todo: tee is too slow || Mattias Andrée

parakiss [izaber...@gmail.com] Sent: 12 December 2017 13:31 To: hackers mail list Subject: Re: [hackers] [blind] update todo: tee is too slow || Mattias Andrée don't you realize how insane the whole thing is? On 12/12/17, Mattias Andrée <maand...@kth.se> wrote: > Perhaps I should clarif

RE: [hackers] [blind] update todo: tee is too slow || Mattias Andrée

. From: Mattias Andrée [maand...@kth.se] Sent: 12 December 2017 11:32 To: hackers mail list Subject: RE: [hackers] [blind] update todo: tee is too slow || Mattias Andrée When I rendered a video, tee used 100% while the other process was basically at 0

RE: [hackers] [blind] update todo: tee is too slow || Mattias Andrée

Andrée bullshit On 12/4/17, g...@suckless.org <g...@suckless.org> wrote: > commit d8aa45da86d1128149fd7ab6ac3725bf8e88a1b1 > Author: Mattias Andrée <maand...@kth.se> > AuthorDate: Mon Dec 4 22:35:59 2017 +0100 > Commit: Mattias Andrée <maand...@kth.se> > Co

Re: [dev] [general][discussion] constants: `#define` or `static const`

On Thu, 12 Oct 2017 15:21:14 +0100 Matthew Parnell wrote: > Afternoon suckless community. > > It is made clear in the suckless coding style guide when to use > #define and enums; however, it doesn't mention general global > constants. > > I would search through the mailing

[hackers] [sbase][PATCH v2] Add patch(1)

Signed-off-by: Mattias Andrée <maand...@kth.se> --- Makefile |2 + README |1 + TODO |1 - libutil/asprintf.c | 74 +++ libutil/getlines.c | 17 +- patch.1| 248 +++ patch.c

Re: [hackers] [PATCH][sbase] Add patch(1)

On Sun, 24 Sep 2017 19:24:10 +0200 Silvan Jegen <s.je...@gmail.com> wrote: > Heyho > > On Sun, Sep 24, 2017 at 06:28:57PM +0200, Mattias Andrée wrote: > > On Sun, 24 Sep 2017 14:08:41 +0200 > > Silvan Jegen <s.je...@gmail.com> wrote: > >

Re: [hackers] [sbase][PATCH] patch: improvments suggested by Silvan

On Sun, 24 Sep 2017 11:12:35 -0700 Michael Forney wrote: > Hi Mattias, > > Instead of sending these patches on top of your original patch, can > you send amended versions (v2, v3, etc)? You can use `git format-patch > -v 2` to make this clear in the subject. > > I think

[hackers] [sbase][PATCH] patch: improvments suggested by Silvan

Signed-off-by: Mattias Andrée <maand...@kth.se> --- patch.c | 182 +--- 1 file changed, 95 insertions(+), 87 deletions(-) diff --git a/patch.c b/patch.c index c118dc9..caf34be 100644 --- a/patch.c +++ b/patch.c @@ -41,7

Re: [hackers] [PATCH][sbase] Add patch(1)

ind my comments below. > > On Sun, Sep 03, 2017 at 07:13:20PM +0200, Mattias Andrée wrote: > > +static void > > +save_file_cpp(FILE *f, struct file_data *file) > > +{ > > + size_t i, j, n; > > + char annot = ' '; > > + > > + for (i = 0; i <= file

  1   2   3   4   5   >