I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.
So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).
OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.
Thanks. I was a genuine question and you answered it well. For some reason I've internalized that closures can capture variables sometimes, but I guess I'm not sure the conditions in which that's true (or perhaps I've learned/mis-remembered the wrong lesson a long time ago.
If the code in the closure moves a value, then the closure becomes an FnOnce and does move the value out of the context. That's what you probably have in mind.
So, Rust does support partially-moving closures, and does so automatically.
But the converse is also true: Rust does not move values just because. If the code inside the closure doesn't move the context, then it will only move context if you use the `move` keyword (in which case the lifetime of the closure is not restricted by borrows of the context; Rust doesn't automatically move things to satisfy the closure's required lifetime, that's a manual decision process consistent with how Rust behaves in other places).
There's still one difference to the macro case: the closure borrows all the values at once. So if it needs &mut access to some variable in the context, you can't take another &mut to the same variable outside the closure as long as it is alive (as determined per what the non-lexical lifetime borrow checker can do). Those cases need to be worked around by instead passing in the &mut as a closure argument. Code deposited by macros is not subject to bundling all captures together, hence the borrow checker has more allowance to reduce the borrowing time of each borrow.
> The behavior is all the more impressive given that the rodents hunt at night, when they are effectively blind
I can't access the paper to check if they verified it, but given there is a strong IR light, and even humans can see IR light if strong enough (and close enough in frequency, which is typically true for IR illumination for cameras), I wonder if that is true.
Intriguing, but I'm referring to the toolchain as a whole. Everything is done with CMake mumbo jumbo that is a pain to set up. For a computer this small and simple there should be a straightforward "compile .c to .o, link .o to flashable binary, flash binary" that any user can type in at the shell or put into a Makefile.
I wonder if they sensed that at some point number plates would be automatically recorded wherever you drive, even when not causing an accident or doing anything illegal.
Just a funny coincidence or is there some connection?: OP writes that legislation started 1 January 1904, which happens to be the time epoch in the classic Mac OS, which was released in 1984 with the well-known 1984-styled commercial.
I would expect that this increases the gap between new and old phones / makes old phones unusable more quickly: new phones will typically have enough RAM and can live with the 9% less efficient memory use, and will see the 5-10% speedup. Old phones are typically bottlenecked at RAM, now 9% earlier, and reloading pages from disk (or swapping if enabled) will have a much higher overhead than 5-10%.
> At the end of the last century, coal was used to generate more than 95% of the UK's energy, but last year it had fallen to 1%.
That looks like an impressive change, even if the coal use hasn't been replaced with renewables. But looking up details, the 95% number doesn't appear to be true:
- "Energy mix of UK"[1] shows no time when coal was above ~55%, and even total fossil fuel use was over 95% in 1965, not around the year 2000. But this may be total energy use, not just for electric (not sure).
- "UK electricity production by source"[2] shows that around the year 2000 fossil fuels made up perhaps about 70% of the mix.
I wonder if the author was thinking of 1899 as "the end of the last century." It can happen to people who lived much of their lives in the 20th century.
I was born not that far off the end of the last century and I didn't bat an eyelid at that, heh.
Even weirder is that we are currently in the '20s. That's always going to mean 1920s to me, but I imagine I'm going to have to get used to younger family & news etc. using it to mean 2020s in the not too distant future.
I subtitled an album of music written and performed by friends and colleagues in about 2000, "Music from Turn of the Century Southampton" and some people were initially confused because they indeed hadn't got used to the idea that nope, this is in fact the turn of the century - all that stuff you thought would happen in the 21st century? Well that's now.
Historians tend to talk about "long" versions of the centuries, e.g. European historians might have a "long 19th century" which ends when World War I breaks out in 1914 and begins with the French Revolution in 1789. The idea is that although calendars start and end arbitrarily, these "log" centuries are roughly 100 years but are bookended by substantial change to society.
I think there's an argument to be made that the "Long 20th century" didn't end until a few years back, historians doubtless have numerous events they'd focus on, Ukraine, Liz dying, financial crash... So it may still feel to some people like "last century" still means the 19th.
A different woman, somewhat more important than Liz Truss, but also with the given name Elizabeth. She was roughly the same age as my (dead) grandmother and they had roughly the same notional military job during WW2, driving a truck.
GP means Queen Elizabeth II, it's an annoying antimonarchist trope of being coy about the most obvious descriptors and using generics because 'they're just like the rest of us' etc.
I don't think I've ever been called "antimonarchist" before. I think a (constitutional) monarchy is a very good solution to a big real problem if it's available and so the UK is in an enviable position in this regard.
If we're talking about constructing structs, like in `Foo { bar, baz: 123 }` (with the `bar` style shortcut in it), I have used that kind of syntax 10 times in 16 KLOC of Rust. Not a lot, but it does happen, and I found it kinda neat when LSP integration suggested its use.
I've probably used it more for pattern matching (`let Foo { bar, baz } = ...`), but haven't measured the number of instances of that idiom.
I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.
So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).
OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.
reply