By no mean it is as nice looking as your demo, but it is interesting to ME... C++, compiled to WASM, using WebGL. Works on Firefox too. M4 decimation.
152 karma · joined February 19, 2019
By no mean it is as nice looking as your demo, but it is interesting to ME... C++, compiled to WASM, using WebGL. Works on Firefox too. M4 decimation.
The fact that the code was generated by a human or a machine is less and less important.
Funny enough, I am doing something very similar: a C++ portable (Windows, Linux MacOS) charting library, that also compile to WASM and runs in the browser...
I am still at day 2, so see you in 3 days, I guess!
- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.
- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.
- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.
Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.
https://github.com/BehaviorTree/BehaviorTree.CPP
This library is increasingly popular in robotics and automation, and I am very excited about the new features being introduced.
100% agree. I also agree that would be a minimum requirement to call it "high-performance".
This means that you can easily extend the number of interfaces and protocols adding new plugins, as shown in version 3.
But of course I am biased, as author of PlotJuggler ;)
Give it a try, it should be quite self explaining. If you have any issue, get in touch on Github Issues.
This means that you can develop proprietary (closed source) plugins to create your own custom interfaces to parse data, if you want/need to.
This is one of the key feature of PlotJuggler. They are called "layouts".