gdwatson

I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.

They adopted the existing Debian Free Software Guidelines as the Open Source Definition. The DFSG are good, actually, and represent an important community consensus outside the FSF.

I agree with your address example. That is user data, and it should be selectable.

Personally, I found the length of the quotes from politicians kind of tedious, but I sure wouldn’t want them to capitulate to Bloomberg after this.

I suspect that disabling advanced data protection in the UK was meant to let Apple say it was complying as far as it could while fighting the main order.

Maybe it would have been easier if CPU performance didn’t end up outstripping memory performance so much, or if cache coherency between cores weren’t so difficult.

But now the user has to set the preprocessor macro appropriately when he builds your program. Nobody wants to give the user a pop quiz on the intricacies of his C library every time he goes to install new software. So instead the developer writes a shell script that tries to compile a trivial program that uses function foo. If the script succeeds, it defines the preprocessor macro FOO_AVAILABLE, and the program will use foo; if it fails, it doesn’t define that macro, and the program will fall back to bar.

That shell script grew into configure. A configure script for an old and widely ported piece of software can check for a lot of platform features.

But yeah, I agree that we were promised a lot more automatic multithreading than we got. History has proven that we should be wary of any promises that depend on a Sufficiently Smart Compiler.

I rarely have the patience or temperament to read Yarvin, so I can’t say whether you are right or not. But I can say that his critique of progressive institutions has resonated with a much larger share of the right than his positive vision of politics.

And this makes sense! It’s entirely possible to have insight into the problems your side is facing while being off base about the solutions. That’s pretty common to intelligent, eccentric thinkers across the political spectrum.

It’s a great way to have my cake and eat it too.

I think this is partly because big OEMs doubt (used to doubt?) AMD’s ability to consistently deliver product in the kind of volume they need. Partly it’s because of Intel’s historically anticompetitive business practices.

I used to think it doubled your workload to do both, but if you are using JS-free client-side validation, I think that the server can just return an HTTP error guilt-free for any invalid input that the browser will catch. It’s a pretty good compromise for format validation.

Would you clarify what you mean by this? Does the first secretary of the Communist party no longer have de facto dictatorial power?

For implementation-defined behavior, the language standard lays out a menu of options and your implementation is required to pick one and document it. IMHO, many things in the C standard are undefined that ought to be implementation-defined. But unaligned pointer accesses would be hard to handle that way; at best you could make the compiler explicitly document whether or not it supports them on a given architecture.

I am not a C++ person, but I protest this characterization. You obviously know the categories and I suppose you know the history, but I will recount them so that everyone else understands my objection.

O.G. coroutines emerged in a world where subroutines were, by and large, not reëntrant. Function parameters, local variables, and return addresses were static, and there was no call stack in the modern sense. This is why the old timers said that coroutines were a generalization of subroutines; only the jump instruction of the call/return really needed to change.

Once call stacks became common, coroutines fit awkwardly, and people tried to adapt them in various ways.¹ The world has settled on two designs for reconciling coroutines to the call stack: thick and thin coroutines. Thin coroutines allow suspension within the body of the coroutine but not within subroutine calls; this way the size of the coroutine’s state can be known at compile time and its interaction with the stack is relatively clear. Thick coroutines (i.e., green threads) can be suspended within a subroutine call, and thus require their own slices of stack — either separate from the main stack or copied from and to it as the coroutine is suspended and resumed.

Thin coroutines are absolutely coroutines. They are truer to the original definition than thick coroutines are! They are more limited than thick coroutines, true; whether that makes them better or worse is a matter of design trade-offs. But they certainly deserve the name.

[1] Simula 67, to my understanding, treated objects as a kind of coroutine instance where function definitions in the coroutine body became methods that closed over its local variables.

Something about taking a screenshot on a scaled display makes my first image (at 125% scaling) look bigger than it should be; at 80% magnification it looks about the same size as it does in my browser, so edges may not come across quite right. (100/125 = 0.8, so that’s probably not a coincidence.)

I set scaling to 100% for the second image, and that one looks true to life size, so it’s probably the better reference.

Edit: On comparison, it’s not the serifs. Maybe it’s the lighter overall color on the page, or maybe it’s the way that autohinting exaggerates the contrast between thick and thin strokes.

How does it look on a Mac monitor?

I do like Baskerville, but I am a little sad that the only open source version I know of, Libre Baskerville, changes the design so much for the screen. Caslon is in the same boat.

Preferring a single space between sentences is a reasonable choice. But flagging or "correcting" the two-space style is simply a mistake.