twitter example fails to run with slim build

[johnnyman727]

Test Case:

mkdir twit-demo; cd twit-demo;
t2 init;
npm i twitter;
echo "require('twitter')" > index.js
t2 run index.js

Expected Results (which you can see by running node index.js or t2 run index.js --full):

INFO Looking for your Tessel...
INFO Connected to .
INFO Building project.
INFO Writing project to RAM on  (3816.448 kB)...
INFO Deployed.
INFO Running index.js...
# No output

Actual Results:

➜  twit-demo  t2 run index.js
INFO Looking for your Tessel...
INFO Connected to horse.
INFO Building project.
ERR! TypeError: self.key.print is not a function

[rwaldron]

I'll take a look at this immediately.

[johnnyman727]

I should have tested this more thoroughly after your recent PR @rwaldron but it looks like Slim builds are still failing for some reason. When I run the twitter example I get the following error (and it doesn't occur if I run with --full):

➜  twit-demo  t2 run index.js
INFO Looking for your Tessel...
INFO Connected to Tessel-02A3BBAD6C82.
INFO Building project.
INFO Writing project to RAM on Tessel-02A3BBAD6C82 (974.336 kB)...
INFO Deployed.
INFO Running index.js...
/tmp/remote-script/node_modules/extend/index.js:1
(function (exports, require, module, __filename, __dirname) { "use strict";var e=Object.prototype.hasOwnProperty,t=Object.prototype.toString,r=function(e){return"function"==typeof Array.isArray?Array.isArray(e):"[object Array]"===t.call(e)},o=function(r){var s,i,o;if(!r||"[object Object]"!==t.call(r))return!1;if(s=e.call(r,"constructor"),i=r.constructor&&r.constructor.prototype&&e.call(r.constructor.prototype,"isPrototypeOf"),r.constructor&&!s&&!i)return!1;for(o in r);return void 0===o||e.call(r,o)};module.exports=function s(){var a,i,s,t,c,u,e=arguments[0],l=1,d=arguments.length,n=!1;for("boolean"==typeof e?(n=e,e=arguments[1]||{},l=2):("object"!=typeof e&&"function"!=typeof e||null==e)&&(e={});d>l;++l)if(a=arguments[l],null!=a)for(i in a)s=e[i],t=a[i],e!==t&&(n&&t&&(o(t)||(c=r(t)))?(c?(c=!1,u=s&&r(s)?s:[]):u=s&&o(s)?s:{},e[i]=s(n,u,t)):void 0!==t&&(e[i]=t));return e};


TypeError: s is not a function
    at s (/tmp/remote-script/node_modules/extend/index.js:1:841)
    at e.request (/tmp/remote-script/node_modules/request/index.js:1:651)
    at e.__request (/tmp/remote-script/node_modules/twitter/lib/twitter.js:1:1676)
    at e.post (/tmp/remote-script/node_modules/twitter/lib/twitter.js:1:2018)
    at Object.<anonymous> (/tmp/remote-script/index.js:1:418)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Function.Module.runMain (module.js:467:10)

[rwaldron]

This is pretty frustrating. We need to be able to compress code, but I don't know how we're going to avoid completely valid source failing at runtime if the compression is over-eager. I will try peeling back compression options and see what I can learn.

[rwaldron]

It's this:

    ast.figure_out_scope(mangle);
    ast.compute_char_frequency(mangle);
    ast.mangle_names(mangle);

When I comment it out, everything works...

$ t2 run index.js
INFO Looking for your Tessel...
INFO Connected to bishop.
INFO Building project.
INFO Writing project to RAM on bishop (1092.608 kB)...
INFO Deployed.
INFO Running index.js...
Successfully tweeted! Tweet text: Hello @tesselproject. This is your #Tessel 2 speaking.

...But we lose a lot of compression.

I don't really want to ditch this, so I'd like to think about it a bit before jumping to write a fix. I think strongest compression should be the default, with options to relax it. Not sure how to to do that, but I'll think on it and come back tomorrow.

[johnnyman727]

I think strongest compression should be the default, with options to relax it. Not sure how to to do that, but I'll think on it and come back tomorrow.

I'm of the opposite opinion simply because it doesn't matter how fast your code get deployed if it doesn't work on Tessel :/ I didn't previously realize that we could be potentially be creating runtime errors with our slimming (especially with popular libraries like `twitter).

[rwaldron]

TBH, this is bad library code at fault, not our operation. I'm going to try making this seamless.

[rwaldron]

Looks like I merely needed to set these true:

      keep_fargs: false,
      keep_fnames: false,

[rwaldron]

Or at very least: keep_fnames: true

[rwaldron]

it doesn't matter how fast your code get deployed

That's not really the value here, code deploys are always pretty fast. The real value is the unused disk on the board itself.