faho

The rust cygwin target has been merged (in a different attempt): https://github.com/rust-lang/rust/pull/134999

No, they work in zsh, with one extremely small change: The referenced variable needs to exist.

Try this (tested with zsh 5.9 on archlinux):

    foo='PWD[$(echo hahaha >&2)0]+42'
    [[ "$foo" -eq 5 ]]

In bash, this would also print "hahaha" with "a" (or any other possible variable name) instead of "PWD", that's why many think it doesn't work at all in zsh.

I'm pretty sure zsh has an optimization where it skips the indexing if the variable doesn't exist, which happens to sometimes stop this. But since you can just reference variables like PWD, that you know exist, it's not really a security improvement.

Fish has always used utf-32 codepoints stored in wchar_t, from the first git commit in 2005.

Unfortunately it's pervasive throughout the entire codebase (which does a lot of string shuffling).

So it's a historical mistake, but not something to be fixed in the same step as switching the implementation language.

bstr was mentioned as a direction and is a possibility.

>Matrix's moderation should be at least as good as Gitter

Well, yes and no. The moderation features might be the same, but:

1. It's a lot easier to make matrix accounts, especially if you run your own server.

2. The user interface for blocking an entire server is basically missing? The only thing I can find has you run a bot to do it?

So if someone with their own homeserver wants to troll you, you end up playing wack-a-mole unless you self-host a bot. At least that's the best I can find so far.

The idea behind this series of posts is to see how much of python, concretely, is syntactic sugar and how much is necessary. How much could you do with e.g. doing macro transformation on top of a minimal core?

The last post before this was titled: "MVPy: Minimum Viable Python".

So, since python doesn't have goto, you can't replace while with an if with two gotos (without adding a goto to the language).

You can replace an `if` with a while tho, easily.

Arch already has the nvidia drivers in the normal repos. You can just install them.

This isn't something Manjaro adds.

Depends on your echo. Zsh's interpretes escape sequences by default unless the "BSD_ECHO" option is used, bash's doesn't unless "xpg_echo" is on.

And xpg_echo is on by default for bash on macOS, so for users on macOS it looks like echo interprets escapes by default.

This is one of the reasons why echo is hopelessly unportable.

See https://unix.stackexchange.com/a/65819/55665

One issue is that make will default to only using one job (i.e. one cpu), and you need to pass `-j NUMBER` to make it use more, while Ninja is parallel by default.

For my uses, I've not found `ninja` to be much faster than `make -j8` on an 8-core machine.

Not that the defaults don't matter, of course.

Bash also turns off the bracketed paste, because it can't know if the command it is about to launch supports it. So that command would have to re-enable it itself. Something like emacs or vim might do so (or another bash, you can nest shells).

And yes, then bash starts ls, which is an external program. It might be /usr/bin/ls.

And then ls quits, and bash re-enables bracketed paste because the command might have not enabled it or enabled it and disabled it before quitting. So you get this weird bracketed paste sandwich.

"\r", "carriage return", is what the return/enter key sends (either that or "\n", it's configurable).

So what's being sent from the terminal to bash here is "ls" (which is echoed back) and then the return/enter key, which bash interprets as "run the command".

So it sends "\r\n" to the terminal (this is "recv" in that notation), which moves the cursor to the beginning of the line and then to a new line to get the cursor off of the prompt line, and then "\x1b[?2004l", which is the sequence to turn off bracketed paste.

Then ls runs and prints "file\r\n", which is the filename "file" on its own line.

Then bash takes over again, reenables bracketed paste and prints the prompt. Notably it does not move the cursor to get the prompt on its own line, so when the command didn't end in a newline the prompt hangs in a weird spot - try `printf '%s' foobar`, it'll show your prompt like "foobarbork@kiwi:/play$". There are tricks to get around this.

The original performance claim was about https://vimuser.org/cat.c.txt.

Which just does read/write - so it's the same as the "cat-simple" example, which is the slowest listed.

GNU cat [0] does copy_file_range if it can and falls back to a read/write loop otherwise, so it's unlikely to be much slower (possibly some overhead from argument parsing, but that's just a constant).

So the performance claims are wrong.

[0]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat...

First of all: Your code is missing braces around the `if` blocks - the `goto out` would be run unconditionally.

But anyway, the case for `goto` here is that it jumps immediately to the cleanup that needs to happen always.

If you put something between the loop and that, `break` would jump before that and also execute that.

Yes, this is a workaround for C's lack of automatic cleanup (RAII, garbage collection, python's `with` or whatever).

>This change prohibits nothing, it allows specifying something (which was a bit complicated to enforce before).

It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.

Say you have a table (EmployeeName, CarID). You could do a UNIQUE constraint on those two attributes, but that would still allow:

EmployeeName | CarID

Jeff | 2

Kim | NULL

Kim | NULL

Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.

Hence the new constraint.

But an employee can't be car-less twice!

That's what this change prohibits.

>But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX.

Unfortunately, it doesn't specify those known locations. It explicitly declines specifying that /bin/sh exists.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... says:

> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.

and it doesn't specify the location of getconf either, so you have a chicken-and-egg problem where you need the standard $PATH to find getconf to get the standard $PATH.

These files are already in toml, so it's only "unnecessary" if you ask for them to switch the file format.

Otherwise, adding tools to the standard library to read file formats required by the ecosystem is a good idea, regardless of whether you agree with the particular format.

The first two lines are setup, real code would already have done that.

You could maybe count the import, but you'd have to do that once and could do multiple bisections, so it's amortized.

Setting the variable doesn't count because you do, of course, need a variable to perform an operation on a variable. Sorting the array also wouldn't count because you can't use binary search if the array isn't sorted.

Or you can implement a binary search in your type's __contains__ and just use `"foo" in c`

CentOS 7 may have been released in 2014, but the software it shipped was already quite old then.

As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9.

Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009).

[0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.

Fish also enables bracketed paste and does smart escaping when you paste inside single-quotes.

(I'm a fish developer)

Would you mind posting a link to your tmux config? I'd look into it.

You're overthinking things, it's simply hyperbole.

He doesn't. Linus uses MicroEMACS [0], which is an entirely different editor that uses emacs bindings.

It's not the lisp vm that incidentally happens to edit code that GNU Emacs is.

Or, as he puts it [1]:

> I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.

[0]: https://github.com/torvalds/uemacs [1]: https://www.tag1consulting.com/blog/interview-linus-torvalds...

And in english it's "Ivory Coast", in german it's "Elfenbeinküste".

None of those is an official name tho, they are quite insistent that's exclusively the french one:

>Therefore, in April 1986, the government declared that Côte d'Ivoire (or, more fully, République de Côte d'Ivoire) would be its formal name for the purposes of diplomatic protocol, and has since officially refused to recognize any translations from French to other languages in its international dealings.

(from https://en.wikipedia.org/wiki/Ivory_Coast#Etymology)

Well, yeah, if you source the file (for which `.` is a shortcut) it runs in the current shell so the environment is intact.

If you just run it it won't work.

So instead of running `boop` you would always have to `source boop` or `. boop`. A function or alias you could just run like normal.

(and `export ?` complains about ? being an invalid identifier in bash, in zsh `export "?"` apparently "works", but will reset it before you get a chance to print it in another process)

He's listed as the (co-)author on a number of PEPs:

- PEP 533 – Deterministic cleanup for iterators

- PEP 518 – Specifying Minimum Build System Requirements for Python Projects

- PEP 517 – A build-system independent format for source trees

- PEP 465 – A dedicated infix operator for matrix multiplication

- PEP 600 – Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions

- PEP 8016 – The Steering Council Model

- PEP 568 – Generator-sensitivity for Context Variables

(and that's as far as I cared to look - unfortunately https://peps.python.org/ lists the authors by last name and there are multiple people named "Smith")

So it seems he has in fact "done much".

For python code, yeah, most of it.

Python does sometimes have backwards-incompatible changes, e.g. for 3.10 they removed a bunch of stdlib modules and methods, like the "formatter" and "parser" module [0].

So if you used those, your code wouldn't work in 3.10.

But the main reason to wait for wheels (which is pythonese for "pre-built packages") is if they use native code (like C or rust) and you would have to compile them yourself otherwise, which increases installation time quite a bit.

(this was also the reason why Alpine was a bad choice for python containers for a long time because it uses musl and there were only wheels for glibc available. AFAIK musl wheels exist now so that isn't relevant anymore)

[0]: https://docs.python.org/3/whatsnew/3.10.html#removed

That news item is only saying that wireplumber will activate pipewire as an audio server, and won't allow you to use it for video only (with pulseaudio serving audio).

It's irrelevant for those who've picked pipewire as audio server specifically, so it will most likely be irrelevant for Ubuntu.

Plus the Ubuntu 22.10 release is in October 22 (they use calendar versioning), so there's still some time to work out the kinks.

Plus a lot of interesting things aren't mentioned in terminfo - bracketed paste, cursor shaping, synchronized output, ...

And even truecolor was added to it about 10 years after terminals started gaining support.

And many terminals just claim to be "xterm-256color".

>2) try them and have graceful degradation if they're not supported

Note: There are many cases where degradation isn't graceful. Many terminals on windows currently spew garbage on your screen if you send bracketed paste (alacritty, for instance).

>1) probe for those features by asking the terminal, which some terminals support

This requires waiting for a reply, which often isn't useful. E.g. if you want synchronized output, you want it from the very first paint (because that's when the terminal is most likely to still be resized, e.g. by a tiling window manager). So you would have to delay your startup until you've either gotten a reply or "enough" time has passed that you believe it's not supported.

Frankly, this is all a big mess and terminfo isn't very helpful, but we don't have a good alternative either.

>I may be generalising but I find older (40+) programmers more likely to write good code

[...]

>For example, in Common Lisp

Technology choice can correlate with age. In Lisp's case I would expect that it's long past "cool", i.e. that it's attracting fewer people than it used to, and so I would expect it to skew older.

Just like perl and tcl and awk.

Also you would have to take survivor bias into account - if you only see good lisp projects, maybe that's because the bad lisp projects died out? Maybe the bad old lisp programmers left?