Big update to prettier-extension-monkeyc

I've posted about prettier-extension-monkeyc before, but I've added a bunch of new features that developers will probably like (well, I've been missing them, so maybe you have too).

The new features it implements for VSCode include:

Goto Definition. Point at a symbol, Ctrl/Cmd click, and it will take you to the definition. Or F12
Goto References. Right click on a symbol and select "Goto References". It will show you all the references. Or Shift-F12
Peek Definition/Peek References. Same as above, but in a popup window so you don't lose your place in the original document.
Rename Symbol. Right click on a local, function, class or module name, and select "Rename Symbol". It will rename all the references. It doesn't yet work for class members/methods.
Goto Symbol. Type Ctrl/Cmd-Shift-O and pick a symbol from the drop down (which has a hierarchical view of all symbols in the current file). This also appears as an outline across the top of the file.
Open Symbol By Name. Type Ctrl/Cmd-T, then start typing letters from a symbol name. A drop down will be populated with all matching symbols from anywhere in your project.

Older features include a prettier based formatter for monkeyc, and a monkeyc optimizer that will build/run/export an optimized version of your project.

[edit: My last couple of replies seem to have just disappeared, and the whole conversation seems to be in a jumbled order, so tldr: there's a new test-release at https://github.com/markw65/prettier-extension-monkeyc/releases/tag/v2.0.9 which seems to work for me on linux. I'll do more verification tomorrow, and push a proper update to the vscode store once I'm sure everything is working]

Top Replies

markw65 over 1 year ago in reply to andyj713 +2

You can't really conclude very much from reading it, because it basically represents the program straight out of the parser. The optimizer and code generator could do anything before actually spitting…
markw65 7 months ago in reply to 9811827 +2

9811827 said:
I think, it's better to have an option to build PRG for side loading

When it was just argc, I didn't think it was worth it. But I think I've finally found all the issues, and I agree with…
flocsy🤠 over 2 years ago in reply to FlowState +1

It also depends on how many times you call the function, but the smaller the code in the function the inclining gains more, because calling the function adds a few bytes, and the biggest gain is deleting…

All Replies

markw65 3 months ago in reply to markw65

In fact it's explicitly documented to work as I originally described. So the behavior in local variables must be a bug. See the bottom paragraph of this page:

When relative paths are used within a jungle file the path will be resolved against the Jungle file’s parent directory. Relative paths within the default.jungle are resolved against the parent directory of the manifest file that is found

Note that the default.jungle it mentions can be found in <sdk>/bin/default.jungle.

Anyway, I'll file a bug against the compiler, but I'll match the current behavior in the next release of the optimizer.

[edit: here's the bug report]

markw65 3 months ago

v2.0.105 is out.

Fixes this issue relating to relative paths in local variables.
Fixes some issues with find references and inheritance.

markw65 3 months ago

v2.0.106 is out

Fixes one more issue with references to initialize methods

markw65 2 months ago

v2.0.107 is out.

Fixes an issue with nested classes that could cause infinite recursion, which resulted in no analysis for the project, and no real indication of what was wrong.
Fixes a type flow issue with instanceof Boolean

flocsy🤠 2 months ago

I noticed that App.iq is bigger than App.original.iq. Is that normal?

markw65 2 months ago in reply to flocsy🤠

flocsy🤠 said:
I noticed that App.iq is bigger than App.original.iq. Is that normal?

I'm seeing the same. But IQ files are basically zip files, and you can use different levels of compression when creating zip files.

For one of my projects, the .iq sizes are 5.12M (optimized) and 5.08M (original). If I unzip both, the resulting directories are 50M (optimized) and 52M (unoptimized). So the optimized builds are definitely smaller.

If I zip those directories with level 9 compression, I get 4.95 and 4.91M. Not sure what's going on there. I guess the unoptimized files are easier to compress.

andyj713 1 month ago in reply to markw65

The simulator won't run, I'm getting this:

The provided PRG file does not exist: c:\Users\Andy\Desktop\Garmin-GIT\Annulus\bin\optimized-Annulus.prg
The provided source file does not exist: c:\Users\Andy\Desktop\Garmin-GIT\Annulus\bin\optimized-Annulus.prg.debug.xml

But the generated files are this:

It's using the name of the directory where the manifestt.xml file is for the output files. In my case the higher level directory and app name in the manifest are the same, so I can't say which it would normally use.

markw65 1 month ago in reply to andyj713

Oops. Should be fairly easy to fix. I'll take a look.

9811827 1 month ago

There's one more case with enums, that is similar to the one, I've reported before:

enum Enum1 {
    VALUE_1,
}

enum Enum2 {
    VALUE_2 = VALUE_1,
}

function test1() as Void {
    // The type Number<0> as Enum1 as Enum2 cannot be converted to Number<0> as Enum1 because they have nothing in common
    test2(VALUE_2 as Enum1);
}

function test2(value as Enum1) as Void {}

markw65 1 month ago in reply to andyj713

Fixed in v2.0.108.