I hope you won't mind my picking your brain: which MPSC ring buffer implementations did you find that does drop old items when full? I could only found implementations that are basically re-purposed MPMC, or that cannot deal with non-POD data (seqlock-based).
Generally I find it's best to implement push operations as try_push operations and let the caller decide if they want to drop, or spin.
There are definitely designs that can deal with non-POD data of variable size, although that does imply heterogeneous types, which will need some sort of type erasure to destroy safely.
LOX is apparently MPL, so a bit easier to work with than Nyx' AGPL, but still at odd with the MIT/Apache2 combo that has become the norm in the Rust world.
Asynchronics | Rust developer | ONSITE or hybrid (2+days/week) | Full time | Warsaw, PL
We are a young startup building digital twinning solutions for spacecraft validation & verification.
The ideal candidate would have a demonstrated track record with Rust or possibly C++/Haskell/*ML, a passion for space and a background in physics or a related field of engineering.
I can see why someone would prefer Typst over LaTeX when the source is written in Typst or LaTeX, but what are the advantages if your source document is in Markdown? Is there anything else beyond the (presumably) smaller install size of Typst?
When compiling the Markdown to PDF, you might want to customize the PDF template. That's arguably easier and more pleasant to do with a Typst template than a Latex template. Also the compilation with Typst is often much faster.
Typst is 2-3 orders of magnitude faster than latex, which for book-sized projects can be the difference between a minute and sub-second compilation time.
Something I found useful is that you can create a much more minimal pandoc template for typst than for latex. Obviously if familiar with latex it probably won't be an issue, but when I tried to make my own barebones pandoc template (i.e., stripping out beamer) I gave up.
Not a solution.
Verification emails alone got a small web site I set up to be blacklisted within days. Most of the unwilling recipients presumably couldn't understand the language the verification email was written in and reported it as spam.
AtomicWaker is much less bad, because it will only spin in the case that another thread has spuriously called `wake` – i.e. called `wake` despite that fact that the future it’s waking is in fact unable to progress.
In the common case, the waker side will operate some logic like:
set_flag();
atomic_waker.wake();
and the future will run:
atomic_waker.register(cx.waker());
if flag_is_set() {
Poll::Ready(())
} else {
Poll::Pending
}
Thus, even if `register` decides to “spin”, the flag will already be set, and so the future will not spin in reality (it may be polled unnecessarily, but this will only happen once).
I can’t immediately think of examples where support for spurious waking is necessary.
The producers of an MPSC queue may use an AtomicWaker::wake to signal to the consumer that a new item is ready. In this case all wake-ups are necessary (not spurious).
I needed to reflect Rust enums and went a bit further with that approach. All variants are wrapped in a decorated class, where the decorator automatically computes the union type and adds de/serialization hooks for `cattrs`.
@enumclass
class MyEnum:
class UnitLikeVariant(Variant0Arg): ...
class TupleLikeVariant(Variant2Arg[int, str]): ...
@dataclass
class StructLikeVariant:
foo: float
bar: int
# The following class variable is automatically generated:
#
# type = UnitLikeVariant | TupleLikeVariant | StructLikeVariant
TBH I consider the C++ `std::chrono` as the worse possible design.
`tai_clock::now` does not actually take into account leap seconds. Unless it does, who knows ("Implementations may use a more accurate value of TAI time.").
Likewise, `tai_clock::from_utc/to_utc` does not correct for leap second. It just translates the UTC epoch to the TAI 1958 epoch.
I found Hifitime to be very opinionated and give a false sense of security due to its automatic computation of leap seconds based on historical tables. Yes, leap seconds are announced some ~6 month in advance, but what if you don't update regularly the library? Or if you can't because it is deployed on an embedded system?
In the end I wrote my own minimalistic TAI timestamp library [1] and made the conscious decision to let the user take the responsibility to deal with leap seconds in UTC conversion.
