Status Reports?

Posted on by Eric Bishton in Status Reports

Every month, I spend a few minutes writing progress or status reports for my corporate sponsors (for which I am truly thankful).  Frequently, these are related to efforts on the IntelliJ-Haxe plugin.  They are pretty simple stuff, usually.  A bunch of one-liner summaries so that folks know what I and others in the community have been working on.  I’ll add a bit of explanation when it’s useful (like why a task is taking more time than I would expect, or what underlying issues were exposed by making related changes).  And I got to thinking…  Why not just post those reports to the blog?  Maybe you folks would like to read about recent progress?  Well, on the premise that some of you actually care, I’m going to do just that.

Here are the status reports for the last several months (in reverse chronological order):

November 2017:

What I worked on this month:

  • Split the build and run phases for debugging Flash targets. Found underlying issues that require a new solution.
  • 0.11.2 Release.
  • Fixed 16 classes of parsing errors. (The last four after the release.)
  • Wrote a ton of parsing tests.
  • NPE fix for haxelibs without metadata.
  • Disabled a bunch of debug logging that was filling idea.log.

Community contributions:

  • Added Adobe AIR target.
  • Fixed a document link.
  • Fixed a couple of null references in the lime and hxml project file models.

October 2017:

This month a client had a request to complete a task that was something another client had been asking for.  The task was to “Include all implementations of the interface in usage search.” In other words, prompt during FindUsages if a method that was being searched for was declared in a superclass or interface, whether to search for callers of the super-method or just those of the current class.  That is now complete and has been made available in a preview build (0.11.2.Preview.4).  That will go live very shortly.

What I did this month:

  • Implemented “Include all implementations of interface in usage search.”
  • Fixed parsing block statements when used as an intializer. For example: 
      class Test {
    private static var a = { // <----- Used to have a parsing error here.
      var t = "Yadayada";
      t;
    } // <---- And another here.
  }
  • Fixed exceptions when running haxelib and the SDK is incorrectly configured.
  • Refactored automatic haxelib library dependency detection and project synchronization. It now follows the complete (multi-level) dependency graph and runs much faster.
  • Add a UI option to disable haxelib library dependency synchronization at the module level.
  • 0.11.2.Preview.4 drop.

There were no contributions from the community this month.

September 2017:

Here’s the work I did:

  • Spent my time doing more work to make flash debugging reliably launch the .SWF. To that end, I added code to:
    • parse the lime-produced debug/release.hxml files to ensure that I could find the proper .SWF and runtime args;
    • invalidate and track project and lime output changes;
    • added the haxe and neko directories to the run-time path;
  • UI work to support remapping of sources from one library to another without changing import lines. (e.g. –remap support). Underlying support in the resolver is not written yet.
  • Rewrite of the module/haxelib dependency gathering (auto-updating the dependency tree for haxelibs). This helps resolving variables when one haxelib depends upon another and the user is unaware of why “find usages” and “goto” don’t seem to be working correctly.

Community contributions:

  • Fixed Windows build environment for the plugin.
  • Fix for keeping environment variables that were being dropped in some cases. (Depending upon which internal process launcher was used.)
  • Fixed NPE when static methods in statically imported classes had no parameters.
  • Fixed parameter count resolving for anonymous functions.
  • Better parser recovery after “extends” and “implements” statements.
  • Fixed parser error when dot-separated types are used in type parameters (“generics”).

August 2017:

This month I spent time on the following:

Getting flash (.swf) file debugger starting the debugger properly. I found one of the underlying problems is the environment that is in place when IDEA starts up. Unfortunately, it is in IDEA’s code and not something that can be worked around with code in the plugin. I sent an email separately talking about the issues and the workaround. There is still work to be done and I’ve been working through it.

  • Getting the hxcpp debugger to display the proper source file when source files do not properly live in either the compiled tree or the project subtrees (meaning they are referenced as symlinks to another projects source tree).
  • Adding –remap support (e.g. flash -> openFL) within the plugin. This work is to help Find, Goto References, and type resolution to be more correct. (And when type resolution is better, lots of other things magically work better.)

 

There were no community submissions this month.