I still try to be somewhat efficient about loading the dishwasher, but… if I notice myself stressing I just say “screw it”, run it, and wash the rest by hand.

The other thing I’ve realized is that sometimes things don’t get clean if you load them properly. For example, tall glasses that had smoothies in them. It’s a little gross if you don’t notice it until you’re about to use it, but… you can just look at them and wash them by hand when you unload the dishwasher.

I guess this is all to say that sometimes the best optimization is to not think about it too much.

If the operator were explicit (let’s call it ~), the example would look like this:

    $ echo 'cat' | trre 'c:d~a:o~t:g'
    dog

    $ echo 'cat' | trre '(c:d)~(a:o)~(t:g)'
    dog

There is a hidden operator of concatenation as for usual regular expressions. In the code I denote it as lower dot '.' (as in the old Thompson's implementation).

I found the operator precedence unnatural, and it looks like a lot of other folks in this thread did too. I would naturally assume `cat:dog` would be equivalent to `(cat):(dog)` rather than `ca(t:d)og`.

> I would naturally assume `cat:dog` would be equivalent to `(cat):(dog)` rather than `ca(t:d)og`

It was confusing to me too until I remembered that we all kind of use regexes sort of wrong. They're "really" supposed to be considered as generators and not matchers. So IIR cat|dog as a "regular expression" (not a regex) is supposed to formaly expand to

{catog,cadog}

For matching, this set of strings can then be substring matched against some larger text.

The problem is that almost no regex matching engine actually does this, and so now they'll do all kinds of strange things either to meet our expectations, or for efficiency or something.

If you go and try a bunch of different regex tools you'll get variations that either service (cat)|(dog) or (cat)|(dog)|(ca[td]og) or something else.

So from a more formal conceptualization I think cat:dog should produce ca(t:d)og not (cat):(dog). But our experience with "regex" tools has subverted that formalization and now everybody just puts parens around expressions they want to alternate.

My real minor issue with this proposal, as interesting and well thought out as it is, is that it feels like it's just trying to get back at regular expressions as generators, which they actually are and it's coming from a place on the other side of a few decades of how we've been abusing them as regexes for user expectations. In other words, the problem is the tooling, not the syntax.

source: I've worked adjacent to this space in the past and if you've never thought of regexes as string set generators you can toy with the idea here

https://onlinestringtools.com/generate-string-from-regex

but again, how these generator tools works is also very specific. The ones I used to work with had a variety of ways to specify constraints on closures and such to restrict the generators.

In pure theoretical computer science, regular expressions exist as an abstract concept independent from syntax or parsers. They are an “algebra”, which means they are composed of elements connected with operators, but they are not inherently tied to a syntax. In the most fundamental formulation of regular expressions (the one in the Chomsky hierarchy), the only operators are alteration (which modern syntaxes express as “|”), the Kleene star (“*”) and — notably — concatenation, which modern syntaxes simply omit, in a way comparable to how modern mathematics notation omits the multiplication operator when you write “2x”.

In the same way that maths needs rules to define whether “2x²” means “(2x)²” or “2(x²)”, regex syntax needs such rules too. This is called operator precedence. I’m sure you’ve heard that before, but you just might not have realized that the regular expression “ab” has an operator in it because it is typically not written.

Now I’m not going to argue that the operator precedence in maths notation is haphazard or without reason — but it is arbirary. It was arbitrarily chosen to be the most useful to mathematicians using the notation. And it turns out that giving exponentiation higher precedence than (invisible) multiplication (meaning: “2x²” means “2(x²)” rather than “(2x)²”) is more useful.

So coming back to the original example, whether “cat:dog” means “ca(t:d)og” or “(cat):(dog)” is simply a matter of defining the precedence of the “:” operator relative to the concatenation operator. You can argue (and I would agree with you) that one is more useful than the other, and therefore preferable (in the same way that “(cat)|(dog)” is more useful than “ca(t|d)og”), but neither of them is more fundamentally correct or primal or, as you put it, “supposed to formally expand to”.

1 Escaped characters

2 []

3 ()

4 * + ? {m,n}

5 :

6 . (implicit concatenation)

7 |

I have some reasons to put it that way. I want : to be somewhat 'atomic'. If you think about '*' or '+' they can be lower in the table as well. Anyway, I will try to put : lower in the next version and see how it goes.

If I shift it behind concatenation there could be another problem. E.g. with non-associative : should be illegal. And I am not sure how to treat this:

cat:dog:mouse

In the current version I inject the epsilon (empty string). It looks natural E.g. to remove every second letter I could run '..:' which is technically '.(.:eps)':

echo 'abcde' | ./trre '..:'

result: 'ace'

actually ':' association could have a meaning as a composition of regular relations; but I found it too complicated for now.

I would not worry about "cat:dog:mouse" because intuitively it is clearly correct and it means replacing cat with mouse. With parentheses it could be written as "((cat:dog):mouse)".

(:a)

(a:)

a:|b

a|b:

etc

I will try to change the precedence and see how it works. Btw what do you think about explicit operators '>' '<' where '<' works as usual regex matcher, and '>' as a generator. For example to change 'cat' to 'dog' there could be something like '<cat>dog' where '<cat' part is a parser and '>dog' is a generator. Thanks.

    TRRE <- TRRE ':' REGEX | ':' TRRE | TRRE ':' | REGEX | ...

Then there is no syntactic special case. This is just EXPR:EXPR; the special case is that both EXPR are character class syntax, and so the tr-like range mapping applies.

So if we do [a-z]:[A-Z] it should be expanded to:

(a|b|...|z):(A|B|...|Z)

which is pretty legal in trre but has different meaning of mapping any a-z to ALL the A-Z (generating A-Z on each occurrence of lowercase letter).

Distinct syntactic forms can be given distinct semantics, as long as there is rhyme and reason.

Moreover, the right side of the colon is not the normal regex language, it only borrows its syntax. So there, we may be justified in denying that the usual equivalence holds between character class syntax and a disjunction of the symbols denoted by the class.

But I got your point. Maybe there could be some ways to do it in consistent way. Just straight tr-like syntax won't work, e.g I really want it something like this to be valid:

[a-b]:(x|y) (pairs a:x, b:x, a:y, b:y)

and I prefer not handle these in some ad-hoc way.

    I understand that Signal does not consider this
    https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117 to be
    a valid security bug, but it would be helpful to at least be able to
    mitigate it.

    Please add an option in settings to disable automatically downloading
    attachments.

    That should be enough to change the attack from 0-click (just opening the
    conversation) to 1-click (click the attachment). Most people won’t care
    about this, but for some every little bit of privacy is important.

" You can disable the auto-download. Settings > Data and storage > Media auto-download, you can choose what to auto download for mobile data/wifi/roaming."

So, that part is there, but my question is, it's still aissue when they manually download the image, right? Unless something never accepts images from someone they aren't expecting, who 's number or unique created ID has never been seen before

Yes, this still an issue if you manually download an attachment, but that’s a lot better than automatically when you open a conversation.

> I decided it was finally time to build a file server to centralize my files and guard them against bit-rot. Although I would have preferred to use OpenBSD due to its straightforward configuration and sane defaults, I was surprised to find that none of the typical NAS filesystems were supported.

OpenBSD does not support ZFS.

/usr/local is not small at all by default.

https://youtube.com/c/FallofCivilizationsPodcast

(This particular episode is not out with images yet.)

The stock stuff earlier really adds value though. It's not some generic background pan and zoom. If it's in the background it's probably being activity talked about and being used as a visual aid. Having a map of an area or seeing the ruins as they are today or quotes from sou fe out of books etc really elevates the experience.

I honestly don't listen to the non-video ones they are such an essential element.

It’s been a long time since I did any work on a real authentication system — since before TOTP was common, anyway. I appreciated the post and found it interesting.

I’ve seen the “clean up errors yourself” argument before, but, like the author, I don’t think it holds water. Often the correct response to errors is to panic() or pass it up the stack so the caller can deal with it or—more likely—panic() itself.

You get compile errors if you try to handle an impossible error, or don't include an `else` prong (in which case the compiler tells you the full set of unhandled errors).

    fn canError(foo: bool) !void {
        if (foo) {
            return error.Foo;
        } else {
            return error.Bar;
        }
    }

    test "canError" {
        canError(true) catch |e| switch (e) {
            error.Foo => @panic("foo!"),
        };
    }

    ./tmp/errors.zig:10:30: error: error.Bar not handled in switch
        canError(true) catch |e| switch (e) {
                                 ^

Unfortunately most common languages does not prioritize this. As a contractor I have dug myself thru a lot of awful code in different languages and the most common denominator is improper error handling.

>He posted a follow up about error handling......

When I was reading the original blog I was thinking if he had any follow up, so I decide to click on archive and the homepage. And this article, somehow doesn't show up in both list. As a matter of fact I couldn't even find how to get to this blog post without your direct linking. Then it turns out it is a "FUTURE POSTS".

How does that work and why? Is this suppose to be some sort of preview before it is officially published?

That is a great idea. Thank You I might start doing that as well.

The author posted the link in the comments of the original post.

Handling Errors causes us developers so confusion, because we are so used to exceptions and how poorly they were conceived.

Errors should be called Failures. It's just when a function fails to so what it says it does. Nothing more, nothing special about it!

If you call fopen() and it doesn't find the file, that's a Failure! No reason to panic! Just go create the file!

Seriously, I would love to have a quicker way to cook onions.

https://forums.flyingmeat.com/t/memory-consumption-when-open...

Gus Mueller (the author of the linked tweet) is the author of the Acorn image editor.

> I’ve narrowed it down quite a bit (and submitted it to Apple as FB9112835).

> What’s going on is that the IOAccelerator framework has some sort of massive leak in it, where it’s using up 35GB of ram, 25 of which is going to swap (which is why you’re seeing kernel_task flake out).

> On intel, the same image only uses 1480K from IOAccelerator.

I compared smartctl output with activity monitor on disk writes and it's exactly the same number. You can do the same.

> "While we're looking into the reports, know that the SMART data being reported to the third-party utility is incorrect, as it pertains to wear on our SSDs" said an AppleInsider source within Apple corporate not authorized to speak on behalf of the company. The source refused to elaborate any further on the matter when pressed for specifics.

We'll likely never hear anything else about this again from Apple officially or unofficially, so I don't expect anyone who believes there's an SSD wear issue to stop believing that there is. Either the combination of "smartmontools is emulating SMART access, but doesn't actually have it" and "a source at Apple said that smartmontools is incorrect" is enough to make this a non-issue, or it's not — and since most people who think that there is a wear issue don't realize the part about smartmontools faking that it has access to SMART data in this scenario (hint: nope!), I don't expect to find common ground.

So as far as I'm concerned, this is all irrelevant until someone's SSD wears out, and no one's reported that, so everyone is all tempest-in-a-teapot over some numbers that an open source tool is handcrafting from a macOS kernel API based on assumptions about Apple's proprietary hardware that are probably wrong. Wake me up when someone's SSD wears out.

Apple are aware of it, the bug is fixed in 11.4, and once the corresponding XNU source code drops I'll be happy to diff it and show you exactly what they changed in the swapper to fix it and debunk your "debunking".

So, maybe premature to get too hopeful but certainly not too soon to look in that direction?