Avatar for g_lander


Member since Jun 2020 • Last active Oct 2022
  • 3 conversations

Most recent activity

  • in JavaScript
    Avatar for g_lander

    I'm worried that using a normal JS library would cause memory problems - in some other posts, it can be seen that the Bangle.js 1 is struggling with memory in some posts in some cases. I think I have to agree with Gordon that the upper limit for UIs on the Bangle.js is not that high to warrant very complex UI frameworks.
    The reason I originally steered away from a master function is because unlike React, where there's one master function for everything (React.createElement, or jsx in newer versions) and having it always loaded everywhere is consented, a lot of Espruino apps might never want Layout (or not have it at all), so I don't think the React way of making elements is suitable for Espruino.
    The way I did it in the intepreter (and what I think should be done) is without a constructor function: the JSX syntax would be a shorthand function call, basically. Esprima natively supports JSX and is used in EspruinoTools, so it would probably make sense to have it convert

    <Button col="blue">Maybe</Button>


    Button({ children: "Maybe", col: "blue" })

    , though I could see why part-improvised syntax and grammar might be frowned upon.

  • in JavaScript
    Avatar for g_lander

    JSX is usually transpiled by the TypeScript compiler or Babel.
    There are multiple issues with my current implementation, I wanted to have a prototype in case it was a definite no.
    A thing React does for some reason is when there's only one child, it's not wrapped in an array in the props. My implementation doesn't do this, because it's weird. I don't think it would make sense to implement it because it would require most things to manually wrap the lone child in case it's a child layouting thing (strings are automatically concatenated). I bring this up because TypeScript's JSX support is very flexible, and it almost support using JSX for layout exactly the way I described, except for that quirk.
    The issue other than RegEx lexing is the fact that the tag contents (inbetween and ) doesn't allow any characters other than the latin alphabet, this is more tricky than it sounds, as there's no way to tell if a string has had single or double quotes after it has been lexed, and it would require manually adding the delimiter characters, which is not ideal. I think the solution would be to have the lexer have flags for a couple of modes:

    • Normal - the usual lexing mode
    • No tokens - always gives one character at a time, without trying to read strings and stuff. Pretokenised characters might be a problem, but they can just be converted into their string forms (It doesn't matter that pretokenised characters represent multiple characters, since it's going to be appended to a buffer string in any case)
    • No regex - this is hacky and less subtle than I personally like, but I don't know of any other way for resolving the issue.

    As per having a string and parsing it, there are multiple pitfalls, some of them which are described in the original JSX spec:

    • There's no way to verify that the XML is correct before running the code.
    • There's no meaningful way of referencing anything which doesn't serialize to a string, eg. there's no way to set a button's callback.

    I see why people would be confused as to why JSX is used in a different way versus React, but using Layout requires reading the docs (or examples) beforehand, so if the usecase of JSX can be explained there, I don't think it will be a problem.

  • in Bangle.js
    Avatar for g_lander

    The problem you are facing is that you are uploading your code to RAM and not somewhere to flash storage, which means all the code is stored in RAM as a string, which takes up a lot of space, considering the font. You can see the difference yourself by logging the memory used at the beginning of the file and saving to file vs. RAM (using console.log(process.memory())).

    I suspect the non-Layout version didn't run out of memory with the code in RAM because while Layout is great, it does use a lot of RAM to compute the (initial?) sizes of everything.

  • in JavaScript
    Avatar for g_lander

    I like the Bangle.js Layout library, and I like React. Both are similar, in my opinion. One thing React has which Layout doesn't is JSX: Instead of having to write object literals or function calls, it can be something which looks like HTML or XML.
    For example:

    const layoutObj = <Vertical>
        <Label font="20%">JSX</Label>
        <Button col="blue">Maybe</Label>

    instead of

    const layout = { type: "v", c:[
      { type: "txt", font: "20%", label: "JSX"},
      { type: "btn", color: "blue", label:"maybe"}

    I think it would be cool if the Espruino interpreter supported some form of JSX, since it would make Bangle.js Layout code be easier to read.
    I've made a local branch which implements JSX in the interpreter.
    I think there can be a problem with JsHint not supporting it and stuff, but maybe it can remedied by updating CodeMirror to use ESLint?

  • in Bangle.js
    Avatar for g_lander

    Thank you! That actually worked, I didn't know the IDE could flash non-USB Espruinos.
    Unfortunately, it didn't fix the HRM issues I hoped the update would fix, but oh well.

  • in Bangle.js
    Avatar for g_lander

    I am having problems updating my Bangle.js 2 (Dev edition) to the cutting edge version of the firmware for it. I have attached a video to show what is going on. When I try to update my watch via the nRF Toolbox app for Android, I recieve a note that there an SD version failure, though I don't really know what that means... Maybe ya'll can help?

  • in Interfacing
    Avatar for g_lander

    Hmm, I doesn't seem like it has a part number, just has "MicroSD Card Adapter" on the back...If you can specify what exactly to do with the card reader I can ask someone with soldering stuff to fix it