• @Robin,

    having this code - from post #5 -

    var exports={};
    var c = E.compiledC(`
    // double lookup(int)
    double lut[8] = {
     41,42,43,44,45,46,47,48
    };
    double lookup(unsigned int x)
    {
      return lut[x&7];
    }
    `);
    exports = c;
    var exports={};
    

    in local on level 0 and working - like with

    console.log(exports(44));
    

    as next piece of code as uploaded (or issued in console after uploading), defies gravity... and leaves me speechless... and so does '...running in the IDE' and '...Incidentally, works either with or without the second occurrence'. ...obviously writing I still can and therefore this post ;-) ... just not talking... talking would be useless anyway since it is not an audio forum ;-)

    --- Again: '... w/ or w/o second occurrence...' says that there is a first occurrence... and I can tell you that putting the first occurrence w/ or w/o second in module code and pull the module in with require("... - from where ever it is deployed - it will NOT work... because the variable scope / definition of 'exports is outside of - or global to - the module... --- BUT: ...marvelously - or as designed - if you do NOT have the first occurrence, but only 'the second one' in a 'deployed' module, it works,... it works as long as everything has been set using the one that was already defined and provided to the module. Defining exports in the module creates a locally scoped exports and lets the externally provided exports reference go / hide it it from the module context. Any Setting or populating the local object will not bee seen by the require("... and not returned buy it. Tying to use any of the expected things will fail, because they were done to a local variable that by that time already may be garbage collected.

    May be we should take a break from this thread and resume at a later time.

    PS: Writing about how modules work is back on the plate...

  • Tue 2018.09.25

    For the record: There have never been any references on my part to placing var exports={}; in a deployed module, ever.

    One could re-read #1 and load the deployed module in a browser to verify.


    'having this code - from post #5'

    There was no need for me to even post that. The tutorial is fine and explains the necessary testing process. Did that for your benefit from your insistence #4 that I post code to review the testing of a pre-deployed module as explained in the tutorial.


    'and I can tell you that putting the first occurrence . . . from where ever it is deployed - it will NOT work.'

    It is being misunderstood which code snippet goes with which situation.

    The pre-deployed test file or the two lines of code calling the deployed module.

    The discussion started on the deployed code issue, for which there is the link to actually see what code lines are there. The tutorial for this part was fine and I had the working editor side pre-deployed 'wrapped' module working as indicated in #1.

    The responses that I see, should be about solving the deployed situation, not the testing of the pre-deployed 'wrapped' module in the editor window for which I thought you cleared up the comma-'and' reference. and to add, this has always worked as I pointed out in #1.

    In any event, Gordon validated and presumes a solution in #7 above. Hint: It's not the code.


    @Gordon,

    re: 'Then yes, it's time to upgrade :)'

    I was holding off performing either upgrade, until I am convinced that the situations I'm seeing are other than logic issues. Once upgraded, it will be next to impossible to rule out what is causing these headaches. Didn't want to throw in more levels of combinations and permutations in the mix to muddy the waters. I'm still seeing IDE hangs regularly, which can only be fixed by powering down and closing the IDE and the ongoing issue where uploading and syntax checking gets slower and sllooowwwwer on large files edited in the right-hand pane.

About

Avatar for Robin @Robin started