WasmTime.Net: Access to Handle in Memory Class about wasmtime-dotnet HOT 10 CLOSED

I completed porting to WasmTime, please see https://github.com/christophwille/csharp-opa-wasm/tree/master/WasmTimeTest. It is much more readable thanks to DynamicObject (never cared to nicely hide the necessary magic in WasmerSharp). I think I'll port the NuGet that I create over to WasmTime too.

from wasmtime-dotnet.

CC @peterhuene

from wasmtime-dotnet.

ok, I traced the min exception to here:

https://github.com/bytecodealliance/wasmtime/blob/master/crates/misc/dotnet/src/Bindings/MemoryBinding.cs#L57

and yes, the wat shows (import "env" "memory" (memory $env.memory 2)) with a minimum of 2. This fixes the exception I reported. Just for clarification: providing more min memory than min requested is really a problem?

from wasmtime-dotnet.

Hi @christophwille. I think these restrictions in the .NET API should be relaxed so that the host doesn't have to specify exactly the same values.

By the way, the constructor to Memory expresses the minimum and maximums in page units, so this should do it:

EnvMemory = new Memory(2); // min page size = 2

from wasmtime-dotnet.

It also appears that the doc comment for the Memory constructor is missing param text too.

from wasmtime-dotnet.

Yes, thanks, the min page I figured out by reading the source code of WasmTime.Net.

from wasmtime-dotnet.

@christophwille that's awesome!

If there are other improvements you'd like to see regarding the Wasmtime .NET API, we're definitely open to suggestions and contributions!

from wasmtime-dotnet.

After that little memory snag, the only minor issue was the null-terminated strings; however, I already had the code for WasmerSharp, so this translated nicely to Memory.Span. I don't know how common those null-terminated strings are, but maybe having a ReadNullTerminatedString baked into Memory might be useful (but only if OPA isn't the only one out there doing it this way).

from wasmtime-dotnet.

ExternMemory.ReadNullTerminatedString was added after 0.12.0 (I think? I'd have to check) as well and would be included in the next release.

from wasmtime-dotnet.

This should now be fixed in 0.15.0 since it uses the new internal Wasmtime linker rather than implementing linker in the C# API. For future issues, we've created a new repro at https://github.com/bytecodealliance/wasmtime-dotnet.

from wasmtime-dotnet.