Recent activity

Re: List of talks 27 days ago

From Christopher Wellons to ~skeeto/public-inbox

Hi, Gabriel, I'm glad you asked! A couple of other people have also also 
asked for an updated list, so I knew there's some interest. I did follow 
CppCon 2019, but unfortunately I didn't carefully keep track of which 
talks I thought we worthy of recommendation, in part because there 
weren't that many this time. However, checking my notes, I had 
enthusiastically shared these talks with others at the time:

CppCon 2019: JF Bastien “Deprecating volatile”
https://www.youtube.com/watch?v=KJW_DLaVXIY

J. Bialek, S. Block “Killing Uninitialized Memory: Protecting the OS Without Destroying Performance”
https://www.youtube.com/watch?v=rQWjF8NvqAU

CppCon 2019: Matt Godbolt “Path Tracing Three Ways: A Study of C++ Style”

Re: inquiring about internship 27 days ago

From Christopher Wellons to ~skeeto/public-inbox

Hi, Amol. I'm glad to hear you've taken an interest in C and that my 
blog has helped you along that path. As you know, C is far from 
obsolete, and anyone saying otherwise doesn't see the larger picture. 
Not only is C still foundational to a greater degree than any other 
language, it remains *the* most popular programming language in the 
world to this day (recently overtaking Java again in the Tiobe index):

https://www.tiobe.com/tiobe-index/

So you can cite that for anyone who doubts it. In case you hadn't seen 
it yet, this one of my favorite papers about C and its importance:

Some Were Meant for C
https://skeeto.s3.amazonaws.com/share/onward17-essays2.pdf

Re: Latency in Asynchronous Python a month ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for the link! I've never heard of this place before, so I would 
have never seen it. 

> That's different from an unbuffered queue, which would have a buffer 
> size of zero – but asyncio.Queue doesn't support those.

Doh! Completely right. I've just made a couple of tweaks to the article 
to correct this.

Re: w64devkit: a Portable C and C Development Kit for Windows a month ago

From Christopher Wellons to ~skeeto/public-inbox

> Can you explain what the escape characters do?

The escape is interpreted by awk, and it's just a single quote. I needed 
that because it's triple-nested. The awk "script" is in single quotes, 
awk's strings are in double quotes, and I need single quotes again for 
generating SQL: double quotes are for identifiers, single quotes for 
strings. So ultimately the output from awk is:

INSERT INTO hashes VALUES ('a69...99c6');

> Another approach with the sqlite3 tool is the .import dot command.

I've used .import often for CSV but I easily forget it can be used for 
more than that. Thanks for the tip!

Re: w64devkit: a Portable C and C Development Kit for Windows a month ago

From Christopher Wellons to ~skeeto/public-inbox

> I guess that's the price of not having the repository embedded into 
> the checkout as is done with the .git directory.

Yeah, that's basically what meant. That particular gripe is off the 
cuff, and I can accept that in practice it's a total non-issue. It's 
just something I noticed poking around with Fossil before writing that 
message. It reminded me of Subversion's awful branch interface where to 
make a branch you had to provide the fully-qualified repository URL in 
the commands.

> I wonder how David Crawshaw would respond to that claim. He is pushing 
> SQLite far beyond any use I have made of it.

Thanks for sharing Davis Crawshaw's article. That's interesting. I'm in

Re: w64devkit: a Portable C and C Development Kit for Windows a month ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks, Eric! You and your cohort were actually on my mind while I was 
working on this, so I'm happy to have hit the mark. BusyBox-w32 was 
already such a hit with them.

> I would appreciate any more detailed thoughts you have on this

First, I must confess: This is me being intentionally provocative. :-)

I've said this, or something close to it, to friends who like Docker. 
They quickly disagree, but I have yet to hear a satisfactory response. 
The most coherent argument is that Docker allows for flexible horizontal 
scaling. This is true, but then my question is, "What the heck are you 
doing that you need to scale so much?"

Re: w64devkit: a Portable C and C Development Kit for Windows a month ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks, Kurt! I didn't know about goversioninfo. That looks like it 
might be useful sometime. I've used windres for C applications, but I 
wouldn't want to rely on it for Go applications.

By "makensys" do you mean NSIS? I've used NSIS in the past, and I mostly 
liked the results. But these days the lack of 64-bit support is a real 
deal-breaker. A 32-bit installer for a 64-bit application confuses 
Windows and makes for a poor experience. I know there are hacks to work 
around this, but I've tried them and they don't work well.

> You may consider including fossil as an alternative.

Every few years I check in on Fossil to see how it's doing. There are a 
couple features where it's better than Git, but it's worse in nearly

Re: When Parallel: Pull, Don't Push 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for taking the time to reach out about a potential mistake, 
Michael!

That line of code is correct, and I believe this is just a coordinate 
system mix-up. I intend for my example to use traditional screen 
coordinates, particularly because I mentioned VGA, and so the top-left 
corner is the origin, and positive Y is downward. As I understand it, 
this is because the first computer screens were CRT text terminals for 
English speakers. The CRT beam goes left-to-right, top-to-bottom, as did 
humans reading text from the screen. So screen coordinates inherited 
this.

The first example uses "y-1" for the destination to push the flame up a 
row. The second example uses "y+rand()" to reach down 1 or 2 rows to

Re: Sourcehut Blog RSS Feed 2 months ago

From Christopher Wellons to ~sircmpwn/public-inbox

Turning this into a thread about the RSS feed, there are a couple other 
issues I've noticed lately. This article was published twice, one day 
apart:

https://drewdevault.com/2020/04/05/My-weird-branchless-git-workflow.html
https://drewdevault.com/2020/04/06/My-weird-branchless-git-workflow.html

The earlier one is no longer listed, and it appears to not have been 
re-rendered since it was originally published, i.e. it's an older 
version of the template. This artifact doesn't show up in the site's Git 
repository. Perhaps a stale file left behind in the generator's output 
directory? And perhaps it was originally generated with the wrong date 
due to a clock issue?

Re: LDLIBS in portable makefiles 2 months ago

From Christopher Wellons to ~skeeto/public-inbox

> why don't they put all the flags (both -L and -l) together into 
> LDFLAGS and put that macro at the end?

That's a really good question, and I don't know the reason behind it. As 
you pointed out, as long as the -L option precedes the corresponding -l 
option, I believe it shouldn't matter that -L comes later, even for gcc.

I suspect it's a historical accident. Dynamic linking came relatively 
late, and along with it linker sensitivity to argument order (at least 
when invoked via some compilers). By convention, options go before file 
arguments so the POSIX make documentation put LDFLAGS first. However, 
with dynamic linking we needed some arguments passed after the source 
file names. Rather than override the established inference rules to put 
LDFLAGS last, introduce a new variable, LDLIBS, to hold just the