Recursion when optimizing code for apps on Windows

[bombsimon]

Thanks for this awesome optimizer and all your work for the Garmin ecosystem!

I noticed that when optimizing a project for multiple devices such that they result in multiple groups and using the (:typecheck(false)) annotation, this tools ends up in a recursion state which in best case makes it crash with ERROR: Internal: Error: EMFILE: too many open files but in worst case hangs forever.

From group 006 I see that I get a new bin/optimized folder and from group 012 it seems to recurse even further with paths like gorup012-release/source/bin/optimized/group006-release/... and so on.

The easiest way to reproduce this would be:

• Create a new project with the VS Code plugin
• Add the annotation (:typecheck(false)) to your Application.AppBase
• Enable all/many devices
• Chose Export optimized project

The reason why I need this is because I'm working with a widget that has a glance view so I'm using the :glance annotation as per recommendation. However it seems to be a bug in the typechecker, giving me this error when not disabled: [...] not available in all function scopes. I think it is this bug.

I'm using SDK version 7.2.0 and 2.0.102 of Prettier Monkey C on Windows 11 with VS Code 1.92.2

[markw65]

I think I see what's going on. I used to automatically filter out any paths that ended up under "bin", so that a monkey.jungle that didn't restrict the source path wouldn't pick up the generated files I place there.

But there were a couple of issues with that. First, I have to unpack compiled barrels somewhere, and bin/optimized was the obvious location. So I needed to avoid filtering those files out. And another user mentioned generating their own code into the bin directory, so again, it made sense to not filter out those files.

So I tried to fix it by only filtering files when the source path is **.mc (which is the default if you don't specify a source path). The theory being that if you create your own source path, it's your responsibility to ignore files you don't want to include.

It seems pretty clear that that's not working in your case. When its processing group012, it finds the sources for the previously generated group006. But I just followed your steps to repro (selecting every device), and it worked perfectly.

Maybe there's something else needed? Did you set base.sourcePath?

[edit: maybe its platform dependent. Are you on Windows? I'll try that next]

[markw65]

Tried on windows, and it reproduces, even without typecheck(false).

[bombsimon]

Thanks for the super quick response and for the explanation!

Ah yeah sorry, forgot to mention, this is on Windows! Never used the annotation on any other OS before so didn't know it was OS dependent. Happy you found a way to reproduce, let me know if there's anything else I can help out with or test!

Tried on windows, and it reproduces, even without typecheck(false).

Huh, that's odd I think, I'm using Windows for other projects (and this one until I ended up using the annotations) and it used to work fine - I think? Or for this project I think I was using way fewer devices so maybe that's way it worked.🤔 But now that I tried to do a new empty project I can also reproduce it just like that.

I noticed however it only seems to affect apps and not watch faces? This watchface has 216 enabled devices (resulting in 109 groups) and that works fine under Windows. Maybe I must've only ever exported watch faces from Windows and apps from macOS.

[markw65]

This is relatively new. I think I introduced the problem in 2.0.100, so yes, it would have worked in the past.

Even in this version, as long as your computer doesn't run out of resources, everything should work. Also, if you start from a clean build, you have a much better chance of not hitting a problem, because the early groups don't see the later ones.

Anyway, I just pushed a fix.