From dave at 19a6.net  Fri Oct  2 15:11:33 2020
From: dave at 19a6.net (Dave Bucklin)
Date: Fri, 2 Oct 2020 10:11:33 -0500
Subject: Free Books
Message-ID: <20201002151133.GA15733@19a6.tech>

I'm moving soon. These books have served their purpose in my life, so
I'm looking for new homes for them. If you are interested, please email
me to make an appointment. Ideally, someone will come grab all of them
today or tomorrow. Whatever's left on Sunday will be taken to Half Price
Books.

Some highlights:

* SICP
* Fundamental Algorithms
* The Unix Programming Environment
* Software Tools
* Modern Perl

The full set:  
http://teamkave.us/files/books.html

Thank you.

From zach at nor.mn  Fri Oct  2 15:45:06 2020
From: zach at nor.mn (Zach Norman)
Date: Fri, 02 Oct 2020 10:45:06 -0500
Subject: Free Books
In-Reply-To: <20201002151133.GA15733@19a6.tech>
Message-ID: <i3dfctcqt4135hj4bh5qhd71.1601653506824@nor.mn>

Hi Dave,

I'll take them off your hands and give them a good home.

Zach

normnco automata



? Original Message ?


From: dave at 19a6.net
Sent: October 2, 2020 10:11
To: friends at talk.begriffs.com
Reply-to: dave at 19a6.net
Subject: Free Books


I'm moving soon. These books have served their purpose in my life, so
I'm looking for new homes for them. If you are interested, please email
me to make an appointment. Ideally, someone will come grab all of them
today or tomorrow. Whatever's left on Sunday will be taken to Half Price
Books.

Some highlights:

* SICP
* Fundamental Algorithms
* The Unix Programming Environment
* Software Tools
* Modern Perl

The full set:?
http://teamkave.us/files/books.html

Thank you.

From dave at 19a6.net  Fri Oct  2 17:40:03 2020
From: dave at 19a6.net (Dave Bucklin)
Date: Fri, 02 Oct 2020 12:40:03 -0500
Subject: Free Books
In-Reply-To: <20201002151133.GA15733@19a6.tech>
References: <20201002151133.GA15733@19a6.tech>
Message-ID: <738916CC-C1CE-455C-96CC-FCE99AE9880F@19a6.net>

Hi all. The books have found a new home. Thanks, and pardon the interruption.

On October 2, 2020 10:11:33 AM CDT, Dave Bucklin <dave at 19a6.net> wrote:
>I'm moving soon. These books have served their purpose in my life, so
>I'm looking for new homes for them. If you are interested, please email
>me to make an appointment. Ideally, someone will come grab all of them
>today or tomorrow. Whatever's left on Sunday will be taken to Half
>Price
>Books.
>
>Some highlights:
>
>* SICP
>* Fundamental Algorithms
>* The Unix Programming Environment
>* Software Tools
>* Modern Perl
>
>The full set:  
>http://teamkave.us/files/books.html
>
>Thank you.

From chris at sencjw.com  Tue Oct  6 18:05:48 2020
From: chris at sencjw.com (Chris Wilson)
Date: Tue, 06 Oct 2020 13:05:48 -0500
Subject: Help Me Understand C Numbers
Message-ID: <59ef62df-42b2-4845-a1dc-989851a4a862@www.fastmail.com>

Hey all, longtime listener infrequent caller ;)

I've been working on a toy project as something to hack on between (and sometimes during) meetings:

https://challenge.synacor.com

The idea is that you're given a specification for a fictional machine architecture and then a compiled executable for that same architecture. Embedded within it are a series of codes that you have to unearth (and yes, some of them can be got just by using strings(1)).

Anyway, I've been implementing this using C and it was all going well until I got to implementing jmp. The jmp opcode was the first one that required lager numbers in order to be able to specify the location of the jump destination. In this architecture, numbers are stored as two bytes with little-endian arrangement: low byte, high byte. My code to read numbers went like this (old bad function followed by one that works):

// read the current 16-bit value at pc's location
unsigned short bad_read_num(char *buf) {
    unsigned short num = 0, offset;
    offset = pc * 2;
    return buf[offset+1] << 8 | buf[offset];
}

// read the current 16-bit value at pc's location
unsigned short read_num(char *buf) {
    unsigned short num = 0, offset, hi;
    unsigned char lo;

    offset = pc * 2;
    hi = buf[offset+1] << 8;
    lo = buf[offset];
    num = hi | lo;
    return num;
}

Here's an excerpt of test suite that demonstrates what's going on:

TEST read_num_works(void) {
    char buf[] = { 0xe4, 0x01 };
    pc = 0;
    ASSERT_EQ(65508, bad_read_num(buf));

    pc = 0;
    ASSERT_EQ(484, read_num(buf));
    PASS();
}

As you can see, the actual number should be 484 (0x01E4) but bad_read_num is returning: 65508 (0xFFE4). I get that something like sign extension (?) is happening but what is C thinking here? And would there be a better refactoring given how C numbers work?

Thanks!

-- 
  Chris Wilson
  chris at sencjw.com

From eric at faehnri.ch  Tue Oct  6 18:35:22 2020
From: eric at faehnri.ch (Eric Faehnrich)
Date: Tue, 06 Oct 2020 14:35:22 -0400
Subject: Help Me Understand C Numbers
In-Reply-To: <59ef62df-42b2-4845-a1dc-989851a4a862@www.fastmail.com>
References: <59ef62df-42b2-4845-a1dc-989851a4a862@www.fastmail.com>
Message-ID: <C149CCC5-F050-4A0E-9A13-47851E0B778E@faehnri.ch>

My quick understanding...

It seems << performs integer promotions to both operands to an int. Then the OR operation sees one value is an int so it also promotes the 0xe4, which looks negative so sign extends to0xffffffe4.

From chris at mikk.net  Tue Oct  6 23:54:34 2020
From: chris at mikk.net (Chris Mikkelson)
Date: Tue, 6 Oct 2020 18:54:34 -0500
Subject: Help Me Understand C Numbers
In-Reply-To: <C149CCC5-F050-4A0E-9A13-47851E0B778E@faehnri.ch>
References: <59ef62df-42b2-4845-a1dc-989851a4a862@www.fastmail.com>
 <C149CCC5-F050-4A0E-9A13-47851E0B778E@faehnri.ch>
Message-ID: <20201006235434.GA59862@mikk.net>

On Tue, Oct 06, 2020 at 02:35:22PM -0400, Eric Faehnrich wrote:
> My quick understanding...
>
> It seems << performs integer promotions to both
> operands to an int. Then the OR operation sees one
> value is an int so it also promotes the 0xe4, which
> looks negative so sign extends to0xffffffe4.

That sounds right to me, and I've run into this in a lot
of my own bit-tweezering. The best way around it I've
found is to cast early, to wit:

	unsigned short
	toshort(char *buf)
	{
		unsigned short lo, hi;

		lo = (unsigned short)buf[0];
		hi = (unsigned short)buf[1] << 8;

		return hi | lo;
	}

I would also suggest using unsigned char or preferably
uint8_t from stdint.h when dealing with arbitrary bytes,
as it avoids these sign issues.

-- 
Chris Mikkelson  | Setting delivery schedules is easy enough using the
chris at mikk.net   | I Ching, astrology, psychic hotlines, or any of the 
		 | well-known scatomantic and necromantic methodologies.
                 | Meeting your prophetic deadlines, though, is another
                 | bowl of entrails.   -- Stan Kelly-Bootle

From joe at begriffs.com  Wed Oct  7 05:43:04 2020
From: joe at begriffs.com (Joe Nelson)
Date: Wed, 7 Oct 2020 00:43:04 -0500
Subject: Installing mimedown on Debian
In-Reply-To: <1pCo~.wSWlVy3aqv2@19a6.net>
References: <1pCo~.wSWlVy3aqv2@19a6.net>
Message-ID: <20201007054304.GA25681@begriffs.com>

I'm CC'ing my reply to the friends list, hope you don't mind.  Perhaps
someone else knows about more about mailcap or mutt integration.

dave at 19a6.net wrote:
> I had some extra time, so I decided to try installing mimedown on my
> Debian machine. It wasn't super-straightforward, so I though I should
> share my experience with you.

Thank you for taking notes! I should update the readme with more
detailed libcmark install instructions for different platforms.

> Ah, of course. I need to install the library! After searching the
> Debian repo, I did apt install libcmark0 , but that didn't change
> anything.

Hm that's annoying. Could you give this one a try for me?
https://packages.debian.org/buster/libcmark-dev

Sometimes Linux distros use the "-dev" suffix for headers and libraries
of given programs. BSDs I think tend to include the dev extras with the
main program, such as these ports for Mac and OpenBSD:

https://ports.macports.org/port/cmark/summary
http://ports.su/textproc/cmark

> It works! I tried testing it by sending an email to my gmail account
> and viewing it in the web interface.
> 
> I did some more tests. Including the line
> 
> ![](https://teamkave.us/files/books1.jpg)

Thanks for the test case, I reproduced the problem. Examining the core
dump inside my debugger, it looks like the problem is in my new text
justification code, in best_breaks().

* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff74edab66 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff750a5080 libsystem_pthread.dylib`pthread_kill + 333
    frame #2: 0x00007fff74e361ae libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff74f348a6 libsystem_malloc.dylib`free + 521
    frame #4: 0x0000000109870ed6 md2mime`best_breaks(ws=0x00007f807b402840, width=72) at wrap.c:157
    frame #5: 0x0000000109870b27 md2mime`print_wrapped(ws=0x00007f807b402840, overhang="", width=72, flowed=true) at wrap.c:172
    frame #6: 0x000000010986f7a9 md2mime`render_inner_text(iter=0x00007f807b402c80, prefix="", overhang="", flow=true) at md2mime.c:117
    frame #7: 0x00000001098700cc md2mime`main(argc=2, argv=0x00007ffee6392928) at md2mime.c:309
    frame #8: 0x00007fff74d8a015 libdyld.dylib`start + 1
    frame #9: 0x00007fff74d8a015 libdyld.dylib`start + 1

When I added alt text to the image and reran, the crash went away, so
that gives me a pretty good hint.

> I did a little research on how I might get it working with mutt, but I
> didn't come up with any solid leads. I tried using the F command to filter
> the message, but mutt just puts everything in the first attachment. I guess
> it's not expecting a filter to add attachments. I suppose I should change
> the way it invokes msmtp to include mimedown, but I'm not sure that's the
> "right way" to do it.

I've been curious about that too. I learned that a system's .mailcap
file can specify not only how to view MIME types, but how to compose
them. There's a promising distinction between the "compose" vs
"composetyped" fields. https://tools.ietf.org/html/rfc1524.html Looks
like mutt knows about it too:
http://www.mutt.org/doc/manual/#advanced-mailcap

From chuck at cpjj.net  Tue Oct 13 15:39:28 2020
From: chuck at cpjj.net (Chuck Jungmann)
Date: Tue, 13 Oct 2020 10:39:28 -0500
Subject: What I've been working on, lately,
Message-ID: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>

I have been working on a C library that processes command line 
arguments. https://github.com/cjungmann/readargs

I have looked at a bunch of similar libraries on github.com, but I 
didn't find any that use my approach, which I think is easier and 
quicker to use.

I'll confess that I hope to win some recognition for this library, if 
only to learn about what the community values in a project like this.

I would like any feedback from the mailing list about a few things:

  * The README page is the first contact to a project.? In this case,
    I'm thinking about the README as a "sales brochure" that will tempt
    people to download and try it.? That means that the above-the-fold
    content is important.? I put a code sample above the list of
    advantages.? Does that work for you?? I'd be interested in being
    directed to project pages that you think do a good job of
    introducing the project.

  * I created /Texinfo/ documentation to explain how to use and extend
    the library.? Is it reasonable to expect programmers to use *info*
    to learn about the project, or should I also generate HTML to which
    users can refer online?? I'd also appreciate feedback on the content
    of the *info* file, if anyone is interested enough to download and
    install the library.? The Makefile can install the *info* file by
    itself, if necessary.

  * The README code sample is complete, but very rudimentary.? It is
    intended to show a simple case that doesn't need much explanation.?
    However, its simplicity cannot show features that might make the
    library more attractive.? What would be better?

     1.  ? To include more features in the README code listing, with or
        without explanation.
     2.  ? To create and link to another Markdown page that shows and
        explains more complex features.
     3.  ? To generate HTML from the *Texinfo* and link to its code
        listings.
     4.  ? To leave it as is because no one wants to read two code listings.

  * If you've read the README, is this a library that you would be
    interested in using for your next C project?? If not, why not? I'm
    curious if there are things that make you more or less willing to
    explore a project.

I'm apologize if this is an inappropriate request.? If we were still 
having IRL meetings, I would have tried to judge how appropriate this is 
by reading the reactions of a couple of people I might have shown my work.

Thanks for reading this.

Chuck Jungmann

P.S. I am sending this as a mixed HTML/plain text email.? I once posted 
something that my email client had sent as HTML only and it never made 
it to the list.? I'm curious the list accepts a mixed email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://talk.begriffs.com/pipermail/friends/attachments/20201013/9a20f4aa/attachment.html>

From june at causal.agency  Tue Oct 13 20:33:44 2020
From: june at causal.agency (June Bug)
Date: Tue, 13 Oct 2020 16:33:44 -0400
Subject: What I've been working on, lately,
In-Reply-To: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
References: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
Message-ID: <DCADCE7B-BD9F-40BA-B070-EF24B3408939@causal.agency>

Sorry about the awkward quoting here. My mail client only wants to
quote the unwrapped HTML version of the original message.

> 	? The README page is the first contact to a project.  In this case, I'm thinking about the README as a "sales brochure" that will tempt people to download and try it.  That means that the above-the-fold content is important.  I put a code sample above the list of advantages.  Does that work for you?  I'd be interested in being directed to project pages that you think do a good job of introducing the project.


I think I?d rather see the list of features first. In my projects
I also like to include a list of non-features, because I like to
find software that does what I need without doing a bunch of stuff
I don?t. I also like to see a features list that focuses on what
makes this software different from similar pieces of software.

> 	? I created Texinfo documentation to explain how to use and extend the library.  Is it reasonable to expect programmers to use info to learn about the project, or should I also generate HTML to which users can refer online?  I'd also appreciate feedback on the content of the info file, if anyone is interested enough to download and install the library.  The Makefile can install the info file by itself, if necessary.

Personally I wouldn?t use a C library that doesn?t have man pages.
Texinfo seems decent for tutorial-like content, but the standard
structure and naming convention of man pages is much better for
referencing while writing code, in my experience. And you don?t
need to learn how to use Emacs or pretend-Emacs; pressing K on a
function name in (neo)vim is very convenient.

> 	? If you've read the README, is this a library that you would be interested in using for your next C project?  If not, why not?  I'm curious if there are things that make you more or less willing to explore a project.
> I'm apologize if this is an inappropriate request.  If we were still having IRL meetings, I would have tried to judge how appropriate this is by reading the reactions of a couple of people I might have shown my work.

In my opinion, given the size of what the library does, it?s
unreasonable to distribute as an actual shared library. Getting
those installed properly on a system where they?re not packaged,
just to try one program that wants to use it, is quite a hassle.
As an application developer, I ideally only want to use libraries
that are either packaged everywhere, or that I can easily vendor
in my project. Single-file libraries are easiest (for instance
<https://github.com/nothings/stb>), but anything that can be added
to a project just by copying a couple files in is good.

From joe at begriffs.com  Thu Oct 15 03:52:06 2020
From: joe at begriffs.com (Joe Nelson)
Date: Wed, 14 Oct 2020 22:52:06 -0500
Subject: What I've been working on, lately,
In-Reply-To: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
References: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
Message-ID: <20201015035206.GC80092@begriffs.com>

Chuck Jungmann wrote:
> I have been working on a C library that processes command line arguments.
> https://github.com/cjungmann/readargs
> ...
> I apologize if this is an inappropriate request.? If we were still
> having IRL meetings, I would have tried to judge how appropriate this
> is by reading the reactions of a couple of people I might have shown
> my work.

First, I don't think it's inappropriate at all! I love that you share
what you're working on. One of my hopes for our group is that we can
boost and review each other's projects.

>  * The README page is the first contact to a project.? In this case,
>    I'm thinking about the README as a "sales brochure" that will tempt
>    people to download and try it.? That means that the above-the-fold
>    content is important.? I put a code sample above the list of
>    advantages.? Does that work for you?? I'd be interested in being
>    directed to project pages that you think do a good job of
>    introducing the project.

Seeing code snippets is very helpful, but I think one of the first
things I'd like to see is a list of similar software and how readargs
differs from them. Those differences and the reasoning behind them would
help me see where it fits into the picture.

>  * I created /Texinfo/ documentation to explain how to use and extend
>    the library.? Is it reasonable to expect programmers to use *info*
>    to learn about the project, or should I also generate HTML to which
>    users can refer online?? I'd also appreciate feedback on the content
>    of the *info* file, if anyone is interested enough to download and
>    install the library.? The Makefile can install the *info* file by
>    itself, if necessary.

I'm glad you're including local documentation with the library!  Many
don't do that and refer people exclusively to online docs...  However,
might I ask why you chose `info` pages rather than man pages?  Man works
on more systems.

>  * The README code sample is complete, but very rudimentary.? It is
>    intended to show a simple case that doesn't need much explanation.?
>    However, its simplicity cannot show features that might make the
>    library more attractive.? What would be better?
> 
>     1.  ? To include more features in the README code listing, with or
>        without explanation.

Personal opinion, but I'd say choice 1. Make the most of your code
example and show some of the nice features. I can then intuit a little
more about what it's offering me.

>  * If you've read the README, is this a library that you would be
>    interested in using for your next C project?? If not, why not? I'm
>    curious if there are things that make you more or less willing to
>    explore a project.

What would make the README more interesting is more comparisons and
specifics. For instance in "Why use this library" you list advantages,
but I'd like to see examples in there. So in "Easy-to-scan, Compact
Code," maybe show actual snippets of your code vs POSIX getopt(), vs
https://github.com/skeeto/optparse 

Under "Generates Help and Usage Displays" show an example usage screen,
and error messages for incorrect input. As they say about fiction
writing: show, don't tell.

## Code review

I cloned the project to take a look. The following notes are for commit
c393dab. The first thing I noticed is that there's no Makefile at the
root of the project, so the installation instructions didn't work. There
was a Makefile in src, so I tried in there.

	$ make
	*** Parse error in /home/begriffs/readargs/src: Missing dependency operator (Makefile:18)
	*** Parse error: Need an operator in 'endif' (Makefile:22)
	*** Parse error: Need an operator in 'build_install_info' (Makefile:26)
	*** Parse error: Need an operator in 'endef' (Makefile:31)
	*** Parse error: Need an operator in 'remove_info' (Makefile:33)
	*** Parse error: Need an operator in 'endef' (Makefile:36)

That was using BSD make. So my assumption is that it must rely on GNU
make extensions.

	$ gmake
	clang -Wall -Werror -std=c99 -pedantic -m64 -fPIC -shared -fvisibility=hidden -c -o scene.o scene.c
	gmake: /bin/bash: Command not found
	gmake: *** [Makefile:50: scene.o] Error 127

OK, we're getting somewhere. However the `SHELL=/bin/bash` specifies a
path that doesn't exist on all Unices. Using `SHELL=${/bin/env bash}`
instead gets past that one.

	$ gmake
	clang -Wall -Werror -std=c99 -pedantic -m64 -fPIC -shared -fvisibility=hidden -c -o scene.o scene.c
	gmake: -O: Command not found
	gmake: *** [Makefile:50: scene.o] Error 127

After messing with .SHELLFLAGS I ran into more problems and it wasn't
clear what to do.

I created a Debian 10 VM to try things in GNUville. The project compiled
just fine there.

Now looking at the code.

* The terminology of scenes, tours, and agents is obscure to me. Are
  there more common names for these things?

* Why do you use
  __attribute__((visibility("default")))?  Can't you choose the hiding
  or sharing by choosing static or non-static declarations? I'm
  surprised the code compiled cleanly with -std=c99 -pedantic, because
  that __attribute__ is a GNU extension.

* alloca is not in the C standard or POSIX. Also if the allocation
  causes stack overflow, program behaviour is undefined.

* Rather than if(str_is_number(s) n = atoi(s); what about a function
  like strtol that can detect errors? Atoi is pretty nasty, it's UB when
  it fails, I believe even for overflow.

* With all the states and string scanning in ra_advance_action and
  ra_seek_*, and the code in str2args, I wonder whether it would be more
  compact to define a yacc grammar of valid argument strings?

* Some strings have hard coded ANSI escape codes for colors etc. Might
  be more robust to use ncurses, since it's probably installed on most
  systems.  I can understand if you want to avoid another dependency
  though.

Anyhow, those are random things I noticed. And as for the whole
portability thing, it's of course reasonable not to care about it.
Maybe you intend to use the library on only Linux, and you're
comfortable in that environment and you enjoy the extra conveniences.
I'd just say that if this is a Linux-only library, just document that in
the README.

If you do want to pursue more portability, you're welcome to use our
frostbyte.cc server to try building the project. It's OpenBSD so it will
uncover things. I find portability to be a fun challenge because it
sometimes makes you code things in a cleaner way.

> P.S. I am sending this as a mixed HTML/plain text email.? I once
> posted something that my email client had sent as HTML only and it
> never made it to the list.? I'm curious the list accepts a mixed
> email.

The plaintext part of your message is beautifully formatted in my
reader.

Since I was experimenting with mimedown, I allowed more types of mail on
this list. It currently accepts these MIME types:

	multipart/mixed
	multipart/alternative
	text/html
	text/uri-list
	text/plain
	text/x-diff
	text/x-patch
	application/x-patch
	image/png

From joe at begriffs.com  Thu Oct 15 04:30:47 2020
From: joe at begriffs.com (Joe Nelson)
Date: Wed, 14 Oct 2020 23:30:47 -0500
Subject: What I've been working on, lately,
In-Reply-To: <DCADCE7B-BD9F-40BA-B070-EF24B3408939@causal.agency>
References: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
 <DCADCE7B-BD9F-40BA-B070-EF24B3408939@causal.agency>
Message-ID: <20201015043047.GD80092@begriffs.com>

June Bug wrote:
> I think I?d rather see the list of features first. In my projects
> I also like to include a list of non-features, because I like to
> find software that does what I need without doing a bunch of stuff
> I don?t. I also like to see a features list that focuses on what
> makes this software different from similar pieces of software.

+1 on non-features and differences.

> Personally I wouldn?t use a C library that doesn?t have man pages.
> Texinfo seems decent for tutorial-like content, but the standard
> structure and naming convention of man pages is much better for
> referencing while writing code, in my experience. And you don?t
> need to learn how to use Emacs or pretend-Emacs; pressing K on a
> function name in (neo)vim is very convenient.

+1 on this too. Do you have opinions or advice about choosing man page
dialects like http://man.openbsd.org/mdoc.7 vs
http://man.openbsd.org/man.7 ?

> In my opinion, given the size of what the library does, it?s
> unreasonable to distribute as an actual shared library.

Additionally, if it *is* installed as a shared library, it should
install pkg-config metadata so I can more easily build against it.
https://people.freedesktop.org/~dbn/pkg-config-guide.html

> As an application developer, I ideally only want to use libraries
> that are either packaged everywhere, or that I can easily vendor
> in my project.

I'd also rather use a library that's widely available in OS packages,
but if I can ./configure; make; make install and it works without a
problem then that's not so bad either. It's when a project has some
weird CMake setup that it starts being no fun.

> Single-file libraries are easiest (for instance
> <https://github.com/nothings/stb>), but anything that can be added to
> a project just by copying a couple files in is good.

If a library is just providing a bunch of macros then header-only makes
sense, but otherwise it feels like an abuse or misunderstanding of the
notion of a translation unit. I do love how vendoring Just Works, and
doesn't impose any unreliable interaction with the target system, but if
a library is big enough it's better not to fear the linker/loader.

Speaking of stb, I got a bad taste in my mouth after reviewing its
implementation of stretchy_buffer. More like sketchy_buffer. :) Details
about that are in my message <20200927235728.GA7738 at begriffs.com>.

From nicholasdrozd at gmail.com  Thu Oct 15 21:12:33 2020
From: nicholasdrozd at gmail.com (Nicholas Drozd)
Date: Thu, 15 Oct 2020 16:12:33 -0500
Subject: What I've been working on, lately,
In-Reply-To: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
References: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
Message-ID: <CABAiW0q+9XNWOMQ4Z-GLSbzSZa3ZiCZFN9Z9AZ6JprwahqW_eA@mail.gmail.com>

I second the suggestion to put a Makefile at the toplevel. You can
additionally put Makefiles in any or all of the subdirectories and
have higher ones call lower ones "recursively". It's the classy way to
do it!

None of the doc commands worked for me on Ubuntu (commit 074a967). Example:

  make install-docs
  makeinfo ../docs/readargs.txi
  ../docs/functions_basic.txi:21: unknown command `subentry'
  ../docs/functions_basic.txi:63: unknown command `subentry'
  ../docs/functions_basic.txi:91: unknown command `subentry'
  Makefile:75: recipe for target 'install-docs' failed
  make: *** [install-docs] Error 1

From chuck at cpjj.net  Fri Oct 16 14:15:10 2020
From: chuck at cpjj.net (Chuck Jungmann)
Date: Fri, 16 Oct 2020 09:15:10 -0500
Subject: Fwd: Re: What I've been working on, lately,
In-Reply-To: <cf3075bc-dd2c-0995-4c52-7a75ba9d7c46@cpjj.net>
References: <cf3075bc-dd2c-0995-4c52-7a75ba9d7c46@cpjj.net>
Message-ID: <710cded6-e274-1f40-80ef-c6f92fd64773@cpjj.net>

Joe kindly informed me that I emailed him instead of the list, and I did 
the same with this response.



-------- Forwarded Message --------
Subject: 	Re: What I've been working on, lately,
Date: 	Tue, 13 Oct 2020 21:47:58 -0500
From: 	Chuck Jungmann <chuck at cpjj.net>
To: 	June Bug <june at causal.agency>



First, thank you for taking time for a thoughtful response to my email.

On 10/13/20 3:33 PM, June Bug wrote:
> Sorry about the awkward quoting here. My mail client only wants to
> quote the unwrapped HTML version of the original message.
>
>> ? The README page is the first contact to a project. In this case, 
>> I'm thinking about the README as a "sales brochure" that will tempt 
>> people to download and try it. That means that the above-the-fold 
>> content is important. I put a code sample above the list of 
>> advantages. Does that work for you? I'd be interested in being 
>> directed to project pages that you think do a good job of introducing 
>> the project.
>
> I think I?d rather see the list of features first. In my projects
> I also like to include a list of non-features, because I like to
> find software that does what I need without doing a bunch of stuff
> I don?t. I also like to see a features list that focuses on what
> makes this software different from similar pieces of software.
I spent a little time looking through your github and causal.agency 
projects.? Are there a couple of example projects (yours or someone 
else's) you recommend that show features/non-features the way you 
prefer?? I decided to put my features list below the code sample because 
they are so long.? I'd like to see alternate presentations for inspiration.
>
>> ? I created Texinfo documentation to explain how to use and extend 
>> the library. Is it reasonable to expect programmers to use info to 
>> learn about the project, or should I also generate HTML to which 
>> users can refer online? I'd also appreciate feedback on the content 
>> of the info file, if anyone is interested enough to download and 
>> install the library. The Makefile can install the info file by 
>> itself, if necessary.
> Personally I wouldn?t use a C library that doesn?t have man pages.
> Texinfo seems decent for tutorial-like content, but the standard
> structure and naming convention of man pages is much better for
> referencing while writing code, in my experience. And you don?t
> need to learn how to use Emacs or pretend-Emacs; pressing K on a
> function name in (neo)vim is very convenient.
I was going to write man pages, but found the GNU standards document 
that says "In the GNU project, man pages are secondary." (info standards 
"Man Pages")? I will write man pages for the functions if people start 
to use it, but I find that info pages are more useful to me because I 
can include links between code listings, functions, and topics.? I 
appreciate your preference, however.? I refer to man pages all the time, 
and like that I don't need to open a browser or have internet access to 
figure out how to use something.
>
>> ? If you've read the README, is this a library that you would be 
>> interested in using for your next C project? If not, why not? I'm 
>> curious if there are things that make you more or less willing to 
>> explore a project.
>> I'm apologize if this is an inappropriate request. If we were still 
>> having IRL meetings, I would have tried to judge how appropriate this 
>> is by reading the reactions of a couple of people I might have shown 
>> my work.
> In my opinion, given the size of what the library does, it?s
> unreasonable to distribute as an actual shared library. Getting
> those installed properly on a system where they?re not packaged,
> just to try one program that wants to use it, is quite a hassle.
> As an application developer, I ideally only want to use libraries
> that are either packaged everywhere, or that I can easily vendor
> in my project. Single-file libraries are easiest (for instance
> <https://github.com/nothings/stb>), but anything that can be added
> to a project just by copying a couple files in is good.

I also had this thought, that this would be better as a static-link 
library.? I just have more experience creating shared-object libraries.? 
I will heed your suggestion.

Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://talk.begriffs.com/pipermail/friends/attachments/20201016/c2f5d1fb/attachment.html>

From chuck at cpjj.net  Fri Oct 16 14:18:53 2020
From: chuck at cpjj.net (Chuck Jungmann)
Date: Fri, 16 Oct 2020 09:18:53 -0500
Subject: Fwd: Re: What I've been working on, lately,
In-Reply-To: <f84e9070-b2e6-52c2-c1a6-8fcc57b87503@cpjj.net>
References: <f84e9070-b2e6-52c2-c1a6-8fcc57b87503@cpjj.net>
Message-ID: <0ddb57f1-bc2b-2dc4-8ef9-17d956093347@cpjj.net>

I sent this to Joe instead of the list.? Here it is for the edification 
of all.


-------- Forwarded Message --------


Subject: 	Re: What I've been working on, lately,
Date: 	Thu, 15 Oct 2020 17:15:28 -0500
From: 	Chuck Jungmann <chuck at cpjj.net>
To: 	Joe Nelson <joe at begriffs.com>



On 10/14/20 10:52 PM, Joe Nelson wrote:
> ## Code review
>
> I cloned the project to take a look. The following notes are for commit
> c393dab. The first thing I noticed is that there's no Makefile at the
> root of the project, so the installation instructions didn't work. There
> was a Makefile in src, so I tried in there.
>
> $ make
> *** Parse error in /home/begriffs/readargs/src: Missing dependency 
> operator (Makefile:18)
> *** Parse error: Need an operator in 'endif' (Makefile:22)
> *** Parse error: Need an operator in 'build_install_info' (Makefile:26)
> *** Parse error: Need an operator in 'endef' (Makefile:31)
> *** Parse error: Need an operator in 'remove_info' (Makefile:33)
> *** Parse error: Need an operator in 'endef' (Makefile:36)
>
> That was using BSD make. So my assumption is that it must rely on GNU
> make extensions.
>
> $ gmake
> clang -Wall -Werror -std=c99 -pedantic -m64 -fPIC -shared 
> -fvisibility=hidden -c -o scene.o scene.c
> gmake: /bin/bash: Command not found
> gmake: *** [Makefile:50: scene.o] Error 127
>
> OK, we're getting somewhere. However the `SHELL=/bin/bash` specifies a
> path that doesn't exist on all Unices. Using `SHELL=${/bin/env bash}`
> instead gets past that one.
>
> $ gmake
> clang -Wall -Werror -std=c99 -pedantic -m64 -fPIC -shared 
> -fvisibility=hidden -c -o scene.o scene.c
> gmake: -O: Command not found
> gmake: *** [Makefile:50: scene.o] Error 127
>
> After messing with .SHELLFLAGS I ran into more problems and it wasn't
> clear what to do.
I didn't realize that there would be so much trouble building the 
project in BSD.? Frankly, I hadn't considered it at all.? I'll look into 
what I need to do to ensure compatibility. Unfortunately, I have taken 
advantage of some conveniences available in GNU, so I need to weigh the 
value of compatibility with the effort in achieving it.? I made a 
NomadBSD USB drive as a start, and will try to ensure that gmake, at 
least, can build the project.
>
> I created a Debian 10 VM to try things in GNUville. The project compiled
> just fine there.
>
> Now looking at the code.
>
> * The terminology of scenes, tours, and agents is obscure to me. Are
> there more common names for these things?

I always spend an uncomfortable amount of time naming objects. In this 
project, I am using several states that I need to name.? I save the list 
of command line arguments and "action" array elements, both static and 
constant, to the "scene."? Since the contents of the main scene are 
unchanging, it can be a global variable, so its contents are always 
available, even after the arguments have been processed.? Then there is 
a "tour" object that contains pointers to the scene that are updated as 
the library considers each command line argument.? Processing the 
arguments is a tour through the scene.? I separated the "tour" from the 
"scene" because I wanted to be able to restart or copy the "tour" 
without disturbing the "scene."? I agree that they are obscure names, 
but I couldn't think of better ones at the time.

You didn't mention "action," but it is also a strange name.? It is the 
corollary to "struct option" in getopt.h, but since it also handles 
non-option arguments, it seemed wrong to call it an option.

Based on what it does, the name "agent" seems appropriate, though I 
guess it's a bit obscure, too.? In this context, the agent is a C-style 
object that performs a read or write operation on behalf of the action.

Naming objects is one of many areas where I regret working alone. I'd 
prefer to try out terms on other programmers, but I'm limited to my own 
peculiar way of categorizing things.

>
> * Why do you use
> __attribute__((visibility("default")))? Can't you choose the hiding
> or sharing by choosing static or non-static declarations? I'm
> surprised the code compiled cleanly with -std=c99 -pedantic, because
> that __attribute__ is a GNU extension.
I wanted to use short function names, and I worried about name 
collisions, so I wanted to hide function names that were not for public 
consumption.? When I looked into this, I understood the situation to be 
that all functions in a library were accessible, and that setting the 
visibility flag was the appropriate way to hide some of them.? I can 
easily change this since the flag is set with a macro.
>
> * alloca is not in the C standard or POSIX. Also if the allocation
> causes stack overflow, program behaviour is undefined.
As you may recall, one of my peculiarities is to avoid using heap 
memory.? I wanted my library to allow this.? Also, in the few cases I 
use alloca, I'm duplicating the C++ feature of declaring a local array 
with a variable for the length.? Using alloca in this way is no more 
likely to cause stack overflow than the C++ way of doing it.
>
> * Rather than if(str_is_number(s) n = atoi(s); what about a function
> like strtol that can detect errors? Atoi is pretty nasty, it's UB when
> it fails, I believe even for overflow.
I only recently discovered the strtoX functions when I was more worried 
about errors while making a float processing example.? I'm a bit old 
school, using the functions I am familiar with.? I appreciate comments 
that inform me of better practices.
>
> * With all the states and string scanning in ra_advance_action and
> ra_seek_*, and the code in str2args, I wonder whether it would be more
> compact to define a yacc grammar of valid argument strings?
I've never worked with yacc.? I'm familiar with it only to the extent 
that I know what its letters stand for and, from that, what I infer its 
purpose to be.? I saw a yacc grammer definition recently, is it 
something that can be embedded into a C program? I may look into this 
for academic purposes, though I am reasonably happy with how my program 
is handling this right now.
>
> * Some strings have hard coded ANSI escape codes for colors etc. Might
> be more robust to use ncurses, since it's probably installed on most
> systems. I can understand if you want to avoid another dependency
> though.
One of my programming practices is the create a #ifdef ...#endif section 
in modules that defines main() and runs tests to confirm the proper 
operation of certain functions.? The #ifdef section is only compiled in 
EMACS when I run the "compile" command, and it makes an executable from 
the module.? The ANSI codes are in these sections or in the source code 
of programs that test the library.
>
> Anyhow, those are random things I noticed. And as for the whole
> portability thing, it's of course reasonable not to care about it.
> Maybe you intend to use the library on only Linux, and you're
> comfortable in that environment and you enjoy the extra conveniences.
> I'd just say that if this is a Linux-only library, just document that in
> the README.
>
> If you do want to pursue more portability, you're welcome to use our
> frostbyte.cc server to try building the project. It's OpenBSD so it will
> uncover things. I find portability to be a fun challenge because it
> sometimes makes you code things in a cleaner way.

I made a NomadBSD USB drive that I'll use for testing, so I won't need 
the frostbyte server just yet.? Thank you for the offer.? I agree that 
it would be satisfying to make it possible to build on BSD.? I'm going 
to at least try to achieve "gmake" compatibility. I don't know if going 
for full BSD-make is practical right now.? I am using a few GNU-make 
features that would be hard to work around.? I would reconsider in the 
unlikely event that the library becomes popular.


I really appreciate the time you spent reviewing my code and making 
comments.? I will probably respond separately to your comments about 
documentation (info vs man pages) and README contents.? That's another 
area where I appreciate feedback, but is a different domain from your 
code review.

Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://talk.begriffs.com/pipermail/friends/attachments/20201016/c3b4caa5/attachment.html>

From rhayman at pureice.com  Fri Oct 16 16:38:16 2020
From: rhayman at pureice.com (r hayman)
Date: Fri, 16 Oct 2020 11:38:16 -0500
Subject: hardware that needs a good home
Message-ID: <95f194fe5d2d826d3d740ebdd17c7dd871ae0c85.camel@pureice.com>

Cleaning out some old electronics if anyone wants/needs any of this. 
This stuff needs to find a good home so it doesn't go into the
electronic waste dump.
I live in Eagan, MN and would rather not ship.

Email me off-list and make an offer if you can give it a good home/make
use of it.

SCSI
======
Anybody still run SCSI HDDs? - good spares if you need to support
legacy equipment.

I have tested these HDDs by doing a low-level drive format (wrote zeros
across device and then GPT formatted) each of these.

(1)		Compaq, 7200 RPM, Ultra 2 wide, 68 pin BB009222B5,
9.1GB

(10)	Seagate Cheetah, 10K RPM, Ultra 2 wide, 80 pin, ST318203LC
,18.2GB

(1)		Quantum Atlas 10K, 10K RPM, 68 pin, TN18L462, 18GB

(1)		Seagate Cheetah, 10K RPM, Ultra 160, 68 pin,
ST336706LW, 36.7GB

(2)		Quantum Atlas 10K ii, 10K RPM, Ultra wide, 68 pin,
TY73L011, 73.4GB

I also have
(2)		80-pin to 68-pin SCSI Ultra 320 compliant adapters (80
pin on one side, 68 pin + 4-pin power on the other)


4U 16-bay SATA servers
=====================
I have two 4U rack mount servers that I haven't powered up in years,
but they ran fine when I shut them down.
I can secure erase the HDDs if you want them included, but that'll take
a few days.
HDDs were all Seagate Barracudas, but I see I replaced a failed one
with a Western Digital Caviar Black.
CDROM or CD/DVD and Gb ethernet in each

#1	16 bay SATA connected to two 3Ware 9550SX RAID controllers (I
ran 2 8x750GB HDD RAID5 arrays)
	Boot drive: separate SATA (RAID or HDD) connected to mainboard
	mainboard: Supermicro X6DHE-XB
	case: Chenbro RM414
	CPU: 2x 3.0GHz Xeon
	RAM: 16GB PC2100 DDR 266 ECC Reg

#2	16 bay SATA connected to two 3Ware 9550SX RAID controllers (I
ran 2 8x500GB HDD RAID5 arrays)
	Boot drive: separate SATA (RAID or HDD) connected to mainboard
	mainboard: Supermicro X6DHE-XB
	case: Chenbro RM414
	CPU: 2x 3.4GHz Xeon
	RAM: 4GB PC2100 DDR 266 ECC Reg


KVM switch
==============
I also have an Altusen KN9116 remote KVM controller with cables that I
used in my home 42U rack
https://www.aten.com/global/en/products/kvm/kvm-over-ip-switches/kn9116/


Embedded ATA SSDs
====================
(2)	Zheino Industrial B 8GB SLC SSD
(2)	Zheino Industrial B 16GB SLC SSD


Tabloid Printer
================
Xerox Phaser 7700gx with optional 3 drawer base set up for 2 letter, 1
legal, 1 tabloid
Does not print well - prints illegible greyish smudge.
It has lots of toner remaining, plus NIB high-capacity Black, Yellow,
and Magenta toner cartridges.
I also have NIB waste toner cartridge and NIB belt cleaner assembly.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://talk.begriffs.com/pipermail/friends/attachments/20201016/59b0a4ff/attachment.html>

From joe at begriffs.com  Fri Oct 16 18:14:28 2020
From: joe at begriffs.com (Joe Nelson)
Date: Fri, 16 Oct 2020 13:14:28 -0500
Subject: Fwd: Re: What I've been working on, lately,
In-Reply-To: <0ddb57f1-bc2b-2dc4-8ef9-17d956093347@cpjj.net>
References: <f84e9070-b2e6-52c2-c1a6-8fcc57b87503@cpjj.net>
 <0ddb57f1-bc2b-2dc4-8ef9-17d956093347@cpjj.net>
Message-ID: <20201016181428.GB26133@begriffs.com>

> > * Why do you use
> > __attribute__((visibility("default")))? Can't you choose the hiding
> > or sharing by choosing static or non-static declarations? I'm
> > surprised the code compiled cleanly with -std=c99 -pedantic, because
> > that __attribute__ is a GNU extension.

> I wanted to use short function names, and I worried about name collisions,
> so I wanted to hide function names that were not for public consumption.?
> When I looked into this, I understood the situation to be that all functions
> in a library were accessible, and that setting the visibility flag was the
> appropriate way to hide some of them.? I can easily change this since the
> flag is set with a macro.

Truth be told I've never created my own shared library yet, so maybe
there are things I don't understand about symbol visibility. :) However
my assumption is that the "static" keyword in standard C controls it
(among its other overloaded uses).

Just tried this test. Created stuff.c:

	int f(void)
	{
		return 0;
	}

	static int g(void)
	{
		return 0;
	}

Then checked which symbols are public in its object file:

	$ cc -c -o stuff.o stuff.c
	$ nm stuff.o
	0000000000000000 T _f

Looks like f() is visible and g() is hidden.

> > * alloca is not in the C standard or POSIX. Also if the allocation
> > causes stack overflow, program behaviour is undefined.

> As you may recall, one of my peculiarities is to avoid using heap memory.

Can you tell me more about that choice? What are the pros and cons?

> Also, in the few cases I use alloca, I'm duplicating the C++ feature
> of declaring a local array with a variable for the length.? Using
> alloca in this way is no more likely to cause stack overflow than the
> C++ way of doing it.

Since you're using C99 (your makefile specifies -std=c99 at least), what
about using the variable length array (VLA) language feature? That would
be portable everywhere that C99 is, unlike alloca() which is nonstandard.

For instance:

	#include <alloca.h>

	/* alloca way */
	void f(size_t len)
	{
		foo *a = alloca(len * sizeof *a);
		/* ... */
	}

	/* VLA way */
	void g(size_t len)
	{
		foo a[len];
		/* ... */
	}

The VLA also has the advantage that it really is an array, e.g.
sizeof(a)/sizeof(*a) is its length.

> > * With all the states and string scanning in ra_advance_action and
> > ra_seek_*, and the code in str2args, I wonder whether it would be more
> > compact to define a yacc grammar of valid argument strings?
> I've never worked with yacc.? I'm familiar with it only to the extent that I
> know what its letters stand for and, from that, what I infer its purpose to
> be.? I saw a yacc grammer definition recently, is it something that can be
> embedded into a C program? I may look into this for academic purposes,
> though I am reasonably happy with how my program is handling this right now.

The reason it comes to mind is that I'm studying a book right now about
Lex and Yacc. I have a hammer so it everything looks like a nail. ;)

For instance, compare this C code to scan through a string with its
corresponding Lex version.

C
https://github.com/begriffs/lexyacc/blob/master/ch1-lex-vs-c-2.c?ts=4

Lex
https://github.com/begriffs/lexyacc/blob/master/ch1-lex-vs-c-1.l?ts=4

They even have an example of using Lex on argv. Here's my slightly
cleaned up version:

https://github.com/begriffs/lexyacc/blob/master/ch2-06.l?ts=4

That example has hard-coded options and has to build its own usage
message by hand, but I'm thinking that going to the next level with Yacc
would allow it to be generic. Anyway I'll give it a try when I get
further in the book and learn more.

From joe at begriffs.com  Wed Oct 21 03:25:48 2020
From: joe at begriffs.com (Joe Nelson)
Date: Tue, 20 Oct 2020 22:25:48 -0500
Subject: Real man pages for POSIX reference?
Message-ID: <20201021032548.GA53936@begriffs.com>

The latest POSIX spec is available as a downloadable tarball of HTML
articles: https://pubs.opengroup.org/onlinepubs/9699919799/download/index.html
I wish it was available in man page format so I could change man's
search path and read those files as desired.

For instance, here's the HTML article for ls:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

It's obviously a man page in spirit, just wish I could consume it that
way rather than having to pop into a browser.

Thought it would be a cool project for anyone who likes text
manipulation to write an html2man program that converts each POSIX HTML
article to its man page equivalent. Or maybe such a program already
exists...

From june at causal.agency  Wed Oct 21 04:02:40 2020
From: june at causal.agency (June Bug)
Date: Wed, 21 Oct 2020 00:02:40 -0400
Subject: Real man pages for POSIX reference?
In-Reply-To: <20201021032548.GA53936@begriffs.com>
References: <20201021032548.GA53936@begriffs.com>
Message-ID: <0F7C5B3C-BFA8-40BD-84D2-9C0B6BDE8550@causal.agency>


> On Oct 20, 2020, at 23:25, Joe Nelson <joe at begriffs.com> wrote:
> 
> The latest POSIX spec is available as a downloadable tarball of HTML
> articles: https://pubs.opengroup.org/onlinepubs/9699919799/download/index.html
> I wish it was available in man page format so I could change man's
> search path and read those files as desired.
> 
> For instance, here's the HTML article for ls:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
> 
> It's obviously a man page in spirit, just wish I could consume it that
> way rather than having to pop into a browser.
> 
> Thought it would be a cool project for anyone who likes text
> manipulation to write an html2man program that converts each POSIX HTML
> article to its man page equivalent. Or maybe such a program already
> exists...

The Linux man-pages project has POSIX man pages available from
<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/>.
You can install them in some distros as something like ?man-pages-posix?,
and they?re in 0p, 1p and 3p sections. It?s not clear to me however
where the sources for these come from.

I had a similar idea with the man page search path, and I wrote a
tool to download man pages for POSIX, Linux, FreeBSD, NetBSD and
OpenBSD to be read locally: <https://git.causal.agency/exman/>. The
wrapper script essentially just sets MANPATH for the system you
want to read manuals from.

From june at causal.agency  Wed Oct 21 04:13:48 2020
From: june at causal.agency (June Bug)
Date: Wed, 21 Oct 2020 00:13:48 -0400
Subject: What I've been working on, lately,
In-Reply-To: <20201015043047.GD80092@begriffs.com>
References: <8435a082-4d6f-d3af-6b7c-da127f71e88a@cpjj.net>
 <DCADCE7B-BD9F-40BA-B070-EF24B3408939@causal.agency>
 <20201015043047.GD80092@begriffs.com>
Message-ID: <4D49AA05-5F46-439B-BA72-42E04A4EB8BB@causal.agency>


>> Personally I wouldn?t use a C library that doesn?t have man pages.
>> Texinfo seems decent for tutorial-like content, but the standard
>> structure and naming convention of man pages is much better for
>> referencing while writing code, in my experience. And you don?t
>> need to learn how to use Emacs or pretend-Emacs; pressing K on a
>> function name in (neo)vim is very convenient.
> 
> +1 on this too. Do you have opinions or advice about choosing man page
> dialects like http://man.openbsd.org/mdoc.7 vs
> http://man.openbsd.org/man.7 ?

I haven?t come across any reason not to use mdoc(7). It can be
formatted almost as well by groff as by mandoc, and it?s far nicer
to author in than man(7). It baffles me that man(7) is still so
prevalent.

>> As an application developer, I ideally only want to use libraries
>> that are either packaged everywhere, or that I can easily vendor
>> in my project.
> 
> I'd also rather use a library that's widely available in OS packages,
> but if I can ./configure; make; make install and it works without a
> problem then that's not so bad either. It's when a project has some
> weird CMake setup that it starts being no fun.

Even the usual ./configure; make; make install steps aren?t foolproof
with libraries. Usually the default PREFIX is set to /usr/local,
but many distros don?t include /usr/local/lib in their library
search path by default. Even when that?s set up correctly, if you
forget to run ldconfig(8), the compiler will find the library, but
then the dynamic linker won?t be able to find it, which is really
confusing if you?re not familiar.

From joe at begriffs.com  Thu Oct 22 03:07:34 2020
From: joe at begriffs.com (Joe Nelson)
Date: Wed, 21 Oct 2020 22:07:34 -0500
Subject: Real man pages for POSIX reference?
In-Reply-To: <0F7C5B3C-BFA8-40BD-84D2-9C0B6BDE8550@causal.agency>
References: <20201021032548.GA53936@begriffs.com>
 <0F7C5B3C-BFA8-40BD-84D2-9C0B6BDE8550@causal.agency>
Message-ID: <20201022030734.GE53936@begriffs.com>

June Bug wrote:
> The Linux man-pages project has POSIX man pages available from
> <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/>.
> You can install them in some distros as something like ?man-pages-posix?,
> and they?re in 0p, 1p and 3p sections. It?s not clear to me however
> where the sources for these come from.

This is brilliant! Thank you so much.

> I had a similar idea with the man page search path, and I wrote a tool
> to download man pages for POSIX, Linux, FreeBSD, NetBSD and OpenBSD to
> be read locally: <https://git.causal.agency/exman/>. The wrapper
> script essentially just sets MANPATH for the system you want to read
> manuals from.

Nice, I could set keywordprg in vim to `exman posix` so my K key will
jump to those docs. (Fun fact, I just discovered that a "count" will
choose a section, so 3K will do man 3.)

From joe at begriffs.com  Fri Oct 23 03:28:10 2020
From: joe at begriffs.com (Joe Nelson)
Date: Thu, 22 Oct 2020 22:28:10 -0500
Subject: Real man pages for POSIX reference?
In-Reply-To: <20201022030734.GE53936@begriffs.com>
References: <20201021032548.GA53936@begriffs.com>
 <0F7C5B3C-BFA8-40BD-84D2-9C0B6BDE8550@causal.agency>
 <20201022030734.GE53936@begriffs.com>
Message-ID: <20201023032810.GG53936@begriffs.com>

I modified the man pages and republished them in this repo:
https://github.com/begriffs/posix-man

I changed the section names from 0P,1P,3P to 0,1,3 for compatibility
with Vim's "K" command, and removed a Linux preamble from each page.