"Native OS Module not implemented" error

Monkey Targets Forums/HTML5/"Native OS Module not implemented" error

Arjailer(Posted 2015) [#1]
I'm trying to get an existing code-base (~160 source files) running on HTML5. Until now I've only ever built it as GLFW.

I'm getting a "Native OS Module not implemented" error in the OS module. I understand that the OS module is for desktop builds only and as far as I can see I'm not using any of the OS methods. I've searched the codebase for all the method names listed in the OS module and the only matches I had were for LoadString and ExtractDir, but I'm using the mojo.LoadString and filepath.ExtractDir versions which I believe should be fine.

Obviously I'm not going to post my entire game here :-) But does anyone have any clues as to how I might go about finding the culprit?


bitJericho(Posted 2015) [#2]
Do you have "Import os" at the top of your code? If so, you need to remove this for the html5 build. The best way to do this is as follows:

#if TARGET<>"html5"
Import os
#end


Arjailer(Posted 2015) [#3]
Nope, no "import os" in any of my code.


bitJericho(Posted 2015) [#4]
Perhaps you're using a third party module that is importing it. Does monkey output a list of the locations that led up to the error? What is the full error message?


Arjailer(Posted 2015) [#5]
The entire compiler output is:

C:\Documents\Programs\MonkeyXPro85b\Bin\transcc_winnt.exe -build -config=debug -target=Html5_Game   "C:/Documents/Development Projects/Monkey X/Sandbox/Sandbox/sandbox.monkey"
TRANS monkey compiler V1.86
Parsing...
C:/Documents/Programs/MonkeyXPro85b/modules/os/os.monkey<14> : Error : Native OS Module not implemented
Abnormal program termination.
 Exit code: -1


... so not very useful :-(

I'm using a handful of third party source files, but I'm including those when I say "no import os in any of my code" and I'm not using any other third party stuff.

Obviously something is using the os module, but it doesn't appear to be my own code and I can't figure out what is using it :-(


bitJericho(Posted 2015) [#6]
Hmm mojo.LoadString and filepath.ExtractDir work on html5 for me. Perhaps you could temporarily remove os.monkey and see what is calling it that way. Perhaps it will error out saying that the module was not found.


Arjailer(Posted 2015) [#7]
Ha! Renaming "os.monkey" (to "_os.monkey") makes the build work and the game runs. Strange ...


bitJericho(Posted 2015) [#8]
Oh yes I see this is normal behavior I guess. Hmm puzzling! Well something somewhere is calling os.monkey. You could find it by using edit > find in files and checking your project and any modules you are importing.


Arjailer(Posted 2015) [#9]
Did that already (see my first post).

I searched every file in my source and the build folders for "os" and every method name listed in the os.module documentation and couldn't see anything :-(


ImmutableOctet(SKNG)(Posted 2015) [#10]
If you really want to figure out what's importing 'os', then unfortunately you'll have to rebuild transcc (Which isn't that big of a deal). I've done this kind of thing before, most notably when I was porting code from Mojo to Mojo 2, and I had a ton of imports to the original Mojo.

Basically, you'll want to either call 'DebugStop' on this line, or output every time you import a module. For the sake of keeping things simple, the first option is better.

From there, simply rebuild the "src/transcc/transcc.monkey" file in debug mode (Using the "C++ Tool" target), then (Ideally) move the binary ("transcc.buildvVERSIONHERE/cpptool/main_INSERTHOSTHERE") to your Monkey installation's "bin" folder. Now, rename your existing version of "transcc_INSERTHOSTHERE" to whatever you want, then rename your new binary to the previous name of your transcc version.

After that, try building again. It'll take longer (Since it's a debug build), but when it gets to the error, you can look at the module-paths using your IDE's debugging functionality (Right side of Ted). When you're done debugging, make sure to switch back to your original version, as it will run faster.

For future reference, whatever module is using 'os' should switch to the 'brl' modules, as 'os' is technically deprecated.


Arjailer(Posted 2015) [#11]
Thanks, though it doesn't look like it's my code that's referencing os.module at all as I can delete the os.module file and my code will build and run fine in both HTML5 and GLFW3.

Something is pulling os.module in, but none of my source files are directly referencing it and whatever is pulling it in doesn't actually appear to use it.


Nobuyuki(Posted 2015) [#12]
You have to understand that transcc culls unreachable code before compiling it. Maybe not before attempting to import it, however. I can almost guarantee you that OS is being imported somewhere, maybe a third party library. Since OS is depreciated, nothing should really use it. It is used for command line template in jungle IDE to access arguments, however, that functionality has been superseded by brl.process, and I'm guessing that Ziggy just hasn't gotten around to updating the template. I don't know anywhere else that the OS import would be called accidentally without your knowledge, unless it's used in some third party library...

I recommend taking your entire modules directory, and also your source code project directory, and using an automated search on ALL monkey files contained therein for either "import os" (case insensitive) or "Alias". Or take immutable octet advice and recompile transcc. Skipping out on this runs the risk of this problem coming back to haunt you later, especially considering your work around is altering a core module, however depreciated that module may be.


Arjailer(Posted 2015) [#13]
I should've mentioned this at the beginning, but before I started this thread I did a grep on all my *.monkey files for "import os", "os" (whole word matched) and "os." (nothing for any of them). I then did a grep of *all* files (including the build folder) for the same (nothing suspicious, a few "pos.x" and "pos.y" hits in GLFW3 source, some mentions of "OS X" in comments and string constants). I then pulled up the os module help and greped all files for all the function names listed and the only matches (other than comments and a reference to a genenv function in one of the GLFW3 source files) were for LoadString and ExtractDir, but I was already using the mojo.LoadString and filepath.ExtractDir versions as I knew the os module was deprecated.

The only modules I use are two single file ones: Skn3's Xml Module (https://github.com/skn3/xml, only uses the os module in one example, not in the actual module), and AngelFont (which originally used os.LoadString but I long ago changed this to mojo.LoadString) and both of these were included in the searches described above.

I've now also searched for "alias" with the only hits being in comments.

So I'm pretty confident when I say that none of my source files are referencing the os module :-)

Clearly I'm missing something and it looks like recompiling transcc might be my only option for finding out what, though it seems like a bit of a nuclear option ...


Arjailer(Posted 2015) [#14]
Turns out (after rebuilding transcc as ImmutableOctet suggested) that I had imported trans.trans at some point (which in turns imports the os module).
I think I added the trans.trans import to my framework at some point last year when I inadvertently used ExitApp instead if EndApp and then promptly forgot it was there.

I removed the import (and nothing else) and now everything runs fine in HTML5.

So, thanks everyone for your help :-)