I've added a simple explanation right into the readme: "Essentially, you define your data structures and Baboon generates implementations for you. Then you define new versions, Baboon generates new versions of the structures, the conversions from old structure versions to new ones and forces your to provide conversions which cannot be derived automatically. Also it comes with extremely efficient tagless binary encoding for all your structures."
This thing can remove a lot of manual work and save your ass sometimes from the effects of incorrect migrations.
FWIW, even with the "simple explanation," I'll echo OP's statement that the README doesn't really explain what it is or what it's solving. "Generates new versions of the structures" might mean something really clear to you, but even the phrase "data modeling" is enough to trigger lots of conflicting baggage in my head. Also: it took awhile it realize it's for Scala. I initially assumed this was a Smithy-like competitor.
It looks neat (once I found your docs)! Show what it is and what it solves in your README! The structural inheritance is slick.
It's not for Scala. Currently there are Scala and C# backends, TypeScript and Python are on the way.
We did everything to make it easy to add new backends. As much as that can be considering the feature set.
> Smithy
Little bit different. Smithy is more an RPC tool. Baboon is not (or not yet), it allows you to model your data structures and derive conversions (migrations) between versions.
As someone who runs data analyses on experimental data, my first thought that this was a tool to automatically data munge, and perform analyses. My current impression it is a tool to convert database type information structures to new formats. None of these are probably correct.
The reference server is an Android app so yes, that is probably the point of the default design, but reading the README I believe you can also use a more traditional server-to-server setup:
DeltaChat/ArcaneChat Integration
DeltaChat and ArcaneChat are perfect companions for Tyr. These are messengers that use email protocols but provide modern chat interfaces. When you configure DeltaChat/ArcaneChat to use Tyr's local server:
1. DeltaChat/ArcaneChat sends messages via SMTP to Tyr
2. Tyr wraps them in Yggmail protocol and sends through Yggdrasil
3. The recipient's Tyr receives the message via Yggdrasil
4. Their DeltaChat/ArcaneChat fetches it via IMAP from their local Tyr
5. All this happens peer-to-peer, with no central servers
If you run Tyr on a VPS/RPi/old smartphone, you can still exchange messages decentralised this way, as long as your server and the device/server you're communicating to are both online, and have DeltaChat/ArcaneChat fetch the messages later.
Such a setup could be useful if you find people around you using Tyr and you're losing messages because your phone kills the app, though a PoC like this probably won't have much of a network effect.
openldk itself builds from source. It reads jar/class files and JIT-transpiles them to common lisp code, which is in turn compiled to native instructions. It does not read java source code at all. But you can run OpenJDK's javac with OpenLDK. You can write "native" methods in Common Lisp, extend Java classes with CLOS classes, use conditions/restarts, :before/:after/:around methods, dump images, etc. There's some ways to go still, but -- like I said -- javac just started working as a native lisp image executable, which was an important milestone.
I cannot bootstrap openjdk from ground zero, from pure source files without binaries. From what I know there is just one pathway to that, the Guix one, which starts from Jikes.
reply