Where is the logic for writing a new mod? about runmod HOT 11 CLOSED

Question: Should I be able to use the old method of flashing (from the http commit), alongside the new WS method?

Yes. They are two different ways to write the same data to the same location.

from runmod.

Working, thanks!

from runmod.

Where in the main.js or main.c is logic for installing a mod

The answer is in Issue 3, titled "Current install mod state? (http removed?)" opened by you.

from runmod.

I meant, where is the code for installing/flashing a mod? The Execution Environment section says the mod is dynamically loaded (via the require('mod') line I expect), but I can't follow how that comes into existence (in the http or websocket code).

I guess I expected to find a "store this xsa data as the mod" function somewhere, but it doesn't appear to be in this repo (part of the base xs language?). This repo's main functions seem to just load the current mod and setup a websocket connection, but don't actually handle loading a new mod.

from runmod.

I meant, where is the code for installing/flashing a mod?

The link in Issue 3 to the commit is what you are looking for, if I understand you well. It contains the excised ModServer which is the support for receiving an upload of a mod an installing to the correct location in flash. The mod install process begins at line 68.

I guess I expected to find a "store this xsa data as the mod" function somewhere

When getting acquainted with a new code base, it is best to leave expectations behind. Not every environment works the same. Not everyone writes code in the same way.

from runmod.

The mod install process begins at line 68.

Thank you, I'll keep trying that route. The WS missing all that stuff had me concerned, and I wasn't able to get deploy working using that commit after a day of hacking. I think I may have a mismatch with the modPreference, or xsPlatform files.

Question: Should I be able to use the *old* method of flashing (from the http commit), alongside the new WS method? The old code had both alongside, so I don't expect a problem when adding http back, but I wanted to verify the flash/storage of the xsb is the same. I feel like using the old commit with the updates to the base platform is just asking for problems, and having a dedicated http endpoint for installing a new mod is useful (requires no tool install, just the built xsa and curl).

When getting acquainted with a new code base, it is best to leave expectations behind. Not every environment works the same. Not everyone writes code in the same way.

Exactly why I posted my perspective, hoping you'd tell me how wrong I was :) Apologies if some of these questions are really basic or wildly off-base.

from runmod.

Able to get modballs deployed (thanks!), but spent some time on converting piu/drag or piu/scroller, and failed at both. Those include examples on using multiple js files, as well as touch input, and fonts.

I tried updating the runmod manifest.json to include the $(MODULES)/pins/digital/* modules, and preload digital as well as increase the creation.stack, config.touchCount, and resources (for fonts) as necessary, but it fails in a way that unreadable debugging output starts going to the console instead of xsbug.

Would it be possible to have piu/scroller or piu/drag converted to a mod format, along with changes required to runmod's manifest? Those examples go a long way towards making it simpler to create a "full" app interface through runmod on the mzero.

from runmod.

In requesting many changes to runmod, you seem to be assuming you know why your attempt to deploy the Piu drag failed. I don't see anything to back that up.

from runmod.

Sorry, not quite sure what you mean by "requesting many changes to runmod." Not trying to be coy; the deploy works, it just doesn't run the mod and I'm struggling to get debugging working.

When trying to build a drag mod using mcrun, I would receive an error

$ cd modscroller
$ mcrun -d -m -p esp/moddable_zero
# xsc pins/digital.xsb
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:21: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:21: error: missing }!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:21: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:22: error: invalid token static!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:22: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:22: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:23: error: invalid token static!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:23: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:23: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:25: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:25: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:26: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:26: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:27: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:27: error: missing ;!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:28: error: invalid character @!
/Users/nickreed/Projects/moddable/modules/pins/digital/digital.js:28: error: missing ;!
### 17 error(s)
make: *** [/Users/nickreed/Projects/moddable/build/tmp/esp/debug/moddrag/files/pins/digital.xsb] Error 22

which I took to mean that I needed to add "$(MODULES)/pins/digital/*", to modules, and "digital" to preload (in runmod's manifest.json).

Then, deploying/installing the mod seems to work fine (it builds the xsa, and the install on mzero is confirmed), and I can switch back to running modballs or another mod example (using the http install I added back in), but I don't have insight into debug messages because the terminal starts receiving garbled logs, instead of xsbug. I'm trying to get more insight, but visibility is lost as soon as my mod attempts are loaded.

I'm assuming that I simply have a misconfigured runmod manifest.json, or mod manifest.json, causing the broken debugger (everything is fine with modballs) and inability to run the mod (screen stays blank).

from runmod.

When trying to build a drag mod using mcrun, I would receive an error

It appears you are simply re-using the drag application's manifest intended for use with mcconfig and hoping it will work with runmod. It did not.

Here's the fundamental problem. This project is an advanced topic. The documentation states that. The fact that it is hosted outside the Moddable SDK suggest that. You are cutting your teeth on the Moddable SDK with it. It isn't a good idea. There's that's too much to learn at once. While your enthusiasm and persistence are appreciated, the time you are taking prevents actual progress on the project to make it accessible to many more people. Perhaps it would be apppriate to wait a bit, learn the fundamentals of the Moddable SDK, and re-engage on this project later.

from runmod.

It appears you are simply re-using the drag application's manifest intended for use with mcconfig and hoping it will work with runmod. It did not.

I did put in a bit more work (and documentation and source reading and debugging) than just blindly tossing values into the manifest :) But, I definitely don't fundamentally understand most of what is happening in the handoff/running of the mods.

Perhaps it would be appropriate to wait a bit, learn the fundamentals of the Moddable SDK, and re-engage on this project later.

;) posed that in a different thread I think. I appreciate the candor and am happy to wait and see how runmod develops. Apologies if I hindered anything!

from runmod.