Big update to prettier-extension-monkeyc

markw65, First let me say, this optimizer saved me enough space to add a new feature to my app, thanks for that!

I found something interesting... 

This code optimizes a bit oddly.

Before:

if(hasTouchscreen and System.getDeviceSettings().isTouchScreen) {
    Push_Main_Menu();
} else if (hasButtons) {
	parseUpDown(evt);
}

After:

{
  Push_Main_Menu();
}

The intent of this code is to send the user to the menu when a button is tapped on touchscreen watches, but for button devices to parse the input, and interact with the UI.

hasTouchscreen and hasButtons are defined like this:

(:touchscreen)
const hasTouchscreen = true;
(:no_touchscreen)
const hasTouchscreen = false;
(:buttons)
const hasButtons = true;
(:no_buttons)
const hasButtons = false;

and monkey.jungle:

base.excludeAnnotations = no_buttons;no_touchscreen;no_wifi;no_routing;no_phone

In this particular situation, on a fenix6s, `hasTouchscreen` should be evaluated as True, while `System.getDeviceSettings().isTouchScreen` should be false. So the whole expression should evaluate to false, instead of true.

-------------

Side note, when `touchscreen` is excluded in monkey.jungle, the produced code looks like this (works correctly):

if (false and System.getDeviceSettings().isTouchScreen) {
  Push_Main_Menu();
} else {
  parseUpDown(evt);
}

Any idea what is happening here?

Thanks,

Lance

Aha! It has to do with using `and` instead of `&&`. When I use && the code works properly.

SirLancelot said:

Aha! It has to do with using `and` instead of `&&`

Thanks - with that I found the bug. The problem was that I added support for "and" and "or" relatively late (because I hadn't initially noticed they were alternative spellings for && and ||), and when I did, I didn't update every reference to "&&" and "||". In some places, the code assumed that if a LogicalExpression's operator wasn't "&&" it must be a logical or, and then optimized accordingly. So "if (true and X)" just became "if (true)".

I've fixed it and will try to get a new release out over the next couple of days.

Thanks!

v2.0.34 is out.

I went down a rabbit hole with this one. Since compiler2 uses slightly different lookup rules than compiler1 I decided it was time to make my optimizer understand both, and optionally warn about the differences (so that, for example, it doesn't report "Unknown symbols" for things that would work). But along the way, I found all sorts of issues relating to differences between what the type checker reports, and what actually works at runtime - especially in static functions (I filed some bugs). But I eventually got everything more or less resolved. So this version:

• reports missing symbols more accurately (especially in static methods)
• reports diagnostics for symbols that will only be found when using compiler2. This seems important, because even with the latest sdk, -O0 uses compiler1 while -O1 and above use compiler2. So even with the same sdk you could write code that works at -O1 and fails at -O0. But the optimizer will warn you (by default) about such things.
• sdk-4.1.6 has bugs relating to private and protected statics. You'll get diagnostics about any issues that may show up if you're using 4.1.6 (and the solution is to go to 4.1.7).

The typechecker in 4.1.7 (just released) has actually fixed several of the bugs I reported; for the most part it now matches the diagnostics my optimizer produces in these cases.

I also fixed the bug reported by SirLancelot a few days ago, and made Goto References, and Goto Definition a little more precise.

markw65 I just noticed that when I execute "Prettier Monkey C: Build and Run Optimized Project" then the compiler is called with -l 0 even though I have it set to 3 both in the extension settings and in my monkey.jungle file

flocsy🤠 said:

compiler is called with -l 0 even though I have it set to 3 both in the extension settings

Yes, I've mentioned this before. This bug makes it impossible for me to guarantee to transform a type-correct, unoptimized program into a type-correct optimized program.

That said, it's easy to fix such issues in the source (by adding an "as Number" where necessary), and these issues are rare. In my code, it came up exactly once, and I think there were a couple of cases in the Garmin samples.

So by default, I ignore the Garmin typeCheckLevel setting, but you can use the prettierMonkeyC.typeCheckLevel to request that the optimized code be compiled with whatever level you want. You can also control it on a task-by-task basis in tasks.json, or per launch config in launch.json (and this is what I've done with my project).

I just realized that since that original issue, there's a new one that *could* bite. If you have an (:inline,:typecheck(false)) function, the :typecheck(false) will be lost when it gets inlined, so the error will be reported in the inlinee. I've not hit that issue myself, but I guess I could just transfer any :typecheck(false) to the target function (I'll do that in a future release).

So try it. If you hit any issues other than those two, let me know.

flocsy🤠 said:

and in my monkey.jungle file

That reminds me. Currently, I will drop typecheck and optimization settings that occur in the jungle file (they didn't exist when I wrote the jungle processing code, so didn't know to copy them over). I will add support for that.

how am I supposed to use prettierMonkeyC.typeCheckLevel?

v2.0.35 is out.

Main features of this release are

• Performance improvements: This mostly affects how quickly refs and defs are available after you type (which should now be really fast); but for certain projects build times were significant (several minutes) but should now be no more than a few seconds (and probably less than a second).
• Full support for resource and manifest files. You can now click on an @Strings.Foo and goto all refs and refs. Outlines and workspace symbols work across resource files now too.