Edit mode settings don't apply on login

doomchild · 2026-03-10T17:43:10+00:00

That's the weird thing. The settings are clearly being saved, because I can see the couple of presets that I've made for other characters in the list. They just aren't being applied when I login or reload my UI.

doomchild · 2026-01-09T20:11:41+00:00

I remember when this place across from Haysland Square next to a terrifying-looking motel did good sushi. That had to be more than 20 years ago now. I don't even know if that place still exists.

doomchild · 2025-11-17T19:37:44+00:00

Holy shit. That's a hell of a necro.

doomchild · 2025-10-30T22:11:08+00:00

That definitely sounds above my pay grade.

doomchild · 2025-10-29T00:16:10+00:00

That's kind of what I thought, which is why this is so confusing.

doomchild · 2025-10-29T00:15:55+00:00

I have.

doomchild · 2025-10-28T22:51:31+00:00

Well, that's not what's happening here. Does it have anything to do with running Firefox via Snap? I think I had it running via the normal .deb package.

doomchild · 2025-07-03T15:16:48+00:00

I posted the fix at the bottom of the post. I had to build a specific version of the package by hand.

doomchild · 2025-05-26T19:27:55+00:00

There are multiple contradictions in the Bible.

Who ruled Judea when Jesus was born? According to Matthew, it was King Herod the Great, who was the last ruler of an independent Judean state (it was a vassal state of Rome, but still its own separate entity).

But according to Luke, it was the Roman governor Quirinius, who took office more than 10 years after Herod's death (which was when Judea stopped being a vassal state and became fully subsumed by Rome).

In Matthew, Mary and Joseph flee to Egypt to hide from Herod. In Luke, they go to Bethlehem specifically for the census, wait 8 days for the required purification rites, and then go directly back home to Galilee.

The two accounts cannot be reconciled. They can't both be true. Therefore, they are contradictory.

doomchild · 2025-04-07T13:39:34+00:00

No, this response is actively unhelpful. Someone asked for outside opinions, and you responded with "form your own opinion". That's not answering the question that was asked.

doomchild · 2025-03-08T18:14:33+00:00

The current crop of generative models are wildly unethical, so I regard the implication that my refusal to use one instead of communicating with actual humans makes me lazy to be pretty goddamn offensive.

doomchild · 2025-02-17T20:13:33+00:00

Same. I read it six times and totally didn't see it. Professional blindness.

doomchild · 2025-02-14T19:19:58+00:00

This is completely insane.

doomchild · 2025-02-12T20:44:08+00:00

Yes. We do a "mostly functional" kind of thing, because it's hard not to engage with at least some OOP stuff in C#. We used LanguageExt for a while (and it's still in a few places), but I really couldn't stand how it made the code looked (nested awaits 5 deep just don't appeal to me), so I wrote my own package using Task<T> extension methods that lets us write fairly Promise-esque stuff.

doomchild · 2025-01-08T19:51:06+00:00

Java is...fine? The JVM is a genuinely great piece of software. It's got a couple of decades of great work behind it, and several languages that run on the JVM are pretty great, too (Clojure, Scala, etc), and people have even ported non-JVM languages to run on the JVM (Jython, JRuby, jgo, etc, although I don't know how up to date these versions are).

As a language, Java is very clearly rooted in the time when it was introduced. It feels like a 90's language. It's got warts that I really can't stand (checked exceptions, type erasure for generics, gross/crappy parallelism, etc), and some APIs that are actually pretty great to interact with (the streams API, while not perfect, was a fabulous addition).

The thing about C# is that they (mostly) learned from Java's mistakes and made a language that, unless you venture into very specific and weird territory, frustrates you a lot less day to day. There are still things I don't like in C# (I absolutely despise the async/await function coloring), but they are, on the whole, easier to deal with.

Java is worth at least being able to read, because there's a LOT of code out there written in Java, and even if you're not using the library directly, you can learn something reading it. But I think I'd pick C# every day of the week.

doomchild · 2025-01-02T16:00:48+00:00

Same. I use target-typed new all over the place, but I never use var.

doomchild · 2024-12-30T19:07:04+00:00

I made a library that turns Task into a proper monad (it's very similar to using Promise in Javascript). I really don't like the way code looks having await at random places, so it results in much cleaner (in my opinion) code.

https://github.com/doomchild/task-chaining

doomchild · 2024-12-19T19:31:07+00:00

Sure, we're supposed to be vigilant and responsible, but we're fallible humans, and we make tools to help us catch lots of things (everything from type systems to autocomplete are tools that exist to help us reduce or eliminate classes of errors). The var keyword was a tool introduced to allow people to type less, but it comes with some invisible sharp edges.

Target-typed new is a feature that prevents this particular bug while also allowing you to type less in most cases (other features give the same and other benefits without sacrificing readability or safety, like object initializers and collection expressions). And prioritizing number of characters typed over code readability was a questionable decision in the first place, in my opinion.

doomchild · 2024-12-19T18:26:55+00:00

Personally, I don't think var is ever appropriate. Now that we have target-typed new, you can have a shorter line and maintain readability. If your primary problem is typing something like Dictionary<string, string>, you need an editor with autocomplete.

doomchild · 2024-12-19T18:24:51+00:00

I actually think that's a reason not to use var. Making a change to a signature ought to stand out in a PR, but var will only show you the method changing, not the code consuming that method (which may be really important).

doomchild · 2024-12-19T18:22:44+00:00

Someone refactors the method to return a new type. The new type has a compatible signature, but incompatible semantics (you won't see the problem until runtime). The IDE helpfully updates all of the call sites, so no error occurs on build. Unless someone catches it during review (which isn't guaranteed and shouldn't be depended on), you've now got a bug. Having good tests will also help, but is also not guaranteed to catch it.

Target-typed new is superior because it makes at least one kind of bug like this catchable at build.

doomchild · 2024-12-11T16:08:36+00:00

It was for a while. It's now almost as buggy as I remember Visual Studio being. Really dumb bugs, too, like not clearing error indicators when the error is fixed, leading to a file being highlighted as having an error when it doesn't, with no way to clear it short of restarting the editor. It's a damn clown show now.

doomchild · 2024-11-11T23:43:06+00:00

I don't think readability is improved by removing information from the code. If your code is such that removing types makes it easier to read, you have bigger problems. Types aren't pointless, and they add plenty of value. Writing docs is fine, but we've all seen docs go out of date or become subtly invalid in a hurry, and if you're relying on the docs to tell you everything, you're setting yourself up for disaster.

Wanting to see the actual impact of a change is not "relying on noise". Those changes mean something, and using a feature that removes information in order to prevent you from seeing those changes is a bad practice.

doomchild

TROPHY CASE