Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andy Carle
    @PrototypingAndy_twitter
    For the XS engine itself, the Moddable SDK strips unused features by default. See Strip Unused Features in the "XS Differences" document and the associated note in the manifest documentation. If you're talking about application files, the build tools just go by what they're told to do in the manifest.
    Daniel Ashcraft
    @dashcraft

    Good question, im contemplating some build tooling similar to what I get in web. If I use import { debounce } from 'lodash' for instance, it won't import
    the entire library, but it'll import the destructured method that's used and the rest of the dependencies "shake" off so to speak.

    I'm interested if anyone has used a bundler or js minifier with success, up to and including tree shaking, to reduce end bundle size.

    I apologize in advance for my lack of knowledge in this area, I'm used to the web world and I'm contemplating building an expressJs like router for
    moddable sdk wanted to make sure i didn't go down a path that left too many unused deps
    Peter Hoddie
    @phoddie
    Minifiers for the web are generally focused on making the JavaScript source text small. On an embedded device with the Moddable SDK the JavaScript is usually precompiled so shrinking the source text isn't always helpful. In some cases, it can make the code bigger. For example, a minifier may replace "false" with "!1" to save three byes. But, it will generate bigger (and slower) bytecode when built for embedded. Similarly, many of the goals of a bundler aren't really meaningful with the preload feature of the XS linker.
    All that said, like expressJs should very much be possible. The full expressiveness of JavaScript is there. The difference is that using it efficiently for embedded is often quite different from the web world.
    Some form of tree shaking for modules should be possible and would be great for helping keep firmware sizes down. It just looks like a non-trivial project to sort out the right place to start and how to integrate that through the build.
    Daniel Ashcraft
    @dashcraft

    Hmmmm very interesting. Is there any current moddable sdk npm style packages that have been used and work well that I could emulate?

    I also have some resources in the webpack and older gulpjs community I might be able to leverage.

    Peter Hoddie
    @phoddie
    Sorry, no NPM packages (hard as that may be to believe!)
    Peter Hoddie
    @phoddie
    Each .js fie in $MODDABLE/modules/ is a real ECMAScript module. It should be straightforward to put together an npm style package for them.
    Daniel Ashcraft
    @dashcraft
    @phoddie are there any plans for js sandboxing or using vm's for dedicated isolated app environments?
    Peter Hoddie
    @phoddie
    XS is the only engine to implement Secure ECMAScript natively. That provides Compartments which is a low-overhead way to virtualize/sandbox JavaScript code. The Secure ECMAScript section of this blog post is a good place to start learning about that, though a few of the details are out-of-date.
    This talk includes a demo of using Secure ECMAScript to sandbox JavaScript extensions to the firmware of a lightbulb. It is from a meet-up sponsored by Agoric, the folks who have been working on JavaScript virtualization longer than anyone.
    Daniel Ashcraft
    @dashcraft
    Very interesting, very very interesting
    Daniel Ashcraft
    @dashcraft
    Probably a question that's answered somewhere in the docs, but how do you parse a posted body through the http server?
    I'm trying to acccess incoming headers and data/body
    Daniel Ashcraft
    @dashcraft
    I’ve actually figured out headers, working on bodies, disregard
    Peter Hoddie
    @phoddie
    The httpserverputfile example is a good place to start for receiving the body in chunks.
    Daniel Ashcraft
    @dashcraft
    Another potential silly question, i don't see many docs explaining nested file includes. It seems as though each
    file needs to be included as a module. Are there examples i can reference for local nested file includes?
    image.png
    fwiw, i have this working fine
    Peter Hoddie
    @phoddie
    Forgive me for answering with a silly question, by "nested file includes" what specifically do you want to do?
    (Express? Spiffy!)
    Daniel Ashcraft
    @dashcraft

    if i have a folder structure
    -main.js
    -libs
    --lib.js
    --another-lib.js

    Is there a way for me to not have to specifically include each file in the manifest.json
    I tried, "./libs/*" and it only includes the root file not subsequent files

    Peter Hoddie
    @phoddie
    Understood thanks. Yes, you can do that. If you have several modules in a directory, use the * wildcard. You can also alias the path. Here's a quick modification o the helloworld manifest to show how. the source directory is named "lib" but the modules will be available at "library/" instead of "lib/". The preload section also supports wildcards.
    {
        "include": "$(MODDABLE)/examples/manifest_base.json",
        "modules": {
            "*": [
                "./main"
            ],
            "library/*": "./lib/*"
        },
        "preload": [
            "library/*"
        ]
    }
    Daniel Ashcraft
    @dashcraft
    fantastic, i'll give that a shot tonight, i was left working in a single file and it was messing with my ocd considerably
    Daniel Ashcraft
    @dashcraft
    Had some fun, will pick at it as I need more items in the future
    Peter Hoddie
    @phoddie
    That looks interesting. TypeScript and all. ;) I'll make some time to give it a try.
    FWIW - I noticed that you have Globals.d.ts to provide a declaration for trace. The Moddable SDK includes xs.d.ts which contains all the XS extensions to JavaScript, including trace.
    Daniel Ashcraft
    @dashcraft
    I’ll get that imported in! Thanks!
    Peter Hoddie
    @phoddie
    I posted some notes in an issue in your repository. I hope that's OK. If anything is unclear, just let me know. dashcraft/express-js-mod#2
    Daniel Ashcraft
    @dashcraft
    Absolutely
    I haven’t used Object.freeze but maybe a handful of times to enforce some semblance of immutability in react, that’s pretty neat about using it for storing in ROM
    Daniel Ashcraft
    @dashcraft

    Did some work with it today, got it working decent for posted data now and put/patch data. Took a lot of your suggestions and implanted them.

    Need to work on more in the future, but get/post json and text are my two main use cases and this drastically simplifies the process of listening to and responding to requests.

    POST: sensor.local/home?id=1

    raw json body: { "test" : "control"}

    {
        "test": "test",
        "request": {
            "state": "done",
            "headers": {
                "content-type": "application/json",
                "user-agent": "PostmanRuntime/7.28.0",
                "accept": "*/*",
                "cache-control": "no-cache",
                "postman-token": "83dae780-2ef5-491d-8a3d-b2ea217c042e",
                "host": "sensor.local",
                "accept-encoding": "gzip, deflate, br",
                "connection": "keep-alive",
                "content-length": "24"
            },
            "path": "/home",
            "httpMethod": "post",
            "data": {
                "test": "control"
            },
            "params": {
                "id": "1"
            },
            "rawQuery": "id=1",
            "location": "/home?id=1"
        }
    }

    This is about as easy as it gets when it comes to receiving data in the form of json or query params.
    Need to send files and other content types in the future,

    let express = new Express(Server)
    express.get('/home', function(req,res) {
        res.json({test: 'test', request: req})
    })
    
    express.post('/home', function(req,res) {
        res.json({test: 'test', request: req})
    })
    express.listen(80)
    Peter Hoddie
    @phoddie
    Looks straightforward to use. I see the update is up on your repository. I'll try give that a look later.
    FWIW - the use of headers above runs into the same runtime symbol problem I mentioend in my notes yesterday. A Map would be better. But, I suppose that's not API compatible with Express? If that's the case, maybe a workaround to minimize the problem by pre-defining the common headers names so that they are already baked into the firmware.
    Daniel Ashcraft
    @dashcraft
    I need to work on a way to be able to print the headers when returned, but i can find a work around for that.
    for some reason the Map got stripped when i sent the string json response, i need to take a look at how it's implemented
    or figure out a way to parse them when returned
    shouldn't be too hard

    There's some other things i need to do as well, like defining params in the path such as /home/1
    and also setting outbound headers
    res.header('something', "value")
    sending static HTML
    res.send('index.html')

    etc

    Peter Hoddie
    @phoddie
    For send, the obvious thing to do is send a file. But, actually, we usually build without a file system. Instead we have resources which are just named pieces of data. So, it could work with the same API (e.g. res.send) though perhaps you would want some prefix to indicate "this is a resource" (res.send("resource:index.html") so you can also unambiguously use files too.
    Daniel Ashcraft
    @dashcraft
    I need to also setup something to support an event stream strategy, to write text to an open socket as long as its active
    Daniel Ashcraft
    @dashcraft
    Is there a package registry for moddable? Seems like npm would be cumbersome.
    Peter Hoddie
    @phoddie
    Good question. There isn't yet, though there's been discussion. We are open to PRs to the Moddable SDK. There are details in contributing. The $MODDABLE/contributed directory might be a fit for your Express.js work.
    Daniel Ashcraft
    @dashcraft
    Gotcha, that sounds good, if there were a way to let people easily pull in moddable compatible packages from a somewhat reputable
    package manager, that'd be pretty sweet. There was a BME280 sensor package I used recently that would be a good fit for that with a little
    cleanup. Both the power and downfall of npm/yarn is how easy it is for people to install packages and manage dependencies.
    Right now, for instance, i'm rolling an event emitter class. I'm not sure if that's already been done to moddable's spec, but it's possible it has been and I'm
    rewriting the wheel. Which is okay, but ideally others could benefit from standing on the backs of giants
    Peter Hoddie
    @phoddie
    No argument. For now, that is manageable in our repository. That won't scale indefinitely.
    Daniel Ashcraft
    @dashcraft
    Not going to lie, i don't know many package managers that don't get a lot of grief from their users haha
    Daniel Ashcraft
    @dashcraft
    Simple event emitter following some others in naming conventions. This is very low brow. Nothing fancy.
    https://github.com/dashcraft/event-emitter-mod