Day 59 — The littlest Jupyter console in Rust!
01 November 2020 · recurse-center TweetToday I continued working on translating cutypr to Rust.
I was able to serialize and sign messages, and send them to the kernel, but the kernel kept saying that the message has an invalid signature :( I found it difficult to debug and check if the (message signature) bytes sent from Rust are the ones that Python expects because they both print different representations. To make it all work temporarily, I manually disabled auth on the "backend" by adding a self.auth = None
just before signatures are verified.
And the Rust client worked after that! You can check out the code here.
In [1]: import os
In [2]: print(os.getcwd())
"/home/vinayak/dev/jupyterm\n"
In [3]:
Now I need to fix message signing, and then slowly add more IPython things (nicer editing, terminal history, code completion, syntax highlighting)!
I also ran into this issue where the Rust compiler started saying "borrowed value does not live long enough" :(
I have defined an execution_state
variable just before the REPL starts. In the REPL, I send a message to the kernel, get one back as a serde Map
, and then update the execution_state
using the value from this Map
.
match msg_type {
"status" => {
execution_state = msg["content"]["execution_state"].as_str().unwrap();
}
...
The compilation failed with "borrowed value does not live long enough" because msg
is dropped at the end of the loop, which is its scope.
match msg_type {
"status" => {
let _execution_state = msg["content"]["execution_state"].as_str().unwrap();
match _execution_state {
"starting" => execution_state = "starting",
"idle" => execution_state = "idle",
"busy" => execution_state = "busy",
_ => {
panic!("Unknown execution state");
}
};
}
...
Changing the earlier code to this match
statement solved the issue because it meant I didn't have to move the value from msg
(which gets dropped at the end of the loop) to execution_state
. What would be a better way to do this?