<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in serialize.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>9ce3ffe1 - Update some CI dependencies (#7983)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#9ce3ffe1</link>
        <description>Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Thu, 22 Feb 2024 23:54:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b0939f66 - Remove explicit `S` type parameters (#5275)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#b0939f66</link>
        <description>Remove explicit `S` type parameters (#5275)* Remove explicit `S` type parametersThis commit removes the explicit `S` type parameter on `Func::typed` and`Instance::get_typed_func`. Historical versions of Rust required thatthis be a type parameter but recent rustcs support a mixture of explicittype parameters and `impl Trait`. This removes, at callsites, asuperfluous `, _` argument which otherwise never needs specification.* Fix mdbook examples

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Wed, 16 Nov 2022 05:04:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>7a1b7cdf - Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#7a1b7cdf</link>
        <description>Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)Implement Wasmtime&apos;s new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it&apos;s best to read the RFC thread and the PR thread.

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Thu, 03 Jun 2021 14:10:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>8384f3a3 - Bring back `Module::deserialize` (#2858)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#8384f3a3</link>
        <description>Bring back `Module::deserialize` (#2858)* Bring back `Module::deserialize`I thought I was being clever suggesting that `Module::deserialize` wasremoved from #2791 by funneling all module constructors into`Module::new`. As our studious fuzzers have found, though, this meansthat `Module::new` is not safe currently to pass arbitrary user-definedinput into. Now one might pretty reasonable expect to be able to dothat, however, being a WebAssembly engine and all. This PR as a resultseparates the `deserialize` part of `Module::new` back into`Module::deserialize`.This means that binary blobs created with `Module::serialize` and`Engine::precompile_module` will need to be passed to`Module::deserialize` to &quot;rehydrate&quot; them back into a `Module`. Thisrestores the property that it should be safe to pass arbitrary input to`Module::new` since it&apos;s always expected to be a wasm module. This alsomeans that fuzzing will no longer attempt to fuzz `Module::deserialize`which isn&apos;t something we want to do anyway.* Fix an example* Mark `Module::deserialize` as `unsafe`

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Tue, 27 Apr 2021 15:55:12 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>d1313b12 - Code review feedback.</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#d1313b12</link>
        <description>Code review feedback.* Move `Module::compile` to `Engine::precompile_module`.* Remove `Module::deserialize` method.* Make `Module::serialize` the same format as `Engine::precompile_module`.* Make `Engine::precompile_module` return a `Vec&lt;u8&gt;`.* Move the remaining serialization-related code to `serialization.rs`.

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Thu, 01 Apr 2021 06:46:30 +0000</pubDate>
        <dc:creator>Peter Huene &lt;peter@huene.dev&gt;</dc:creator>
    </item>
<item>
        <title>2697a18d - Redo the statically typed `Func` API (#2719)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#2697a18d</link>
        <description>Redo the statically typed `Func` API (#2719)* Redo the statically typed `Func` APIThis commit reimplements the `Func` API with respect to statically typeddispatch. Previously `Func` had a `getN` and `getN_async` family ofmethods which were implemented for 0 to 16 parameters. The return valueof these functions was an `impl Fn(..)` closure with the appropriateparameters and return values.There are a number of downsides with this approach that have becomeapparent over time:* The addition of `*_async` doubled the API surface area (which is quite  large here due to one-method-per-number-of-parameters).* The [documentation of `Func`][old-docs] are quite verbose and feel  &quot;polluted&quot; with all these getters, making it harder to understand the  other methods that can be used to interact with a `Func`.* These methods unconditionally pay the cost of returning an owned `impl  Fn` with a `&apos;static` lifetime. While cheap, this is still paying the  cost for cloning the `Store` effectively and moving data into the  closed-over environment.* Storage of the return value into a struct, for example, always  requires `Box`-ing the returned closure since it otherwise cannot be  named.* Recently I had the desire to implement an &quot;unchecked&quot; path for  invoking wasm where you unsafely assert the type signature of a wasm  function. Doing this with today&apos;s scheme would require doubling  (again) the API surface area for both async and synchronous calls,  further polluting the documentation.The main benefit of the previous scheme is that by returning a `impl Fn`it was quite easy and ergonomic to actually invoke the function. Inpractice, though, examples would often have something akin to`.get0::&lt;()&gt;()?()?` which is a lot of things to interpret all at once.Note that `get0` means &quot;0 parameters&quot; yet a type parameter is passed.There&apos;s also a double function invocation which looks like a lot ofcharacters all lined up in a row.Overall, I think that the previous design is starting to show too manycracks and deserves a rewrite. This commit is that rewrite.The new design in this commit is to delete the `getN{,_async}` family offunctions and instead have a new API:    impl Func {        fn typed&lt;P, R&gt;(&amp;self) -&gt; Result&lt;&amp;Typed&lt;P, R&gt;&gt;;    }    impl Typed&lt;P, R&gt; {        fn call(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;        async fn call_async(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;    }This should entirely replace the current scheme, albeit by slightlylosing ergonomics use cases. The idea behind the API is that theexistence of `Typed&lt;P, R&gt;` is a &quot;proof&quot; that the underlying functiontakes `P` and returns `R`. The `Func::typed` method peforms a runtimetype-check to ensure that types all match up, and if successful you geta `Typed` value. Otherwise an error is returned.Once you have a `Typed` then, like `Func`, you can either `call` or`call_async`. The difference with a `Typed`, however, is that theparams/results are statically known and hence these calls can be muchmore efficient.This is a much smaller API surface area from before and should greatlysimplify the `Func` documentation. There&apos;s still a problem where`Func::wrapN_async` produces a lot of functions to document, but that&apos;snow the sole offender. It&apos;s a nice benefit that thestatically-typed-async verisons are now expressed with an `async`function rather than a function-returning-a-future which makes it bothmore efficient and easier to understand.The type `P` and `R` are intended to either be bare types (e.g. `i32`)or tuples of any length (including 0). At this time `R` is only allowedto be `()` or a bare `i32`-style type because multi-value is notsupported with a native ABI (yet). The `P`, however, can be any size oftuples of parameters. This is also where some ergonomics are lostbecause instead of `f(1, 2)` you now have to write `f.call((1, 2))`(note the double-parens). Similarly `f()` becomes `f.call(())`.Overall I feel that this is a better tradeoff than before. While notuniversally better due to the loss in ergonomics I feel that this designis much more flexible in terms of what you can do with the return valueand also understanding the API surface area (just less to take in).[old-docs]: https://docs.rs/wasmtime/0.24.0/wasmtime/struct.Func.html#method.get0* Rename Typed to TypedFunc* Implement multi-value returns through `Func::typed`* Fix examples in docs* Fix some more errors* More test fixes* Rebasing and adding `get_typed_func`* Updating tests* Fix typo* More doc tweaks* Tweak visibility on `Func::invoke`* Fix tests again

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Thu, 11 Mar 2021 20:43:34 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>399ee0a5 - Serialize and deserialize compilation artifacts. (#2020)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/serialize.rs#399ee0a5</link>
        <description>Serialize and deserialize compilation artifacts. (#2020)* Serialize and deserialize Module* Use bincode to serialize* Add wasm_module_serialize; docs* Simple tests

            List of files:
            /wasmtime-44.0.1/examples/serialize.rs</description>
        <pubDate>Tue, 21 Jul 2020 20:05:50 +0000</pubDate>
        <dc:creator>Yury Delendik &lt;ydelendik@mozilla.com&gt;</dc:creator>
    </item>
</channel>
</rss>
