diff options
Diffstat (limited to 'plugins/af_readability/vendor/fivefilters/readability.php/test/test-pages/v8-blog/source.html')
| -rw-r--r-- | plugins/af_readability/vendor/fivefilters/readability.php/test/test-pages/v8-blog/source.html | 259 |
1 files changed, 0 insertions, 259 deletions
diff --git a/plugins/af_readability/vendor/fivefilters/readability.php/test/test-pages/v8-blog/source.html b/plugins/af_readability/vendor/fivefilters/readability.php/test/test-pages/v8-blog/source.html deleted file mode 100644 index 4a23d093f..000000000 --- a/plugins/af_readability/vendor/fivefilters/readability.php/test/test-pages/v8-blog/source.html +++ /dev/null @@ -1,259 +0,0 @@ -<!DOCTYPE html> -<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> - <head> - <meta charset="utf-8" /> - <title> - Outside the web: standalone WebAssembly binaries using Emscripten · V8 - </title> - <meta content="width=device-width,initial-scale=1" name="viewport" /> - <meta content="dark light" name="color-scheme" /> - <link href="/_css/main.css" rel="stylesheet" /> - <link href="/.webmanifest" rel="manifest" /> - <meta content="#4285F4" name="theme-color" /> - <link href="/blog.atom" rel="alternate" title="V8 Atom feed" type="application/atom+xml" /> - <link href="/features.atom" rel="alternate" title="V8 JS/Wasm features Atom feed" type="application/atom+xml" /> - <script> - <![CDATA[ - document.documentElement.className+=' js' - ]]> - </script> - <meta content="Emscripten now supports standalone Wasm files, which do not need JavaScript." name="description" /> - </head> - <body> - <header id="header"> - <h1> - <a href="/">V8</a> - </h1><a href="#navigation-toggle" id="nav-toggle">Show navigation</a> - <nav> - <ul> - <li> - <a href="/">Home</a> - </li> - <li class="current"> - <a href="/blog">Blog</a> - </li> - <li> - <a href="/docs">Docs</a> - </li> - <li> - <a href="/features" title="JavaScript and WebAssembly language features">JS/Wasm features</a> - </li> - <li> - <a href="/grant">Research</a> - </li> - </ul> - </nav> - </header> - <main id="main"> - <article itemscope="itemscope" itemtype="http://schema.org/BlogPosting"> - <header> - <h1 itemprop="headline"> - Outside the web: standalone WebAssembly binaries using Emscripten - </h1> - <p class="meta"> - Published <time datetime="2019-11-21" itemprop="datePublished">21 November 2019</time> · Tagged with <a href="/blog/tags/webassembly" class="tag">WebAssembly</a> <a href="/blog/tags/tooling" class="tag">tooling</a> - </p> - </header> - <div itemprop="articleBody"> - <p> - Emscripten has always focused first and foremost on compiling to the Web and other JavaScript environments like Node.js. But as WebAssembly starts to be used <em>without</em> JavaScript, new use cases are appearing, and so we've been working on support for emitting <a href="https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone"><strong>standalone Wasm</strong></a> files from Emscripten, that do not depend on the Emscripten JS runtime! This post explains why that's interesting. - </p> - <h2 id="using-standalone-mode-in-emscripten"> - Using standalone mode in Emscripten <a href="#using-standalone-mode-in-emscripten" class="bookmark">#</a> - </h2> - <p> - First, let's see what you can do with this new feature! Similar to <a href="https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-javascript-code-sizes-in-emscripten/">this post</a> let's start with a "hello world" type program that exports a single function that adds two numbers: - </p> - <pre class="language-c"><code class="language-c"><span class="token comment">// add.c</span><br /><span class="token macro property"><span class="token directive-hash">#</span><span class="token keyword directive">include</span> <span class="token string"><emscripten.h></span></span><br /><br />EMSCRIPTEN_KEEPALIVE<br /><span class="token keyword">int</span> <span class="token function">add</span><span class="token punctuation">(</span><span class="token keyword">int</span> x<span class="token punctuation">,</span> <span class="token keyword">int</span> y<span class="token punctuation">)</span> <span class="token punctuation">{</span><br /> <span class="token keyword">return</span> x <span class="token operator">+</span> y<span class="token punctuation">;</span><br /><span class="token punctuation">}</span></code></pre> - <p> - We'd normally build this with something like <code>emcc -O3 add.c -o add.js</code> which would emit <code>add.js</code> and <code>add.wasm</code>. Instead, let's ask <code>emcc</code> to only emit Wasm: - </p> - <pre><code>emcc -O3 add.c -o add.wasm -</code></pre> - <p> - When <code>emcc</code> sees we only want Wasm then it makes it "standalone" - a Wasm file that can run by itself as much as possible, without any JavaScript runtime code from Emscripten. - </p> - <p> - Disassembling it, it's very minimal - just 87 bytes! It contains the obvious <code>add</code> function - </p> - <pre class="language-lisp"><code class="language-lisp"><span class="token punctuation">(</span><span class="token car">func</span> $add <span class="token punctuation">(</span><span class="token car">param</span> $0 i32<span class="token punctuation">)</span> <span class="token punctuation">(</span><span class="token car">param</span> $1 i32<span class="token punctuation">)</span> <span class="token punctuation">(</span><span class="token car">result</span> i32<span class="token punctuation">)</span><br /> <span class="token punctuation">(</span><span class="token car">i32</span>.add<br /> <span class="token punctuation">(</span><span class="token car">local</span>.get $0<span class="token punctuation">)</span><br /> <span class="token punctuation">(</span><span class="token car">local</span>.get $1<span class="token punctuation">)</span><br /> <span class="token punctuation">)</span><br /><span class="token punctuation">)</span></code></pre> - <p> - and one more function, <code>_start</code>, - </p> - <pre class="language-lisp"><code class="language-lisp"><span class="token punctuation">(</span><span class="token car">func</span> $_start<br /> <span class="token punctuation">(</span><span class="token car">nop</span><span class="token punctuation">)</span><br /><span class="token punctuation">)</span></code></pre> - <p> - <code>_start</code> is part of the <a href="https://github.com/WebAssembly/WASI">WASI</a> spec, and Emscripten's standalone mode emits it so that we can run in WASI runtimes. (Normally <code>_start</code> would do global initialization, but here we just don't need any so it's empty.) - </p> - <h3 id="write-your-own-javascript-loader"> - Write your own JavaScript loader <a href="#write-your-own-javascript-loader" class="bookmark">#</a> - </h3> - <p> - One nice thing about a standalone Wasm file like this is that you can write custom JavaScript to load and run it, which can be very minimal depending on your use case. For example, we can do this in Node.js: - </p> - <pre class="language-js"><code class="language-js"><span class="token comment">// load-add.js</span><br /><span class="token keyword">const</span> binary <span class="token operator">=</span> <span class="token function">require</span><span class="token punctuation">(</span><span class="token string">'fs'</span><span class="token punctuation">)</span><span class="token punctuation">.</span><span class="token function">readFileSync</span><span class="token punctuation">(</span><span class="token string">'add.wasm'</span><span class="token punctuation">)</span><span class="token punctuation">;</span><br /><br />WebAssembly<span class="token punctuation">.</span><span class="token function">instantiate</span><span class="token punctuation">(</span>binary<span class="token punctuation">)</span><span class="token punctuation">.</span><span class="token function">then</span><span class="token punctuation">(</span><span class="token punctuation">(</span><span class="token parameter"><span class="token punctuation">{</span> instance <span class="token punctuation">}</span></span><span class="token punctuation">)</span> <span class="token operator">=></span> <span class="token punctuation">{</span><br /> console<span class="token punctuation">.</span><span class="token function">log</span><span class="token punctuation">(</span>instance<span class="token punctuation">.</span>exports<span class="token punctuation">.</span><span class="token function">add</span><span class="token punctuation">(</span><span class="token number">40</span><span class="token punctuation">,</span> <span class="token number">2</span><span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">;</span><br /><span class="token punctuation">}</span><span class="token punctuation">)</span><span class="token punctuation">;</span></code></pre> - <p> - Just 4 lines! Running that prints <code>42</code> as expected. Note that while this example is very simplistic, there are cases where you simply don't need much JavaScript, and may be able to do better than Emscripten's default JavaScript runtime (which supports a bunch of environments and options). A real-world example of that is in <a href="https://github.com/zeux/meshoptimizer/blob/bdc3006532dd29b03d83dc819e5fa7683815b88e/js/meshopt_decoder.js">zeux's meshoptimizer</a> - just 57 lines, including memory management, growth, etc.! - </p> - <h3 id="running-in-wasm-runtimes"> - Running in Wasm runtimes <a href="#running-in-wasm-runtimes" class="bookmark">#</a> - </h3> - <p> - Another nice thing about standalone Wasm files is that you can run them in Wasm runtimes like <a href="https://wasmer.io">wasmer</a>, <a href="https://github.com/bytecodealliance/wasmtime">wasmtime</a>, or <a href="https://github.com/WAVM/WAVM">WAVM</a>. For example, consider this hello world: - </p> - <pre class="language-cpp"><code class="language-cpp"><span class="token comment">// hello.cpp</span><br /><span class="token macro property"><span class="token directive-hash">#</span><span class="token keyword directive">include</span> <span class="token string"><stdio.h></span></span><br /><br /><span class="token keyword">int</span> <span class="token function">main</span><span class="token punctuation">(</span><span class="token punctuation">)</span> <span class="token punctuation">{</span><br /> <span class="token function">printf</span><span class="token punctuation">(</span><span class="token string">"hello, world!\n"</span><span class="token punctuation">)</span><span class="token punctuation">;</span><br /> <span class="token keyword">return</span> <span class="token number">0</span><span class="token punctuation">;</span><br /><span class="token punctuation">}</span></code></pre> - <p> - We can build and run that in any of those runtimes: - </p> - <pre class="language-bash"><code class="language-bash">$ emcc hello.cpp -O3 -o hello.wasm<br />$ wasmer run hello.wasm<br />hello, world<span class="token operator">!</span><br />$ wasmtime hello.wasm<br />hello, world<span class="token operator">!</span><br />$ wavm run hello.wasm<br />hello, world<span class="token operator">!</span></code></pre> - <p> - Emscripten uses WASI APIs as much as possible, so programs like this end up using 100% WASI and can run in WASI-supporting runtimes (see notes later on what programs require more than WASI). - </p> - <h3 id="building-wasm-plugins"> - Building Wasm plugins <a href="#building-wasm-plugins" class="bookmark">#</a> - </h3> - <p> - Aside from the Web and the server, an exciting area for Wasm is <strong>plugins</strong>. For example, an image editor might have Wasm plugins that can perform filters and other operations on the image. For that type of use case you want a standalone Wasm binary, just like in the examples so far, but where it also has a proper API for the embedding application. - </p> - <p> - Plugins are sometimes related to dynamic libraries, as dynamic libraries are one way to implement them. Emscripten has support for dynamic libraries with the <a href="https://github.com/emscripten-core/emscripten/wiki/Linking#general-dynamic-linking">SIDE_MODULE</a> option, and this has been a way to build Wasm plugins. The new standalone Wasm option described here is an improvement on that in several ways: First, a dynamic library has relocatable memory, which adds overhead if you don’t need it (and you don’t if you aren’t linking the Wasm with another Wasm after loading it). Second, standalone output is designed to run in Wasm runtimes as well, as mentioned earlier. - </p> - <p> - Okay, so far so good: Emscripten can either emit JavaScript + WebAssembly as it always did, and now it can also emit just WebAssembly by itself, which lets you run it in places that don't have JavaScript like Wasm runtimes, or you can write your own custom JavaScript loader code, etc. Now let's talk about the background and the technical details! - </p> - <h2 id="webassembly's-two-standard-apis"> - WebAssembly's two standard APIs <a href="#webassembly's-two-standard-apis" class="bookmark">#</a> - </h2> - <p> - WebAssembly can only access the APIs it receives as imports - the core Wasm spec has no concrete API details. Given the current trajectory of Wasm, it looks like there will be 3 main categories of APIs that people import and use: - </p> - <ul> - <li> - <strong>Web APIs</strong>: This is what Wasm programs use on the Web, which are the existing standardized APIs that JavaScript can use too. Currently these are called indirectly, through JS glue code, but in the future with <a href="https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md">interface types</a> they will be called directly. - </li> - <li> - <strong>WASI APIs</strong>: WASI focuses on standardizing APIs for Wasm on the server. - </li> - <li> - <strong>Other APIs</strong>: Various custom embeddings will define their own application-specific APIs. For example, we gave the example earlier of an image editor with Wasm plugins that implement an API to do visual effects. Note that a plugin might also have access to “system” APIs, like a native dynamic library would, or it might be very sandboxed and have no imports at all (if the embedding just calls its methods). - </li> - </ul> - <p> - WebAssembly is in the interesting position of having <a href="https://www.goodreads.com/quotes/589703-the-good-thing-about-standards-is-that-there-are-so">two standardized sets of APIs</a>. This does makes sense in that one is for the Web and one for the server, and those environments do have different requirements; for similar reasons Node.js does not have identical APIs to JavaScript on the Web. - </p> - <p> - However, there is more than the Web and the server, in particular there are also Wasm plugins. For one thing, plugins can run inside an application that may be on the Web (just like <a href="https://www.figma.com/blog/an-update-on-plugin-security/#a-technology-change">JS plugins</a>) or off the Web; for another, regardless of where the embedding application is, a plugin environment is not a Web nor a server environment. So it's not immediately obvious which sets of APIs will be used - it may depend on the code being ported, the Wasm runtime being embedded, etc. - </p> - <h2 id="let's-unify-as-much-as-possible"> - Let's unify as much as possible <a href="#let's-unify-as-much-as-possible" class="bookmark">#</a> - </h2> - <p> - One concrete way Emscripten hopes to help here is that by using WASI APIs as much as possible we can avoid <strong>unnecessary</strong> API differences. As mentioned earlier, on the Web Emscripten code accesses Web APIs indirectly, through JavaScript, so where that JavaScript API could look like WASI, we'd be removing an unnecessary API difference, and that same binary can also run on the server. In other words, if Wasm wants to log some info, it needs to call into JS, something like this: - </p> - <pre class="language-js"><code class="language-js"><span class="token parameter">wasm</span> <span class="token operator">=></span> <span class="token keyword">function</span> <span class="token function">musl_writev</span><span class="token punctuation">(</span><span class="token parameter"><span class="token punctuation">.</span><span class="token punctuation">.</span></span><span class="token punctuation">)</span> <span class="token punctuation">{</span> <span class="token punctuation">.</span><span class="token punctuation">.</span> console<span class="token punctuation">.</span><span class="token function">log</span><span class="token punctuation">(</span><span class="token punctuation">.</span><span class="token punctuation">.</span><span class="token punctuation">)</span> <span class="token punctuation">.</span><span class="token punctuation">.</span> <span class="token punctuation">}</span></code></pre> - <p> - <code>musl_writev</code> is an implementation of the Linux syscall interface that <a href="https://www.musl-libc.org">musl libc</a> uses to write data to a file descriptor, and that ends up calling <code>console.log</code> with the proper data. The Wasm module imports and calls that <code>musl_writev</code>, which defines an ABI between the JS and the Wasm. That ABI is arbitrary (and in fact Emscripten has changed its ABI over time to optimize it). If we replace that with an ABI that matches WASI, we can get this: - </p> - <pre class="language-js"><code class="language-js"><span class="token parameter">wasm</span> <span class="token operator">=></span> <span class="token keyword">function</span> <span class="token function">__wasi_fd_write</span><span class="token punctuation">(</span><span class="token parameter"><span class="token punctuation">.</span><span class="token punctuation">.</span></span><span class="token punctuation">)</span> <span class="token punctuation">{</span> <span class="token punctuation">.</span><span class="token punctuation">.</span> console<span class="token punctuation">.</span><span class="token function">log</span><span class="token punctuation">(</span><span class="token punctuation">.</span><span class="token punctuation">.</span><span class="token punctuation">)</span> <span class="token punctuation">.</span><span class="token punctuation">.</span> <span class="token punctuation">}</span></code></pre> - <p> - This isn't a big change, just requiring some refactoring of the ABI, and when running in a JS environment it doesn't matter much. But now the Wasm can run without the JS since that WASI API is recognized by WASI runtimes! That’s how the standalone Wasm examples from before work, just by refactoring Emscripten to use WASI APIs. - </p> - <p> - Another advantage of Emscripten using WASI APIs is that we can help the WASI spec by finding real-world issues. For example, we found that <a href="https://github.com/WebAssembly/WASI/pull/106">changing the WASI "whence" constants</a> would be useful, and we've started some discussions around <a href="https://github.com/WebAssembly/WASI/issues/109">code size</a> and <a href="https://github.com/WebAssembly/WASI/issues/122">POSIX compatibility</a>. - </p> - <p> - Emscripten using WASI as much as possible is also useful in that it lets users use a single SDK to target Web, server, and plugin environments. Emscripten isn't the only SDK allowing that, as the WASI SDK's output can be run on the Web using the <a href="https://wasi.dev/polyfill/">WASI Web Polyfill</a> or Wasmer's <a href="https://github.com/wasmerio/wasmer-js">wasmer-js</a>, but Emscripten’s Web output is more compact, so it lets a single SDK be used without compromising Web performance. - </p> - <p> - Speaking of which, you can emit a standalone Wasm file from Emscripten with optional JS in a single command: - </p> - <pre><code>emcc -O3 add.c -o add.js -s STANDALONE_WASM -</code></pre> - <p> - That emits <code>add.js</code> and <code>add.wasm</code>. The Wasm file is standalone just like earlier when we only emitted a Wasm file by itself (<code>STANDALONE_WASM</code> was set automatically when we said <code>-o add.wasm</code>), but now in addition there is a JS file that can load and run it. The JS is useful for running it on the Web if you don't want to write your own JS for that. - </p> - <h2 id="do-we-need-non-standalone-wasm%3F"> - Do we need <em>non</em>-standalone Wasm? <a href="#do-we-need-non-standalone-wasm%3F" class="bookmark">#</a> - </h2> - <p> - Why does the <code>STANDALONE_WASM</code> flag exist? In theory Emscripten could always set <code>STANDALONE_WASM</code>, which would be simpler. But standalone Wasm files can't depend on JS, and that has some downsides: - </p> - <ul> - <li>We can't minify the Wasm import and export names, as the minification only works if both sides agree, the Wasm and what loads it. - </li> - <li>Normally we create the Wasm Memory in JS so that JS can start to use it during startup, which lets us do work in parallel. But in standalone Wasm we have to create the Memory in the Wasm. - </li> - <li>Some APIs are just easy to do in JS. For example <a href="https://github.com/emscripten-core/emscripten/pull/9558"><code>__assert_fail</code></a>, which is called when a C assertion fails, is normally <a href="https://github.com/emscripten-core/emscripten/blob/2b42a35f61f9a16600c78023391d8033740a019f/src/library.js#L1235">implemented in JS</a>. It takes just a single line, and even if you include the JS functions it calls, the total code size is quite small. On the other hand, in a standalone build we can't depend on JS, so we use <a href="https://github.com/emscripten-core/emscripten/blob/b8896d18f2163dbf2fa173694eeac71f6c90b68c/system/lib/libc/musl/src/exit/assert.c#L4">musl's <code>assert.c</code></a>. That uses <code>fprintf</code>, which means it ends up pulling in a bunch of C <code>stdio</code> support, including things with indirect calls that make it hard to remove unused functions. Overall, there are many such details that end up making a difference in total code size. - </li> - </ul> - <p> - If you want to run both on the Web and elsewhere, and you want 100% optimal code size and startup times, you should make two separate builds, one with <code>-s STANDALONE</code> and one without. That's very easy as it's just flipping one flag! - </p> - <h2 id="necessary-api-differences"> - Necessary API differences <a href="#necessary-api-differences" class="bookmark">#</a> - </h2> - <p> - We saw that Emscripten uses WASI APIs as much as possible to avoid <strong>unnecessary</strong> API differences. Are there any <strong>necessary</strong> ones? Sadly, yes - some WASI APIs require tradeoffs. For example: - </p> - <ul> - <li>WASI does not support various POSIX features, like <a href="https://github.com/WebAssembly/WASI/issues/122">user/group/world file permissions</a>, as a result of which you can't fully implement a (Linux) system <code>ls</code> for example (see details in that link). Emscripten's existing filesystem layer does support some of those things, so if we switched to WASI APIs for all filesystem operations then we'd be <a href="https://github.com/emscripten-core/emscripten/issues/9479#issuecomment-542815711">losing some POSIX support</a>. - </li> - <li>WASI's <code>path_open</code> <a href="https://github.com/WebAssembly/WASI/issues/109">has a cost in code size</a> because it forces extra permissions handling in the Wasm itself. That code is unnecessary on the Web. - </li> - <li>WASI doesn't provide a <a href="https://github.com/WebAssembly/WASI/issues/82">notification API for memory growth</a>, and as a result, JS runtimes must constantly check if memory grew and if so update their views, on every import and export. To avoid that overhead, Emscripten provides a notification API, <code>emscripten_notify_memory_growth</code>, which <a href="https://github.com/zeux/meshoptimizer/blob/bdc3006532dd29b03d83dc819e5fa7683815b88e/js/meshopt_decoder.js#L10">you can see implemented in a single line</a> in zeux's meshoptimizer that we mentioned earlier. - </li> - </ul> - <p> - In time WASI may add more POSIX support, a memory growth notification, etc. - WASI is still highly experimental and expected to change significantly. For now, to avoid regressions in Emscripten we do not emit 100% WASI binaries if you use certain features. In particular, opening files uses a POSIX method instead of WASI, which means that if you call <code>fopen</code> then the resulting Wasm file will not be 100% WASI - however, if all you do is use <code>printf</code>, which operates on the already-open <code>stdout</code>, then it will be 100% WASI, as in the "hello world" example we saw near the beginning, where Emscripten's output does run in WASI runtimes. - </p> - <p> - If it would be useful for users we can add a <code>PURE_WASI</code> option which would sacrifice code size in return for strict WASI compliance, but if that's not urgent (and most plugin use cases we’ve seen so far don’t need full file I/O) then maybe we can wait for WASI to improve to where Emscripten can remove these non-WASI APIs. That would be the best outcome, and we’re working towards that as you can see in the links above. - </p> - <p> - However, even if WASI does improve, there is no avoiding the fact that Wasm has two standardized APIs as mentioned earlier. In the future I expect Emscripten will call Web APIs directly using interface types, because that will be more compact than calling a WASI-looking JS API that then calls a Web API (as in the <code>musl_writev</code> example from before). We could have a polyfill or a translation layer of some sort to help here, but we wouldn't want to use it unnecessarily, so we will need separate builds for Web and WASI environments. (This is somewhat unfortunate; in theory this could have been avoided if WASI were a superset of Web APIs, but obviously that would have meant compromises on the server side.) - </p> - <h2 id="current-status"> - Current status <a href="#current-status" class="bookmark">#</a> - </h2> - <p> - Quite a lot works already! The main limitations are: - </p> - <ul> - <li> - <strong>WebAssembly limitations</strong>: Various features, like C++ exceptions, setjmp, and pthreads, depend on JavaScript due to Wasm limitations, and there is no good non-JS replacement yet. (Emscripten may start to support some of them <a href="https://www.youtube.com/watch?v=qQOP6jqZqf8&list=PLqh1Mztq_-N2OnEXkdtF5yymcihwqG57y&index=2&t=0s">using Asyncify</a>, or maybe we'll just wait for <a href="https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md">native Wasm features</a> to arrive to VMs.) - </li> - <li> - <strong>WASI limitations</strong>: Libraries and APIs like OpenGL and SDL don't have corresponding WASI APIs yet. - </li> - </ul> - <p> - You <strong>can</strong> still use all those in Emscripten's standalone mode, but the output will contain calls to JS runtime support code. As a result, it will not be 100% WASI (for similar reasons those features also do not work in the WASI SDK). Those Wasm files won't run in WASI runtimes, but you can use them on the Web and you can write your own JS runtime for them. You can also use them as plugins; for example, a game engine could have plugins that render using OpenGL, and the developer would compile them in standalone mode and then implement the OpenGL imports in the engine's Wasm runtime. Standalone Wasm mode still helps here because it makes the output as standalone as Emscripten can make it. - </p> - <p> - You may also find APIs that <strong>do</strong> have a non-JS replacement that we haven’t converted yet, as work is still ongoing. Please <a href="https://github.com/emscripten-core/emscripten/issues">file bugs</a>, and as always help is welcome! - </p> - </div> - <footer> - <div> - <picture><source srcset="/_img/avatars/alon-zakai.avif, /_img/avatars/[email protected] 2x" type="image/avif" /><img alt="" height="96" loading="lazy" src="/_img/avatars/alon-zakai.jpg" srcset="/_img/avatars/[email protected] 2x" width="96" /></picture> - <p> - Posted by Alon Zakai. - </p> - </div><a href="https://twitter.com/v8js/status/1197547645729988608" class="retweet">Retweet this article!</a> - </footer> - </article> - </main> - <footer id="footer"> - <div> - <nav> - <a href="/logo">Branding</a> · <a href="/terms">Terms</a> · <a href="https://policies.google.com/privacy">Privacy</a> · <a href="https://twitter.com/v8js" rel="me nofollow">Twitter</a> · <a href="https://github.com/v8/v8.dev/tree/main/./src/blog/emscripten-standalone-wasm.md" rel="nofollow">Edit this page on GitHub</a> - </nav> - </div> - <p> - <small>Except as otherwise noted, any code samples from the V8 project are licensed under <a href="https://chromium.googlesource.com/v8/v8.git/+/master/LICENSE">V8’s BSD-style license</a>. Other content on this page is licensed under <a href="https://creativecommons.org/licenses/by/3.0/">the Creative Commons Attribution 3.0 License</a>. For details, see <a href="/terms#site-policies">our site policies</a>.</small> - </p> - </footer> - <script src="/_js/dark-mode-toggle.mjs" type="module"></script> - <script src="/_js/main.mjs" type="module"></script> - <script src="/_js/legacy.js" nomodule=""></script> - </body> -</html> |