• Replies 1246 replies
  • Subscribers 33 subscribers
  • Views 335279 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.