u/f2u

The summary doesn't say if they they controlled for training as a typist. Depending on how they recruited their test subjects, this could be what they measure, and it just happens to be closely correlated to gender (e.g., a university department that hires women almost exclusively as secretaries).

Do you mean the tenor? Sounds like the regular dein sanfter Flügel weilt to me.

Lines like this are used in polyphonic music to clarify how more than two voices are represented in two staffs. Sometimes, being dotted means that they have been added by the editor and were not written by the composer.

Their use in this instance is rather peculiar because whoever wrote this also uses an LH indication in the same measure. Under these circumstances, I would have expected the A to be written in the upper staff with an LH indicator, and perhaps put the overlapping 8th note in parentheses.

The damper pedal indications are partially cut off, but I think if you use damper pedal as indicated, the sostenuto pedal will not have any effect because the dampers are already up anyway.

Bach, von dem die Schulregeln der Fuge abgezogen

Bach, from whom the academic rules of the fugue were derived

Maybe Adorno meant to write Fux instead of Bach here. The translation and your rephrasing look essentially correct to me, so if the claim is indeed of questionable accuracy, perhaps that would explain the discrepancy.

Latin had the second pattern as well (Iura te non nociturum esse homini de hac re nemini), but perhaps only in more colloquial usage.

You could run Emacs independently of the terminal (start it from the window manager), or run it in the background (emacs &). Then the terminal window is usable directly after switching to it.

You can have problems with zero-width types in any language because some serialization formats, like AMQP, use them.

That's essentially the proposed O(n + s) approach. It computes the logarithm for each prime in the product.

The piano case is strange because the piano is generally stereotyped as a more feminine instrument. Maybe not as extreme as the harp, flute and recorder, but the bias is still there. I don't have access to proper statistics, but I suspect that as a result, female students have higher likelihood of prior exposure to the piano than male students, and that should compensate for differences in hand size (in the aggregate).

Unfortunately, alternative keyboard sizes and layout (7/8, 15/16, Janko) are too difficult to come by. Their availability would pretty much settle the debate. But then, one could probably use four hands for demonstrating chorale settings.

And quite frankly, I would be more worried about instrument cost and discrimination based on social status, rather than based on hand sizes.

Have a look at the bootstrap-lto and profiledbootstrap targets. See the build documentation.

Right the first theme? Compare that to the theme which starts around at 22:35. It's not an exact quote, of course, but I still think there is still quite a bit of similarity.

The final movement sounds a lot like Mahler's 3rd symphony. Coincidence?

But that's not how serializability is defined. Something has to observe that the commit has happened, and in the example, that part is missing. If you observe transactions from the outside, you always get dirty reads, non-repeatable reads etc. (Looking at things from the outside of the transaction processing system doesn't count.)

Isn't the MySQL result valid, too? There is nothing in the transactions themselves which ensures that txn1 commits first, so both orders are valid.

The streaming/CDN servers aren't really part of the Netflix backend infrastructure.

If it sounds fine, you can certainly use it. In the excerpt you posted, the long G#s and C#s in the right hand could be problematic: you have to hit the same key later in the same measure with the left hand, and this can sound awkward with the sostenuto pedal.

What kind of LTO do you use? If the combination of GCC and the linker doesn't make the whole-world assumption, __attribute__ ((weak)) should work quite nicely. Vaguely related gcc list thread

Right. I'm not sure if I would have immediately claimed to understand it even though I can read the notation. This is quite subtle. (I haven't watched the whole talk, but I assume it's about a programming language with built-in correctness proofs, and the programming example in the talk is some sorting algorithm. Showing that a sorting algorithm actually sorts is a bit like showing that S² is simply connected, in the sense that you can easily prove something that is true, but not actually demonstrates what you are after. This is why details are extremely important here.)

Can .Net Core be built outside of Microsoft, in an automated way? Apparently, building .Net Core is quite difficult. Older versions of Mono could at least be built from source (perhaps after bootstrapping, but that's expected for a toolchain package).

Now parties may also attempt to bring a claim treating the license as a contract for purposes of standing, where there are writings or representations that some kind of contract exists.

That could be specific to the “open core“ model used for Ghostscript because as far as I understand it, Artifex offers a GPL buy-out license. Most GPLed projects do not.

Sure, it's theoretically possible, but the mt_allocator problems mean that many distribution moved away from the default even before GCC upstream made the switch. I'd also expected more recent results for this mt_allocator search if there actually was someone changing the upstream default.

Except that the code they identified as the cause has been unused for close to a decade, which means their analysis is incorrect, and something else fixed it or papered over the actual problem (probably the switch to jemalloc).

Great question. It's pretty likely that their issue is not caused by mt_allocator, but that they hit a corner case in their system malloc (probably glibc's, but they don't say so explicitly). These corner cases are very sensitive to allocation patterns (sizes, lifetime of objects, which threads allocate and deallocate etc.), so you often need the exact same workload to reproduce issues.

Maybe they do not want to recompile all the C++ libraries they use from source code. And libc++ has different performance characteristics and bugs, something they would have to figure out from scratch.

Do the libstdc++ maintainers also consider this a bug?

Yes, they do, which is why mt_allocator has not been the default allocator in upstream (since GCC 4.1, released in February 2006) and distributions. Here's a 2005 proposal for Debian to switch to the direct malloc allocator.

Unless the reporter used some very advanced GNU extensions, they haven't found the actual bug. If they used the GNU extensions, it's hardly a libstdc++ bug because you are supposed to know the trade-offs involved with those.