11–18 of 18 posts
If our only goal is to run forever, the solution is immediate: ```rs fn main() { loop {} } ``` I think this can even cause Undefined Behavior :) https://github.com/rust-lang/rust/issues/28728
If our only goal is to run forever, the solution is immediate: ```rs fn main() { loop {} } ``` I think this can even cause Undefined Behavior :) https://github.com/rust-lang/rust/issues/28728
The doubly funny thing is that some C++ people don't want those either, and so the ISO document will be updated to say actually C++ does have infinite loops because programmers want that. It just won't have an elegant way to express it like Rust.
If our only goal is to run forever, the solution is immediate: ```rs fn main() { loop {} } ``` I think this can even cause Undefined Behavior :) https://github.com/rust-lang/rust/issues/28728
Not to mention that it will halt on signal, contrary to the goal. I guess that's the problem with "vibe coding": What immediately looks like the solution isn't apt to be.
Well, it's difficult not to halt on, say, SIGKILL, that's for sure. There are ways to do it, but they are cursed and I hate them (e.g. zombie processes). Though you can still usually get rid of zombie processes by killing the parent, or just rebooting the system.
tricky tricky- I think this stops well before 10^^15 due to the limits of 64 bit addressing
To get 10^^15 steps, the article assumes "any amount of zero-initialized memory". (It calls that assumption "unrealistic but interesting".)
def tetrate(a, tetrate_acc):
assert is_valid_other(a), "not a valid other"
assert is_valid_accumulator(tetrate_acc), "not a valid accumulator"
assert a > 0, "we don't define 0↑↑b"
exponentiate_acc = xmpz(1)
for _ in count_down(tetrate_acc):
multiply_acc = xmpz(1)
for _ in count_down(exponentiate_acc):
add_acc = xmpz(0)
for _ in count_down(multiply_acc):
for _ in range(a):
add_acc += 1
multiply_acc = add_acc
exponentiate_acc = multiply_acc
return exponentiate_acc
fn tetrate(a: u32, acc: &mut BigUint) {
assert!(a > 0, "we don’t define 0↑↑b");
let mut exp = BigUint::from(1u32);
for () in acc.count_down() {
let mut mul = BigUint::from(1u32);
for () in exp.count_down() {
let mut add = BigUint::ZERO;
for () in mul.count_down() {
for _ in 0..a {
add += 1u32;
}
}
mul = add;
}
exp = mul;
}
*acc = exp;
}Earlier quoted context omitted.
Not to mention that it will halt on signal, contrary to the goal. I guess that's the problem with "vibe coding": What immediately looks like the solution isn't apt to be.
> Not to mention that it will halt on signal, contrary to the goal. Well, it's difficult not to halt on, say, SIGKILL, that's for sure. There are ways to do it, but they are cursed and I hate them (e.g. zombie processes). Though you can still usually get rid of zombie processes by killing the parent, or just rebooting the system.
But something like SIGINT is at the discretion of the program. If it chooses to accept the signal and halt it is entirely because the program decided it was finished.
tricky tricky- I think this stops well before 10^^15 due to the limits of 64 bit addressing
Yes, the article figures that with a limit of 64GB of memory, with simple nested loops, you could only loop about 10^(165 billion) steps. To get 10^^15 steps, the article assumes "any amount of zero-initialized memory". (It calls that assumption "unrealistic but interesting".)
If you are cloud-averse, you could do the same with networked storage on your local LAN and just connect more disks when it's running out.
If our only goal is to run forever, the solution is immediate: ```rs fn main() { loop {} } ``` I think this can even cause Undefined Behavior :) https://github.com/rust-lang/rust/issues/28728
Not to mention that it will halt on signal, contrary to the goal. I guess that's the problem with "vibe coding": What immediately looks like the solution isn't apt to be.