The closest thing is probably RustBelt [0], which proved the soundness of a subset of Rust that included borrowing/lifetimes. This was later extended to include relaxed memory accesses [1].
Neither of these papers include the trait system, unfortunately, and I'm not aware of another line of research that does (yet?).
> My hope is that the educational and non-profit intentions of this repository will enable it to stay hosted and available, but the original copyright holders do have the right to ask for it to be taken down, in which case I will comply without hesitation. I do hope, though, that along with the various other disassemblies and commentaries of this source, it will remain viable.
Long copyrights are a cancer in our society. Just notice the fear in his writing - "without hesitation". We're talking about a ~40 year piece of work here.
Patents last 20 years and people keep filing them in the millions. We remain an inventive species. Obviously the protection works. Why do we need to protect copyrights for near a century?
That's not fear, it's an indication of the respect in which I hold the original authors (whom I believe are still the copyright holders). If Bell or Braben asked me to take it this down, I'd roll with it. Same if Geoff Crammond asked me to take down my Aviator and Revs analyses; of course I'd comply. It's their code.
I have copyright content out there in the world (including the commentary aspects of this project), and I'd want to be able to control what happens to that too. Seems fair to me.
I admire your integrity. At the same time, these "rights" come from flawed laws. The code should no longer be "theirs".
I won't write a long and boring critique of the current copyright length, but this work should be in the public domain at this point - nobody should be entitled to ask you to take it down. It should belong to you as much as it does to them. Like Algebra and Hamlet.
It in fact belongs to humanity, as the creation of the work itself was built on top of everything that came before it.
> Xiaomi central hub gateway is only available in mainland China. In other regions, it is not available.
Nonstarter for many, myself included.
ETA: Yes it does say "partial" local control can be done without the gateway software, but is not recommended and does not work unless you are on the same local network. Better than nothing, but still a nonstarter.
> If you do not have a Xiaomi central hub gateway or other devices having central hub gateway function, all control commands are sent through Xiaomi Cloud.
Now I don't actually know what central hub gateway function entails :) but it does sound like some non-Xiaomi devices could also fulfill this role.
In case of HASS I think local network is a pretty decent assumption. I have my HASS on both my local VLAN as well as the IOT VLAN.
still people who are touch typists are able to find the characters faster on the keyboard than others. this message is written that way to test that out, in parts where it was possible.
however, in my case the blank keycaps did make the task a bit more difficult. i would write faster in cursive, and it might feel less effort.
also the reason was outlined:
> Allowing the use of (the fingers of) both hands would cause many unforeseen effects on the brain, which would make it hard to interpret the results.
I don't think that should trigger a reasonable interesting condition one has specified, so that should not happen. So I suppose for non-compiler-bugs you need to check (from the output) that the correct thing is being done, in addition to detecting the actual issue.
I was not disagreeing with that, merely pointing out that the reproduction test shouldn't be passing with the minimal runnable C program, or indeed for many many previous iterations before that. In my mind also runnable programs would be tested with grep, instead of relying on the return code of the program.
Well, the conditions were satisfied with pipewire, that introduced some dependency at some point that were not satisfiable in Debian Stable.
So, for now, I'm stuck with the version one commit before that dependency :). (I haven't tried undoing the change later, I suspect it might be dependend upon later on..)
If that's practical experience that you need, I remember reading some studies comparing the reliability and efficiency of nomad vs k8s under load (spoiler: they do not look very good for k8s).
If that's popularity that you need, then sure, nobody ever got fired for choosing kubernetes.
I actually rather like the mli-files. It's a nice file to read, with the documentation and externally available symbols only. However, the fact that the syntax is so different is a bit annoying.
Sometimes I wrote (haven't written OCaml for some time now..) functions like:
Is this the case? E.g. the issue "Prove the Rust type system sound" https://github.com/rust-lang/rust/issues/9883 is closed with comment "This will be an open issue forever. Closing." in 2016: https://github.com/rust-lang/rust/issues/9883#issuecomment-2... .
At least nowadays (since 2022) we do have a language specification for Rust: https://ferrous-systems.com/blog/the-ferrocene-language-spec...
reply