Status Report: March 2019

Hi folks,

This month, I spent some time fixing Refactor->Rename… issues — specifically when constructors are renamed along with classes. This doesn’t happen all of the time, but when invoked from certain references, rather than the class name itself. Issue 785 documents the issue. There is a secondary issue that the action is disabled (and menu items grayed out) when it should be perfectly valid. I haven’t finished that, but I have made significant progress in terms of understanding why this happens and am now building a Haxe-specific solution, rather than relying on the default Java solution.

I also spent a significant amount of time refactoring the formatting engine because the new changes to the tab settings UI exposed a number of issues and I’ve been testing more scenarios, which also exposed some issues. Things are much better now and I think I’ve finished, except that I haven’t written the unit tests. That always brings some surprises so we will see how that goes. Look for it soon.

Another long-running task that I’ve been working on has been UI changes for STD library settings and toolkit detection. I could just have released the UI change a few months ago. However, I decided to wrap that up with the changes which locate the installed toolkit and detects versions, so that we know what language features are available to the compiler. (To know whether things like arrow functions (lambdas), property settings, new keywords, and the like are available using specific toolkit versions.) Progress this month has been in the realm of locating and running the compiler and tools to get the specific versions.

What I worked on for our sponsors:


1) Type annotation cleanup: All of last months changes are merged.
2) Refactor->Rename…

What I worked on for the Community:

1) Add Haxe-specific tab settings page.
– Rewrote the formatting rule engine.
– Added new rules for a lot of previously ignored situations.
2) Progress on the new UI for standard library locations.

Community Contributions:

None this month

Next month:

1) Finish tab settings pane.
2) Finish Refactor->Rename changes
3) Fix debugging C++ projects when build with Lime. (Currently looks like
an hxcpp issue.)
4) Add safeguards so that project rebuilds won’t erase directories outside
of the project tree.
4) Time for another release!
6) Continue UI for standard library locations.
7) Haxe 4 features?

Be good, everybody!

-Eric

Status report: February 2019

This month I spent a bunch of time working on giving better error highlighting (of actual errors, now that we don’t highlight non-errors so much any more). The basic issue I was tackling was type differences. Things like numeric expressions, which in Haxe are always Floats being assigned to an Integer. This led me down a path of having to do better typing of expressions and some work toward top-down inference and monomorphs. I still have to deal with monomorphing of class fields/properties and structural sub-typing. Both of those are interesting and rather difficult to deal with. (You can look at the Haxe typer if you want a clue as to why.) At any rate, I was able to complete a substantial portion of work and made great headway.

What I worked on for our sponsor:

1) Type annotation cleanup: (ongoing)

  • Detect Float values being assigned to Int variables in variable declarations – including adding selectable quick fixes (such as “Wrap with Std.int()”). (merged – was in-review last month)
  • Detect incompatibility when initializing variables using type-tagged expressions (merged – was waiting for review);
  • Detect incompatibility when initializing variables using parenthesized expressions (merged – was waiting for review);
  • Detect incompatibility during assignment (merged – was in-progress)
  • Limited monomorph detection within a single method (merged – new)
  • Add one-click “quick-fixes” for automatic conversions to standard types, changing declared field type, etc. (merged – new)

What I worked on for the Community:

1) Add Haxe-specific tab settings page.

  • Refactor indent calculations; add “continuation” indenting (for multi-line expressions, parameter lists, etc.).

2) Some progress on the new UI for standard library locations. (It is going slow.)

Community Contributions:

None this month

Next month:

1) Finish tab settings pane.
2) Continue type annotation cleanup. (Sponsor priority)
3) Fix debugging C++ projects when build with Lime. (Currently looks like
an hxcpp issue.)
4) Add safeguards so that project rebuilds won’t erase directories outside
of the project tree.
4) Time for another release!
5) Fix class constructor being inappropriately renamed during class rename
refactoring. (FlowPlay list)
6) Continue UI for standard library locations.
7) Haxe 4 features?

Everybody have a great month.

-Eric

Status report: January 2019

Hi folks,

This month, while I spent a little bit of time understanding and finding how to fix class name refactoring, I realized that it wasn’t as high up my sponsor’s priority list as “Better error detection” was, so I switched gears back to the detection and have spent my time fixing those issues as I find them. The only one that was particularly pointed out in the work description was “var i : int = 10/2;”. I’ve fixed that and a number of other issues and am now working on the highlighted lines here:

Highlighting Type Errors

By the way, the inspections you see here are not limited to Float/Int comparisons; it applies to anything that is assignment [in]compatible. That said, the plugin doesn’t have any real unification support or monomorph type coercion yet.

What I worked on for our sponsors:

1) Type annotation cleanup: (ongoing)

  • Detect Float values being assigned to Int variables in variable declarations – including adding selectable quick fixes (such as “Wrap with Std.int()”). (complete – not reviewed — was in-progress last month)
  • Detect incompatibility when initializing variables using type-tagged expressions (complete – not reviewed);
  • Detect incompatibility when initializing variables using parenthesized expressions (complete – not reviewed);
  • Detect incompatibility during assignment (in-progress)

2) Renaming a class (refactoring) inappropriately renames the constructor. (in-progress)

What I worked on for the Community:

1) Fix review comments and merged “Extract Variable” and “Extract Constant” refactorings. (merged)

  • Added type-tag parsing (in general) and support it during extraction. (completed in January)
  • Detect type and use it to make better name suggestions. (completed in January)
  • Avoid using/allowing keywords as variable names/suggestions. (completed in January)
  • Stop infinite loop when a variable was being extracted to the class level. (completed in December)
  • Avoid Haxe keywords when making variable name suggestions. (complete in December)
  • Fixed multi-select (for renaming all occurrences simultaneously). (completed in December)
  • Fixed semi-colon detection and insertion. (completed in December)

2) Adding tab settings pane (in-progress):

  • Get pane to display. (complete)
  • Save settings and honor them. (complete, except for continuations)
  • Honor continuation settings. (in-progress)

3) Research and preliminary work on Issue #641 – where unexpected directories (e.g. root!) are being deleted.

4) Some progress on the new UI for standard library locations. (It is going slow.)

Community contributions:

1) Updated hxcpp-debugger code with code generated using hxjava 3.2.0 to get rid of warnings and messy class names (m0rkeulv). (merged)

Next month:

1) Finish tab settings pane.
2) Continue type annotation cleanup. (sponsor priority)
3) Fix class constructor being inappropriately renamed during class rename refactoring.
4) Fix debugging C++ projects when build with Lime. (Currently looks like an hxcpp issue.)
5) Time for another release!
6) Continue UI for standard library locations.
7) Haxe 4 features?

Have a great month, everybody!

-Eric

Status Report: November 2018

Hello Everybody,

I hope everyone (at least those in America) had a great Thanksgiving and is looking forward to the Holidays. I wish you all a Merry Christmas and a Happy New Year.

This month I was able to get the 1.1 release of the plugin out the door. For you folks who had been waiting while we ironed out the CPU issues with the last release, I trust you will find this release a lot more to your liking, and hopefully will make use of all of the benefits of the last two releases.

The other thing the I worked on was finalizing the work to infer function return types and propagate [generic] type parameters when resolving method call chains — or in other words: understand objects stored in Maps. That was mostly finished last month. I just had to write some unit tests, which exposed a couple more issues that I also fixed before submitting everything. Now, it’s DONE and released.

So, I have a question for all of you:  Where does Haxe4 support fall into your priorities, and what is your time frame for moving to Haxe4 (if ever)?  Please share your thoughts on the Haxe Community Discourse.

What I worked on for our sponsors:
1) Infer function return types and propagate [generic] type parameters when resolveing method call chains; resolution fixes for generics, typedefs, and array access. (Complete and submitted.)
2) Release 1.1.

What I worked on for the Community:
1) Fixed an ClassCastException in the parameter hints code.
2) Release 1.1!
3) Better handling of comments and DocX comments. (Incomplete.)

No community contributions this month.

Next month’s goals:
1) Finish new UI for standard library locations.
2) Issues debugging C++ projects when built with Lime. (Currently looks like an hxcpp issue.)
3) Bug hunt. Resolve a number of issues which have come up recently:
4) Support for more of the new Haxe4 features.

-Eric

Status Report: October 2018

Hi folks,

This month, I spent time finishing up the task to infer function return types and propagate [generic] type parameters when resolving method call chains. This took more time than expected. The primary pass was complete last month and had been in code review. It got approved, but needed unit tests. Of course, while writing those, I found another issue that took a bit of effort. So, it’s about ready for real-world testing.

I had expected to get a release out to everybody and I wanted to have this new functionality included. Thus, I waited, and now it’s been another month without a release. That is my top priority now, and I will do so before I work on anything else.

What I worked on for our sponsors:
1) Infer function return types and propagate [generic] type parameters when resolving method call chains. (Complete, except for merging into the code base.) Resolution fixes for generics, typedefs, and array access.

What I worked on for the community:
1) Fixed a few Null Pointer Exceptions for different circumstances.
2) Fixed a stack overflow when locating PSI parent of the same type as the starting element.

Community contributions:
1) Haxe 4 enum abstract support. (Ilya Malanin)
2) Fix NPE occurring while resolving module libraries. (Ilya Malanin)
3) Support of read/write access separation for “Find Usages”.

Next month’s goals:
1) Release 1.1.0
2) (Pushed to next release) Finish new UI for standard library locations.
3) Bug hunt. Resolve a number of small issues that have come up recently.

-Eric

Status Report: September 2018

Hi Folks,

It looks like the CPU over-use bug has been fixed. So, unless I hear different, I’m going to make a release shortly so that everybody can pick it up.

After last month’s status report, one of our sponsor’s employees reported an issue locating types of elements in Maps. We originally thought of it as an extension of resolving generics as we did with Vector. It turns out to be much more complicated than that, requiring fixes to (so far) array access, typedef resolution, and inferring the return types of functions — all of which required enhancement for generics as well. At any rate, that is well on its way to being fixed now.

What I worked on for our sponsors:
1) CPU Over-use bug. Profiling, code path optimization. (Complete.)
2) Infer function return types and propagate [generic] type parameters when resolving method call chains. (In-process.)

What I worked on for the Community:
1) Resolve overlap between my Haxe SDK work and Alexander’s; finish new UI for standard library locations. (In process.)

Community Contributions (Thanks to Alexander Kuzmenko and Ilya Malanin):
1) Add super call to generated override methods. (Alexander)
2) Fixed searching of interface implementations and inheritance hierarchy. (Ilya)
3) Automatically change references to a moved class (refactoring). (Alexander)
4) Fixed bug when physical variables were marked as not real. (Ilya)
5) Fixed recognizing type of “this” expression. (Ilya)
6) Verify a file is a Haxe file before conducting inspections (fixes crash on PyCharm). (Ilya)

Next Month’s goals:
1) Release 1.1 (not 1.3 — we are currently at 1.0.2).
2) (Pushed to next release) Finish new UI for standard library locations.
3) (Stretch) More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional problems.

-Eric

Status Report: August 2018

Hi folks,

A death by a thousand cuts. That’s what the CPU overuse problem really amounted to. By finding a few files that produced the problem, and then spending quite a bit of time in the YourKit profiler, I was able to find a number of places that created small delays, each relatively inconsequential in themselves. As I was attacking each of them, I kept wondering, “Is this the big issue? Is this the smoking gun?” Well, yes and no, as it turns out.

The primary issue was that resolution was slow. It was slow because it was re-doing a lot of work. Adding caching was a help, but no magic bullet. Parsing, itself, was still too slow. In the end, the parsing culprits turned out to be String.split(), the streaming Collections.collect() interface, and parsing float values — all Java intrinsic functions. The answer turned out to be: don’t do those things. Replacing and/or avoiding each of them saved time incrementally.

As it stands, parsing and annotation processing are about ten times as fast as they were. That leaves more time in the UI thread so that colorizing and annotating the sources no longer appear to delay user’s typing response.

What I did for my sponsors:
1) CPU Over-use bug. Profiling, code path optimization. (Complete? In testing.) (Also fixes bug #851)

What I did for the Community:
1) Small number of code reviews.
2) Some work on fixing the debugger launching the wrong configuration when HXML or custom configurations are used.

Community Contributions (Thanks to Alexander Kuzmenko):
1) Auto-setup of the Haxe SDK for new projects.
2) Auto-setup of the Haxe SDK for projects imported from source.
3) Auto-setup of libraries and run configuration when importing from sources.

Next Month:
1) Resolve overlap between my Haxe SDK work and Alexander’s; finish new UI for standard library locations.
2) Release 11.1 (not 11.3 — we are currently at 11.0.2)
3) (Stretch) More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional problems.

-Eric

Status Report: July 2018

Hi folks,

This month, most of my time went to the CPU over-use issue. Thanks to a bug report from Matan Uberstein, I have finally been able to duplicate it on a Windows PC, too. The base problem is that “resolving” (or figuring out what/where the type that is being referred to is defined) has slowed down and it is most apparent when working with large files — either editing or including them. This was due to a restructuring of that code: refactoring to use our model APIs and making it compliant with the Haxe language (if multiple versions of a name were found, we may have picked the wrong one). What I said last month is still true: the background processing of annotations (“Find Unused Imports” and colorizing) is much slower, and that is in large part due to the resolution issue. I have some more optimizations and I’ll keep working on it.

What I did for our sponsors:
1) CPU Over-use bug. Profiling, code path optimization.

What I did for the Community:
1) Small number of code reviews.
2) Worked on using HAXE_STD_LIB environment variable and associated UI and project changes (ongoing).

Contributions from the community:
1) Initial “Hello World!” content for new projects.  (Thanks to Alexander Kuzmenko!)

Next month [same as last month 🙁 ]:
– CPU Over-use: Finish optimizing and/or refactor “Find Unused Imports” inspection.
– Finish using HAXE_STD_LIB environment variable and be able to set it inside of IDEA.
– Fix bug where Neko (NME) is trying to be launched when custom or HXML configurations are specified.
Stretch goal – Release 11.3
Stretch goal – More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional definitions.

Status Report: June 2018

Hi Folks,

June was kind of a slow month, results-wise, but plenty of stuff got worked on…

For my sponsors, most of my time went to dealing with the CPU Over-use issue, where the CPU is running at roughly 300% forever on a Mac.  I’ve been having trouble duplicating the issue exactly.  However, we were able to create a similar results by opening up a specific file, approximately 1000 lines long, with a few dozen imports (including OpenFL). I say “similar” because it’s not clear that it’s the same issue, in that the CPU runs high for a few minutes and then calms back down if no editing occurs. We agree that it *might* be the issue, so I’m addressing it.

In that vein, we found that the problem is the background annotations; specifically, the “Find Unused Imports” inspection. In profiling that code, I have found several hot-spots and have fixed a few of them, bringing the total run time down about 15%. That’s not enough to deal with the problem, though, and the other hot spots aren’t accessible (they are in IDEA’s code — accessing the file caches). Therefore, I’m looking to change the algorithm so that we don’t have to call into IDEA’s code so much.

As for other things that got done over the month, there have not been many checkins, but things have been happening…

What I did for our sponsors:
1) CPU Over-use bug.
1a) Duplicate the sponsor’s code environment on site.
1b) Also set it up for plugin development, so that I can debug and test changes in situ.
1c) Duplicate and profile the bug.
1d) Optimize critical code path, resulted in 15% run time reduction. (Continuing)

What I did for the Community:
1) Code review of Ilya’s latest semantic annotation rewrite — needs changes.
2) Code review for Mads’ build changes (using gradle) — not yet merged, but approved.
3) Checked in the example project showing hxcpp target debugging with openfl.
4) Worked on using HAXE_STD_LIB environment variable and associated UI and project changes (ongoing).

Contributions from the community:
1) Mads’ changes to use gradle instead of ant to build the plugin are complete, but not yet merged. (Waiting for the CPU Over-use bug to be finished; it has higher priority and changing to gradle may be disrupting to work flows.)

Next month:
– CPU Over-use: Finish optimizing and/or refactor “Find Unused Imports” inspection.
– Finish using HAXE_STD_LIB environment variable and be able to set it inside of IDEA.
– Fix bug where Neko (NME) is trying to be launched when custom or HXML configurations are specified.
– Release 11.3 (Stretch goal)
– More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional definitions. (Stretch goal)

Status Report: May 2018

Hi folks,

May was an exciting month, what with the trip to the Haxe Summit this year. I was glad to meet with you and make the acquaintance of folks I’ve only known by name, thus far.

While I was there, I took the opportunity to spend time with our sponsors, Flowplay in their Seattle office, I spent a bit of time with Mark Aoyama, who mentioned a couple of frustrations he was having. It turned out that he was having speed issues that were due to another couple of plugins — that he doesn’t use — generating NPEs. When we removed them, his life was suddenly much better.  So, let that be a reminder to us all: don’t run plugins you don’t need; they slow down the overall IDEA environment and can cause unexpected issues.

Mark also pointed out that he would really like type completion when creating new methods. It was frustrating to him that completion wasn’t triggered by a ‘:’. He added it to the list of things to work on, and now it’s implemented. It is currently available in the new EAP build and will be in the next release which should come very soon.

Speaking of the EAP build, while we were all enjoying the spring weather in Seattle, Ilya Malanin was hard at work creating a new nightly build for the plugin (built against the latest *released* IDEA).  It is released onto the JetBrains’ plugin repository in the “EAP” channel.  You can enable it (and get notifications of new builds) inside of IDEA by following the directions for adding custom repositories.  Simply downloading it from the repository and installing from disk is useful, too, if you don’t like the integration.

Things I did for sponsors this month:
– Worked on CPU over-use issue on Mac.
– Added ‘:’ to the list of triggers when types are expected. (Context sensitive; not in select statements.) (Available in EAP build.)

Things I did for the community this month:
– Added UI for the location of the Haxe std library, instead of assuming it’s on the classpath. This is to eliminate a set of bugs, most notably on the Mac, where std library classes cannot be found. We still have to *use* this value when setting up SDKs, and it’s not yet merged into the development branch.
– Created an example/sample OpenFL project with a C++ target, primarily as a demonstration of hxcpp debugging. (Not yet merged into the main branch.)
– The usual batch of code reviews.

Community contributions
From Ilya Malanin:
– Nightly developer builds (from the “develop” branch) published to the EAP channel on the JetBrains plugin repository.
(https://plugins.jetbrains.com/plugin/6873-haxe-toolkit-support)
– Fixed “Find Usages” for properties.
– Support of “Find Usages” for constructors.
– Fully re-written semantic annotations, added a lot of new checks and quick fixes. Not yet merged.
– Fixed indents for fat arrow expressions.
– Fixed indents for anonymous structures fields and extends lists.
– Fixed NPE that occurred if current project SDK was not properly configured.
– Fixed parsing of anonymous type with empty body.
– Add anonymous types in anonymous types support
– Add anonymous structures names support
– Added chained anonymous fields recognition
– Add proper generics propagation for anonymous structures, typedefs and classes
– Add generic constraint support
– Add Null<T> support
– Add proper from-to declaration support, types infer and compatibility checks
– Fix referenced var-init support check

From Mads Lundemo:
– Gradle as our primary build environment for the plugin. Not yet merged into development.

Next month:
– Finish using HAXE_STD_LIB environment variable and be able to set it inside of IDEA.
– Fix bug where Neko (NME) is trying to be launched when custom or HXML configurations are specified.
– Review Ilya’s latest semantic annotation (5000 line+) rewrite.
– Release 11.3
– More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional definitions.