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]

  • There's an issue caused by enum initializer:

    import Toybox.Lang;
    
    class Test {
        enum Values {
            VALUE = 1 + 1,
        }
    
        var value as Float;
    
        function initialize() {
            value = VALUE.toFloat(); // Invalid assignment to value. Expected Float but got Null or Float [pmc-analysis]
        }
    }

    With "VALUE = 2" everything is OK.

  • Thanks. I have a fix. Still working on a couple of other issues, but hope to get a new release out soon.

  • Using the SDK 7.3 stock compiler my project compiles and runs as expected, but when I try to compile an optimized version it dies with this error:

    ERROR: A bitmap resource matching the provided launcher icon can't be found. You must provide a bitmap resource for the launcher icon.

    Is there something I need to do differently?

  • Is there something I need to do differently

    It's supposed to just work, so no.

    I've not seen that issue across hundreds of projects, so I'm going to need more details.

    I think this has to be a problem with the generated jungle file; I don't change the resources at all, so the only way I can see this happening is if debug.jungle is pointing at the wrong locations. So I guess a start would be to post:

    • location of the file that the bitmap is supposed to be in
    • contents of the "debug.jungle" file (or release.jungle if that's what you're building). Usually found in bin/optimized, but you can change that in the settings.
    • location of the debug.jungle file if you did change the settings
  • I have not changed any optimizer settings related to directories. Here's my debug.jungle:

    project.manifest=..\..\wfSource\manifest.xml
    fenix7x.personality = ..\..\..\..\..\AppData\Roaming\Garmin\ConnectIQ\Devices\fenix7x
    fenix7x.excludeAnnotations = isApp;logPos;getImage

    The bitmaps are in the resources/images directory Here's my project tree:

    Here my monkey.jungle:

    project.manifest = wfSource/manifest.xml
    #project.manifest = appSource/manifest.xml
    
    appType = ../wfSource
    #appType = ../appSource
    
    srcBase = ../source
    rezBase = ../resources
    
    base.sourcePath = $(srcBase);$(appType)
    base.resourcePath = $(rezBase)
    
    #base.excludeAnnotations = isWF
    base.excludeAnnotations = isApp
    base.excludeAnnotations = $(base.excludeAnnotations);logPos
    base.excludeAnnotations = $(base.excludeAnnotations);getImage
    

  • Ok, well clearly the "resources" folder is missing from the debug.jungle, which explains the error - but I need to figure out why. Also, source and wfSource are missing - presumably for the same reason.

    One unusual thing is that it looks like your manifest isn't in the same directory as your monkey.jungle. As I understood it, the way paths are resolved is as follows:

    • all default paths (resources, resources-round, resources-fenix7x etc) are resolved relative to the manifest file. By the looks of things, those defaults won't resolve to actual paths (since they would resolve to directories under wfSource, which don't exist).
    • explicit paths are resolved relative to the jungle file they occur in. But that also wouldn't work, because ../resources would be one directory too high.

    So if this really works when you don't use the optimizer, I must have something wrong there. Maybe if explicit paths don't resolve against the location of the jungle file, they are tried against the location of the manifest file. If so that's a change in behavior since I first wrote the optimizer.

    Anyway, I'll see if I can repro.

    Meanwhile I'm pretty sure the optimized project would work if you changed "../" to "./" in your monkey.jungle. And based on past experiments, I would also assume the unoptimized project would work that way...

  • I can't get things to work at all, based on what I think your layout is. I get the same "ERROR: A bitmap resource matching the provided launcher icon can't be found" with or without the optimizer.

    I have monkey.jungle in the root of the project and I put the manifest file in wfSource. If I change srcBase and rezBase to ./source and ./resources then the project works, with or without the optimizer.

    Can you create a minimal repro project, zip it up, create an issue here and attach the zip?

    Thanks

  • Meanwhile I'm pretty sure the optimized project would work if you changed "../" to "./" in your monkey.jungle. And based on past experiments, I would also assume the unoptimized project would work that way...

    I learned the manifest file directive can't resolve variables, so that's why the manifest path is hardcoded relative to the directory that the jungle file is in. The paths in the jungle file variables have to be relative to the directory that the manifest file is in, so they necessarily need to refer to its parent directory. It works anyway, if there's another way I don't know about it because I got this to work first. It's a feature to be sure, but it allows me to compile my project as either a watchface or an app with only needing to change the few commented lines in the jungle file. Here's my layout in VS code:

    Can you create a minimal repro project, zip it up, create an issue here and attach the zip?

    Eventually, maybe. It won't be this week. Sorry.

  • The paths in the jungle file variables have to be relative to the directory that the manifest file is in, so they necessarily need to refer to its parent directory

    Well, that's not what I've found. As I said above, paths in jungle files are relative to the jungle itself. Only the default paths are relative to the manifest file.

    But... I just figured it out. When I setup my project I didn't bother with the variables - since they're only used once. And apparently, if you use local variables, the paths are relative to the manifest file, but if you don't they're relative to the jungle file.

    So with your setup:

    rezBase = ../resources
    base.resourcePath = $(rezBase)

    works (as you say), while

    rezBase = ./resources
    base.resourcePath = $(rezBase)

    fails. But

    base.resourcePath = ./resources
    

    works, while

    base.resourcePath = ../resources

    fails!

    So yes, this is a bug in the optimizer, because it treats variables the same as non-variables (which works as long as the manifest is in the same directory as the jungle, or as long as you don't use variables). Although I'm willing to bet this is really a bug in the monkeyc compiler. I can't believe they intended for paths in variables to behave differently from paths outside variables...