This is a really impressive amount of effort. Every entry has a fairly even quality to it...screen grabs and contextual descriptions of even one-off episodes of television shows, yet alone decades worth of movies.
In some cases, reviewing PR diffs commit-by-commit (and with the logs as the narration of the diff-by-diff story) is a substantial improvement over reviewing the entire PR diff. Concrete examples...
* A method or function that has code you realize needs to be shared...the code may need to be moved and also modified to accommodate its shared purpose. Separating the migration from any substantive modifications allows you to review the migration commit with the assistance of git's diff.colorMoved feature. It becomes easier to understand what changes are due to the migration, and what changes were added for more effective sharing.
* PRs sometimes contain mechanical work that is easy to review in isolation. Added or removed arguments, function renames, etc. No big deal if it's two or three instances, but if it's dozens or hundreds of instances, it's easier for the humans to review all of those consistent changes together, rather than having them mixed in with other things one has to reason about.
* Sometimes a flow of commits can help follow a difficult chain of reasoning. PR developer claims that condition X can never occur, but the code is complex enough that it's difficult to verify. However, by transforming the code in targeted ways that are possible to reason about, the complexity might be reducible to the point where the claim becomes obvious. One frequent example I see of this is of function/method arguments that are actually unnecessary, but it wasn't obvious until after some code transformations.
I'm not willing to cede the point on hardware design for as long as their primary mouse product cannot be charged during use. It's such a simple and obvious mistake, like a throwback to the days of hockey-puck mice.
The comic pokes fun at the ridiculously cruel babelfish puzzle. Which, I'm proud to say, I solved back in the day without assistance, after a full day's worth of effort, and requiring at one point to completely restart the game because of an apparently useless item I didn't pick up at the very beginning of the game (if you've solved it, you'll know the item I'm referring to).
But...while that was a nice achievement, I still got stuck later in the game, trying to fix the Nutrimatic.
I left Slashdot for HN...but I didn't leave Slashdot because of HN. I was frustrated with Slashdot and was actively seeking alternatives. About 2 days after I discovered HN existed, I was done forever with Slashdot.
Among other frustrations (including some really vile comments), I felt like the world was bursting with interesting tech news, and Slashdot was just not keeping up. The publish rate was too slow (maybe 10-13 stories a day), and the %age of stories I found interesting had dropped considerably from a few years previous.
I wasn't a fan of the redesign, but it was content that drove me to seek alternatives.
Growing up in the 70s, among the things I sought out in our house to play with was an old manual typewriter. It was endlessly fascinating to me. I liked playing with all of the mechanical bits. Trying to jam keys, working the carriage return, scrolling paper through it, pressing the Shift key and looking to see how it moved the entire basket of typebars, overtyping to make new characters, watching how the ribbon advanced with each keystroke and rewinding it by hand, etc. One thing I had forgotten, which was mentioned in this article, was figuring out how to set tab stops, which allowed me to either stutter the carriage across, or make it fly free from one end to the other.
An alternative to securing or recreating the entire technology stack top to bottom would be to own one critical piece of the stack. If European interests owned a vital slice of the technology stack that was difficult to recreate and too cheap/convenient to not be used by international government/business/consumer interests, that could be a powerful deterrent. I.e., it sets up a "mutual assured destruction"-style defense.
The 1200XL was my first computer. My family purchased it at a department store at a fire sale price (IIRC Montgomery Ward's, $199) after Atari stopped manufacturing and began dumping its inventory to make way for the 600XL/800XL. I had been researching a computer to get for ages, but my family was very careful about how we spent money, and it was a big purchase. We had seriously considered getting a TI-99/4A when TI exited the business, but we were concerned that it was just going to be a dead end. But the chance for a cheaper entry into an established ecosystem was great (that and me begging my mother to finally, finally get a computer!).
Re compatibility, I never came across software that didn't run on it. I'd read in magazines that there were issues, but never once experienced it. One interesting software change, though (but true of other XL computers, too) was that the color "artifacting" worked differently on it than it did the 400/800. For example, Ultima III used color artifacting, and so playing it on my system produced some incorrect colors...most notably the sea was red.
I did come across one hardware issue...a cheap third-party parallel interface adapter that didn't work, and that we thought at the time was defective, but I now think it's likely to have been affected by the incorrect power wiring in the 1200XL's SIO adapter. It was cheap enough that we didn't lose too much money on it, and I ended up getting the far superior ICD P:R: Connection instead.
The Atari community was a super great community to be in. And in so many ways, Atari was doing things that wouldn't be seen again for years, if not decades. Atari's SIO port is famously a predecessor/inspiration of USB. The APX Exchange was basically a third-party app store decades before Apple popularized the concept. The machine was hackable and moddable (I bought a 256KB upgrade kit for mine). When I migrated to PC for college use, it hurt to have to fall back to CGA...even EGA was just ugly, compared to what my 1200XL was capable of (although the 80 column displays were nice compared to Atari's 40-column).
Solved, and it was fun! But...some of the colored lines were hard to see. Particularly the light yellow ones. I had one "alternate" solution that it was marking incorrect for reasons it took me over a minute to spot...and it was just a super light yellow line I missed without really scrunching up to my screen.
Improving the color choice might help, but slightly thicker lines I think would also be of significant help.
Also, it's common for sudoku solvers to allow you to press Shift+number to do a one-off toggle for the "note" checkmark.
I had hope at one point to set up a Kindle with large fonts on a treadmill, but that was just totally hopeless. I tried again with a music stand next to the treadmill, but it was too far away, badly angled, and touching the device to flip pages could still turn it off.
And it's not just the accidental power-off, it's also the accidental power-on. I slip the Kindle into a tight pocket in my backpack, and it sometimes turns on by itself. Further, inserting it into the pocket can sometimes reproduce the swipe motion, so it can be on and active (and sometimes randomly page-flipping) inside my backpack.
_Thank you_. I read this story probably around 1980 (I think in a magazine that was subsequently trashed or garage-saled), and I have spent my adult life remembering the bones of the story, but not the author or the title.
They can absolutely be checked out to the same commit. They cannot be checked out to the same local branch. But checking out to the same SHA, or even the same remote branch (which, really, is just another name for a given SHA) is just fine.
I have two workflows heavily benefitting from worktrees. The first is simple enough...code archeology. I want to do it without disturbing my working tree. Yes, this could have also been done with a separate clone, but I'd have to fetch in that clone, and that's just extra keystrokes.
The second is that I like to have a "synthesis" worktree...one that includes PRs I'm reviewing and ones I'm creating. Both benefit from my regularly building and using them (e.g., I might incidentally find bugs through usage I otherwise missed through testing or code-reading, or I might spot pending integration
problems). I don't want multiple build locations...I want to run everything
in one build.
But when I've finished developing a PR, need to create a clean version of it from the master branch. In my secondary worktree, I can just cherry-pick commits from my synthesis worktree to produce a clean branch to push.
I could do this in the synthesis worktree, too, but at the cost of
almost certainly forcing a complete rebuild. In a second clone, I'd have
to create patch files because the clone wouldn't have access to the commit
objects for cherry-picking.
This can come up even with application software (which is my area). If it worked before and it's broken now, or if your application appears to be the only thing that is broken for the user, from most user perspectives, it doesn't matter that the problem may have been technically created by an OS bug, errant virus scanner, or whatever. As I tell colleagues, "It may not be our fault, but it's still our problem."
A reborn version of PLATO is available at https://www.irata.online/ (JS client if you hit the Login button at the top, various other clients enumerated below). I haven't played with it much, but I did find "Bugs and Drugs" from the article in the Irata games list, and was able to successfully launch it.
Surrogate pairs were new to Unicode 2.0. Unicode 1.0 didn't anticipate the need for more than 65,536 code points (who would ever need more?); the main perceived threat to that limit having been resolved by Han unification.
* Coding ligatures often display as a single glyph (maybe occupying a single-width character space, or maybe spread out over multiple spaces), but are composed of multiple glyphs. The ligature may "look" like a single character for purposes of selection and cursoring, but it can act like multiple characters when subject to backspacing.
* Similarly, I've seen keyboard interfaces for various languages (e.g., Hindi) where standard grapheme cluster rules bind together a group of code points, but the grapheme cluster was composed from multiple key presses (which typically add one code point each to the cluster). And in some such interfaces I've seen, the cluster can be decomposed by an equal number of backspace presses. I don't have a good sense of how much a monospaced Hindi font makes sense, but it's definitely a case where a "character" doesn't always act "character-like".
Last month, my wife and I visited the Musée d'Orsay (as visiting American tourists). As it happens, we were in line when the museum opened and I had the bright idea to go straight to the top floor...partly because I was interested to see the van Gogh room, and partly because the large body of people entering the museum were still milling around on the first couple of floors.
And so it was that, as we wandered the relatively empty top floor, I walked through the entryway to the van Gogh exhibit room, looked left...and I just stopped, absolutely stunned as I looked upon Starry Night Over the Rhône. It completely took my breath away. I've never had that reaction (or much of any reaction) to a work of art before. My wife ended up wandering a different direction, and I had the pleasure of taking her back into the van Gogh room and watching her have the same reaction.
So, yeah...definitely nothing like looking at it on a screen or in a book.
Yes, there's a lot of messiness in how fonts work. Doing cross-platform desktop GUI development, I feel that pain firsthand (and not just for fonts, but for all kinds of rendered constructs...controls, lines/curves/polys, bitmaps, windows). But working with pixels is no solution. On macOS, Retina pixels are 1/2 the dimensions of non-Retina pixels (in principle, on Apple hardware...actual dot pitches will vary). "Standard" vs. 2k vs. 4k vs. 8k monitors (not to mention all the things in between). And multiple monitors on the same system might not agree with one another. This is especially common with laptops, where there's really no particular correlation between the laptop's built-in display and the external monitor the user happens to have available.
I can't understand why anybody would consider pixel measurements a viable solution at all. My best attempt to understand what the blog author is wanting to achieve is maybe he wants to fine-tune appearances on his system in a way that doesn't need to be portable. He talks about customizing editor appearances, and I suppose that editors generally don't have the problem of having to do something sensible across multiple systems. But even there, at least some people are still going to have the disagreeing-multiple-monitors problem.