• Replies 1248 replies
  • Subscribers 33 subscribers
  • Views 352821 views
  • Users 0 members are here
Options
Related

Big update to prettier-extension-monkeyc

markw65

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]

  • in reply to markw65

    OK, as a person who writes code because I have domain knowledge of the problem, more than a computing science degree knowledge, Prettier is amazing as it makes my solutions better. And I think better functionally than if someone with a CompSci degree tried to develop domain applications (see e.g. Garmin Edge firmware for an example of this -- does anyone there actually take a device outside and try and ride a bike with it?)

    So... I don't really want to even look at a launch.json file hence #1 is an example of how to make a debug build that hits breakpoints?

    #2 would be a optimal recommended settings as defaults like post-build optimisation are not set

    #3 Performance hints -- why is it taking forever to build my final build (10mins+) when it's only a few seconds to create the individual device optmisation
    Optimization step completed successfully in 3017ms  <--- "Build and Run Optimised" for a device
    Optimization step completed successfully in 658953ms  <--- everything.... 200x longer for 100 devices

    #4 I still haven't worked out to create a single-device PRG file for sideloading; it must be there somewhere ... Oh, wait, I have ... it was it just took another 5 minutes to optimise from the timestamp on the optimized-APP.original.prg to optimized-APP.prg

    Native Windows 11, VSC, 12th Gen Core i7, 16GB RAM

  • in reply to crispgarmin

    Optimised (post build) on Fr255 gave runtime (not in regular optimised) exception below: -- happy to take conversation offline and share PRG etc if it would help

    UnexpectedTypeException: Expected Array, given Primitive Module

  • in reply to jim_m_58

    If you use my optimizer with the post-build optimizer enabled, and disable Garmin's optimizer, you typically get better results than you would from Garmin's optimizer alone.

    If you use both, you typically get better results still - but yes, the relative improvement my optimizer gives is smaller when Garmin's optimizer is enabled (no surprise there - Garmin's optimizer does some of the same things mine does).

    The actual improvement varies a lot - but I would say 10% code size reduction over the Garmin only results is typical, and 25% is not unusual.

  • in reply to crispgarmin

    You can contact me through email  "mark at replayroutes dot com" - or create an issue on GitHub.

    I'll need the non-post optimized prg file, and details of how to repro the issue in the optimized one.  

  • in reply to crispgarmin
    crispgarmin said:
    it was it just took another 5 minutes to optimise from the timestamp on the optimized-APP.original.prg to optimized-APP.prg

    If it's taking 5 minutes to run the post-optimizer on a single .prg file, I really want to see that .prg file!

    For pretty much everything I've seen, it's a few seconds at most (minutes for a .iq file that includes hundreds of devices).

    crispgarmin said:
    So... I don't really want to even look at a launch.json file hence #1 is an example of how to make a debug build that hits breakpoints?

    Since the source-to-source optimizer literally creates new source files and compiles them, you need to set the break points in the generated sources, unfortunately.

    Normally I debug the non-optimized code; I only need breakpoints in the optimized code when the optimizer introduces a bug (which is hopefully not often, but you seem to have landed on a couple).

  • v2.0.133 is out.

    • fixes a bug in the post build optimizer's sizeBasedPRE optimization that could cause issues in the presence of try/catch blocks
    • fixes a bug handling "-r" in compilerArgs. Now specifying "-r" will force the source to source optimizer to work in "release" mode.
    • for .prg files that include Glance and or Background code, shows the glance and background sizes, in addition to the overall app size.

  • v2.0.134 is out.

    • Checks to see if your monkey.jungle includes .mc files under the bin/optimized directory, and if so, will suggest changes to exclude it, or (for complex cases) ask you to edit the monkey.jungle to fix it. Can be disabled by prettierMonkeyC.disableJungleFixes.
    • Adds Enable Garmin Analysis and Disable Garmin Analysis commands. These enable/disable Garmin's language server by renaming the .jar file. Disabling it avoids getting duplicate entries from things like Goto Definition. As always, if you prefer, you can instead disable Prettier Monkey C's analysis via its own settings.
    • Adds settings for connectIQPath and sdkPath. These can be used to override the default sdk. You can set them at the User, Workspace or Project level, or in individual tasks or launch configs.
  • in reply to markw65
    Nice new-version sourcePath identifier popped up on a (new) project I was working on today ... one that hasn't gone through the optimiser yet so I hadn't (yet) run into the multiple *.mc files being found problem when you don't specify the path. The diff viewer integration is very neat and helps polish a great extension.