Merge remote-tracking branch 'origin/incoming' into merge-mar-13-2015

Author: kripken

emscripten-version.txt

@@ -1,2 +1,2 @@
-1.29.12
+1.30.0
 

site/source/docs/api_reference/Filesystem-API.rst

@@ -14,7 +14,7 @@ Emscripten predominantly compiles code that uses synchronous file I/O, so the ma
 
 File data in Emscripten is partitioned by mounted file systems. Several file systems are provided. An instance of :ref:`MEMFS <filesystem-api-memfs>` is mounted to ``/`` by default. Instances of :ref:`NODEFS <filesystem-api-nodefs>` and :ref:`IDBFS <filesystem-api-idbfs>` can be mounted to other directories if your application needs to :ref:`persist data <filesystem-api-persist-data>`.
 
-The automatic tests in `tests/test_core.py <https://github.com/kripken/emscripten/blob/master/tests/test_core.py#L4110>`_ (search for ``test_files``) contain many examples of how to use this API. The :ref:`tutorial <tutorial-files>` also shows how to pre-load a file so that it can be read from compiled C/C++.
+The automatic tests in `tests/test_core.py <https://github.com/kripken/emscripten/blob/1.29.12/tests/test_core.py#L4285>`_ (search for ``test_files``) contain many examples of how to use this API. The :ref:`tutorial <tutorial-files>` also shows how to pre-load a file so that it can be read from compiled C/C++.
 
 A high level overview of the way File Systems work in Emscripten-ported code is provided in the :ref:`file-system-overview`. 
 
@@ -87,7 +87,7 @@ The device node acts as an interface between the device and the file system. Any
 	Registers the specified device driver with a set of callbacks.
 
 	:param dev: The specific device driver id, created using :js:func:`makedev`.
-	:param object ops: The set of callbacks required by the device. For an example, see the `NODEFS default callbacks <https://github.com/kripken/emscripten/blob/master/src/library_nodefs.js#L213)>`_.
+	:param object ops: The set of callbacks required by the device. For an example, see the `NODEFS default callbacks <https://github.com/kripken/emscripten/blob/1.29.12/src/library_nodefs.js#L213>`_.
 
 
 

site/source/docs/api_reference/emscripten.h.rst

@@ -179,7 +179,7 @@ Functions
 
 	The JavaScript environment will call that function at a specified number of frames per second. Setting 0 or a negative value as the ``fps`` will instead use the browser’s ``requestAnimationFrame`` mechanism to call the main loop function. This is **HIGHLY** recommended if you are doing rendering, as the browser’s ``requestAnimationFrame`` will make sure you render at a proper smooth rate that lines up properly with the the browser and monitor. If you do not render at all in your application, then you should pick a specific frame rate that makes sense for your code.
 	
-	If ``simulate_infinite_loop`` is true, the function will throw an exception in order to stop execution of the caller. This will lead to the main loop being entered instead of code after the call to :c:func:`emscripten_set_main_loop` being run, which is the closest we can get to simulating an infinite loop (we do something similar in `glutMainLoop <https://github.com/kripken/emscripten/blob/master/system/include/GL/freeglut_std.h#L400>`_ in `GLUT <http://www.opengl.org/resources/libraries/glut/>`_). If this parameter is ``false``, then the behavior is the same as it was before this parameter was added to the API, which is that execution continues normally. Note that in both cases we do not run global destructors, ``atexit``, etc., since we know the main loop will still be running, but if we do not simulate an infinite loop then the stack will be unwound. That means that if ``simulate_infinite_loop`` is ``false``, and you created an object on the stack, it will be cleaned up before the main loop is called for the first time.
+	If ``simulate_infinite_loop`` is true, the function will throw an exception in order to stop execution of the caller. This will lead to the main loop being entered instead of code after the call to :c:func:`emscripten_set_main_loop` being run, which is the closest we can get to simulating an infinite loop (we do something similar in `glutMainLoop <https://github.com/kripken/emscripten/blob/1.29.12/system/include/GL/freeglut_std.h#L400>`_ in `GLUT <http://www.opengl.org/resources/libraries/glut/>`_). If this parameter is ``false``, then the behavior is the same as it was before this parameter was added to the API, which is that execution continues normally. Note that in both cases we do not run global destructors, ``atexit``, etc., since we know the main loop will still be running, but if we do not simulate an infinite loop then the stack will be unwound. That means that if ``simulate_infinite_loop`` is ``false``, and you created an object on the stack, it will be cleaned up before the main loop is called for the first time.
 	
 	.. tip:: There can be only *one* main loop function at a time. To change the main loop function, first :c:func:`cancel <emscripten_cancel_main_loop>` the current loop, and then call this function to set another.
 	

site/source/docs/api_reference/module.rst

@@ -33,7 +33,7 @@ When generating only JavaScript (as opposed to HTML), no ``Module`` object is cr
 
 .. important:: If you run the :term:`Closure Compiler` on your code (which is optional, and can be done by ``--closure 1``), you will need quotation marks around the properties of ``Module`` as in the example above. In addition, you need to run closure on the compiled code together with the declaration of ``Module`` — this is done automatically for a ``-pre-js`` file.
 
-When generating HTML, Emscripten creates a ``Module`` object with default methods (see `src/shell.html <https://github.com/kripken/emscripten/blob/master/src/shell.html#L1220>`_). In this case you should again use ``--pre-js``, but this time you add properties to the *existing* ``Module`` object, for example
+When generating HTML, Emscripten creates a ``Module`` object with default methods (see `src/shell.html <https://github.com/kripken/emscripten/blob/1.29.12/src/shell.html#L1220>`_). In this case you should again use ``--pre-js``, but this time you add properties to the *existing* ``Module`` object, for example
 
 	::
 

site/source/docs/getting_started/FAQ.rst

@@ -249,7 +249,7 @@ Why do functions in my C/C++ source code vanish when I compile to JavaScript, an
 
 Emscripten does dead code elimination of functions that are not called from the compiled code. While this does minimize code size, it can remove functions that you plan to call yourself (outside of the compiled code). 
 
-To make sure a C function remains available to be called from normal JavaScript, it must be added to the `EXPORTED_FUNCTIONS <https://github.com/kripken/emscripten/blob/master/src/settings.js#L359>`_ using the *emcc* command line. For example, to prevent functions ``my_func()`` and ``main()`` from being removed/renamed, run *emcc* with: ::
+To make sure a C function remains available to be called from normal JavaScript, it must be added to the `EXPORTED_FUNCTIONS <https://github.com/kripken/emscripten/blob/1.29.12/src/settings.js#L388>`_ using the *emcc* command line. For example, to prevent functions ``my_func()`` and ``main()`` from being removed/renamed, run *emcc* with: ::
 
 	./emcc -s EXPORTED_FUNCTIONS="['_main', '_my_func']"  ...
 

site/source/docs/getting_started/test-suite.rst

@@ -69,7 +69,7 @@ You can also run a specific mode or test in a mode, or a specific test across al
 	# Run one test in all modes.
 	python tests/runner.py ALL.test_hello_world 
 
-The core test modes are documented at the end of `/tests/test_core.py <https://github.com/kripken/emscripten/blob/master/tests/test_core.py#L7099>`_.
+The core test modes are documented at the end of `/tests/test_core.py <https://github.com/kripken/emscripten/blob/1.29.12/tests/test_core.py#L7421>`_.
 
 .. _emscripten-test-suite-modes:
 

site/source/docs/optimizing/Optimizing-Code.rst

@@ -37,7 +37,7 @@ In addition to the ``-Ox`` options, there are separate compiler options that can
 Advanced compiler settings
 ==========================
 
-There are several flags you can :ref:`pass to the compiler <emcc-s-option-value>` to affect code generation, which will also affect performance — for example :ref:`DISABLE_EXCEPTION_CATCHING <optimizing-code-exception-catching>`. These are documented in `src/settings.js <https://github.com/kripken/emscripten/blob/master/src/settings.js>`_. Some of these will be directly affected by the optimization settings (you can find out which ones by searching for ``apply_opt_level`` in `tools/shared.py <https://github.com/kripken/emscripten/blob/master/tools/shared.py#L906>`_).
+There are several flags you can :ref:`pass to the compiler <emcc-s-option-value>` to affect code generation, which will also affect performance — for example :ref:`DISABLE_EXCEPTION_CATCHING <optimizing-code-exception-catching>`. These are documented in `src/settings.js <https://github.com/kripken/emscripten/blob/master/src/settings.js>`_. Some of these will be directly affected by the optimization settings (you can find out which ones by searching for ``apply_opt_level`` in `tools/shared.py <https://github.com/kripken/emscripten/blob/1.29.12/tools/shared.py#L958>`_).
 
 A few useful flags are:
 

site/source/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.rst

@@ -464,12 +464,12 @@ for defining the binding:
    natural fit for the project and its build system.
 
 .. _library.js: https://github.com/kripken/emscripten/blob/master/src/library.js
-.. _test_js_libraries: https://github.com/kripken/emscripten/blob/master/tests/test_core.py#L4800
+.. _test_js_libraries: https://github.com/kripken/emscripten/blob/1.29.12/tests/test_core.py#L5043
 .. _src/deps_info.json: https://github.com/kripken/emscripten/blob/master/src/deps_info.json
 .. _tools/system_libs.py: https://github.com/kripken/emscripten/blob/master/tools/system_libs.py
 .. _library_\*.js: https://github.com/kripken/emscripten/tree/master/src
-.. _test_add_function in tests/test_core.py: https://github.com/kripken/emscripten/blob/master/tests/test_core.py#L5904
+.. _test_add_function in tests/test_core.py: https://github.com/kripken/emscripten/blob/1.29.12/tests/test_core.py#L6237
 .. _tests/core/test_utf.in: https://github.com/kripken/emscripten/blob/master/tests/core/test_utf.in
-.. _tests/test_core.py: https://github.com/kripken/emscripten/blob/master/tests/test_core.py#L5704
+.. _tests/test_core.py: https://github.com/kripken/emscripten/blob/1.29.12/tests/test_core.py#L4597
 .. _Box2D: https://github.com/kripken/box2d.js/#box2djs
 .. _Bullet: https://github.com/kripken/ammo.js/#ammojs

site/source/docs/porting/files/Synchronous-Virtual-XHR-Backed-File-System-Usage.rst

@@ -16,7 +16,7 @@ The backend can improve start up time as the whole file system does not need to
 Test code
 =========
 
-An example of how to implement a synchronous virtual XHR backed file system is provided in the test code at `tests/test_browser.py <https://github.com/kripken/emscripten/blob/master/tests/test_browser.py#L1266>`_ (see ``test_chunked_synchronous_xhr``). The test case also contains an HTTP server (see `test_chunked_synchronous_xhr_server <https://github.com/kripken/emscripten/blob/master/tests/test_browser.py#L14>`_) showing CORS headers that might need to be set (if the resources are hosted from the same domain Emscripten runs from, there is no issue).
+An example of how to implement a synchronous virtual XHR backed file system is provided in the test code at `tests/test_browser.py <https://github.com/kripken/emscripten/blob/1.29.12/tests/test_browser.py#L1313>`_ (see ``test_chunked_synchronous_xhr``). The test case also contains an HTTP server (see `test_chunked_synchronous_xhr_server <https://github.com/kripken/emscripten/blob/1.29.12/tests/test_browser.py#L14>`_) showing CORS headers that might need to be set (if the resources are hosted from the same domain Emscripten runs from, there is no issue).
 
 The tests use `checksummer.c <https://github.com/kripken/emscripten/blob/master/tests/checksummer.c>`_ as the Emscripten-compiled program. This is simply a vanilla C program using synchronous *libc* file system calls like ``fopen()``, ``fread()``, ``fclose()`` etc.
 
@@ -59,7 +59,7 @@ Instructions
 #. 
 	You will need a page that spawns the web worker. 
 
-	The `test code <https://github.com/kripken/emscripten/blob/master/tests/test_browser.py#L1266>`_ that does this is shown below:
+	The `test code <https://github.com/kripken/emscripten/blob/1.29.12/tests/test_browser.py#L1286>`_ that does this is shown below:
 
 	.. include:: ../../../../../tests/test_browser.py
 		:literal:
@@ -72,4 +72,4 @@ Instructions
 
 
 
-    
+    

site/source/docs/porting/guidelines/function_pointer_issues.rst

@@ -25,7 +25,7 @@ There are three general issues with function pointers:
 
 #. 
 
-  When using optimisation :ref:`-O2 <emcc-O2>` and above, comparing function pointers of different types can give false positives, and bugs with incorrect function pointers are potentially more misleading. To check if this is the cause of problems with your code, you can compile with `ALIASING_FUNCTION_POINTERS <https://github.com/kripken/emscripten/blob/master/src/settings.js#L209>`_ unset (``-s ALIASING_FUNCTION_POINTERS=0``).
+  When using optimisation :ref:`-O2 <emcc-O2>` and above, comparing function pointers of different types can give false positives, and bugs with incorrect function pointers are potentially more misleading. To check if this is the cause of problems with your code, you can compile with `ALIASING_FUNCTION_POINTERS <https://github.com/kripken/emscripten/blob/1.29.12/src/settings.js#L213>`_ unset (``-s ALIASING_FUNCTION_POINTERS=0``).
 
   .. note:: In **asm.js**, function pointers are stored within a function-type specific table (as in the ``FUNCTION_TABLE_ii`` example from before).
 

site/source/docs/porting/guidelines/portability_guidelines.rst

@@ -34,7 +34,7 @@ The following types of code will compile, but may not run as fast as expected:
 
 -  64-bit ``int`` variables. Mathematical operations (+, -, \*, /) are slow because they are emulated (bitwise operations are reasonably fast). JavaScript does not have a native 64-bit ``int`` type so this is unavoidable.
 
--  C++ Exceptions. In JavaScript such code generally makes the JavaScript engine turn off various optimizations. For that reason exceptions are turned off by default in ``-O1`` and above. To re-enable them, run *emcc* with ``-s DISABLE_EXCEPTION_CATCHING=0`` (see `src/settings.js <https://github.com/kripken/emscripten/blob/master/src/settings.js#L279>`_). 
+-  C++ Exceptions. In JavaScript such code generally makes the JavaScript engine turn off various optimizations. For that reason exceptions are turned off by default in ``-O1`` and above. To re-enable them, run *emcc* with ``-s DISABLE_EXCEPTION_CATCHING=0`` (see `src/settings.js <https://github.com/kripken/emscripten/blob/1.29.12/src/settings.js#L298>`_). 
 
 - ``setjmp`` also prevents :term:`relooping` around it, forcing us to emulate control flow using a less efficient approach.
 

tests/test_benchmark.py

@@ -111,7 +111,7 @@ def process(filename):
                     '-O3', '-s', 'DOUBLE_MODE=0', '-s', 'PRECISE_I64_MATH=0',
                     '--memory-init-file', '0', '--js-transform', 'python hardcode.py',
                     '-s', 'TOTAL_MEMORY=128*1024*1024',
-                    '--profiling',
+                    #'--profiling',
                     #'--closure', '1',
                     '-o', final] + shared_args + emcc_args + self.extra_args, stdout=PIPE, stderr=PIPE, env=self.env).communicate()
     assert os.path.exists(final), 'Failed to compile file: ' + output[0]

tests/test_core.py

@@ -5539,7 +5539,6 @@ def test_sqlite(self):
     Settings.CORRECT_ROUNDINGS = 0
     if self.emcc_args is None: Settings.SAFE_HEAP = 0 # uses time.h to set random bytes, other stuff
     Settings.DISABLE_EXCEPTION_CATCHING = 1
-    Settings.FAST_MEMORY = 4*1024*1024
     Settings.EXPORTED_FUNCTIONS += ['_sqlite3_open', '_sqlite3_close', '_sqlite3_exec', '_sqlite3_free', '_callback'];
     if Settings.ASM_JS == 1 and '-g' in self.emcc_args:
       print "disabling inlining" # without registerize (which -g disables), we generate huge amounts of code