Related: The SymbOS operating system and graphical desktop for Amstrad CPC, MSX and some other Z80 machines was coded entirely manually - the first release was in 2006. https://www.symbos.org/

Of course for the Commodore 64 the GEOS desktop was already released as a commercial product in 1986. https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

Only showing the most common values means that sizes of non-maximized windows are lost in the noise. It would be nice to see a cumulative size distribution that would show the percentage of viewport widths smaller than x, for various values of x. Then a developer could easily see that if they make the content e.g. 900 pixels wide, what percent of users will have to scroll the viewport left/right.

What's crazy is that the much more advanced Amiga custom chips were manufactured at the same 5 micron feature size as the C64 chips. That's why the Amiga needed two custom chips for video (Agnus and Denise) instead of the one in C64 (VIC-II).

Also, since CP/M 3.0 on Z80 supported more than 64 kB memory via bank switching, one might expect CP/M to do so on other platforms too.

You probably mean "more than 64KB" or "more than 64KiB", but you're not wrong that 65,536 > 64,000

C++ template metaprogramming is in some ways more powerful than Common Lisp macros, because it works at the type level: you can generate new types and dispatch into separate implementations by type. In contrast, Common Lisp type declarations are not available at macro expansion time unless you implement a full source-to-source translator in macros.

It leads to the catch-22 that when saving a BASIC program you cannot tell which filenames are already in use, since you cannot get a directory listing without losing the current BASIC program in memory. All you can do is guess a filename that is probably free.

Is there still some kind of sales tax in Germany? Shouldn't it be long gone due to the EU value added tax system?

The sales tax is the value-added tax.

It's the same problem with autovectorization. Often the only way to tell whether a compiler optimization is successful is to check the produced assembly or benchmark the code.

It seems that for devirtualization GCC has a warning option -Wsuggest-final-types which is supposed to tell when devirtualization fails in link-time optimization. Not sure how reliable that is, or whether it will produce gobs of unhelpful warnings. Maybe it could be combined with some kind of hint that we want this particular call to be devirtualized, and don't care about calls without the hint.

I don't see why there has to be a special staging area when you could just edit the HEAD commit instead. In git you could do "git commit --patch" to commit selected parts and then add more changes to the HEAD commit by "git commit --patch --amend".

A normal situation in my tasks is when the working copy contains lots of changes that are used for debug (mainly prints) but these changes shall not be committed to the proposed change. For this, even interactive adding (`git add -i`) does not satisfy; I need `git add -e` which allows editing in a patch form, and remove the temporary local changes.

Yes, I pretty much do the same thing with git-gui. You are right that the staging area isn't strictly necessary for this kind of workflow.

It's not so easy any more if you try to rotate the hypercube and have to visualize intersections with arbitrary hyperplanes. Already in 3 dimensions the intersection of a cube and a plane can be a non-regular polygon with 3-6 sides.