Battle plan for Rust and Ruby
π(5) | Allπ 2023-06-26 05:03:34 -0700
β²οΈπ2023-06-23 08:36:32 -0700 | βοΈthe-field-testers | π·οΈ[rust] [ruby] [long-term] [LineDB] [Selenite] [Selenite/rust] [Selenite/ruby]
(πͺ)
π₯οΈ...β¨οΈ
It has become known that its not as easy as I think to convert Ruby code over to Rust, mostly because the AI in question doesn't fully understand the code, or conflates it with existing libraries ala Google Bard.
Since `emerald`, a Ruby interpreter is written in rust, I can make a great effort to have my partitioned array and linedb code lie in a compiled emerald binary that runs in the background on localhost, and rust sends get and post requests to store and pull data (from the LineDB database).
The new database will be called Selenite, and it will be a library that has code written in it, `artichoke`, which interacts with Rust via GET/POST requests and returns all data in a relevant JSON parser format.
Artichoke, the Ruby interpreter written in Rust: Midscore-IO/artichoke: π Artichoke is a Ruby made with Rust (github.com)
The plan is to have the Selenite/ruby database fully implemented as a stand alone server that works in any kind of ruby environment, and the Selenite/rust server interacts with Selenite/ruby.
We are still trying to figure out how to implement the data structure in Rust that interacts with the artichoke ruby Selenite server.
Also, I don't want to think of it as procrastination in the sense that I really do not want to port this code to Rust at the moment; if I get it fashioned into servers that send GET/POST requests between each other and i/o the corresponding json, I may not have much of a problem.
[Selenite/ruby] < i/o > [Selenite/rust]
But how will i/o work?
It will possibly work by rust having a certain data structure setup that can hold a json response and auto-parse to the array form
I want to keep on thinking about this further, and I really need a concrete battle plan with how I am going to tackle the problem of Rust's data structure that holds entries from the partitioned array, but it seems that at least implementing the basic partitioned array logic in rust and working from there will be the long-term solution.
UPDATE: I have looked around a bit more, and found
magnus::embed::ruby_script
Magnus is basically a standard library in rust, implemented to interact with any aspects of Ruby, and it is the inherent solution (also because its in the standard library)
With all that in mind, the idea is to simply use magnus to implement ruby's partitioned array functions, making keenly aware that magnus::embed::ruby_script has a few nuances, as does this entire operation because working with any kind of Ruby code is labeled in general as unsafe--imagine trying to get an AI to successfully port all of this.
HOWEVER, I also have come up with some source code which clarifies the require method: main.rs - source (docs.rs)
See render: https://thefieldtesters.net/blog/render/?id=5&user=the-field-testers
# SOURCE: https://docs.rs/magnus/latest/src/embed/main.rs.html#9
use magnus::{class, embed, prelude::*, require, Value};
mod word_sink;
mod word_source;
// run with `echo foo bar baz | cargo run --example embed`
fn main() {
// start Ruby
let _cleanup = unsafe { embed::init() };
// effectivly `require`ing these modules, loading the classes in Ruby
word_source::init().unwrap();
word_sink::init().unwrap();
// require our Ruby code
// this example uses a relative path from the working directory
require("./examples/embed/transform").unwrap();
// get the class defined in Ruby and call a method on it
class::object()
.const_get::<_, Value>("Transform")
.unwrap()
.funcall::<_, _, Value>("run", ())
.unwrap();
}