For those interested, this is because of how Rust uses value gaps to represent its nullable/enum structures. E.g., like how None for Option NonZeroU8 [sic, can’t get formatting to work] is represented internally by a 0 instead of a wrapping structure.
When you have that many layers around a unit, it will start at 0 and bump the internal representation for each Some you turn into a None.
but effectively it’s bash, I think /bin/sh is a symlink to bash on every system I know of…
Edit: I feel corrected, thanks for the information, all the systems I used, had a symlink to bash. Also it was not intended to recommend using bash functionality when having a shebang !#/bin/sh. As someone other pointed out, recommendation would be #!/usr/bin/env bash, or !#/bin/sh if you know that you’re not using bash specific functionality.
Still don’t do this. If you use bash specific syntax with this head, that’s a bashism and causes issues with people using zsh for example. Or with Debian/*buntu, who use dash as init shell.
Just use #!/bin/bash or #!/usr/bin/env bash if you’re funny.
#!/bin/bash doesn’t work on NixOS since bash is in the nix store somewhere, #!/usr/bin/env bash resolves the correct location regardless of where bash is
I do think a simple symlink is superior to a tool parsing stuff. A shame POSIX choose this approach.
Still the issue that a posix shell can be on a non-posix system and vice versa. And certificates versus used practice. Btw, isn’t there only one posix certified Linux distro? Was it Suse?
Binaries are not in /usr/bin or /bin except for /bin/sh and /usr/bin/env. Programs should not assume fixed paths for binaries and instead look for them in $PATH.
It is a symlink, but bash will automatically enable posix compliance mode if you use it. So any bash specific features will bomb out unless you explicitly reset it in the script.
i thought most unix-like systems had it symlinked to a shell like dash. it’s what i have on my system (void linux), of course not as an interactive shell lol
i use #!/bin/sh for posix scripts and #!/usr/bin/env bash for bash scripts. #!/bin/sh works for posix scripts since even if it’s symlinked to bash, bash still supports posix features.
Beginning with DebianSqueeze, Debian uses Dash as the target of the /bin/sh symlink. Dash lacks many of the features one would expect in an interactive shell, making it faster and more memory efficient than Bash.
From DebianSqueeze to DebianBullseye, it was possible to select bash as the target of the /bin/sh symlink (by running dpkg-reconfigure dash). As of DebianBookworm, this is no longer supported.
Since all of the expressions just wrap a None, I wouldn’t be surprised if the transmutes basically get compiled to 0, making the assertion at the end assert_eq!(0 * 0, 0).
That’s kind of wild, I double-checked and it’s true.
Although I disagree with the second part, the Rust folks wouldn’t care about the in-memory representation as long as the compilation is on point.
Looking closer at the final enum, I guess it’s because there are nine possible cases for it, making the compiler pack it into 4 bits, with one number representing each? I checked and None is represented as 8, while 7 Somes containing a None is 0 and the full 8 Somes is represented by 1.
Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.
You lost me at “pair programming”. Having tests for what you can test is fine. But there’s code that simply can’t be tested, or at least not easily at which point you are just wasting time. Open source mantra is always great in my opinion… release early, release often. In addition to that have a test version of your software before you push it to production if there’s sensitive data. That’s usually good enough to catch issues.
And he’s right, reviewing changes before merge just takes time and resources away from project while the master branch keeps moving. Merge, if there are issues, whoever submitted the change is obliged to fix it. You can always checkout earlier version.
I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there’s a conflict but the automerge keeps drift to a minimum so it’s less common and fixed sooner.
better than merging poorly tested/reviewed code.
and yeah, a small team of superstars doesn’t need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.
it also leads to plenty of good conversations about the best way to implement, so overall it’s a win.
Well, Git was designed to branch out, not be a single repo with bunch of users. So one team can have a local repo, that in turn gets merged into big one, etc. Structure matters as you say. Small experienced teams move fast. Big teams require a lot of management and supervision. I still think it’s better to split people up into small teams and give individual tasks, or let them pick tasks that need to be done.
[Transcriber’s note: the first line in the following transcription is incorrect. After the equals, there should be eight instances of the word “Option”, each succeeded by a less-than symbol, then two brackets, like (), before the first greater-tha symbol. However, if you type a less-than symbol on Lemmy, it seems to strip that symbol and whatever word comes next out of the source when you save the comment.]
I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.
Still needs to be checked over to make sure it didn’t get anything wrong. In my experience the mistakes AI make with monospace fonts tend to be very awkward to notice (like 1 and l and I and | being interchanged), so I’d have to go over with a fine tooth comb which, for me, since I type quickly, isn’t noticeably faster and is a lot more boring.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.