I start from the OpenWrt devices page. Filter by the Wi-Fi revision I need (ac or ax), opt for 4 cores or more and sufficient RAM, and then read the forum posts and the device page to make a shortlist. Then I look at price and availability.
It’s a standard way to do pre and post conditions. Clojure pre and post conditions also behave this way. If you force these conditions into compile-time checks, well, then you are introducing a second type system with refinement types into the language. And type checking would take a long time. Imagine someone writes a precondition for a function where its integer argument x needs to satisfy collatz(x)==1; do you now expect the compiler to prove the collatz conjecture or verify it for all 64-bit integers every compilation?
My experience using pre and post conditions in Clojure makes me really like them. They are a small but meaningful improvement over plain old assertions. And yes being able to turn them off is a feature not a bug. Don’t expect them to be like LiquidHaskell.
SPARK (Ada) has compile time pre and post conditions, and it works well. If you declare the post-condition Collatz (n) = 1, the compiler can't help you, and compilation will fail. If you've got a difficult condition, you're going to have to help the theorem prover, often by introducing "ghost" functions, or by simply softening the condition. In the latter case, you can't prove total correctness, but you can often still prove things like absence of run-time errors.
I haven't tried it and am afk rn but I'd imagine you just define a constexpr function that implements collatz and use that in your contract.
(Edit: if the input is constexpr itself)
Its also quire easy to think about specializing a few templates and doing it that way. If you look up an example of the fib sequence in c++ templates you'll get the general idea.
I feel like I'd have something to learn from seeing the code.
Won't you just run into a constexpr evaluation depth error with a suggestion to set -fconstexpr-depth? I don't see how this is the gotcha it's made out to be.
I'd exepct something like that to happen. Worth reiterating that the whole scenario is for a hypothetical different implementation of contract that would execute comptime, as noted in the parent thread.
If you wanted a c++26 preconditon for collatz tho, here it is.
```cpp
bool collatz(unsigned long long n) {
while (n != 1) n = n % 2 ? 3 * n + 1 : n / 2;
return true;
}
void f(unsigned long long n) pre(collatz(n));
```
That's basically what you'd write if you were doing it with asserts, as the linked article states, just now you add it to the declaration.
For some reason I read a long time ago that offloading is unreliable and I turn it off everywhere. I’m glad that the author also had to turn it off to fix Qualcomm’s bugs. But in general, is this still good advice in 2026?
> When you open the AirPods box for the first time does the iPhone do that animation and say "Set up AirPods..." etc?
There are many amusing videos of someone in China setting up counterfeit AirPods on a train, and every single unlocked iPhone on the train car did that animation. The counterfeiters took pride that their product had a “stronger connection” than the real thing.
> I do appreciate that passkey adoption has led to wider support for hardware security tokens
In my experience this simply didn’t happen. Many sites support passkeys but only the native passkey stored on the current device, but not a hardware security key. Many sites don’t even allow multiple passkeys, which is frankly required if you use hardware security because you will want multiple pieces of hardware in case one is misplaced.
I no longer go to my local community hospital for any purpose. It’s either an inconsequential thing that my primary care doctor can deal with, or go to a large reputable hospital even if it’s a one-hour drive away.
Absolutely not. When I create projects I only credit other existing systems if they are a direct inspiration. If I independently come up with the same idea as someone else I see no reason for me to do the due diligence and credit them.
Okay, well, in this case (even accepting your argument) I've been told there is direct overlap in contributors so there is no feasible way they couldn't have known.
reply