abendstolz
But then think about the CEOs and their employees again.
We just need to invent something like money for an "AI" and then we can lead in on a stick ;-)
It's like human to dog years ;-)
Right?
I assume you wouldn't ship the whole plugin runtime for each plugin that wants to host another plugin?!
I manually compile a plugin and in my system I can "refresh" a plugin and even say "activate version 1.1 of the plugin" or "activate version 1.2" of the plugin etc.
But that's something I had to build myself and is not built into wasmtime itself.
match Plugin::instantiate_async(&mut store, &component, &linker).await {
Ok(plugin) => {
match plugin
.plugin_guest_oncallback()
.call_ontimedcallback(&mut store, &callback_name)
.await
{
Ok(()) => debug!("Successfully called oncallback for {plugin_path:?}"),
Err(e) => warn!("Failed to call oncallback for {plugin_path:?}: {e}"),
}
}
Err(e) => {
error!("Failed to call oncallback for {plugin_path:?}!: {e}");
}
}
If of course I put a wasm file in the plugin folder that doesn't adhere to that definition, that wasm file isn't considered a plugin.
But I prefer the wasmtime webassembly component model approach these days.
Built a plugin system with that, which has one major upside in my book:
No stringly function invocation.
Instead of run_function("my-function-with-typo") I have a instantiated_plugin.my_function call, where I can be sure that if the plugin has been instantiated, it does have that function.
I've never checked core before, so I did when checking up for this discussion.
I somehow missed Result. Silly me didn't search on that page, but ofc I found it on std
https://doc.rust-lang.org/std/result/index.html
Also thanks for clarifying that values of Result can be stack-only!
It never occurred to me (being in non-embedded land) that returning an enum as the error or a &'static str instead of a heap structure like String, could also fail.
Seeing that Result isn't part of core, but of std, this makes sense.
Just to tickle my nerve though: theoretically speaking, with your example, it would work, right?
I couldn't allocate 100GB (because OOM or not even enough RAM to begin with) but it could be that the system can allocate the needed memory for error message just fine.
Very interesting.
So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right?
If so, cool, thanks, you just made my day by tickling my learning nerves! :)
Naive me - not a kernel dev at all - would argue that returning Result<Memory, AllocationError> is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this.
Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it.
Note: I am not trying to be snarky here, I genuinely don't know and would like to.
If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!
Has some very weird constraints regarding borders when combining with the eurorail/interrail though.