Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-14058] Code Processor - Alloy: analyzed code results can be different from the expected ones

GitHub Issuen/a
TypeStory
PriorityLow
StatusClosed
ResolutionWon't Fix
Resolution Date2016-08-24T20:00:39.000+0000
Affected Version/sRelease 3.1.1
Fix Version/sn/a
ComponentsCode Processor
Labelsqe-3.1.1, usability
ReporterFederico Casali
AssigneeChris Barber
Created2013-05-30T23:59:00.000+0000
Updated2017-03-20T20:29:58.000+0000

Description

Problem description

Code Processor results for Alloy projects are based an Analysis on the compiled code in the Resources folder. This could generate unexpected results and parity issues for the end user whose expectations are that the Code Processor is checking his code, as included in the Alloy project 'app' folder, even if the Code Processor is actually correctly analyzing the javascript code compiled by Alloy.

Example:

"ContextTest" sample project

(https://github.com/appcelerator/titanium-code-processor/tree/master/test_projects/ContextTest or attached here in the Jira) In this case, the code to be analyzed is:
(function foo() {
	var x = 10;
	setTimeout(function () {
		console.log(x);
	});

	function bar() {
		console.log(x);
		x = 20;
		require(x);
	}
	if (Date.now()) {
		bar();
	}
})();
console.log(x);
and the result, as expected, is that:
"x" is not defined | app.js | 16 
By placing the same identical code in an Alloy project index.js controller file, the result is a bit different. Attached in the Jira there is the ContextTest sample for Alloy too. After being compiled, the Resources/alloy/controllers/index.js looks like this:
function Controller() {
    require("alloy/controllers/BaseController").apply(this, Array.prototype.slice.call(arguments));
    arguments[0] ? arguments[0]["__parentSymbol"] : null;
    arguments[0] ? arguments[0]["$model"] : null;
    var $ = this;
    var exports = {};
    $.__views.index = Ti.UI.createWindow({
        backgroundColor: "blue",
        id: "index"
    });
    $.__views.index && $.addTopLevelView($.__views.index);
    exports.destroy = function() {};
    _.extend($, $.__views);
    (function() {
        function bar() {
            console.log(x);
            x = 20;
            require(x);
        }
        var x = 10;
        setTimeout(function() {
            console.log(x);
        });
        Date.now() && bar();
    })();
    console.log(x);
    $.index.open();
    _.extend($, exports);
}

var Alloy = require("alloy"), Backbone = Alloy.Backbone, _ = Alloy._;

module.exports = Controller;
so, lines 14 to 26 are the ones regarding the code put in the controller. The code is a bit different (for example the function "bar()" is declared before the 'var x = 10') and the Code Analyzer result is a bit different:
The module "20" could not be found | app/controllers/index.js | 10
"x" is not defined | app/controllers/index.js | 17
In this case the Code Processor is likely behaving correctly, in fact putting the generated code from lines 14 to 26 in a Classic Titanium project, I'm getting the same as the Alloy one. The issue relates in the fact that from the end-user standpoint, the two results should be identical and the user could be easily confused by those results. Attached both the classic and the Alloy 'ContextTest' sample projects and the Code Analyzer Results for each.

Attachments

FileDateSize
Alloy_ContextTest_RESULT.zip2013-05-30T23:59:01.000+00003967728
Alloy_ContextTest.zip2013-05-30T23:59:01.000+00007407552
classic_ContextTest_RESULT.zip2013-05-30T23:59:01.000+000044560
classic_ContextTest.zip2013-05-30T23:59:01.000+00003698133

Comments

  1. Ingo Muschenetz 2013-05-31

    [~tlukasavage] Two quick questions. * Why is the order of the code slightly different in the generated version of the controller? * Should the source map not point us back to app.js, line 16?
  2. Tony Lukasavage 2013-05-31

    * The order is slightly different due to the fact that each controller gets broken down into an AST and then reassembled by uglify-js into code. There are options that can impact this reassembly, but I've never dug into them that much as there's never been a need to this point. I would definitely need a ticket logged to pursue that one further. * No, the second example is in index.js, not app.js, so it is pointing to the correct file. The numbering however seems to be off by a line, but could that perhaps simply be something that happened when the code was copied to another project? I'll bet there was just an additional line break in there. It seems unlikely that numbering is off only because studio debugging has been using it for a while. But I ama bit confused and I read the ticket a few times. What is the expectation if not for the code processor to point back to the correct location in the original controller, because that appears to me what is happening? Am I missing something?
  3. Tony Lukasavage 2013-05-31

    Federico, I agree with you in theory, but comparing an Alloy app and a non-Alloy app for code processor output will practically never happen in real world development. No one is going to write an app twice identically and then compare code processor output, except us of course. ;-)
  4. Bryan Hughes 2013-06-03

    Some quick thoughts: I think this is worth some investigation. Ideally they should produce the same output, but as Tony said there are probably some technical reasons why they may differ. It would be nice if we could really investigate these differences and see if they are worthwhile to invest to time fix, if they are possible to fix.
  5. Tony Lukasavage 2013-06-03

    [~fcasali] would you mind logging a ticket in ALOY for, let's say, "less modified" code generation? This is by no means a panacea, and I'm not certain at this moment how similar to the current code I can keep it, but I can start investigating making less changes to the structure of the code generated by uglify-js's AST parsing. This would not be for Alloy 1.1.3 & TiSDK 3.1.1 though. Heh, version palindrome.
  6. Bryan Hughes 2013-06-03

    IMO, before we start logging tickets, we should investigate a little more to see if "less modified" code actually is the proper approach. Figure out the problem first before we dive in to fix it.
  7. Tony Lukasavage 2013-06-03

    [~bhughes] this is something i've been meaning to start investigating anyway for the sake of when the debugger drops a developer into generated code. It will make for a better experience if the code more closely resembles their original source files. This was more of a "two birds with one stone" idea than it was an effort specifically for this ticket. Also, investigating would be part of the ticket as mentioned in my previous comment.
  8. Bryan Hughes 2013-06-03

    Ah, I gotcha now. Ticket away :)
  9. Chris Barber 2016-08-24

    Code processor is dead.
  10. Lee Morris 2017-03-20

    Closing ticket as Code processor is no longer supported.

JSON Source