Big update to prettier-extension-monkeyc

andyj713 said:

But the fact is, something is different, and YES, Garmin did introduce breaking syntax changes between SDK 6 and 7, and every language I've ever worked on has at some point introduced breaking changes as they've moved forward.

I said semantic changes, not syntax changes. Huge difference.

A change in syntax, as annoying as it is, would cause compilation to break (hopefully), which means you can fix your problem.

A change in semantics, which causes the behavior of your programs to change silently, would be a disaster.

If a language made a change of that magnitude, usually there would be a big announcement about backwards incompatibility, as well as a major version change (think python 2 vs 3). Ofc the difference there is that older versions of python are/were maintained and still could be run on modern hardware. With modern languages like Typescript and Python, builds are usually pinned to a specific major and minor version of a language, which avoids problems with backwards-incompatible changes.

In the case of CIQ, you *have* to use the latest SDK to compile for the newest devices, which would make breaking semantic changes even more dangerous.

andyj713 said:

Yes, your trivial example does what you say it does.

Yeah, it’s a trivial example which demonstrates something you asserted as fact over and over again was incorrect. You’re the one who kept saying that Garmin themselves said that arrays were copied on assignment, you’re mad bc I posted simple code which you could have used to verify your claim?

Do you have a more sophisticated and elegant example that proves your point?

andyj713 said:

I'm not sure why you feel the need to make this personal.

Bc you’re unapologetically posting misinformation over and over again which might be believed by others, using Garmin as an authoritative source without actually backing it up. You won’t listen to reason until ppl push back multiple times. You use the fact that people disagree with you as evidence that you might be on to something. Four decades of programming, who cares? You sound like someone else on the forums, who is intelligent and knowledgeable 95% of the time, but when they’re wrong on a subject (*), they’re massively wrong, and they rarely apologize or back down. (* usually something they know nothing about or, even worse, where they have a massive misconception about their own expert knowledge.)

andyj713 said:

I'm not sure why you feel the need to make this personal. When I posted about something I discovered by chance by making a small change to the way variables were passed and referenced and the way compiler handled them the goto reply was that it must be wrong

This seems to be something different than the "arrays are copied on assignment" thing, and I don’t think I mentioned anything about it. If others disbelieved you and you turned out to be right, at least you were vindicated on that point.

Can’t speak for anyone else, but I didn’t think that “arrays are copied on assignment” *must* be wrong, I thought that it was almost certainly wrong, but I would’ve been willing to change my mind. I mean, I’ve never seen that behavior — in fact, I’ve seen completely different behavior (arrays are referenced on assignment) — so it would’ve taken a lot to change my mind.

If you’re making an extraordinary claim, the onus is on you to prove it. You can’t just expect everyone else to blindly accept what you’re saying, and you shouldn’t be surprised when ppl push back.

If CIQ was so stable, we wouldn't need complicated jungle jungle files and lots of "has" if checks. Maybe it is just a few thousand one and two byte improvements. Or maybe it's that and something else. Open and spoiled with details doesn't seem to be the Garmin way. We don't know for certain now, and from experience that's not likely to change much.

andyj713 said:

If CIQ was so stable, we wouldn't need complicated jungle jungle files and lots of "has" if checks. Maybe it is just a few thousand one and two byte improvements. Or maybe it's that and something else. Open and spoiled with details doesn't seem to be the Garmin way. We don't know for certain now, and from experience that's not likely to change much.

Yeah, I agree CIQ has a ton of design and implementation issues, and Garmin could be better at software. I also agree that transparency isn't their strong suit. I'm the first one to whine and complain nonstop about Garmin, both on the device side and the CIQ side.

So I don't blame you for being skeptical.

I still think even Garmin wouldn't be crazy enough to make a breaking change of that magnitude. I happen to think they've stuck with certain old design decisions which have known issues mainly to preserve compatibility.

andyj713 said:

lots of "has" if checks

This is an example of a design decision that they'll never reverse. For them it's a feature, not a bug, that you have to either use conditional compilation (with exclusions) or has checks, when dealing with features which don't exist on all devices. Have to admit I don't have any better ideas rn.

To their credit, they've improved optimization so that has checks can be compiled out. Unfortunately this is a good example of an actual breaking semantic change (bc it prevents your app from being forwards compatible with future versions of a device which may gain a feature that was has checked, without recompilation), and once people complained about it, they added a compiler flag to disable the new behavior.

Starting with the CIQ 7.x.x SDK, the default is that has checks are resolved at compile time.  There is an option (-disable-api-has-check-removal) to keep them at runtime

As far as jungle files, mine are all fairly simple.  I use them for complication publishers, if there are on device maps, and settings for the semioctigon devices where you only have black and white for settings.  I also use them to pull in shared code.

flocsy🤠 said:

WARNING: release.jungle:6: Personality path

Should be fixed in v2.0.87

v2.0.87 is out

Fixes an issue quoting paths in the generated jungle file

Fixes an issue where values that are only referenced from resource files could be incorrectly removed from the program

Fixes an issue where an assignment of a singleton enum value to a class variable of that type in the class initializer could be incorrectly removed.

v2.0.88 is out.

Fixes https://github.com/markw65/monkeyc-optimizer/issues/33

v2.0.89 is out.

Fixes https://github.com/markw65/monkeyc-optimizer/issues/34

Is anyone seeing any benefits from "Minimize Modules" option?

I see differences in generated code like "using Rez;", but code and data sizes are identical with and without this optimization.

Or is this not relevant anymore for modern SDK versions?