Error 'Function "compiledC" not found!' in deployed module using tutorial

Fri 2018.09.21

Using code snippet under heading 'Adding code to a module'

ref: http://www.espruino.com/InlineC

Snippet works when using in a monolithic file between var exports={};
output is

print( c.lookup(3) );
=44

as expected

Verifying

'Adding inline C to a module is easy - just write the Inline C as you would normally do, then export it:'

But, when deployed to GitHub

>Uncaught Error: Function "compiledC" not found!
 at line 8 col 11
var c = E.compiledC(`

Code file

>var c = require("https://github.com/sleuthware/EspruinoDocs/blob/master/modules/moduleInlineCTest.js");

print( c.lookup(3) );

Deployed module

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;

EDIT Sun 2018.09.23
From #4 below

'From where is the > sign come in'

Forum post edit error - quote button slip instead of code button - the fix - for right editor pane

var c = require("https://github.com/sleuthware/EspruinoDocs/blob/master/modules/moduleInlineCTest.js");

print( c.lookup(3) );

Short answer: works as designed.

Long answer will explain why module code cannot include C source.

Will provide link to long answer in a future post.

Edit: there is some misunderstandings going on... I interpreted the line

>var c = require("https://github.com/sleuthware/E­spruinoDocs/blob/master/modules/moduleIn­lineCTest.js");

as being executed in the console, because it has the leading > console prompt. The issue is though something totally different, as posted in #6 (post #6 provides the answer and replaces the promised link).

Sat 2018.09.22

re: 'Long answer will explain why module code cannot include C source.'

Under the same heading from documentation link in #1 above:

'The module itself will contain the C source code, but the IDE will detect the code on upload and will automatically compile it for the board you're uploading to.'

My belief is that the time taken to document the process wouldn't have been done, if it wasn't in fact possible.

From where is the > sign come in the line >var c = require("https://github.com/... of 'Code file?

Another question I have is: I've seen this expression

...between var exports={};

What is the second part of 'between'? Could you give me a screenshot of (or complete copy from) Espruino Web IDE editor pane?

I have the feeling not all details are shown in the post to assess the situation, because it does not matter from where IDE uploader (not the console or Espruino interpreter on the board) gets the module to send it to the C compiler service, get the compile code back, and upload it (with a JS wrapper) to the board.

Sun 2018.09.23

re: 'From where is the > sign come in'

See #1 fix under EDIT

re: I've seen this expression ...between var exports={};

See: http://www.espruino.com/Writing+Modules

comment, just below first blue code block.


Redundant var exports={}; and for snippet explanation un-necessary, as mentioned in above test file, per the instructions from Writing+Modules, but as you insist, here it is:

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={};

re: 'I have the feeling not all details are shown'

Two lines of code to access the module (#1) and one could also load/view the deployed module into a browser by using the URL within the require() declaration.

@Robin, now I understand why it goes side-ways for you:

On Writing and Submitting Modules (or changes), it says:

To test out your module, we'd suggest that you copy it verbatim into the right-hand side of the Web IDE, with the line var exports={}; at the top, and at the bottom, where you use the module, write exports.myfunction() instead of require('MOD123').myfunction().

which means something else in regard to the ...between... you paraphrase it. Try to read it this way:

To test out your module, we'd suggest that you copy it verbatim into the right-hand side of the Web IDE, with the line var exports={}; at the top. *( Fullstop - that is dealing with the top before the module code - then: )*At the bottom, where you use thje module, write exports.myfunction() INSTEAD of require('MOD123').myfunction();.

This reading (interpretation) is corroborated by the code example just above this text.

For your example, the working code reads:

// testingInlineCompiledCInModule.js

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;

// usage (require) of the module with inline, compiled C:
// var lookup = require("lookup.js"); // commented and instead using:
var lookup = exports;

// usage (invocation) of the module with inline, compiled C:
function callLookup() {
  console.log(lookup(13)); // shows 5 in console
}

function onInit() {
  callLookup();
}

setTimeout(onInit,1000); // convenience; while developing...

Take a shot at it (...cannot guarantee for the C part... ;) )

Now we have the between out of the way, let's look what it actually did: The 2nd var exports = {}; just killed what was setup for exports just before. So even if you (would) have used the module correctly, it would never be there, because c was just an empty object again.

It is not about insisting on being as complete and detailed as possible in the forum. It is for everyone on the forum who wants to help, understand the issue and how come the issue in order to find a solution to overcome what ever road blocks. Everyone works out of their context and sometimes this context is more fare from than close to common, especially when coming from all walks of IT.. So please accept your questioning as the expression of being helpless to provide help... ;-)

Every issue is an opportunity... and in this case better phrasing and may be providing the example literally would prevented the rabbit trail with hole as trap at end.

Looking forward to more conversations from you. - aO

Has something changed? I just ran the code you're using:

var c = require("https://github.com/sleuthware/EspruinoDocs/blob/master/modules/moduleInlineCTest.js");
print( c.lookup(3) );

and it works perfectly for me. What IDE version are you using? If you've installed an older IDE on Windows and not updated it in a while then modules won't get parsed for compiled code. However if your IDE is up to date then they will be.

Mon 2018.09.24

@allObjects, not having any issue with the development of a module running in the IDE. It's the deployment part. Gordon understood what the issue is.

Thought the title 'in deployed module' was explicit enough. Thanks for the clarification however. Incidentally, works either with or without the second occurrence.

and, . . . who would have guessed we would have had so much fun over a comma!!? ROTFLOL

Mon 2018.09.24

@Gordon,

re: 'Has something changed?'

No. I just ran it again, and get the same error.

re: 'If you've installed an older IDE on Windows and not updated it in a while'

What is "in a while" mean to you? A 'while' to me is a year or more. But, as I started up this new phase of development, I installed the latest version 68.6 around five to eight weeks ago, right off the link on the Espruino site. Haven't seen any pressing announcements to upgrade since then, so had no need to do another install.

Where is the version change log for the native IDE?

https://github.com/espruino/EspruinoWebIDE/blob/gh-pages/README.md
https://github.com/espruino/EspruinoDocs

did find the one for Espruino, but not the IDE
https://github.com/espruino/Espruino/blob/master/ChangeLog

If this is part of the issue, I'd like to see if there were other changes that are affecting my progress here. Such as folder mapping or module retrieval, for instance.

@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...

I installed the latest version 68.6 around five to eight weeks ago

Then yes, it's time to upgrade :) The 'native' version is the only one without an update system - the other IDEs (Chrome app, or online) would have auto-updated themselves.

It's definitely worth updating your Pico firmware to a cutting edge build if you haven't already as well as I made some changes to the firmware to make USB uploads more stable after you had those issues.

There is no ChangeLog on the IDE I'm afraid - you'll just have to look at the Git logs for:

https://github.com/espruino/EspruinoWebIDE/commits/gh-pages
https://github.com/espruino/EspruinoTools/commits/gh-pages

Just to add that as @allObjects says, you need to be careful with repeated var exports = {}; in modules. As I mentioned in another thread of yours just now, exports isn't magic - it's the value in it after the module has executed that is used, so if you do exports = all_my_stuff; .... exports = {} then all you'll see in exports at the end of the module is {} - and when minified all the code before may even be 'optimised' out :)

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.

I'm still seeing IDE hangs regularly, which can only be fixed by powering down and closing the IDE

With the old IDE? That makes sense, because I fixed something a month or so ago that could cause hanging.

IMO you're better off starting from scratch - update the IDE, update your Pico's firmware to cutting edge - and see what happens then. It'll make your life way easier.