HN user
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).
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.
Just curious, what kind of simulations do you work on (mission design?) and what libraries would you use in C++?
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.
Please apply at: https://www.linkedin.com/jobs/view/4129163803/ or email us at office@[company name].com
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?
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.
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).
Another offender is AtomicWaker [1] which does the same on contention.
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.
Oh yes, absolutely, GP got it backward and I went along with it...
While this doesn't change the essence of your claim, the problem is not with UTC timestamps but with Unix timestamps. UTC timestamps (HH:MM:SS) are actually unique because the extra second inserted is assigned the numeral 60. Unix timestamps do, however, repeat when a leap second is inserted.
I have always wondered about that.
If optimizing repeated atomic loads is indeed allowed, waiting for a signal by spinning on an atomic load could loop forever. Yet I have the feeling most people consider such code to be valid. Are they wrong?
While I have frequently seen LabView used for instrument/hardware control, I admit I have never seen people use Simulink for that purpose. Is there a popular Simulink/Matlab add-on for that?
Sabine Hossenfelder apparently does this [1, 2] for $50/20min.
[1] http://backreaction.blogspot.com/p/talk-to-physicist_27.html
[2] https://aeon.co/ideas/what-i-learned-as-a-hired-consultant-f...
One may count electric propulsion as a "better" propulsion system, but sadly it was a poor fit for Juice due to the very tight power budget.
Even with those gigantic solar arrays, energy management on Juice is extremely challenging. Once in the vicinity of Jupiter, the spacecraft will be powered by less than 4% of the solar flux it receives in earth orbit.
Not only is the instruction set simple, but the clock-per-instruction cost is deterministic, so assembly code is ideal for real-time I/O. Just like GP, we found that we could often use a PRU in place of an FPGA and dramatically cut development cost (this was for very small production series).
One use case for C is communication with the CPU (remoteproc stuff). We commonly had one PRU handle CPU communication with trivial C code while another PRU on the same PRU subsystem was coded with assembly to handle real-time I/O.
I you think the NASA Open Source License is bad, look at the default license for non-commercial, ESA-funded software [1].
The territorial limitations effectively prevents any form of open distribution, yet the license is open enough to remove most commercial incentive for maintenance and further development: a perfect recipe to make software instant abandonware upon release.
[1] https://essr.esa.int/license/european-space-agency-community...
As others wrote, Pandoc is Haskell so it compiles to a fairly efficient binary.
But more importantly, unlike the various Markdown flavors or AsciiDoc, it is incredibly extensible thanks to the combination of custom filters and the possibility to add HTML classes and attributes. One can write filters to leverage the class/attribute information and perform transformations at the AST level, which basically lets you define a DSL with an arbitrary number of custom elements.
I wrote a collection of filters for the publication of a large online legal playbook. Not only did Pandoc make it possible to introduce different kind of custom elements that don't exist in plain Markdown or AsciiDoc, but by using different filters it was possible to use a single Markdown source to generate both the book and various summaries such as a list of examples, a list of civil code clauses etc. I don't know Haskell that well so I used Rust for the filters, but that worked very well.
Pandoc is IMO a very underrated tool.
Two things can be true at the same time
Yes, but it is not possible to assert that both are true at the same time with full certainty.
You are right of course, but I would contend that generating as well sub-normal floats is in 99.9% of the cases a needless cost. The reason is that, more often than not, all this extra precision will be immediately lost in subsequent operations.
A very common situation is for instance to plug the random number in a log, in which case you need to use log(1-r) rather than log(r) to avoid an infinite at r=0. The problem is, by doing this simple subtraction you have already lost all the subnormal precision.
This is a widely used method to map random integers to floating point numbers, but it has the disadvantage of wasting 1 bit of float mantissa precision.
On modern CPUs, its computational advantage over full-precision mapping methods, such as multiplication by a float, is not always clear [1].
To be clear, as mentioned in another thread [0] there is no need to ensure consistency between head and tail for a SPSC so storing them in different cache lines would be much better.
For the multiple-consumer variant, however, consistency between head and tail is required so packing them in the same atomic is the simplest solution.
Note that the second variant does not claim to be MPMC, only SPMC.
Many lock-free structures use CAS loops. It would not be lock-free if a consumer pre-empted at the wrong time could prevent other consumers to make progress, but I don't think this is the case here.
The multiple-consumer version looks extremely similar, if not identical, to the Go [1] and Tokio [2] local work-stealing queues.
These do a bit more though, as they also allow batch stealing operations.
[1] https://github.com/golang/go/blob/master/src/runtime/proc.go...
[2] https://tokio.rs/blog/2019-10-scheduler#a-better-run-queue
Thanks for the video, flexure-based designs can be so beautiful.
It reminded me of a collaboration I had with a small Swiss company that did wonders with electro-discharge machining such as this flexure-based mechanism machined from a single block of aluminium: https://i.imgur.com/PDAVDmJ.jpg
More of a cutting edge CAD than a breakthrough CAD then?
Not a stupid question -- sorry for the jargon.
It is what is mentioned in this fragment of the article:
"When power flows into the EmDrive, the engine warms up. This also causes the fastening elements on the scale to warp, causing the scale to move to a new zero point"
Basically, thermal expansion of the thruster and the measurement device causes the rest position of the thrust balance to drift with time, which is hard to differentiate from the actual thrust generated. This is most critical when the thrust-to-weight ratio is low, as is the case here.
Just to be clear, for most anyone with low-thrust measurement experience, thermal drift had been suspect nr 1 from the moment Eagleworks published their work. Here is a comment I made back at that time:
https://news.ycombinator.com/item?id=12962579
But then, nobody had Tajmar's perseverance; kudos to his team!