Big update to prettier-extension-monkeyc

It only really matters if it prevents you from running a debug build in the simulator. But there's a lot of data included in debug builds that's not there in release builds.

All I'm saying is that it's quite possible that 4.2.0 is including more debug info than 4.1.7 in order to improve the debug experience. And what you ultimately care about is how much memory your app uses in release mode. So its better to compare release builds (or at least, if you notice something odd like this, its worth checking the release builds to see whether its a "real" problem, or not).

[Edit: I just tried building my project with both, and the release builds are identical - both data and code. With a debug build, code size is 11224 for both, and data size is 4522 with 4.2.0, and 4453 with 4.1.7. So like you, I see a small data size increase with 4.2.0 debug builds.]

I started to write a python script that generates some constants and functions for every device (from simulator.json). I noticed that constants that are Array or Dictionary are kept in the optimized code even if they are not referenced. Can you remove them?

Yes. This is mostly just down to the way the code evolved. I think there's a simple fix - but as I said a few days ago, I want to rewrite how this works - instead of looking at the whole program, and seeing what's not referenced from anywhere, I want to start from the entry points, figure out what's reachable, and then drop everything else.

If the simple fix doesn't introduce any issues, I'll probably include that in the next release.

I think there's another compiler bug in SDK 1.4.7. My original code compiles:

import Toybox.Lang;
import Toybox.Graphics;
import Toybox.WatchUi;
const DATAFIELD_HASH_2_DICT = {
 2134095 /*260x260@blrt*/ => {
     :label_font => Graphics.FONT_XTINY,
  },
 2131109 /*260x74@lr*/ => {
     :label_font => null,
  },
} as Dictionary<Number, Dictionary<Symbol, Graphics.FontDefinition?>>;
(:inline)
function datafield_label_font(width as Number, height as Number, obscurityFlags as DataField.Obscurity) as Graphics.FontDefinition? {
   var dict = DATAFIELD_HASH_2_DICT[(((width << 9) | height) << 4) | obscurityFlags];
   return dict == null ? null : dict[:label_font] as Graphics.FontDefinition?;
}

function onUpdate(dc) {
    var labelFont = datafield_label_font(dc.getWidth(), dc.getHeight(), getObscurityFlags());
    var labelFontHeight = labelFont == null ? 0 : dc.getFontHeight(labelFont);
}

but the generated code doesn't compile for some reason I can't understand:

function onUpdate(dc) {
    var width = dc.getWidth();
    var height = dc.getHeight();
    obscurityFlags = getObscurityFlags();
    var labelFont;
    {
      zoneColor /*>dict<*/ =
        DATAFIELD_HASH_2_DICT[
          (((width << 9) | height) << pre_4) | obscurityFlags
        ];
      labelFont =
        zoneColor /*>dict<*/ == null
          ? null
          : zoneColor /*>dict<*/[:label_font] as Graphics.FontDefinition?;
    }
    pre_0 = 0;
    var labelFontHeight =
      labelFont == null ? pre_0 : dc.getFontHeight(labelFont);
}

There are other lines before this in the function but that shouldn't have effect on this. I get this compiler error:

ERROR: fr255: bin/optimized/group008-debug/source/source/MyField.mc:17,4: Passing 'PolyType<Null or $.Toybox.Graphics.FontDefinition>' as parameter 1 of poly type 'PolyType<$.Toybox.Graphics.FontDefinition or $.Toybox.Graphics.FontReference or $.Toybox.WatchUi.FontResource>'.

flocsy said:

but the generated code doesn't compile for some reason I can't understand

Doesn't make sense to me either. In the code you posted, in the call to dc.getFontHeight, labelFont can't possibly be null, so yes, I think its a bug tracking nullness.

You can presumably work around it by casting to FontDefinition in the original source. But I'm pretty sure you shouldn't have to.

I have something strange:

when I add this to my code to a global scope (not using it at all):

[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 3; ]
import Toybox.Lang;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 4; ]
import Toybox.Graphics;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 5; ]
import Toybox.WatchUi;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 3; ]
<init> {
}

[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 3; ]
import Toybox.Lang;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 4; ]
import Toybox.Graphics;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 5; ]
import Toybox.WatchUi;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 6; @position = 4; ]
var TEST_DICT_ARR as Dictionary<Number, Array>;
[ @file = "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc"; @line = 3; ]
<init> {
[ "bin/optimized/group005-debug/source/devices/fenix6/label_font.mc" 6 4 ]
    %tmp.1 = newd Dictionary<Number, Array> 0;
    putv self :TEST_DICT_ARR %tmp.1;
}

feature-request: can you add the device name to the line where you print the code and data size?

flocsy said:

I tested it in another project, and it doesn't happen there, so it is somehow related to my other code in this project

Yes - very strange. The .mir doesn't really tell us much - thats basically the result of parsing the source code, before any optimizations or excludeAnnotations are applied. You could try compiling with -g and capture the output, because thats basically the input to the assembler. So you've got all the byte code, and all the data there...

Holy crap!

I diffed them and I see lots of strings added. For example:
> str_MyApp_bin_optimized_group005_debug_source_source_test_Test_mc_1032749526:
> STRING "MyApp/bin/optimized/group005-debug/source/source/test/Test.mc" ;

But this and 100 other similar strings are commented out. In fact the whole test/Test.mc file is commented out alltogether (with // at the beginning of every line)

So this looks like some serious bug in the compiler, but still what I don't understand is why this happens only when I compile with the prettier optimizer, and not when I compile without it.