Now, it becomes easy to split up the ASM JS functions into multiple files
since each file is just updating the asmJSPrivateState variable. We can
then modify the Emscripten HTML to include multiple script files instead of
the original file and voila, we are done.
The astute reader may have noted that we still haven’t solved the lexical
scoping problem addressed in point (b) above. If we split up the ASM JS
into multiple files, then testFuncVar would not even be in scope when we
try to assign Module[‘testFunc’] to it in the preamble code. To get around
this problem, we forward declare all the global variables and set them to
undefined. They get assigned to the right value when they are defined later
on. With that in mind, the final ASM JS (along with file boundaries) would
look as follows:
// PRE-ASM JS CODE
// FORWARD DECLARE ALL GLOBAL variables to deal with scoping issues
var testFuncVar = undefined;
Module['testFunc'] = testFuncVar;
/////////////////////////////////////////////////////////////////////////////////
// FILE BOUNDARY
/////////////////////////////////////////////////////////////////////////////////
// EMSCRIPTEN_START_ASM
var asmJSPrivateState = {};
// ASM JS global variables
asmJSPrivateState.asmJSGlobal = 0;
// ASM JS functions
/////////////////////////////////////////////////////////////////////////////////
// MULTIPLE FILE BOUNDARIES
/////////////////////////////////////////////////////////////////////////////////
// e.g. testFunc
asmJSPrivateState.testFunc = function () {
var a = asmJSPrivateState.asmJSGlobal;
return a;
}
/////////////////////////////////////////////////////////////////////////////////
// FILE BOUNDARY
/////////////////////////////////////////////////////////////////////////////////
var asm = (function(global, env, buffer)) {
return {testFunc: asmJSPrivateState.testFunc, <OTHER_ASM_JS_FUNCTIONS>};
})
// EMSCRIPTEN_END_ASM
(Module.asmGlobalArg, Module.asmLibraryArg, buffer);
// POST-ASM JS CODE
var testFuncVar = asm['testFunc'];
With such a change, we can now debug through the same ASM JS code, but with
it being split up into multiple files. You no longer have to rely on the
debugger to be able to load up files that can be greater than 50 Mb in
size. Note that the final JS while functional, may not actually be ASM JS
per spec, but for debugging purposes, unless you really care about that
(that is, if the bug you are trying to fix actually relies on this), you
should be just fine.
On Monday, December 14, 2015 at 8:55:50 AM UTC-8, jj wrote:
>
> We have two items in the Firefox issue tracker regarding debugging large
> files:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1158098 - Improve debugger
> to navigate and search large UE4 StrategyGame JavaScript file.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1224726 - High memory
> consumption when opening and searching a large Javascript file in debugger.
>
> These are in the radar for 2016, so we are hoping to improve things
> greatly here.
>
> 2015-12-04 23:16 GMT+02:00 Alon Zakai <[email protected] <javascript:>>:
>
>> Yes, this is a known issue. There is progress on the browser side to more
>> efficiently handle such large programs, but no browser does this well yet.
>>
>> Emscripten supports dynamic linking,
>>
>> https://github.com/kripken/emscripten/wiki/Linking
>>
>> This can be a solution for this problem, by splitting things up into
>> smaller files.
>>
>> In practice, personally, I tend to use print debugging and I open the
>> file in a text editor on the side that can handle massive text files.
>>
>> On Fri, Dec 4, 2015 at 12:02 PM, arnab choudhury <[email protected]
>> <javascript:>> wrote:
>>
>>> Hey all
>>>
>>> I'm using Emscripten to convert a decent sized C++ codebase to
>>> Javascript. As part of this process, I'm finding that debugging the
>>> unoptimized generated JS can be quite painful. Specifically, some JS files
>>> can be up to 1 million lines long and this completely breaks my browser's
>>> node debugger (via node-inspector). Google's v8 debugger (via node debug)
>>> also has a hard time stepping through code. My only debugging technique
>>> that works currently is to enter print statements, and debug and build
>>> iteratively.
>>>
>>> I saw some threads on github about emscripten having the ability to
>>> split up the generated JS files into multiple files. However, the latest
>>> version of emscripten doesn't seem to support this. Have others run into
>>> this issue? Are there any existing solutions for this problem?
>>>
>>> Thanks,
>>> Arnab
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected]
>>> <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
