Can't compile minified version of Firebase module about t1-runtime HOT 5 CLOSED

Now (runtime @ d99c35f) I'm just seeing the error about too many local variables:

➜  firebase git:(master) ✗ colony app.js              

/usr/local/lib/node_modules/colony-compiler/bin/colony-compiler.js:48
        throw err;
              ^
ColonyVMError: ...runtime/test/modules/firebase/node_modules/firebase/lib/firebase-node.js:7: function at line 3 has more than 200 local variables

from t1-runtime.

Hmm, this is actually a limitation of the Lua interpreter, and must be less than 250. It won't be easy to increase, either: local variables are mapped to Lua VM "registers", which are stack indexes within the current function frame. These must fit in a single byte because they are encoded in most of the Lua opcodes as 8-bit fields.

The default 200 allows some space for temporary registers, needed to compile expressions and function calls. There is also a limit of 60 upvalues - variables captured in the function closure from the enclosing function. I'm not sure why this one is so small.

Note that the 200 locals limit applies only to active locals within one function - since Lua has proper lexical scoping, a local used inside a loop or 'do' block only exists during that block. Outside the block, the register is freed up for a different local (e.g. in a following loop or block.)

Also, the top level of a Lua source file is compiled as a function body, so the same limit applies to locals at the file level. This is usually where the limit is hit ;) Named local functions are also included in the total.

from t1-runtime.

Oooof that's a shame. I'll get in touch with Firebase and see if we can work anything else out.

Thanks a ton, @raffecat!

-Jon

from t1-runtime.

Well, that said, there might be ways around it - minified js libs are common enough, and so are large js modules with a lot of vars and functions in one scope. I'm not sure if LuaJIT has the same limitation on locals, either.

One work-around is for the colony compiler to spill >200 local vars into a local table, and generate table field access whenever the vars are used. It would be slightly slower, but that shouldn't matter in a context with more than 200 locals.

It also might be possible to modify the Lua VM to allow many more upvalues, and create extra upvalues for the excess locals. This would only affect a couple of the opcodes, and the Lua code generator already emits getupvalue opcodes for non-local names.

from t1-runtime.

+1 for getting firebase to work with Tessel. It'd be awesome if all the rapid prototyping tools could play nice together!

from t1-runtime.