Recent activity

Re: Latency in Asynchronous Python a day 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 7 days 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 9 days 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 9 days 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 9 days 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 17 days 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 a month 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 a month 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

Re: Four Ways to Compile C for Windows a month ago

From Christopher Wellons to ~skeeto/public-inbox

Thanks for the tip! I've been observing RemedyBG from afar via Handmade 
Hero, including Casey's recent entertaining rant about Visual Studio 
vs. RemedyBG:

Twitter and Visual Studio Rant
https://www.youtube.com/watch?v=GC-0tCy4P1U

I appreciate that someone's taken the time to build a good replacement. 
Though for me personally, I will probably continue to use the Visual 
Studio compiler not so much as an active development tool, but just for 
building finished and already-debugged software.

Re: Your Thoughts on my Rebuttal 2 months ago

From Christopher Wellons to ~sircmpwn/public-inbox

I, for the most part, agree with Drew in the three cited articles. 
You've also previously rebutted one of my own articles, and at the time 
I read a few of your other rebuttals. Revisiting it now, I've noticed 
and overarching theme for all your rebuttals: Perfect is the enemy of 
good.

That is, when you perceive a system or tool as flawed or imperfect, it 
is inappropriate for anyone to praise or prefer those systems. Since C 
and POSIX aren't perfect — and they certainly aren't — it's wrong to 
advocate for their use. Sometimes being imperfect simply means they 
don't make the particular trade-offs you personally prefer.

For instance, one of your criticisms of UTF-8 is that it doesn't support 
random access. This is absolutely true, but accessing Unicode code