Big update to prettier-extension-monkeyc

LOL, I think similar issue here. Can you improve this? https://github.com/markw65/monkeyc-optimizer/issues/17 Or at least add some information so we know where to look?

flocsy🤠 said:

Can you improve this

I think what happened is that originally the parser rejected enums with expressions, so the optimizer treated it as an internal error that should never be able to happen. But at some point I extended the parser to handle expressions, but didn't fix the optimizer. As a result it doesn't get reported properly.

So this is even worse than issue 17 - because you don't even get a notification that there's a problem in the project.

I will definitely fix this so that enums are handled properly. I think there are a few things I can do to make issue 17 a bit better, so that an error in a single file only affects that file, and not the whole project. But even that has a downside - it will report lots of missing symbols against the other files...

I managed to work around some SDK 7.1.0 bugs when compiling without prettier-optimizer, and I am trying now with prettier, but it fails:

> Sizes for optimized-Myapp.original-fr955: code: 16814 data: 7161 <
> Optimizing optimized-Myapp.original.prg to optimized-Myapp.prg <
Post-build failed: TypeError: Cannot read properties of undefined (reading 'view')

What can I do to give you some information?

update: it only happens when compiling for system7 devices.

They've made some changes to the prg file format. That was mostly minor changes that were easy to deal with.

But they've also added a whole slew of new opcodes - which is going to take a while; I've got to figure out what they do, and then implement them.

So I'm going to work on it, but don't hold your breath.

Meanwhile, some the opcodes look like they might be pretty useful. Eg I think they've added bytecodes to construct "literal" arrays. Where previously, something like

var a = [1, 2, 3];

was basically syntactic sugar for

var a = new [3];
a[0] = 1;
a[1] = 2;
a[2] = 3;

I think there's a new opcode that just initializes the array from a read-only copy in memory. That should be a big memory win - but only on new devices that probably don't need it...

markw65 said:

I think there's a new opcode that just initializes the array from a read-only copy in memory. That should be a big memory win - but only on new devices that probably don't need it...

Oh man this brings back terrible memories of trying to handle large-ish amounts of static data in old devices with tiny RAM for data fields and no support for JSON resources.

Yeah, the problem with many of the improvements Garmin does is that it would be most needed on the oldest devices, but they add it only to the newest which don't really need the optimizer at all, because there's enough memory even without using it...

Ah, I thought all these were already added in sdk 7.0.0 and you already had them added.

Maybe until you do all the necessary opcodes add an error message that: "The prg uses unknown opcodes, disable Post Build Optimizer in the settings."

flocsy🤠 said:

Yeah, the problem with many of the improvements Garmin does is that it would be most needed on the oldest devices, but they add it only to the newest which don't really need the optimizer at all, because there's enough memory even without using it...

Agreed, but I'll give them props for adding the "settings" scope for strings which is a huge win for older devices and a feature request I never thought they'd fulfill.

I don't blame Garmin for not making improvements to older devices that they don't sell or support anymore tho. It just so happens that most Garmin users hold on to their devices for much longer than usual, which might make it tough for CIQ devs to decide whether or not to support older devices.

I missed that! Where was it announced? I wish they would properly "close" the tickets we open in the bug forum...

update: found: developer.garmin.com/.../