site: Fix typos.

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:
 

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<typename FieldType>
          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|

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.

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
 

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``.
 

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:
 

site/source/docs/building_from_source/configuring_emscripten_settings.rst

@@ -9,7 +9,7 @@ configuration file (.emscripten) <compiler-configuration-file>`. 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

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 <https://github.com/WebAssembly/WASI/blob/4712d490fd7662f689af6faa5d718e042f014931/legacy/application-abi.md>`_ - 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 <https://github.com/WebAssembly/WASI/blob/4712d490fd7662f689af6faa5d718e042f014931/legacy/application-abi.md>`_ - 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)

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 <https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror#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 <https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror#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.
 

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:**

site/source/docs/introducing_emscripten/index.rst

@@ -1,4 +1,4 @@
-.. _introducting-emscripten-index:
+.. _introducing-emscripten-index:
 
 ======================
 Introducing Emscripten

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 <emccdoc>` can ouptut debug information in two formats, either as
+:ref:`Emcc <emccdoc>` 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

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.

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 <javascript-based-exception-support>`.
 
 

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 <https://github.com/p3/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 <https://github.com/ptitSeb/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 <https://github.com/ptitSeb/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
 ====================

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 <webassembly-exception-handling-based-support>`
-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 <javascript-based-exception-support>` are used or no exception
 support is used, it defaults to ``emscripten``.
 

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 <https://github.com/emscripten-core/emscripten/blob/main/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.