lealanko

This is a common problem with try-catch syntax. An alternative, and arguably more useful syntax would be

  try (File_handle fh {s, "r"}) {
    // use fh
  } unless (const File_error& e) {
    // handle error
  }

Where the "use fh" part is not covered by the exception handler. This is covered (in ML context) in https://www.microsoft.com/en-us/research/publication/excepti...

For a more detailed look at the timeline of a programming language feature in the same vein, you may also enjoy the retrospective on Foozles:

https://wiki.hh.se/wg211/images/5/58/Foozles.pdf

You (and the article) are ignoring smaller companies. In those, you often have the salary negotiations with the owner, or a partner. Your salary comes (effectively) out of their own pocket, and recruiting you is quite possibly a significant and risky investment for the entire company.

In these sorts of situations, negotiation is much harder on a personal level, since the company is not a faceless entity. The company does have a face, that's the face you have to look into when you state your salary request.

On the other hand, it's also harder to accept being underpaid, because if you don't get paid what you're worth, you know the extra profits will go (almost) directly into the pocket of a person you will see daily at work.

Author here (of the plugin, not the page).

This was my only tangible contribution to the Gimp, some twenty years ago. IIRC it was modelled after a similar feature in Paint Shop Pro, and it was easy enough an exercise for an aspiring programmer. Or so I thought: others have now spent much more time maintaining it than I spent writing it.

In hindsight it seems like a bizarre idea to have a feature whose GUI requires filling in 25 numbers. But perhaps it has use as an educational tool.

In development version of the Gimp, the entire plugin has effectively been rewritten. Good riddance!

Probably just a screen capture snafu. The final game (and even QTest1) had an adjustable gamma setting.

They also released some 640x480 screenshots. They are included in Romero's post (fourth row), but that may not be obvious due to scaling. See the originals at http://doomgate.gamers.org/games/quake/screens.html

Fun thing about QTest1: even though you could only explore a static level and there were no creatures in it, the (then) Doom editing community had a ball delving into the details of the WAD format containing all its data. Finally they were rewarded: id had just dumped their graphics assets into the wad, and there were models inside, including the dragon, seen in the screenshots but, alas, not in the final game.

Do I understand correctly that the load-time code specialization described in this presentation is not inherent to the Mill hardware, but instead merely a proposed OS-level mechanism for supporting binaries that are portable across the model family? Could a Mill-targeting compiler choose to bypass this mechanism and directly output model-specific concrete code?

The problem with automatic daemonization is that there is no way to indicate startup failure: you just fire and forget the process in the background. If the process dies, there's no clear way of knowing whether it was due to an error in startup conditions (possibly as simple as a configuration error) or a runtime failure at a later time. In the first case, restarting makes no sense. In the latter case it might be a reasonable option.

With manual daemonization, the process can delay forking until it has ensured that its configuration is sound and it has the resources it needs. This way the parent process can indicate with its exit status whether the service was successfully launched.