Big update to prettier-extension-monkeyc

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.

v2.0.104 is out.

• Fixes this issue with enums in member expressions
• Fixes This issue with personality files referenced from barrels
• Fixes #22

andyj713 said:

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

markw65 said:

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:

markw65 said:

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.

andyj713 said:

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