benji-york

After watching the video, I'm not understanding your objection. That's pretty much how the current bidi voice model sounds.

I find the framing of distrusting/attacking people because they behave in ways you don't understand somewhat off putting.

Any decent human being would have called these Black Hole Suns.

`pip install zig` works today.

This is true; we should strive for this not to be true.

Since the word "draft" was used, it is safe to assume that the message will be reviewed and potentially amended before being sent.

The maintainer of top fully-justifies his commit messages, e.g., https://gitlab.com/procps-ng/procps/-/commit/e6f22569e9db16d...

commit e6f22569e9db16dbef7d9bdee5bb41b8cb7a03ca

Author: Jim Warner <james.warner@comcast.net>

Date: Tue Jul 23 00:00:00 2024 -0500

    top: attempt once again to allow help text translation
    
    Back when our release 4.0.1 was being readied, sources
    were sent to the TP (Translation Project). However one
    person named Benno Schulenberg refused to release them
    for translation. His stated reason was the top command
    line help text which then finally included long forms.
    
    He demanded that the help text be broken into separate
    strings instead of a single large string. But, all the
    top text (some much more complex) has just one string.
    So that stated reason was, at the least, inconsistent.
    
    [ I suspect the real reason was that Mr. Schulenberg ]
    [ thought that the carefully right-justified English ]
    [ wording would also be required of translations too ]
    
    The bottom line was that Benno took it upon himself to
    change the TP motto from "you code, we translate" into
    "first we tell you how to code and then we translate".
    
    Rather than bend a knee to that despot, I disabled the
    text entirely, admittedly denying users a translation.
    Now, with this commit we enable translatable help text
    but with a hint included to ignore the justified text.
    
    Reference)s):
    . Oct, 2022 - finalized translation exclusion
    commit ab05a3785f29cc4b754e17c53bfb3d8ba054563e
    
    Signed-off-by: Jim Warner <james.warner@comcast.net>

Those are totals, not annual spending.

> even if every adult on the planet spent 250$ on AI per year this would still not cover anywhere near what's being invested.

Your math does not make sense. That's something like $1.5 trillion every year. That's no where near what is being spent in AI hardware buildouts on an annual basis.

In the short term (assuming no point fixes help soften the shock).

Can you get (non-LED) lightbulbs you like online?

No. They are illegal.

Iterated games.

I believe it would add color to the discussion if you enumerated a few of the details of those workloads.

I'm a long-time CLI/TUI lover, but the Codex GUI has converted me for at least this use case. It has most of the positives of a TUI plus some that would be hard in a TUI.

> But they are not independent though, they will be owned by Wall Street should they go public.

That depends on how much equity they issue as public stock. (And stock classes and voting rights, but you get the idea.)

My reading is that it uses CV to identify potential click targets on the screen.

This appears to be a successor document: https://archive.org/details/common-user-access-basic-interfa...

I have joint problems in my thumbs and have trouble with thumb-heavy layouts, but have found the Sofle V2 to work well for me. For my hands it is important that the center thumb key be directly below the N and B keys, which the Sofle provides.

Details at https://josef-adamcik.cz/electronics/another_year_for_sofle....

Although that's a different knot (I use the one originally referenced), I taught my kids the knot in the animation and it's worked out well.

Added benefit: adults are impressed when they see my kids tie their laces.

By way of experience report: I've been using this app for a week or so on my daily driver and it's been great.

I love reST and I think it lost primarily because of distribution. I.e., the people using it did not have large audiences and didn't put much effort into promoting it.

It's a shame because reST is almost as easy on the eyes as Markdown and is much more capable without being too much more complex.

> polluted my codebase

I'd love to hear more about that.

You might enjoy this video: https://www.youtube.com/watch?v=a9xAKttWgP4

> Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed

Preventing memory leaks isn't normally what people mean by "memory safety".

As an aside: a common memory management approach used in Zig is to have a dedicated memory pool for an operation and simply free all of the memory after the operation is over instead of freeing individual allocations.

I don't think the character is that uncommon in the output of slightly-sophisticated writers and is not hard to generate (e.g., on macOS pressing option-shift-minus generates an em-dash).

I appreciate the consideration. I'll be watching Vedro with interest.

I do like the nicer vedro.asserts mechanism. If that works with unittest and pytest it would be really nice. You might get a few converts that way, too.

Looks pretty normal: https://playcanv.as/p/apIKHp7a

Your first and second points makes sense. They don't matter much to me, but I see how others could value those things.

Aside: I also don't like the hamcrest syntax. I also don't love unittest's syntax but it's OK and it's pervasive (i.e., available in the stdlib).

The third point is where I start to disagree more strongly.

> I like that there's nothing new to learn, the expressions work exactly like they do in any Python code, with no special test behavior or surprises.

This doesn't seem true to me.

> the expressions work exactly like they do in any Python code

Not to my mind. In normal Python, an assertion communicates something that is unequivocally believed to be true, not something that may or may not be true (a test). Let me see if I can explain it this way, I often use asserts in tests to show (and enforce) something that I believe to be true and must be true, before the test can have any meaning. E.g.,

assert test_condition() == False invoke_the_code_under_test() self.assertTrue(test_condition())

The "assert" communicates that this is a precondition, the "self.AssertTrue" communicates that this is a test.

I can 100% see that others might not see/care about the distinction, but I think it is important.

> no special test behavior

Well, that's not quite true. You have to handle the AssertionError specially and do some fairly magical work to figure out the details of the expression that failed. The unittest-style assertions just report the values passed into them.

I don't really like that magic, both from an aesthetic standpoint and from a least-complexity-in-my-tooling standpoint. Again, I can understand others making different tradeoffs.

As someone that loves Python and hates pytest, you have my support.

(Although, I don't like using bare `assert`s in tests, but maybe you'll convince me.)

I'm not great at electronics, but it looks like it alternates turning on the two LEDs.