Loading Texture (image) and additional scripts in mod

Question

Loading Texture (image) and additional scripts in mod

Closed this issue 5 years ago · 13 comments

I'm working on getting the piu/balls example running as a mod, but struggling to get the balls.png Texture loaded. The mod breaks on throw new URIError("Texture " + it + " not found!"); I'm guessing that the Texture is expecting a url, but the image isn't included when building the mod from source (or the path changes, or the context is runmod and not the actual mod)?

This also happens when trying the scroller example: the require breaks on importing the scripts (example works fine when running w/o runmod, or when bringing the scroller classes into the mod.js script)

Wi-Fi connected to "HOME-123"
IP address 10.0.0.4
host ready
/Users/nickreed/Projects/moddable/examples/experimental/runmod/main.js (182) # Break: require: module "scroller" not found!

I'm also unclear as to where main.act is used by the example.

Answer 1 · 2019-05-06T19:08:35.000Z

Are you including the image and the scroller module in the manifest of your mod?

Answer 2 · 2019-05-06T19:11:09.000Z

Yes, although I think the ping mod actually answers my question pretty well.

The ping protocol is included in the Moddable SDK. However, it is not built into the runmod host. Therefore, the ping mod must include the ping module in its archive. To do that requires building both modules independently using xsc and linking them together using xsl:

I'm a bit unclear on how exactly to fix the scroller or piu/balls mod examples, but I think it is possible using the linking.

Answer 3 · 2019-05-06T19:23:30.000Z

My scroller mod's manifest.json:

{
	"include": [
		"$(MODDABLE)/examples/manifest_base.json",
		"$(MODDABLE)/examples/manifest_piu.json",
	],
	"creation":{
		"stack":350,
	},
	"modules": {
		"*": [
			"./mod",
			"./scroller"
		]
	},
	"preload": [
		"scroller"
	],
	"resources":{
		"*-alpha": [
			"$(MODDABLE)/examples/assets/fonts/OpenSans-Regular-20",
		],
	},
}

Answer 4 · 2019-05-06T22:24:38.000Z

Whoops, I forgot you had to run xcs and xsl manually here. A new command line tool was just (as in, an hour ago) added to the Moddable SDK that simplifies the process of uploading mods. It's called mcrun. The source code is here.

To use it, install the host as usual using mcconfig. Then install the mod using mcrun, which takes the same arguments as mcconfig. So, for example:

cd /path/to/runmod
mcconfig -d -m -p esp/moddable_zero
cd /path/to/mod
mcrun -d -m -p esp/moddable_zero

Answer 5 · 2019-05-06T22:26:29.000Z

Also, I recommend doing a clean build of tools before you use mcrun. So after you pull from top of tree, do the following:

Delete the $MODDABLE/build/tmp folder
Delete everything in the $MODDABLE/build/bin folder
Rebuild tools
```
cd $MODDABLE/build/makefiles/mac
make
```

Answer 6 · 2019-05-07T00:22:25.000Z

I'm assuming the runmod instructions for replacing the xsPlatform files (and modPreference.c in modules/files/preference/) is still valid?

It also appears that building the wasm tools in ubuntu doesnt work (after installing emscripten):

root@6c308cac8e17:~/Projects/moddable/build/makefiles/lin# cd $MODDABLE/build/makefiles/wasm
root@6c308cac8e17:~/Projects/moddable/build/makefiles/wasm# make
make -f tools.mk
make[1]: Entering directory '/root/Projects/moddable/build/makefiles/wasm'
# tools debug : cc wasm_xs.c
cache:INFO: generating system asset: is_vanilla.txt... (this will be cached in "/root/.emscripten_cache/is_vanilla.txt" for subsequent builds)
cache:INFO:  - ok
shared:INFO: (Emscripten: Running sanity checks)
# tools debug : cc xsAll.c
# tools debug : cc xsAPI.c
# tools debug : cc xsArguments.c
# tools debug : cc xsArray.c
# tools debug : cc xsAtomics.c
# tools debug : cc xsBigInt.c
# tools debug : cc xsBoolean.c
# tools debug : cc xsCode.c
# tools debug : cc xsCommon.c
# tools debug : cc xsDataView.c
# tools debug : cc xsDate.c
# tools debug : cc xsDebug.c
# tools debug : cc xsError.c
# tools debug : cc xsFunction.c
# tools debug : cc xsGenerator.c
# tools debug : cc xsGlobal.c
# tools debug : cc xsJSON.c
# tools debug : cc xsLexical.c
# tools debug : cc xsMapSet.c
# tools debug : cc xsMarshall.c
# tools debug : cc xsMath.c
# tools debug : cc xsMemory.c
# tools debug : cc xsModule.c
# tools debug : cc xsNumber.c
# tools debug : cc xsObject.c
# tools debug : cc xsPlatforms.c
# tools debug : cc xsProfile.c
# tools debug : cc xsPromise.c
# tools debug : cc xsProperty.c
# tools debug : cc xsProxy.c
# tools debug : cc xsRegExp.c
# tools debug : cc xsRun.c
# tools debug : cc xsScope.c
# tools debug : cc xsScript.c
# tools debug : cc xsSourceMap.c
# tools debug : cc xsString.c
# tools debug : cc xsSymbol.c
# tools debug : cc xsSyntaxical.c
# tools debug : cc xsTree.c
# tools debug : cc xsType.c
# tools debug : cc xsdtoa.c
# tools debug : cc xsmc.c
# tools debug : cc xsre.c
# tools debug : cc xsa.c
# tools debug : cc xsc.c
# tools debug : cc xslBase.c
# tools debug : xsc commodettoBitmap.js
/root/Projects/moddable/build/bin/mac/debug/xsc: 1: /root/Projects/moddable/build/bin/mac/debug/xsc: �������: not found
/root/Projects/moddable/build/bin/mac/debug/xsc: 2: /root/Projects/moddable/build/bin/mac/debug/xsc: zg�: not found
/root/Projects/moddable/build/bin/mac/debug/xsc: 3: /root/Projects/moddable/build/bin/mac/debug/xsc: �__stubs__TEXT: not found
/root/Projects/moddable/build/bin/mac/debug/xsc: 4: /root/Projects/moddable/build/bin/mac/debug/xsc: r�: not found
/root/Projects/moddable/build/bin/mac/debug/xsc: 5: /root/Projects/moddable/build/bin/mac/debug/xsc: Syntax error: word unexpected (expecting ")")
tools.mk:275: recipe for target '/root/Projects/moddable/build/tmp/wasm/debug/tools/modules/commodetto/Bitmap.xsb' failed
make[1]: *** [/root/Projects/moddable/build/tmp/wasm/debug/tools/modules/commodetto/Bitmap.xsb] Error 2
make[1]: Leaving directory '/root/Projects/moddable/build/makefiles/wasm'
makefile:29: recipe for target 'debug' failed
make: *** [debug] Error 2

Is it mac-only for now?

I was hoping to create a docker image to handle building mods, then a simple mobile app for updating a mod on a device.

Answer 7 · 2019-05-07T00:59:37.000Z

wasm is its own special adventure. Getting it set-up for a given environment isn't always easy. Yes, we build on macOS but there's nothing about the wasm build that requires that. We are definitely not at the point of providing support for building with wasm.

The patches still apply for building a useful runmod. modPreference.c is now part of the Moddable SDK so I've removed that. Thanks for the reminder.

Answer 8 · 2019-05-07T02:42:42.000Z

I was hoping to create a docker image to handle building mods, then a simple mobile app for updating a mod on a device.

That would cool. THere's no particular reason to use wasm for that. If you are running the tools in the cloud, you can just run the native command line tools for your host platform.

Answer 9 · 2019-05-07T06:07:11.000Z

If you are running the tools in the cloud, you can just run the native command line tools for your host platform.

I'm a bit confused as to the pieces required. My understanding is:

use mcconfig for building and deploying runmod to my m-zero
then I can use mcrun /path/to-mod to build the modballs mod.xsa file (which gets put into modballs/build/)
then my m-zero starts up, connects to wifi, and creates a websocket endpoint at runmod.local:8080, which I can use to install the mod (ideally just using cURL)

Am I incorrect in my assumptions? I think this avoids having to install the wasm dev tooling, with the side effect being no debug tooling for mods?

Or does mcrun require wasm builds?

Currently, running mcrun in the modballs directory (on mac, no docker) results in an error with the esptool (note that running mcconfig for installing runmod worked fine):

$ mcrun -d -m -p esp/moddable_zero
make: esptool.py: No such file or directory
make: *** [debug] Error 1

Answer 10 · 2019-05-07T18:13:39.000Z

Let's try to untangle things.

mcrun is a tool in the Moddable SDK. All tools are available as native command line tools built for your host platform. They have nothing to do with Web Assembly. We also provide an experimental WebAssembly version of most of those same tools for execution in the browser.

This works well for me on macOS this morning:

Reset your device to a known state: esptool.py erase_flash
Build run mod: mcconfig -d -m -p esp/moddable_zero ssid="moddable-guest" (change to the appropriate directory)
Build modballs mcrun -d -m -p esp/moddable_zero (change to the appropriate directory)
That should start bouncing and connect to xsbug. Sometimes the ESP8266 doesn't reset properly, so press the reset button.

Answer 11 · 2019-05-07T18:33:48.000Z

Thank you, I'll get that working.

To untangle a bit further: can I separate build/deploy? I'd like to run the build step for the mzero (mcconfig -d -m -p esp/moddable_zero ssid="moddable-guest") in linux (some cloud server), and then get the built files, and deploy using esptool.py path/to/my/bundle (or similar) from my mac.

Same for mods: build in the cloud, deploy from somewhere else?

As best I can tell, from the mcconfig makefile source and tool documentation, there is no flag for "build, don't write" or "write using files from X build directory;" the generated makefile will always build, and always try to write.

Answer 12 · 2019-05-08T18:46:27.000Z

The build provided in our repository does both build and deploy. That is correct. It isn't particularly difficult to modify that behavior, but it isn't something we have yet seen a need to officially support. Adding features to the build is a significant undertaking as there are three different hosts (macOS, Linux, Windows) and many different microcontrollers (ESP8266, ESP32, Gecko family, Qualcomm).

Answer 13 · 2019-05-08T18:53:15.000Z

Am I correct in thinking that the modification would be:

Add new flag to mcconfig (and mcrun that gets passed to mcconfig) to suppress deploy
Modify makefile template to use flag to exclude the esptool.py deploy lines

Not diminishing the effort required, just trying to spec a little. Is this something you'd accept a PR for?