It never came to pass when we used Oracle, maybe now with Postgres I will finally have a chance at it.

But if the last value of numbers[] is not smaller than 500, small_numbers[smlen] will contain that value for the first version whereas the second version does not write to small_numbers[smlen].

Then step down as maintainer if you don't want to do it properly.

You can't call it "engineering" if you don't care about verification.

Who even puts forward such claims?

The more context an LLM gets, the more likely it will start to ignore instructions.

If the LLM runs a context compression, all bets are off. There's a reason Anthropic upped the context to 1M tokens to reduce the chance of this from happening.

The commits in question are no pull requests.

Not a low quality newbie coder.

> That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.

I disagree. The amount of commits is not from somebody who is carefully reviewing the new code and considering the changes done. It's from somebody who thinks they are in control and think they can guardrail the AI.

I've seen this at work as well. Maybe it's a small case of the braineater that so many tech bros get when they get older. But they talk about the AI as if it were a being that can be reasoned with and not that it's just a statistical interpolator and autocompleter.

I know when I'm vibe coding. Just last week I needed 5 colors for a green to read gradient for visualisation some states. I ended up with a script that outputs arbitray color gradients in 5 different colorspaces (including a colorspace for which AFAIK there's no support in Ruby as of now) and additionally also considers different color vision deficiencies.

Is it useful? Yes. Would I run this code in production? Hell no.

Somebody needs to have read deterministic code to even have a chance of noticing something being wrong.

This has not happened here.

I see lots of ground for that claim.

Local filtering is the key to ignoring threads you are not interested in. Depending on the client with 2 or 3 keystrokes you are ignoring the whole thread or this particular sub branch of it and automatically jumping to the next interesting, unread message.

Shared libraries were typically loaded only once into the system's single shared address space. Any process could potentially overwrite another task's memory or shared library state.

I don't have my old setup ready but if I boot into Pimiga, I get about 60 task and processes running.

If you literally mean "seeing" workflows, because of the small monitors back then, you usually didn't have open programs side by side. The Amiga allowed to have multiple screens that were basically a better version of virtual screens combined with fullscreen mode.

Here is an example of somebody having Deluxe Paint open and the Workbench.

https://retrocomputing.stackexchange.com/questions/24842/ami...

The pinnacle of workflow design on the Amiga was of course ARexx which allowed applications to communicate through message ports and automation scripts.

> Yes, but without memory protection.

That’s why it was so fast. :) Also surprisingly stable all things considered.

The rules that are fed into the AI are not unbreakable laws to the AI. We should always remember that.

Given how an LLM works, you can never be sure it will always work. LLMs are not deterministic.

If you can't trust your test suite to catch an automatic language translation you shouldn't trust it at all. :)

Michroma is a Google Font alternative for Eurostile.

This being NetHack, an answer is often not as straight forward as it could be. Most of the time the level difficulty is proportional to how deep you are into the dungeon but there are levels where your experience level factors in as well.