You can change the colors there, and it does work as well.

Thanks for the correction. I must’ve overlooked something when looking at how the preferences are loaded. :)

Could you explain to me how you went about approaching the issue?

At first, I looked into Thunderbird’s source code and tried to simply identify the element that I could use in userChrome.css. I found that the element is called #messageEditor in messengercompose.xhtml. However, this doesn’t work because the editor textboxes are apparently iframe-like things that load another website inside them (probably to prevent copypaste injection attacks or something). Even if I added * {background-color: red} in userChrome.css, it couldn’t match the textbox.

I figured out the userContent.css way when I opened the debugger in Thunderbird’s developer tools and set a breakpoint in the script that manages the textbox. For example, here’s how to find it for the new calendar event editor:

So the calendar editor lives inside about:blank. However, about:blank is used in lots of places, so it would be good to add some extra conditions instead of changing the background of all about:blank pages used throughout Thunderbird. Luckily, the above picture shows that there’s a link element that can be used as an extra condition like this:

@-moz-document url(about:blank) {
    html:has(link[href="chrome://messenger/skin/shared/editorContent.css"]) body {
        background-color: red;
    }
}

The tricky part is finding the right code to put a breakpoint into. It helps if you have a local copy of the comm-central source code files (as instructed in Thunderbird docs), since it includes XHTML files for digging around. The new calendar event window is in the somewhat logical path calendar/base/content/item-editing/calendar-item-iframe.xhtml, and the related scripts are right next to it in calendar-item-iframe.js.

After some trial and error, I found that adding the following to userContent.css seems to work:

@-moz-document url(about:blank?compose) {
    body {
        background-color: red;
    }
}

Thunderbird’s source code also has some function that reads preferences editor.use_custom_colors and editor.background_color and sets the default color based on those, but it seems that the function is never called. Code rot I guess.

This is missing the biggest difference: ISO 8601 costs 190-450€, whereas RFC 3339 is free.

Very few languages (or programmers!) are able to check that a function doesn’t have side effects. In particular, checking that a function doesn’t diverge generally requires a proof assistant, like in F* and Lean.

Your definition of functional programming is as valid as any, but it’s so strict that even Haskell would be mid-tier in the functional ranking.

I didn’t really understand the details of what you’re making, but if you want to generate a random variable with entropy x, the straightforward approach would be to use Σ = { n | 1≤n≤⌈2^x⌉ } as the alphabet and start with a uniform distribution (which overshoots the entropy target) and slightly skew the distribution to reduce entropy to hit the target x. Then you can map Σ to your desired set (f64 or Vec<f64> in your case?) using an injection, since that preserves entropy.

For your holy-mod-sword example specifically, the better approach is to specify a structured data format (think Excel sheets) that your game loads from a specific directory at startup and inserts the found items, NPCs etc. into the game’s runtime data structures (e.g. loot tables).

For example, Skyrim (and other Bethesda games) do this with .esp-files, which allow you to import a big variety of different game entities. In a small indie game, the format doesn’t have to be anything special; e.g. Elin modders use plain .xlsx files, where the columns are item name, item weight, item sell value, item damage, etc.

The above approach works for static data, such as simple items, but you’ll need more to allow modders to write Turing complete scripts. There are two different approaches to this:

• Expose a language runtime in which the game runs mods. You can design your own language and/or runtime (e.g. Warcraft 3 has JASS), or use existing ones (this is basically what eval is, though you’ll need to hide builtins, globals and such by passing extra parameters). These approaches are theoretically safe thanks to the runtime sandbox, but there are often unintended ways to escape the sandbox and execute arbitrary code.
• Inject the mod executable directly into the game with tools like BepInEx (Unity) or DLL injection (used by e.g. Skyrim Script Extender). There are no security guard rails, so you’ll need to manually review mods.

Another European example is Finnish which has yes but not no.

No in Finnish is ei, similar to Estonian ei or Swedish nej.

I wonder when Firefox is going to add a configuration menu for keybinds.

In applied CS, it’s common to talk about pure and impure functions instead of Turing machines.

Pure functions are, broadly speaking, equivalent to Turing machines. A pure function may only depend on its inputs (like a Turing machine) and has no outputs besides the return value (like the end state of a Turing machine’s tape).

Impure functions cover algorithms that aren’t Turing machines. For example, you might have a random number generator rand: 1 → N that outputs different natural numbers on every invocation rand() and is hence impure. Output functions are also impure, e.g., a function write: N → 1 that writes a number into a file can’t be a Turing machine, because Turing machines have no concept of files.

Computer programs that consist entirely of pure functions aren’t very useful, because they can’t interact with the user or reality. The typical approach to solving this is to put the core program logic inside pure functions that interact with impure parts through a limited interface. That way, you can apply CS concepts to the important parts of the program and neatly separate out the impure parts.

Edit: Changed ∅ to 1 (singleton set) in function definitions. A function can’t return ∅ and a function taking ∅ can’t be called.

all of these are different ways to say “firefox account”?

Basically yes. The idea is that each suffix represents something that’s typically a separate word in English, and you can mix and match suffixes just as you’d mix words.

• my account -> tilini
• to an account -> tilille
• to my account -> tililleni
• to my account too -> tilillenikin

As a Finnish speaker, I just can’t see generic localisation systems like Fluent working with agglutinative languages. For instance, consider the Polish example for Firefox Account from Fluent’s front page:

-sync-brand-name = {$case ->
   *[nominative] Konto Firefox
    [genitive] Konta Firefox
    [accusative] Kontem Firefox
}

In Finnish, this would be called Firefox-tili. Tili means account and belongs to the Kotus type 5 words, which specifies how the word is inflected with various suffixes. Fluent doesn’t support agglutination, so you’d have to specify every form of the word separately:

-sync-brand-name = {$case ->
    [nominative] Firefox-tili
    [partitive] Firefox-tiliä
    ... 10ish more inflections
    [nominative first person] Firefox-tilini
    [partitive first person] Firefox-tiliäni
    ... 10ish more inflections
    ... the above inflections but for 2nd and 3rd persons
    [nominative first person plural] Firefox-tilimme
    [partitive first person plural] Firefox-tiliämme
    ... 10ish more inflections
    ... the above inflections but for 2nd and 3rd persons plural
    [nominative first person questioning] Firefox-tilinikö
    [no idea what this is even called] Firefox-tilittömänäkin
    [no idea what this is even called 2] Firefox-tililleensäkään
    ... lots more
}

Ideally, you’d only specify that Firefox-tili is a type 5 word and the system generates all of that boilerplate.

Teams does actually have a sound cue when people join calls: high-pitched repeated beeps that most people can’t hear due to presbycusis, and the few who do hear it think they’re going crazy.

Related reddit thread.

The author should look into Koka. As I see it, Koka is at the bleeding edge of effect handling, which is why the async Rust team has taken some nibbles of inspiration from it. Alas, Rust as a whole is far too cemented to overhaul everything for generic effect support, but at least it’s been beneficial for async.

Love it. Great lesson on why applicative exists, how it would/should look in C++ and discussion on prior/ongoing proposals.

I would call those language-specific. While they are useful in more than one language, they are also replaced by language features in many languages.

• Builder pattern can be simplified with kwargs (Python, C#) or argument objects (JS, C++).
• Factory pattern can be simplified with first-class types (Lisp, Haskell).
• Visitor pattern is similarly simplified by first-class functions (supported by most languages nowadays).
• Dependency injection of concept X is generally simplified by first-class X. I think the least widely supported is dependency injection of effects (Koka).

Design patterns are typically just workarounds for the limitations of the chosen programming language. What you might consider a pattern in C might just be a simple language feature in C++, and the patterns in C++ (as popularized by GoF) might just be language features in Lisp/Rust/whatever.

So rather than thinking about patterns, you should first choose the right language for the task. If you’re working on a parser, you might prefer Haskell. If you need formal verification, there’s C and Idris and little inbetween. If you need to hire lots of developers, something widely-known like JS might be the choice.

After you’ve chosen a language, you can identify the things that the language is bad at and apply the appropriate design patterns. Sometimes the patterns can be found in books (C++, Java) and sometimes it’s just tribal knowledge (D).

Regular expressions are great and can always be matched in linear time with respect to the input string length.

The problem is that JS standard library RegExps aren’t actually regular expressions, but rather a much broader language, which is impossible to implement efficiently. If RegExp switched to proper regular expressions, they would match much faster but supporting backreferences like /(.*)x\1/ would be impossible.

I appreciate that the talk focuses more on automated approaches to safety this time. I feel the past years’ talks were much more focused on goading developers to follow core guidelines, which doesn’t really work in industry.

Very nice. I remember looking up some of these details from StackOverflow years ago, but this blows those answers away.

It would be much easier to read if it was actually table, i.e., if hex codes and the characters were separated into their own columns.