Howdy all, I've been able to implement my own host functions and use wit-deps
to import them for use in a set of wasm guest functions. However, I'm trying to understand how to use wasi:logging in our embedding of wasmtime. I'm getting the classic:
called `Result::unwrap()` on an `Err` value: WasmRuntime(import `wasi:logging/logging` has the wrong type
Caused by:
0: instance export `log` has the wrong type
1: expected func found nothing
so I figured I'd need with
on the wasmtime bindgen and point to bindings for logging in the preview, and then add to the linker? But, I'm not sure what that is for logging? Any thoughts?
I also tried to impl it for my State/Context, but ran into lifetime errors (if that were the path). I've looked at Wasiclouds's impl, but figured that's more specific to their platform. Seemingly, there's no impl of the logging interface in preview tho. Anyhow, any related examples would help.
there is no implementation of wasi:logging provided by wasmtime-wasi, you'd need to write one
where are you getting the definition of wasi:logging?
@Pat Hickey yep, seeing this too https://github.com/bytecodealliance/ComponentizeJS/issues/6, i figured ok. I was pulling via wit-deps like so:
logging = "https://github.com/WebAssembly/wasi-logging/archive/main.tar.gz"
ah, that issue is pretty far out of date, before we had set aside wasi logging for stdout/stderr in favor of using a more posix-like stream representation defined in the wasi-cli package
i'd advise not using wasi-logging if you can avoid it
@Pat Hickey should i still use the interface to be "compatible" or just use my own variation anyhow?
since, afaik, there are no runtimes providing it, nor any client code thats using it
ah interesting.
oh, so if you are looking for some logging solution, and you were just going to define something just like wasi-logging on your own and provide both the host and client side
then sure, use wasi-logging as the definition of that interface if it suits your needs
but be aware that is forging new ground, you'll be essentially the first person to do so (since very early prototypes which we since set aside to take other paths, anyway)
@Pat Hickey yep. ok. yeah, i'll go that route. That was my first intention Let me try that again (that was my first route) and see if i don't run into issues.
@Pat Hickey haha. yep. no worries. Thanks for at least re-affirming my thoughts/etc. Having you and @Alex Crichton help out is awesome. thanks beyond thanks tbh.
sure thing, happy to help
ok, so the lifetime error I run into:
/// Basic helpers interface.
interface helpers {
record time {
seconds: u64,
milliseconds: u32,
nanoseconds: u32,
}
/// Get current time in sub-seconds.
get-current-time: func() -> time;
/// Basic `print` helper.
print: func(msg: string);
}
world imports {
import wasi:logging/logging;
import helpers;
}
is how i'm trying to bring in the current logging interface into my own embedding.
then:
impl wasi::logging::logging::Host for State {
/// Log a message.
fn log(
&mut self,
level: wasi::logging::logging::Level,
context: String,
message: String,
) -> wasmtime::Result<()> {
println!("{message}");
Ok(())
}
}
throws me
error[E0195]: lifetime parameters or bounds on method `log` do not match the trait declaration
--> homestar-wasm/src/wasmtime/host/helpers.rs:32:11
|
32 | fn log(
| ^ lifetimes do not match method in trait
|
::: homestar-wasm/src/wasmtime/world.rs:28:1
|
28 | / wasmtime::component::bindgen!({
29 | | world: "imports",
30 | | tracing: true,
31 | | async: true
32 | | });
| | -
| | |
| |__lifetimes in impl do not match this method in trait
| this bound might be missing in the impl```
so maybe how i'm using the import is wrong here?
the other implements work fine.
I would like to use the interface off deps this way without inlining it within my custom wit.
i expect that the wasmtime::component::bindgen! impl you are using with wasi-logging has async: true
turned on, and you need to decorate your impl with #[async_trait]
at the top and make it an async fn log
yeah, I think it errore'd w/ that as well, one sec.
ah yeah, nvm, dum, dum, that does work. @Pat Hickey :).Actually another issue crept up, but one for me to fix. Thank you.
Zeeshan Lakhani has marked this topic as resolved.
got it all working. thanks again @Pat Hickey (not sure what i missed adding async before tbh, but always updating code haha).
np that one is an uncharacteristic bad error message from rustc
Last updated: Nov 22 2024 at 16:03 UTC