• Replies 1174 replies
  • Subscribers 31 subscribers
  • Views 174588 views
  • Users 0 members are here
Options
Related

Big update to prettier-extension-monkeyc

markw65
over 3 years ago

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]

  • 27 days ago in reply to 9811827
    9811827 said:
    But it still fails in SampleApp

    Sorry, you're right. I was lazy, and didn't go back to the original project after "fixing" the bug. I have a fix now.

    9811827 said:
    It looks like I got lots of new errors related to enums. Maybe, I'm wrong, and they are not caused by this fix

    Pretty sure they're not caused by this fix.

    This is the problem caused by analysis throwing in all of the sources. As a result, C1.ENUM in source/amoled/2.mc could refer to the enum from either source/amoled/1.mc or source/mip/1.mc, so its type is the union of the two. Similarly C1.f could be either of the functions - but neither function accepts both enum types. Note that if you're calling a function that could be one of two types, each argument must be acceptable to both functions; ie each argument must be in the intersection of the corresponding parameter types - not the union.

    Given the way I designed the optimizer/analyser, and the flexibility of the jungle files, it's surprisingly hard to fix this. I have an ongoing project that I keep coming back to - but maybe I can do a simplified version that only deals with excluded source files, rather than exclusions in general.

    There is a workaround, which is to turn off prettierMonkeyC.strictTypeCheck. With strictTypeCheck on, the analyzer only allows things that it can prove are correct; with it off, it allows anything it can't prove is incorrect. Of course, this makes it much less useful.

  • 27 days ago in reply to markw65

    This is the problem caused by analysis throwing in all of the sources.

    Thanks, I remember that, and was kind of expecting that PMC might not work well when analyzing parallel sets of sources. I was just surprised that such error occurs for enums and not for multiple copies of code like this:

    class C {}

function f(c as C) {}

function g(c as C) {
	f(c); // OK
}

  • 27 days ago in reply to 9811827

    That's a good question... I think it's a bug.

    I do have some heuristics, where eg a reference to C in a file with a definition of C will always refer to that particular definition of C (at least in some circumstances). So given two identical files like you proposed it might resolve both the call to f, and the type of C, and avoid any diagnostics.

    But if you move the definition of g to a third file it can't do that, and ought to complain (since now C could be either version of the class) - but it doesn't seem to do so.

    I'll take a look at that too...

  • 27 days ago

    I find that Prettier Monkey C puts its optimized code in directories such as this bin/optimized/group000-debug/source/source/ . Is there any reason why "source" is repeated? 

    Another thing: when I first start vscode, Monkey C does a build without me asking for it, which then generates dozens of "Redefinition" errors due to Monkey C processing both the original code and the optimized code. Is there a way of stopping this (beyond deleting the optimized code)?