From ba5348e85ff9d86bba6eaeeed8001b3fa175157f Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Wed, 14 Feb 2024 21:04:08 +0700 Subject: [PATCH] site: Fix typos. --- docs/emcc.txt | 2 +- site/source/docs/api_reference/bind.h.rst | 4 ++-- site/source/docs/api_reference/console.h.rst | 2 +- site/source/docs/api_reference/emscripten.h.rst | 4 ++-- site/source/docs/api_reference/html5.h.rst | 2 +- site/source/docs/api_reference/module.rst | 2 +- .../configuring_emscripten_settings.rst | 2 +- site/source/docs/compiling/Building-Projects.rst | 4 ++-- site/source/docs/compiling/Deploying-Pages.rst | 4 ++-- site/source/docs/index.rst | 2 +- site/source/docs/introducing_emscripten/index.rst | 2 +- site/source/docs/porting/Debugging.rst | 2 +- .../docs/porting/connecting_cpp_and_javascript/embind.rst | 2 +- site/source/docs/porting/exceptions.rst | 2 +- .../porting/multimedia_and_graphics/OpenGL-support.rst | 2 +- site/source/docs/porting/setjmp-longjmp.rst | 2 +- site/source/docs/tools_reference/emcc.rst | 2 +- site/source/docs/tools_reference/settings_reference.rst | 8 ++++---- site/source/get_api_items.py | 2 +- src/settings.js | 8 ++++---- 20 files changed, 30 insertions(+), 30 deletions(-) diff --git a/docs/emcc.txt b/docs/emcc.txt index 1d2c7900000f..03e77bc8dd6c 100644 --- a/docs/emcc.txt +++ b/docs/emcc.txt @@ -98,7 +98,7 @@ Options that are modified or new in *emcc* are listed below: Note: - If no value is specifed it will default to "1". + If no value is specified it will default to "1". Note: diff --git a/site/source/docs/api_reference/bind.h.rst b/site/source/docs/api_reference/bind.h.rst index 7f6efdea9703..6660c7d36df7 100644 --- a/site/source/docs/api_reference/bind.h.rst +++ b/site/source/docs/api_reference/bind.h.rst @@ -454,7 +454,7 @@ Classes .. cpp:type:: type - This is a typdef to the parent struct typename parameter ``InputType``. + This is a typedef to the parent struct typename parameter ``InputType``. .. cpp:type:: constructor @@ -740,7 +740,7 @@ Classes template EMSCRIPTEN_ALWAYS_INLINE const class_& property(const char* fieldName, FieldType *field) const - :param const char* fieldNam + :param const char* fieldName :param FieldType ClassType\:\:\*field :returns: |class_-function-returns| diff --git a/site/source/docs/api_reference/console.h.rst b/site/source/docs/api_reference/console.h.rst index ecc27a452260..109d69ddf6cb 100644 --- a/site/source/docs/api_reference/console.h.rst +++ b/site/source/docs/api_reference/console.h.rst @@ -50,7 +50,7 @@ Functions Prints the string using the `dbg()` JS function, which by will write to the console (or stdout). Just like the `dbg()` JS function this symbol is - only avilable in debug builds (i.e. when linking with `-sASSERTIONS` or + only available in debug builds (i.e. when linking with `-sASSERTIONS` or equivelently `-O0`). :param utf8String: A string encoded as UTF-8. diff --git a/site/source/docs/api_reference/emscripten.h.rst b/site/source/docs/api_reference/emscripten.h.rst index 613564917ba7..a29edbc51785 100644 --- a/site/source/docs/api_reference/emscripten.h.rst +++ b/site/source/docs/api_reference/emscripten.h.rst @@ -778,7 +778,7 @@ Functions .. c:function:: void emscripten_dlopen(const char *filename, int flags, void* user_data, em_dlopen_callback onsuccess, em_arg_callback_func onerror); - Starts and asyncronous dlopen operation to load a shared library from a + Starts an asynchronous dlopen operation to load a shared library from a filename or URL. Returns immediately and requires the caller to return to the event loop. The ``onsuccess`` and ``onerror`` callbacks are used to signal success or failure of the request. Upon ``onerror`` callback the normal @@ -1048,7 +1048,7 @@ Defines .. c:macro:: EM_LOG_ERROR - If specified, prints an error message (combined with :c:data:`EM_LOG_CONSOLE`). If neither :c:data:`EM_LOG_WARN`, :c:data:`EM_LOG_ERROR`, :c:data:`EM_LOG_INFO` nor :c:data:`EM_LOG_DEBUG` is specified, a log message is printed. :c:data:`EM_LOG_WARN`, :c:data:`EM_LOG_INFO`, :c:data:`EM_LOG_DEBUG` and :c:data:`EM_LOG_ERROR` are mutually exclusive. If :c:data:`EM_LOG_CONSOLE` is not specified then the message will be outputed via err() (for :c:data:`EM_LOG_ERROR` or :c:data:`EM_LOG_WARN`) or out() otherwise. + If specified, prints an error message (combined with :c:data:`EM_LOG_CONSOLE`). If neither :c:data:`EM_LOG_WARN`, :c:data:`EM_LOG_ERROR`, :c:data:`EM_LOG_INFO` nor :c:data:`EM_LOG_DEBUG` is specified, a log message is printed. :c:data:`EM_LOG_WARN`, :c:data:`EM_LOG_INFO`, :c:data:`EM_LOG_DEBUG` and :c:data:`EM_LOG_ERROR` are mutually exclusive. If :c:data:`EM_LOG_CONSOLE` is not specified then the message will be outputted via err() (for :c:data:`EM_LOG_ERROR` or :c:data:`EM_LOG_WARN`) or out() otherwise. .. c:macro:: EM_LOG_C_STACK diff --git a/site/source/docs/api_reference/html5.h.rst b/site/source/docs/api_reference/html5.h.rst index 6334b386ded9..b87712a59f94 100644 --- a/site/source/docs/api_reference/html5.h.rst +++ b/site/source/docs/api_reference/html5.h.rst @@ -2009,7 +2009,7 @@ Struct If the current browser does not support OffscreenCanvas, you can specify the ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_ALWAYS`` WebGL context creation flag. If this flag is passed, and code was compiled with ``-sOFFSCREEN_FRAMEBUFFER`` enabled, the WebGL context will be created as a "proxied context". In this context mode, the WebGLRenderingContext object will actually be created on the main browser thread, and all WebGL API calls will be proxied as asynchronous messages from the pthread into the main thread. This will have a performance and latency impact in comparison to OffscreenCanvas contexts, however unlike OffscreenCanvas-based contexts, proxied contexts can be shared across any number of pthreads: you can use the ``emscripten_webgl_make_context_current()`` function in any pthread to activate and deactivate access to the WebGL context: for example, you could have one WebGL loading thread, and another WebGL rendering thread that coordinate shared access to the WebGL rendering context by cooperatively acquiring and releasing access to the WebGL rendering context via the ``emscripten_webgl_make_context_current()`` function. Proxied contexts do not require any special support from the browser, so any WebGL capable browser can create a proxied WebGL context. - The ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_ALWAYS`` WebGL context creation flag will always create a proxied context, even if the browser did support OffscreenCanvas. If you would like to prefer to create a higher performance OffscreenCanvas context whenever suppported by the browser, but only fall back to a proxied WebGL context to keep compatibility with browsers that do not yet have OffscreenCanvas support, you can specify the ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_FALLBACK`` context creation flag. In order to use this flag, code should be compiled with both ``-sOFFSCREEN_FRAMEBUFFER`` and ``-sOFFSCREENCANVAS_SUPPORT`` linker flags. + The ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_ALWAYS`` WebGL context creation flag will always create a proxied context, even if the browser did support OffscreenCanvas. If you would like to prefer to create a higher performance OffscreenCanvas context whenever supported by the browser, but only fall back to a proxied WebGL context to keep compatibility with browsers that do not yet have OffscreenCanvas support, you can specify the ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_FALLBACK`` context creation flag. In order to use this flag, code should be compiled with both ``-sOFFSCREEN_FRAMEBUFFER`` and ``-sOFFSCREENCANVAS_SUPPORT`` linker flags. Default value of ``proxyContextToMainThread`` after calling ``emscripten_webgl_init_context_attributes()`` is ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_DISALLOW``, if the WebGL context is being created on the main thread. This means that by default WebGL contexts created on the main thread are not shareable between multiple threads (to avoid accidental performance loss from enabling proxying when/if it is not needed). To create a context that can be shared between multiple pthreads, set the ``proxyContextToMainThread`` flag ``EMSCRIPTEN_WEBGL_CONTEXT_PROXY_ALWAYS``. diff --git a/site/source/docs/api_reference/module.rst b/site/source/docs/api_reference/module.rst index f7aa4ec69ecc..c6f2bf0868f5 100644 --- a/site/source/docs/api_reference/module.rst +++ b/site/source/docs/api_reference/module.rst @@ -84,7 +84,7 @@ The following ``Module`` attributes affect code execution. Set them to customize If set, this method will be called when the runtime needs to load a file, such as a ``.wasm`` WebAssembly file, ``.mem`` memory init file, or a file generated by the file packager. The function receives the relative path to the file as configured in build process and a ``prefix`` (path to the main JavaScript file's directory), and should return the actual URL. This lets you host file packages or the ``.mem`` file etc. on a different location than the directory of the JavaScript file (which is the default expectation), for example if you want to host them on a CDN. - .. note:: ``prefix`` might be an empty string, if ``locateFile`` is called before we load the main JavaScript. For example, that can happen if a file package or a mememory initializer file are loaded beforehand (perhaps from the HTML, before it loads the main JavaScript). + .. note:: ``prefix`` might be an empty string, if ``locateFile`` is called before we load the main JavaScript. For example, that can happen if a file package or a memory initializer file are loaded beforehand (perhaps from the HTML, before it loads the main JavaScript). .. note:: Several ``Module.*PrefixURL`` options have been deprecated in favor of ``locateFile``, which includes ``memoryInitializerPrefixURL``, ``pthreadMainPrefixURL``, ``cdInitializerPrefixURL``, ``filePackagePrefixURL``. To update your code, for example if you used ``Module.memoryInitializerPrefixURL`` equal to ``"https://mycdn.com/memory-init-dir/"``, then you can replace that with something like: diff --git a/site/source/docs/building_from_source/configuring_emscripten_settings.rst b/site/source/docs/building_from_source/configuring_emscripten_settings.rst index e7d36b0683c3..df24418b6b0e 100644 --- a/site/source/docs/building_from_source/configuring_emscripten_settings.rst +++ b/site/source/docs/building_from_source/configuring_emscripten_settings.rst @@ -9,7 +9,7 @@ configuration file (.emscripten) `. These settings include paths to the tools (LLVM, Clang, Binaryen, etc.) and the compiler's temporary directory for intermediate build files. -This confuration file is optional. By default, emscripten will search +This configuration file is optional. By default, emscripten will search for the tools it needs in the ``PATH``. This article explains how to create and update the file when you are building diff --git a/site/source/docs/compiling/Building-Projects.rst b/site/source/docs/compiling/Building-Projects.rst index cbc3d26c91b1..ecbf3ca543b8 100644 --- a/site/source/docs/compiling/Building-Projects.rst +++ b/site/source/docs/compiling/Building-Projects.rst @@ -89,10 +89,10 @@ which files are produced under which conditions: - ``emcc ... -o output.html`` builds a ``output.html`` file as an output, as well as an accompanying ``output.js`` launcher file, and a ``output.wasm`` WebAssembly file. - ``emcc ... -o output.js`` omits generating a HTML launcher file (expecting you to provide it yourself if you plan to run in browser), and produces two files, ``output.js`` and ``output.wasm``. (that can be run in e.g. node.js shell) -- ``emcc ... -o output.wasm`` omits generating either JavaScript or HTML launcher file, and produces a single Wasm file built in standalone mode as if the ``-sSTANDALONE_WASM`` settting had been used. The resulting file expects to be run with the `WASI ABI `_ - in particular, as soon as you initialize the module you must manually invoke either the ``_start`` export or (in the case of ``--no-entry``) the ``_initialize`` export before doing anything else with it. +- ``emcc ... -o output.wasm`` omits generating either JavaScript or HTML launcher file, and produces a single Wasm file built in standalone mode as if the ``-sSTANDALONE_WASM`` setting had been used. The resulting file expects to be run with the `WASI ABI `_ - in particular, as soon as you initialize the module you must manually invoke either the ``_start`` export or (in the case of ``--no-entry``) the ``_initialize`` export before doing anything else with it. - ``emcc ... -o output.{html,js} -sWASM=0`` causes the compiler to target JavaScript, and therefore a ``.wasm`` file is not produced. - ``emcc ... -o output.{html,js} --emit-symbol-map`` produces a file ``output.{html,js}.symbols`` if WebAssembly is being targeted (``-sWASM=0`` not specified), or if JavaScript is being targeted and ``-Os``, ``-Oz`` or ``-O2`` or higher is specified, but debug level setting is ``-g1`` or lower (i.e. if symbols minification did occur). -- ``emcc ... -o output.{html,js} -sWASM=0 --memory-init-file 1`` causes the generation of ``output.{html,js}.mem`` memory initializer file. Pasing ``-O2``, ``-Os`` or ``-Oz`` also implies ``--memory-init-file 1``. +- ``emcc ... -o output.{html,js} -sWASM=0 --memory-init-file 1`` causes the generation of ``output.{html,js}.mem`` memory initializer file. Passing ``-O2``, ``-Os`` or ``-Oz`` also implies ``--memory-init-file 1``. - ``emcc ... -o output.{html,js} -gsource-map`` generates a source map file ``output.wasm.map``. If targeting JavaScript with ``-sWASM=0``, the filename is ``output.{html,js}.map``. - ``emcc ... -o output.{html,js} --preload-file xxx`` directive generates a preloaded MEMFS filesystem file ``output.data``. - ``emcc ... -o output.{html,js} -sWASM={0,1} -sSINGLE_FILE`` merges JavaScript and WebAssembly code in the single output file ``output.{html,js}`` (in base64) to produce only one file for deployment. (If paired with ``--preload-file``, the preloaded ``.data`` file still exists as a separate file) diff --git a/site/source/docs/compiling/Deploying-Pages.rst b/site/source/docs/compiling/Deploying-Pages.rst index 74307b749644..4a86d69a6394 100644 --- a/site/source/docs/compiling/Deploying-Pages.rst +++ b/site/source/docs/compiling/Deploying-Pages.rst @@ -41,7 +41,7 @@ In addition to downloading the page, other parts of the startup sequence can som - It is recommended to migrate to WebAssembly to speed up compiled code startup times in browsers. WebAssembly modules are much faster to parse and compile compared to asm.js. Additionally, compiled ``WebAssembly.Module`` objects can be manually persisted to IndexedDB, which avoids the compilation step altogether on the second run. (see next section) -- Occassionally it can be easy to misattribute slow startup to asm.js/WebAssembly compilation, when the actual cause of slowness can in fact be in executing the ``main()`` function entry point of the application itself. This is because these two actions are run closely back to back to each other. It is worthwhile to be precise to profile these two actions separately, check out the ``function callMain()`` in ``src/preamble.js`` which kicks off the execution of application ``main()`` code. If executing ``main()`` takes too long time, consider splitting it out to separate operations that are driven by multiple ``setTimeout()`` calls or by the ``emscripten_set_main_loop()`` event loop. +- Occasionally it can be easy to misattribute slow startup to asm.js/WebAssembly compilation, when the actual cause of slowness can in fact be in executing the ``main()`` function entry point of the application itself. This is because these two actions are run closely back to back to each other. It is worthwhile to be precise to profile these two actions separately, check out the ``function callMain()`` in ``src/preamble.js`` which kicks off the execution of application ``main()`` code. If executing ``main()`` takes too long time, consider splitting it out to separate operations that are driven by multiple ``setTimeout()`` calls or by the ``emscripten_set_main_loop()`` event loop. - To speed up network transfers, experience shows that the under regular network conditions, the fastest approach is to aggressively start all network downloads simultaneously in parallel (assuming there are only a handful of them), as opposed to e.g. downloading a single input file at a time before starting the next one. Therefore to maximize network transfer speed, try to write the main HTML page of the application to start all needed network downloads in parallel instead of queueing them up for sequential transfer. @@ -116,7 +116,7 @@ This way the page will be future compatible once support for the particular feat 3. Traps caused by compiled WebAssembly code. These correspond to fatal errors coming from the WebAssembly VM. This can occur for example when performing an integer division by zero, or when converting a large floating point number to an integer when the float is out of range of the numbers representable by that integer type. -- Implement a final "catch all" error handler on the page by implementing a ``window.onerror`` script. This will be called as a last resort if no other source handled an exception that was raised on the page. See `window.onerror `_ documentaton on MDN. +- Implement a final "catch all" error handler on the page by implementing a ``window.onerror`` script. This will be called as a last resort if no other source handled an exception that was raised on the page. See `window.onerror `_ documentation on MDN. - Do not let the html page "freeze" and bury the error message in the web page console, because most users will not know how to find it there. Strive to provide meaningful error reports to the user on the main html page, preferably with hints on how to act. If updating a browser version or GPU drivers, or freeing up some space on disk might have a chance to help the page to run, let the user know what they could try out. If the error in question is completely unexpected, consider providing a link or an email address where to report the issue to. diff --git a/site/source/docs/index.rst b/site/source/docs/index.rst index b826e01f2493..491b39b330cc 100644 --- a/site/source/docs/index.rst +++ b/site/source/docs/index.rst @@ -11,7 +11,7 @@ This comprehensive documentation set contains everything you need to know to use **Getting started:** -- :ref:`introducting-emscripten-index` explains what Emscripten does, why it is needed, its limitations and its licensing. It will help you understand whether Emscripten is the right tool for you. +- :ref:`introducing-emscripten-index` explains what Emscripten does, why it is needed, its limitations and its licensing. It will help you understand whether Emscripten is the right tool for you. - :ref:`getting-started-index` walks you through downloading, installing and using the Emscripten SDK. **Emscripten Fundamentals:** diff --git a/site/source/docs/introducing_emscripten/index.rst b/site/source/docs/introducing_emscripten/index.rst index d913f6e09423..751b4a5c764b 100644 --- a/site/source/docs/introducing_emscripten/index.rst +++ b/site/source/docs/introducing_emscripten/index.rst @@ -1,4 +1,4 @@ -.. _introducting-emscripten-index: +.. _introducing-emscripten-index: ====================== Introducing Emscripten diff --git a/site/source/docs/porting/Debugging.rst b/site/source/docs/porting/Debugging.rst index d766f32022fa..b249e19d0732 100644 --- a/site/source/docs/porting/Debugging.rst +++ b/site/source/docs/porting/Debugging.rst @@ -22,7 +22,7 @@ This article describes the main tools and settings provided by Emscripten for de Debugging in the browser ======================== -:ref:`Emcc ` can ouptut debug information in two formats, either as +:ref:`Emcc ` can output debug information in two formats, either as DWARF symbols or as source maps. Both allow you to view and debug the *C/C++ source code* in a browser's debugger. DWARF offers the most precise and detailed debugging experience and is supported as an experiment in Chrome 88 diff --git a/site/source/docs/porting/connecting_cpp_and_javascript/embind.rst b/site/source/docs/porting/connecting_cpp_and_javascript/embind.rst index 1df6424aa45b..8a5a6fe980ec 100644 --- a/site/source/docs/porting/connecting_cpp_and_javascript/embind.rst +++ b/site/source/docs/porting/connecting_cpp_and_javascript/embind.rst @@ -255,7 +255,7 @@ There are situations in which multiple long-lived portions of the JavaScript codebase need to hold on to the same C++ object for different amounts of time. -To accomodate that use case, Emscripten provides a `reference counting`_ +To accommodate that use case, Emscripten provides a `reference counting`_ mechanism in which multiple handles can be produced for the same underlying C++ object. Only when all handles have been deleted does the object get destroyed. diff --git a/site/source/docs/porting/exceptions.rst b/site/source/docs/porting/exceptions.rst index 168336875ead..08d690aaae78 100644 --- a/site/source/docs/porting/exceptions.rst +++ b/site/source/docs/porting/exceptions.rst @@ -110,7 +110,7 @@ property. For example: console.log(e.stack); } -Stack traces within Wasm code are not supported in :ref:`JavaScipt-based +Stack traces within Wasm code are not supported in :ref:`JavaScript-based exceptions `. diff --git a/site/source/docs/porting/multimedia_and_graphics/OpenGL-support.rst b/site/source/docs/porting/multimedia_and_graphics/OpenGL-support.rst index f083b831605d..4ccab8b5f58e 100644 --- a/site/source/docs/porting/multimedia_and_graphics/OpenGL-support.rst +++ b/site/source/docs/porting/multimedia_and_graphics/OpenGL-support.rst @@ -70,7 +70,7 @@ What if my codebase depends on a desktop OpenGL feature that is currently unsupp -------------------------------------------------------------------------------------- You can consider building the codebase against the `Regal `_ Desktop OpenGL emulation library, which aims to support Desktop OpenGL features on top of OpenGL ES 2.0. This may work better or worse than Emscripten's GL emulation depending on the project. -Another option is to use `gl4es `_ wich aims at fast OpenGL to GLES conversion for games. It targets OpenGL 2.1 profile on top of OpenGL ES 2.0 and has been used to port a few games with Emscripten already. +Another option is to use `gl4es `_ which aims at fast OpenGL to GLES conversion for games. It targets OpenGL 2.1 profile on top of OpenGL ES 2.0 and has been used to port a few games with Emscripten already. OpenGL ES extensions ==================== diff --git a/site/source/docs/porting/setjmp-longjmp.rst b/site/source/docs/porting/setjmp-longjmp.rst index 0c5b42d1f4f5..d0250f4dc628 100644 --- a/site/source/docs/porting/setjmp-longjmp.rst +++ b/site/source/docs/porting/setjmp-longjmp.rst @@ -13,7 +13,7 @@ by the ``SUPPORT_LONGJMP`` setting, which can take these values: * 1: Default support, depending on the exception mode. ``wasm`` if ``-fwasm-exception`` is used, ``emscripten`` otherwise. If :ref:`native Wasm exceptions ` -are used, ``SUPPORT_LONGJMP`` defaults to ``wasm``, and if :ref:`JavaScipt-based +are used, ``SUPPORT_LONGJMP`` defaults to ``wasm``, and if :ref:`JavaScript-based exceptions ` are used or no exception support is used, it defaults to ``emscripten``. diff --git a/site/source/docs/tools_reference/emcc.rst b/site/source/docs/tools_reference/emcc.rst index 7885ed3cbe6b..637e3eec7ea3 100644 --- a/site/source/docs/tools_reference/emcc.rst +++ b/site/source/docs/tools_reference/emcc.rst @@ -99,7 +99,7 @@ Options that are modified or new in *emcc* are listed below: [different OPTIONs affect at different stages, most at link time] Emscripten build options. For the available options, see `src/settings.js `_. - .. note:: If no value is specifed it will default to ``1``. + .. note:: If no value is specified it will default to ``1``. .. note:: It is possible, with boolean options, to use the ``NO_`` prefix to reverse their meaning. For example, ``-sEXIT_RUNTIME=0`` is the same as ``-sNO_EXIT_RUNTIME=1`` and vice versa. This is not recommended in most cases. diff --git a/site/source/docs/tools_reference/settings_reference.rst b/site/source/docs/tools_reference/settings_reference.rst index 316720fa2874..36d449ba52ad 100644 --- a/site/source/docs/tools_reference/settings_reference.rst +++ b/site/source/docs/tools_reference/settings_reference.rst @@ -1755,7 +1755,7 @@ the WASM_BIGINT option to avoid that problem by using BigInts for i64s which means we don't need to legalize for JS (but this requires a new enough JS VM). -Standlone builds require a ``main`` entry point by default. If you want to +Standalone builds require a ``main`` entry point by default. If you want to build a library (also known as a reactor) instead you can pass ``--no-entry``. .. _binaryen_ignore_implicit_traps: @@ -2399,7 +2399,7 @@ AUTO_NATIVE_LIBRARIES ===================== Like AUTO_JS_LIBRARIES but for the native libraries such as libgl, libal -and libhtml5. If this is disabled it is necessary to explcitly add +and libhtml5. If this is disabled it is necessary to explicitly add e.g. -lhtml5 and also to first build the library using ``embuilder``. .. _min_firefox_version: @@ -2657,7 +2657,7 @@ When this flag is turned on, we error at link time if the build requires any changes to the wasm after link. This can be useful in testing, for example. Some example of features that require post-link wasm changes are: - Lowering i64 to i32 pairs at the JS boundary (See WASM_BIGINT) -- Lowering sign-extnesion operation when targeting older browsers. +- Lowering sign-extension operation when targeting older browsers. .. _abort_on_wasm_exceptions: @@ -2686,7 +2686,7 @@ PURE_WASI Build binaries that use as many WASI APIs as possible, and include additional JS support libraries for those APIs. This allows emscripten to produce binaries -are more WASI compilant and also allows it to process and execute WASI +are more WASI compliant and also allows it to process and execute WASI binaries built with other SDKs (e.g. wasi-sdk). This setting is experimental and subject to change or removal. Implies STANDALONE_WASM. diff --git a/site/source/get_api_items.py b/site/source/get_api_items.py index 7c3492bdae7a..ee94f6909e6d 100755 --- a/site/source/get_api_items.py +++ b/site/source/get_api_items.py @@ -84,7 +84,7 @@ def exportItems(): # Write out each API item to add infile.write(" mapped_wiki_inline_code['%s'] = '%s'\n" % (key, value)) - # write the return fucntion + # write the return function infile.write(" return mapped_wiki_inline_code\n") diff --git a/src/settings.js b/src/settings.js index 71275ad8c9e3..1fa50cb69e45 100644 --- a/src/settings.js +++ b/src/settings.js @@ -1387,7 +1387,7 @@ var WASM = 1; // means we don't need to legalize for JS (but this requires a new enough JS // VM). // -// Standlone builds require a ``main`` entry point by default. If you want to +// Standalone builds require a ``main`` entry point by default. If you want to // build a library (also known as a reactor) instead you can pass ``--no-entry``. // [link] var STANDALONE_WASM = false; @@ -1809,7 +1809,7 @@ var SINGLE_FILE = false; var AUTO_JS_LIBRARIES = true; // Like AUTO_JS_LIBRARIES but for the native libraries such as libgl, libal -// and libhtml5. If this is disabled it is necessary to explcitly add +// and libhtml5. If this is disabled it is necessary to explicitly add // e.g. -lhtml5 and also to first build the library using ``embuilder``. // [link] var AUTO_NATIVE_LIBRARIES = true; @@ -2003,7 +2003,7 @@ var SEPARATE_DWARF_URL = ''; // changes to the wasm after link. This can be useful in testing, for example. // Some example of features that require post-link wasm changes are: // - Lowering i64 to i32 pairs at the JS boundary (See WASM_BIGINT) -// - Lowering sign-extnesion operation when targeting older browsers. +// - Lowering sign-extension operation when targeting older browsers. var ERROR_ON_WASM_CHANGES_AFTER_LINK = false; // Abort on unhandled excptions that occur when calling exported WebAssembly @@ -2025,7 +2025,7 @@ var ABORT_ON_WASM_EXCEPTIONS = false; // Build binaries that use as many WASI APIs as possible, and include additional // JS support libraries for those APIs. This allows emscripten to produce binaries -// are more WASI compilant and also allows it to process and execute WASI +// are more WASI compliant and also allows it to process and execute WASI // binaries built with other SDKs (e.g. wasi-sdk). // This setting is experimental and subject to change or removal. // Implies STANDALONE_WASM.