You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • ...interesting: @ChristianW , for most of the time you use function X {} when X is a singleton and then stick everything to it with something like X.val = 0; or X.init = function(...) { ... };. What is the reason for declaring the singleton as a function rather than as below with a object from a code literal like you do for const PAGES = { ... };:

    var X =
      { val: 0
      , init: function( ... ) {
          ...
        }
    };
    

    Of course, this does not answer your question(s)... yet... f0r sure not the last one (...NaN).

    Reading @Gordon 's post #150 - http://forum.espruino.com/comments/16107155/ - in conversation about Please post what you're working on! and my own experience w/ displays hint to me that the update of the display takes too long and you may run into event buffer overflows, last but least you run advertising at utmost frequency and use a fixed interval for updating the display (though not absolutely sure about the latter).

    In my case, it took too long to update the display with all GPS data, so I updated only parts at a time and only when the value changed. Of course, my display was a color display and I used vector fonts, which did for sure not help with keeping the JS streak for updating the display as 'short' as possible.

    I have no insight into wether the execution is really completely (logically) single single threaded as expected with JS, but I know from other experiences in environments where underlaying system code makes it quasi multi-threaded by responding to interrupts and then not does not just updated a synchronized (event) buffer but also pushes data thru into the space of the single thread in execution by calling (callback) functions of the single threaded code space.

    The scan may also hold up serving intervals timely.

    Therefore, I'd replace intervals with with combination of timeout and self-call to not run into a backup of interval timeouts. To further shorten the JS streaks, you can break up loops in JS into sequence of timeout calls - one for each element - by keeping the index in the global space. Yes, it makes the code more complicated but you can tune the execution load better.

    Btw, there is a simple way for clearing an interval or timeout. Assume var iId =null; and later iId= setInterval(... and var tId = null and later tId = setTimeout(... have happened, the clearing can go like this: if (iId) iId = clearInterval(iId); and if (tId) tId = clearTimeout(tId);, respective, since clearing returns undefined (you could even omit the init with null at declaration).

    Furthermore, to make sure you never 'multi-interval' or 'multi-timeout' one and the same 'thing', check respective id before setup and throw Error. For timeouts, it requires clearing the id in the timeout execution with tId = null;.

    Do you know the ' for a while' time and did you make the calculation of average time per rx received?

    ...and on a completely different note: why Velo and VELOS and not Fahrrad and FAHRRAEDER (Fahrräder)?

  • Regarding the objects / singletons:
    I am not 100 % fluent in JS, most of the things I have looked up somewhere.

    From what I understood the Objects/Classes are declared as functions and since I don't need dynamic instances I'd mostly stick to static Objects, so (I thought):

    function Foo() {} 
    

    would be a static object and

    Foo.bar = function() {
       Foo.some = 123;
    }
    

    would declare a static method to it while

    Foo.prototype.baz = function() {
        this.thing = 123;
    }
    

    would be a dynamic method working on real instances of the object created with

    var foo = new Foo();
    

    Could some awkward style of my code cause some runtime trouble?
    If your example regarding objects is more common / recommended, I can change my code.

    Also thanks for the pointers regarding the draw() method, it is really awkward that it just blocks up sometimes. I'll try to break it into smaller chunks and move things to the background.
    Do you think the timeout value is relevant? Or is it just to have it running asynchronously like

    Object.keys(list).forEach((i)=>{
       setTimeout(()=>{
          …
       }, 1);
    });
    

    Can the timeout value actually be 0 as well?

    Regarding

    Do you know the ' for a while' time and did you make the calculation of average time per rx received?

    Sorry, I am not sure what you are asking here. Could you elaborate?

    Regarding Velo: It is mainly about riding/racing Velomobiles (those fully faired three-wheeled recumbents), not bicycles... ;-)

About

Avatar for allObjects @allObjects started