You could reorder so that the test comes in a commit after the fix rather than before if you want to be able to use plain git bisect, so that no commits are failing. The important thing is that you can use git (i.e. revert in this case) to edit the history to remove the fix and verify the test fails.
Fair. I think what I'd say is that we don't have to use plain git bisect -- it would be quick to make a bisect script that doesn't land on the failing-test commits. Especially seeing as most teams squash before merging, we should have the freedom to create failing-test commits.
Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all.
Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At some point, someone forgot to run the tests, and introduced a commit that broke the test without adding a second commit to fix it. Now it's treated as a "pre-existing failure," and many more commits are added on top.
How would you identify the commit that broke the test?
> How would you identify the commit that broke the test?
You're asking how to use bisect.
You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.
And you can also use bisect by first figuring out the broken commit some other way and then marking everything as good if its before that one or bad if its after - but that's not a very productive use of bisect and if its the only available one I think its fair to call it broken.
> And you can also use bisect by first figuring out the broken commit some other way (...)
Bisect exists to be a tool you can use to fix the problems you are facing.
It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.
Someone tried to recruit me back in 2000 for a startup that would sell a box you connect to your computer allowing you to smell things over the internet. I'll let you guess what industry he was targeting.
2014 was the inflection point. 2013 brought us the term unicorn for companies, and was just long enough after the iphone that we were starting to make sense of it. That's when Elon Musk became a household name thanks to Tesla and SpaceX. Then there was Palantir. Google bought Deepmind in 2014. Google Facebook Amazon and Apple showed founders that software startups could transform the world, and the world leapt at the chance.
To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)
Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.
Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.
If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.
It's (sadly) still not possible to express monads with this change, since generic methods can't implement interfaces. You'd probably want something like:
type Monad[T any] interface {
Bind[U any](func(T) Monad[U])
}
However this requires the Bind method to be generic, which still isn't allowed in an interface
I am not very familiar with Go and especially not its generics support. Can you implement the "join" version instead of the "bind" version, where you turn a T[T[a]] into a T[a]?
> Your entire codebase is now a surface area that is at risk of being blocked
The point of goroutines is that they can freely block when needed. It's not like async where you have to be paranoid at every moment about writing blocking code
Why would there be paranoia when writing blocking code with async?
The downside of goroutines is that you have no control when the goroutine context switches, so naively accessing a global value can lead to race conditions (which the language has no warnings for despite being such a concurrent language), while the same code works fine in JavaScript because context switches don't happen in synchronous code.
> Why would there be paranoia when writing blocking code with async?
In languages like JavaScript, you have to be careful to avoid blocking the event loop, and use something like worker threads for CPU-intensive tasks. Otherwise you will end up with long tail latencies. In Go, the runtime automatically manages this and can suspend and resume long-running goroutines.
> naively accessing a global value can lead to race conditions
Fair point that the language doesn't automatically catch this, but that's what a mutex is for. In return you get actual parallelism that can use all your CPU cores
Amusingly, Go, a language designed for concurrent programming, also had problems with blocking code for years. They had two releases that fixed it with proper preemption (1.2 added preemption, and 1.14 fixed other issues with preemption).
You can only freely block the goroutines that you designed that way, there's plenty of ways of shooting yourself in the foot with goroutines without even touching “blocking” code (because everything is blocking).
Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.
Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.
I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.
I use lowercase for my personal environment variables. It works well since most programs only depend on variables in all caps. Hadn't thought of using MY_
I really want to like Helix, but I wish the developers paid more attention to performance, or were more receptive to outside contributions. Helix can really chug, even on small files, and the perception in the community seems to be "it's written in Rust so therefore it's blazingly fast :rocket-ship-emoji:"
