Stream: git-wasmtime

Topic: wasmtime / PR #1363 Refactor the internals of `Func` to r...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 15:11):

alexcrichton opened PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 15:12):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 15:51):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 15:54):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 17:28):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:01):

sunfishcode submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:01):

sunfishcode submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:01):

sunfishcode created PR Review Comment:

Can this use .add instead of .offset with a cast?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:01):

sunfishcode created PR Review Comment:

While we're here, instead of casting to *mut u8, could we change the signature of wasmtime_call_trampoline to expect a *mut u128? And maybe we can also rename wasmtime_call_trampoline to just call_trampoline, since we're qualifiying it with the crate name here anyway.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:01):

sunfishcode created PR Review Comment:

We use u128 for values in a lot of places, Is there a reason to prefer i128 here?

Random idea, don't feel obliged to do this here, but we could also introduce a new type, like VMValue or so, which has the size and alignment of a u128, that we could use instead of u128 everywhere, to help document the intent.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:08):

alexcrichton submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:08):

alexcrichton created PR Review Comment:

Nah this was just carried over from the original implementation, I'll switch it all to u128

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:12):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 18:17):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 19:21):

alexcrichton updated PR #1363 from less-traits to master:

This commit simplifies Func and its API through a few avenues:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 19 2020 at 19:21):

alexcrichton merged PR #1363.


Last updated: Nov 22 2024 at 16:03 UTC