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]

  • 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]

  • v2.0.105 is out.

    • Fixes this issue relating to relative paths in local variables.
    • Fixes some issues with find references and inheritance.
  • v2.0.106 is out

  • 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
  • I noticed that App.iq is bigger than App.original.iq. Is that normal?

  • 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.

  • 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.

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

  • 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 {}
    

  • Fixed in v2.0.108.