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

    That looks like another bug, although it might be harder to fix - my typechecker needs to notice that the class was passed to a function expecting a particular interface. I'll see what I can do...

    But again, there's a workaround - put (:keep) in front of function compare.

  • in reply to crispgarmin

    (:keep) is my friend - excellent thanks again

  • in reply to crispgarmin

    Both issues should be fixed in v2.0.132

  • in reply to markw65

    I’m just going to upvote this (having two distinct menus) as I was wondering why my (:debug) annotated function was being called in the standard Build and Run. Because my VSC breakpoints were not hit, I assumed it was not a debug version until checking carefully. As a newbie scanning (so far) 55 pages of history in this channel to find this snippet is not very discoverable :-)

    >> this was an upvote for having 2 options in the build, one for Release and one for Debug as per 3 years ago suggestion from Flocsy

  • Hi Mark,

    I have not reverted my (:keep) and function signature yet to test v2.0.132 because I turned on another compatibility check (I assume) and now have a compilation issue via Prettier that I didn't have last week. The default Monkey-C debug compiler is OK.

    There seems to be some issue with the two parts of my array [location and heading] being confused because I am getting warnings like:

    ERROR: fenix6xpro: C:\Projects\Garmin\OSM\OSM_Widget\bin\optimized\group025-debug\source\source\OSM_WidgetView.mc:611,6: Trying to access an uninitialized variable.

    WARNING: fenix6xpro: C:\Projects\Garmin\OSM\OSM_Widget\bin\optimized\group025-debug\source\source\OSM_WidgetView.mc:1247,8: Cannot find symbol ':toDegrees' on type '$.Toybox.Lang.Float'.

    I could (sigh) split the array back into individual components, or a class, or maybe make the 0 a constant; but I first combined the values as a variable-reduction strategy a while back.  I'd rather build features and let the clever people like you create compilers and optimisers than guess how best to refactor my code! Though if there are hints I'll take them.

    [* Edit: tried to use a const value but that didn't help, 0 got replaced by the same variable (though my code is now easier to read)] 

     Many thanks again - Crisp

    Declaration

        // position and orientation
        //public var posCurrent_Heading as [Position.Location or Null, Float] = [null,0f];
        public var posCurrent_Heading as [Position.Location, Float];
        public var mkGotFirstLocation as Boolean;

    Original code:

                    // account for pan/drag offset
                    //  - convert px to m to degrees
                    var lonMap = (posCurrent_Heading[0]).toDegrees()[1];
                    var latMap = (posCurrent_Heading[0]).toDegrees()[0];

    Optimised Code -> ERROR

        // don't set if default 0,0 !
        if (!(pre_0 == longitudeLastPos && pre_0 == latitudeLastPos)) {
          posCurrent_Heading[pre_0] = new Location({
            :latitude => latitudeLastPos,
            :longitude => longitudeLastPos,
            :format => :degrees,
          });

    Optimised code -> WARNING: (looks like it tried to be clever re-using a "0" variable that was also in a loop)?

            // account for pan/drag offset
            //  - convert px to m to degrees
            var lonMap = posCurrent_Heading[pre_0].toDegrees()[pre_1];
            var latMap = posCurrent_Heading[pre_0].toDegrees()[pre_0];

    And finally, the prettier version of the initialise (so it is initialised OK, just needs to reference the right element of the array "better"?)

        // moved here for Prettier
        pre_0 = 0;
        mkGotFirstLocation = false;
        posCurrent_Heading = [
          new Location({
            :latitude => pre_0,
            :longitude => pre_0,
            :format => :degrees,
          }),
          0f,
        ];
  • in reply to crispgarmin

    It looks like you're running into a known problem with Garmin's type checker.

    The issue is described in the wiki. Basically, Garmin's type checker won't correctly resolve the type of a tuple if you index it with a variable, even if the variable has a known value (but note that the code is correct, and will run correctly if Garmin's type checker is disabled).

    Try the solution described there - turn on both "Post Build Optimizer" (this is a good idea for code size reduction anyway) and "Pre Skip Literals".

  • in reply to crispgarmin

    I think the current behavior pretty much exactly matches Garmin's extension - "Build And Run Optimized Project" will build based on the current compiler options.

    If you construct your own launch configs, you can add "releaseBuild": true or "releaseBuild": false, to the config (and name it appropriately for the launch menu). As far as I know, the only way to do that with the Garmin extension is to change the compiler options (adding -r for release builds).

    I should document this on the wiki though...

  • in reply to markw65

    There is so much on the Wiki and in this thread (124 pages) at risk of dumbing something very complex down a “quick start” and FAQ would help… if it’s already there that’s a sign it’s hard to find!  Changing those settings above gets me a good (over to me to test) build again thank you

  • in reply to crispgarmin

    Well yes, this thread has grown to the point it's pretty much unusable except for "current" issues.

    The extension's README is supposed to be the quick start, and the wiki is a more detailed FAQ (there are also links from many of the less obvious settings, and some of the diagnostics, into the wiki to explain what they mean). I'm happy to take suggestions for what to add where...

  • in reply to markw65

    Is there any comparison anywhere as to the optimization done with this vs the optimization done using just the Garmin compiler option?  Both size and speed?  Using multiple apps...