Month: December 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

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

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

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