libddwaf VS evcxr

Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove a couple of GNUisms.

For C++ we were faced with some issues, so the process we ended up with is:

- build musl, install it in some location

- inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use

- build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot

- build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in

- for a dynamic lib, remove dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++)

- for an executable binary instead of a lib, dynamic reference would instead need to be altered so that it works for both

It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software)

https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...

A project for Rust REPL environment is a combination of letter evxvr (Evaluation Context for Rust). It contains Evcxr Jupyter kernel. I chose to follow the documentation and compile Jupyter kernel from Rust sources (which takes about 6 min on my laptop), and simply run in Microsoft Windows PowerShell

Emacs didn't invent REPL, and it's common everywhere. For Rust: https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.m.... But heck, the compiler is reasonably fast enough that any IDE can REPL by compiling the code.

The value here is more in being able to read a script before you run it, then have it run fast, maybe tweaking something here and there. And a compiled script will run 10,000 times faster than LISP, which can be important.

https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.

The engine uses rust_decimal::Decimal to represent high precision decimal numbers, like the weight property. Serialization of RocksDB keys is done by the storekey crate. To know how Yumi's machine stores diffs, we can now ask- How does storekey serialize rust_decimal? Well, using evcxr to run Rust in Jupyter, the answer is as a null-terminated string:

In theory you should be able to create Rust notebooks (Jupyter notebook) using evcxr so maybe some AI, data analysis, prototyping make sense if you aim for good performance in final application (protype in evcxr and use notebook as reference to implement final application in Rust for speed and safety).

You should check out evcxr