Big update to prettier-extension-monkeyc

flocsy🤠 said:

Note that there's and extra comma before the closing }

Does that extra comma actually generate different byte code? (Seems unlikely to me, I could be wrong tho.)

My guess would be that the following two dictionaries would have identical contents:

{ :foo => 42 }

{ :foo => 42, }

I'm pretty sure there's no difference (the .mir file is identical), but still if my original code didn't have the extra comma, then the optimizer probably shouldn't add it either.

That's the default prettier behavior (if an object or array is split across multiple lines, there's a trailing comma after the last item). Its also one of the few things that prettier has options to control, so in theory, setting 'trailingComma: "none"' (either via the Prettier extension's settings, or via one of prettier's many config files) should fix it - and if you're formatting the original source it does.

But I just tried that, and it looks like when the optimizer invokes prettier to format the output, it does so in a way that skips all config files, and it just runs with the default options. There must be a way to pick up the standard options, so I'll fix that in the next release. Apart from anything else, it will make the optimized source a bit closer to the original if you're formatting the original and using non-standard options.

But meanwhile, I'm 100% certain that the trailing comma does not change the meaning of the code in any way. One of my tests for the formatter is building all the Garmin sample projects with and without formatting the source, and verifying that the binaries don't change, and this comes up several times in those projects.

_psx_ said:

What does mean this numbers especial SETTINGS = 0x5e771465? Is it var symbol?

Sorry, was just expanding on my previous statement that a .prg file appears to be a sequence of sections. Each section is a (big-endian) 32-bit int declaring the "type" of the section, followed by a (big-endian) 32-bit int giving the size of the section, followed by the actual data of the section.

By comparing the sections and their types to the output of the compiler when you pass it the "-g" flag, I was able to determine a few of the "type" values. So no, I don't think this will help you at all

v2.0.29 is out.

This fixes a bug handling unused variables declared at the top level in case statements, which could cause the optimizer to fail (it issued an obscure error, and the build failed - it never produced incorrect results).

It also adds an icon :-)

I think I found  bug:

    (:memory32K)
    public function compute(info as Activity.Info) as Void {
        // other stuff
        a = strfHrZone(mConfFormat1, extHr, extZone, fractZoneStr, computeIntHR(info));
        b = strfHrZone(mConfFormat2, extHr, extZone, fractZoneStr, computeIntHR(info));
    }


    typedef AlphaNumeric as String or Number;

    (:inline_memory16K)
    hidden function strfHrZone(format as String, extHr as AlphaNumeric, extZone as AlphaNumeric, fractZone as String, intHr as AlphaNumeric) as String {
        var name = mName != null ? mName : "";
        return Lang.format(format, [extHr, intHr, name, extZone, fractZone]);
    }

got optimized into:

      {
        var intHr =
          info != null && info.currentHeartRate != null
            ? info.currentHeartRate
            : pre_____;
        var name = mName != null ? mName : "";
        extHr = Lang.format(mConfFormat1, [
          extHr,
          intHr,
          name,
          extZone,
          fractZoneStr,
        ]);
      }
      {
        var intHr =
          info != null && info.currentHeartRate != null
            ? info.currentHeartRate
            : pre_____;
        var name = mName != null ? mName : "";
        mResult2 = Lang.format(mConfFormat2, [
          extHr,
          intHr,
          name,
          extZone,
          fractZoneStr,
        ]);
      }

Or in other words: I thought the :inline_memory16K means that in memory16K it does inline it, but in memory32K it doesn't. However as you see it did inline it in memory32K

Hmmm, I tested it now with the current version and it seems to work. The generated code above is the current production that I compiled about 2 weeks ago. I don't know what version of the plugin I had back then... And therefore here's an idea: can you add the version of the plugin to the output? Somewhere in optimized/.... Like in the build-info.json or the beginning of the generated jungle file as a comment.

flocsy🤠 said:

I tested it now with the current version and it seems to work. The generated code above is the current production that I compiled about 2 weeks ago. I don't know what version of the plugin I had back then... And therefore here's an idea: can you add the version of the plugin to the output?

I've not posted an update for a while, and nothing has changed wrt inlining and excludeAnnotations since I flipped the sense of inline_foo (at your request) a long time ago.

But yes, including the version number is a good idea, and I'll do that. I'm also looking at allowing you to npm install @markw65/monkeyc-optimizer@<version> in your project directory, and have the extension use *that* version (if present) rather than the one internal to the extension. That way, the optimizer version would be stored in package.json/package-lock.json (under version control), which would solve the issue brought up by FlowState earlier in the thread.

I'm almost certain this has been "covered" before, but is there a chance you can make the following work:

    (:inline)
    private function isInActivity() as Boolean {
        var info = Activity.getActivityInfo();
        return info != null && info.startTime != null;
    }

    public onStart() as Void {
        var x = Properties.getValue("x");
        if (x == 0 && isInActivity()) {
            //...
        }
    }
    
    public onStop() as Void {
        var x = Properties.getValue("x");
        x = isInActivity() ? 1 : 0;
        // ...
    }

In both places I get a warning:
While inlining isInActivity: This function can only be inlined in statement, assignment, or return contexts