I don't really understand what's going on with it. It's throwing this:

Running "jasmine_node:runCoverage" (jasmine_node) task
Exception loading: /Users/winter/Desktop/aether/coverage/instrument/lib/test/aether_spec.js
{ [Error: ENOENT, no such file or directory '/Users/winter/Desktop/aether/node_modules/iota-compiler/coverage']
  errno: 34,
  code: 'ENOENT',
  path: '/Users/winter/Desktop/aether/node_modules/iota-compiler/coverage',
  syscall: 'open' }
Failed to execute "jasmine.executeSpecsInFolder": Error: ENOENT, no such file or directory '/Users/winter/Desktop/aether/node_modules/iota-compiler/coverage'
...

Does Gruntfile.coffee somehow need to exclude node module's own coverage stuff?

I have some old cruft in there for how I thought we might do this before writing any of the code, but it's not good.

Aether really doesn't like it when you have a variable on the left, use the nonexistent => operator, and then anything on the right.

A simplified test case for this is

var blah;
blah => 3

The original code which triggers a crash is

var gold = gold;
if (gold => 50)
{
var type = 'soldier';
if(this.built.length % 10 === 0)
    type = 'artillery';
else if(this.built.length % 5 === 2)
    type = 'archer';

//this.say('Unit #' + this.built.length + ' will be a ' + type);
this.build(type);}

Need some layout that's not dumb.

@deepak1556 has implemented CoffeeScript support, but we don't have many tests to make sure it's working. Just re-implementing some of the basic tests we have for JavaScript code but in CoffeeScript would for each of the test suites would suffice to cover most of the cases.

It seems that either the the website hasn't been updated since about March 20th or something has broken in the demos. This is because the missingThis bug for using functions as parameters is still there, if it isn't an out of date site that will have to be fixed.

See this issue in traceur: google/traceur-compiler#605

Basically we're just hacking away the labels in aether.coffee to get it kind of not breaking, but the semantics are wrong for any originally labeled breaks and seem to turn all continues into breaks: http://discourse.codecombat.com/t/continue-seems-to-work-like-break/182

I wonder if there's a way we can make continues work?

See this thread. Basically, the functionality would give you a good error message when you tried to call an undefined method will now just give you an "undefined is not a function" message.

Possibly using JSDoc comments somehow? It would be nice if Aether could handle making runtime errors when user code didn't conform to validation.

The current CoffeeScript compiler does not provide a similar method to parse_dammit from acorn. Therefore we can currently not provide any detailed error information in projects such as CodeCombat. The folks of michaelficarra/CoffeeScriptRedux however seemed open to a contribution in that direction.

You can see this in the dev test page with this code when foo is not defined:

foo.indexOf("bar");

Safari gives TypeError: 'undefined' is not a function (evaluating 'tmp3[tmp4](tmp6)')

Firefox gives Line 19508: TypeError: tmp3[tmp4] is not a function.

Chrome does it right: Error: Object ... has no method 'indexOf'

These are a common error message and it's totally impossible to debug what's going on without the original variable name, especially when line numbers still aren't working.

To fix, will need to watch where the error is being generated and perhaps do a transform to head it off.

From the forum:

This is the line of code being used:
var mycars = new Array();

This is the error message:
TypeError: undefined is not a function

Probably the Array constructor needs to be added to the createFunction context, and perhaps needs to be accounted for in the makeCheckThisKeyords transform which try to determine whether an identifier is available.

This is probably the same bug that people are seeing not being able to use parseInt, Infinity, and perhaps many other things that are part of JavaScript like NaN and other types of objects.

Possibly due to interceptThis() stuff?

Metrics on things like what kind of indentation and bracket style the code uses, whether it uses recursion or regular expressions, etc. The old design doc had something like this:

aether.style;
// -> (after having transpiled)
{
    loc: 35,
    sloc: 28,
    statements: 29,
    score: 0.64,  // or something
    conceptsUsed: {
        recursion: true,
        objects: false,
        arrays: false,
        strings: true,
        Math: false,
        //functions: true,
        anonymousFunctions: false,
        ifStatements: true,
        elseStatements: true,
        switchStatements: false,
        forLoops: true,
        whileLoops: false,
        doWhileLoops: false,
        classes: false,
        regularExpressions: false,
        ternaryOperators: false,
        undefined: false,
        null: false,
        NaN: false
        // ... many more
    },
    identifiers: {
        variableNames: ["dx", "dy", "enemies", "nearestEnemy", "nearestDistance", "enemy"],  // names of variables used, perhaps will contain function parameters, properties of non 'this' objects
        functionNames: ["distance_squared"],  // names of functions used
        propertyNames: []  // properties of 'this' objects
    }
    // what else?
}

I'm sure something much better could be thought up.

When using Aether in CodeCombat, we run the code in the web worker and handle infinite loops with timeouts and aborting the worker. On the dev page, it's easy to accidentally create an infinite loop temporarily, from which there is no escape. We should probably hook up the same sort of mechanism whereby we run the code in the worker and send the results back.

It's currently not described how to run/hack on Aether itself.

It might be simpler to have separate python2 and python3 languages, or javascript and javascript_harmony languages, for example, rather than this currently-unused languageVersion option.

I done wrote 'em, might as well let other people see 'em.

It might be time for this, although it's hard to tell how far along JSHint is. Having better control over the error messages and globals would be nice.

The currently used CoffeeScript compiler throws an exception when the syntax doesn't fit. This makes a switch between JavaScript and CoffeeScript impossible unless you always clear the code first (not useful esp. for CodeCombat).

I tried to get JSHint to not prepopulate a ton of globals, but it didn't work. Maybe JSHint has been upgraded and has a working way to do this now. (Or maybe I was just being dumb the first time.)

We should also add quick options for different environments' globals like JSHint does.

In CodeCombat, if I use the array .push() method, it doesn't seem to work (specifically pushing empty arrays.)

Currently it doesn't know, during the transpilation phase, when you try to call a method on this that doesn't exist. It used to guess, just based on a crappy list of common methods that shouldn't be in the Aether repo at all, but I think even that isn't working.

Instead, we should transpile with the this as context so that we can know what methods are and aren't defined (although we'll have to be careful, since the user might define more methods herself). Then we can resurrect the ... has no method X messages and the (did you mean method Y?) messages, maybe even do a little bit of typechecking, etc.

See the CodeCombat Autocomplete interface issue for context. Basically, Aether should be able to provide introspection on available properties for anything so that we can use it to suggest appropriate autocompletions based on their types and values and such. I'll write more about how we might do this later.

At least, that's what I think is happening. See this:

In Greed:

var items = this.getItems();
var peons = this.getByType('peon');
if(peons[0]) {
    var item = peons[0].getNearest(items);
    var index = items.indexOf(item);
    var index2 = _.indexOf(items, item);
    var index3 = items.indexOf(peons[0].getNearest(items));
}

If I hover over index2, I get 6. index and index3, though, are -1.

For each statement, you could also generate a step message of what was achieved, like jsdares does:

Is this worthwhile? @janpaul123, did you see any good results from having the step messages? I'm wondering if it will be redundant with the other hover debugging stuff, or also useful.

In JavaScript, if I try to access an undefined variable, maybe like this:

var foo = 1;
var bar = ofo + 2;

–then it should throw an error, because there is no ofo. But instead, in this transpilation scheme, it just adds 2 to undefined and doesn't throw an error. Maybe we can either find and reverse the behavior that does that, or at least throw an error ourselves.

Because we aren't yet locking down the prototype chain on builtins, this kind of exploit is still possible in multiplayer:

(function(){}).__proto__.constructor("var x=new XMLHttpRequest();x.open('GET','/auth/whoami',false);x.send();var u=JSON.parse(x.responseText);u.name='Lel I Hax U';x=new XMLHttpRequest();x.open('PUT','/db/user/'+u._id,false);x.setRequestHeader('Content-Type','application/json');x.send(JSON.stringify(u));")();

/*
var x=new XMLHttpRequest();
x.open('GET', '/auth/whoami',false);
x.send();
var u = JSON.parse(x.responseText);
u.name = 'Lel I Hax U';
x=new XMLHttpRequest();
x.open('PUT', '/db/user/'+u._id,false);
x.setRequestHeader('Content-Type','application/json');
x.send(JSON.stringify(u));
*/

There is code in localeval starting around L59 that seems to handle this.

1. Will this prevent that attack?
2. Should we use localeval directly or just adapt its code?

I'm working to get these new tests to pass:

  it 'should protect builtin prototypes', ->
    codeOne = '''
      Array.prototype.diff = function(a) {
        return this.filter(function(i) { return a.indexOf(i) < 0; });
      };
      var sweet = ["frogs", "toads"];
      var salty = ["toads"];
      return sweet.diff(salty);
    '''
    codeTwo = '''
      var a = ["just", "three", "properties"];
      var x = 0;
      for (var key in a)
        ++x;
      return x;
    '''
    aether = new Aether()
    aether.transpile codeOne
    fn = aether.createFunction()
    ret = fn()
    expect(ret.length).toEqual(1)

    aether = new Aether()
    aether.transpile codeTwo
    fn = aether.createFunction()
    ret = fn()
    expect(ret).toEqual 3  # <-- fails
    expect(Array.prototype.diff).toBeUndefined()  # <-- fails
    delete Array.prototype.diff  # Needed, or test never returns.

It's pretty hard for me to understand what needs to change with the protectBuiltins stuff, though. @devast8a any pointers?

This might be easy to do with the libs we've already pulled in.

Look at the sin at the top of most of the Aether files:

_ = window?._ ? self?._ ? global?._ ? require 'lodash'  # rely on lodash existing, since it busts CodeCombat to browserify it--TODO

That's not cool. What would be cool? ... ?

Currently, we only support yieldsConditionally and yieldsAutomatically within the top-level function the user is coding, not in any nested functions, because we don't rewrite their calls to those functions to handle the generatorification. Relevant code is here. Instead, we should figure out how to rewrite all user method calls so that we can support the yields inside those functions.

var fooGenerator = foo();
while (true) {
  var result = fooGenerator.next();
  if (result.done) break;
}

This is pretty important for doing more complex plan-based levels in CodeCombat and for the Lua parser that @basicer is working on, which creates a lot of inner functions to make scoping work properly.

See this thread. Basically, things going in and out of function boundaries have API protection applied during the transpiler, which means you can't write their properties. We probably don't need it for this case, since you defined your own function, so any argument you passed to it is already protected.

function test(arg)
{
    arg.id = 3;
}
var o = {id:1};
test(o);
this.say("id: " + o.id"); // always says id: 1

I tried to insert this into every function created, but it's getting JS_WALA normalized away to tmp2 = 'use strict';. Need to insert it after normalization, maybe before any VariableDeclaration node.

Aether should have support for knowing on which line errors happen, sometimes. It now doesn't ever work, so that part is broken. But really a better strategy is needed for transferring and preserving range information throughout the various steps of transpilation. See src/transforms.coffee's makeGatherNodeRanges for the hacky way I've been doing it so far.

Once range information is included in the generated UserCodeProblems, then in CodeCombat they'll automatically start to show line numbers in the error messages as well as showing error annotation cells next to the errored-out lines.

For RuntimeProblems, there's currently a getAnonymousErrorRange attempt that used to sometimes work in Chrome and now no longer works. Instead, runtime errors should know their ranges because of a transform that we run as part of, or in addition to, makeInstrumentStatements, whereby we log the range of the statement we're about to run so that if it errors out, we know where the error was and can attach it to the generated RuntimeProblem. That would also then automatically start showing the ranges properly in CodeCombat.

One working on this would note that makeInstrumentStatements is currently not instrumenting everything we would it to as a statement, so a few more types of AST nodes might need to be handled.

We should also clean up how ranges were being done throughout so that we always had support for both offset-based and row/column-based indexing instead of having to slowly recalculate it in many places.

Most of the statements that one would think of as statements don't actually get captured well after JS_WALA normalization, like a simple variable assignment, so in CodeCombat it looks like that code was not executed.

Two questions:

1. Do we want to migrate aether to brunch like codecombat?
2. Can we add a code coverage component to grunt (like https://www.npmjs.org/package/grunt-istanbul-coverage) or brunch if we switch to that?

Moved from codecombat/codecombat#683

If you type Vector.subtract(a, b); in a spell (confirmed in Dungeon Arena), the spell would fail with the message:

Missing this. keyword; should be this.Vector. There is no function Vector, but this has a method Vector.

While there is a function Vector and this does not actually have a method Vector. The error message prevents the spell from being cast, thus prohibiting use of the class.

See this thread.

Currently we accept the languageVersion option as either ES5 or ES6, but then we ignore it and parse everything with Esprima Harmony (ES6) or Acorn's loose mode (ES5). Hmm. We should either stop pretending the option is meaningful, or make it work.

In languages/javascript.coffee, in the parse method. It shouldn't be used, right? Ranges are used instead. So let's try turning it off.

See the CodeCombat sister issue for context. Basically, Aether should be able to grab and serialize all the variable states we might want to see from a debugging perspective.

It's just a massive file (over 2 MB). If we could remove some big dependencies, we could get it way down.

We haven't fully figured out what to do with statement counting for non-JS languages, which will probably end up generating more statements than writing JS. We might do a per-language statement multiplier, or we might rework the statement counting to weight statements more according to how long they actually take (so calling distanceSquared() would be cheaper than distance()).

Execution time would be better, but then it wouldn't be deterministic and would vary widely from system to system. We can eventually make it smarter until it more closely parallels execution time. At least, that's the hope.

People have problems defining their own functions and then getting this references to work inside them (since this suddenly changes). Even if this is how JS is supposed to work, it's super confusing for most players. Maybe there's something we can do to let them know when we can guess that their this isn't what they are expecting?