can you update the unimplemented functions and tauri commands / main to be async? The operations in kernel sidecar are all expecting to be async in tokio runtime at the moment
I've learned a few things here in terms of working with Tauri and Tokio. Tauri owns and initialized the Tokio runtime. If we need to own and initialize the Tokio runtime ourselves, like for making async calls before booting Tauri up, we can do that in the future. For now, this seems pretty clean.
Generic Changes
Explicitly set tokio as a dependency, with the full suite of features
Switch the notebooks mutex to a tokio Mutex, which feels more natural anyways
Convert all the functions in the Notebook structure to async. Some merely have this for the mutex lock
Create a tokio task when executing a cell. Since this is fake execution this is not necessarily the direction it needs to go. I just wanted end-to-end communication with the backend from the frontend.
App Changes
On page load, create a new notebook. Obviously, we'll need to later add a path for loading a notebook. For now, only new notebooks. This sets us up to be able to have multiple windows/documents too.
Changes I'm less familiar with (still learning)
Introduced anonymous lifetime for the app state to function parameters in the tauri commands. This was primarily guided by rustc and ChatGPT. While working on this PR, @kafonek gave feedback on the lifetimes and it helped me investigate if it could be simplified:
@kafonek: I haven't looked at Tauri directly much, are you stuck dealing with lifetimes in some of these #[tauri::command] functions? Avoid 'em if you can but I get it if you can't
@rgbkrk It looks like I can simplify the whole thing with an anonymous lifetime on the AppState. The other parameters come from JS so they're references to data that is passed from JS -> Rust when the command is invoked (and so are tied to the lifetime of the command invocation)
From Discord
I've learned a few things here in terms of working with Tauri and Tokio. Tauri owns and initialized the Tokio runtime. If we need to own and initialize the Tokio runtime ourselves, like for making async calls before booting Tauri up, we can do that in the future. For now, this seems pretty clean.
Generic Changes
tokioas a dependency, with the full suite of featurestokioMutex, which feels more natural anywaysNotebookstructure to async. Some merely have this for the mutex lockApp Changes
On page load, create a new notebook. Obviously, we'll need to later add a path for loading a notebook. For now, only new notebooks. This sets us up to be able to have multiple windows/documents too.
Changes I'm less familiar with (still learning)
Introduced anonymous lifetime for the app state to function parameters in the tauri commands. This was primarily guided by
rustcand ChatGPT. While working on this PR, @kafonek gave feedback on the lifetimes and it helped me investigate if it could be simplified: