Avatar for Andreas_Rozek

Andreas_Rozek

Member since Dec 2019 • Last active Oct 2023
  • 71 conversations
  • 374 comments

Physicist, Senior Developer and IT Consultant, University Lecturer, Freelancer and Startup Founder

Most recent activity

  • in General
    Avatar for Andreas_Rozek

    Well,

    as someone who "runs with the hare and hunts with the hounds", I came in contact with many discussion forums in the past few months. My personal conclusion - from a user's point of view(!):

    • this forum is not that bad - in fact, its among those I like most: it is not crowded with icons and colors, provides a good hierarchical overview of topics, let's readers search for what they need and offers enough "gamification" options to keep post authors in line
    • I hate "discord" (which may be good for real-time chatting, but serves badly as a searchable forum) and avoids it whenever possible
    • I also don't like GitHub discussions, as GitHub injects technical hints and reports (such as "this issue was mentioned by ..." including badges with the state of their own issue) which may be good for developing in a team, but is just disturbing in a forum. Not mentioning the detail, that it is not shown, if a later post is a direct answer of an earlier one. And that it informs me about any changes in any thread I ever posted in - diluting the relevance of the notification badge which informs me about new issues in my own repositories. I'm working with GitHub almost every day - but I always try to avoid GitHub discussions...

    On the other hand, "discourse" looks like a noteworthy alternative as it provides a clear user interface not unlike this forum.

    With greetings from Germany,

    Andreas Rozek

  • in General
    Avatar for Andreas_Rozek

    I know Discourse from Node-RED and can definitely agree.

    However, AFAIK, Gordon wanted to avoid having to maintain a forum himself, which is why he looked at GitHub Discussions...

  • in Bangle.js
    Avatar for Andreas_Rozek

    I don't think so

    If you change intervals seldomly, setInterval may consume a little less power - but compared to what you need for drawing your screen contents, you should never be able to recognize the difference.

  • in Bangle.js
    Avatar for Andreas_Rozek

    No,

    do not mix both approaches! Either use setTimeout as shown above or start a new setInterval whenever your drawing period changes:

    var TimerId = setInterval(draw,1000)
    ...
    clearInterval(TimerId)
    TimerId = setInterval(draw,60000)
    
  • in Bangle.js
    Avatar for Andreas_Rozek

    Well,

    I usually prefer a construction like

    var Interval = 1000;
    setTimeout(()=>{
      draw();
    }, Interval - (Date.now() % Interval));
    

    if

    • (calculation and) drawing may take longer than 1000ms (should be
      rare) or
    • the Interval may change dynamically (e.g. depending on screen lock)

    But, most often, a simple setInterval should be sufficient.

  • in General
    Avatar for Andreas_Rozek

    Well,

    I don't think you should judge your user's opinions just by the posts in this topic.

    To use myself as an example: being critical (e.g., in terms of privacy and GDPR compliance) does not necessarily means "dissent" - it's just that I want to avoid running into troubles by not having looked at the consequences of this switch.

    On the other side: since I am participating in a GitHub discussion (on the new GitHub "achievement" badges), I definitely prefer the existing forum!

  • in ESP32
    Avatar for Andreas_Rozek

    Well,

    that's indeed an interesting finding, but I doubt that it would have a significant effect on performance:

    • computeDiffusion does a lot of computations and rounds in the end only - replacing it by + 0.5 and relying on internal truncation and clamping would probably not be faster but less intuitive. However, rounding (of small values) is important for the final display any may therefore not just be omitted completely
    • computeHeating does not have any noticeable effect on the overall speed (it deals with 16 pixels only, not 256)
    • prepareDisplay rounds indices into an array only - and this cannot be omitted as you may easily test yourself

      var Test = [0,1];
      print(Test[0.5]);
      

    outputs undefined rather than 0 or 1.

    Anyway, thanks for your effort!

Actions