Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JSDT/Confcalls/Minutes 20160809

< JSDT‎ | Confcalls
Revision as of 04:12, 10 August 2016 by Psuzzi.gmail.com (Talk | contribs)

JSDT/Confcalls/Minutes 20160809

Current Status

Indexing

  • Angel is replacing the old code for the indexing. Now it is working at his best. The AST visitor is visiting the DOM AST that came out of Esprima. Parsing is correct. There is more work to do, as when searching it breaks, likely related to indexing.
    • We're just fixing the JSDT indexing, to be correct, using JDT indexing as model. Hopefully, once done, It'll come easier moving to CDT-like indexing, when the current indexer will be complete.
  • Gorkem note: we already discussed to use the CDT-related indexer (https://www.infoq.com/presentations/java-jdt-index), but for now it is kind of hard understand how to adapt this to JavaScript.

Debugging

  • Ilya is mainly working on frontend debugging. We can have a peek here: https://youtu.be/IcTn0fyaK0s.
  • Soon, target Neon.1, we'll debug HTML, i.e. within Chrome, probably using any free port, not the default one. [internally it is a WIP (hidden) configuration that connects to Chromium launch configuration ]
    • for now we assume all the resources are mapped/located in under web app folder, e.g in this WEB-INF/servlet-context.xml
    • Gorkem discussed this with Ilya. This is Java WTP-server related, and when this world receives a URL, usually it is mapped relatively to the deployment descriptor. Indeed, regular web apps are getting the mappings using that model.
  • If we want to access mapped resources, we could use URLs. For more info about this, we could ask Rob Stryker.

Docs, Oomph Setup and Contributors

  • Patrik started transcripting old meeting notes, to be published on wiki
  • There is a change from Esteban, that should be incorporated in our setup.
  • Patrik is going to work on a list of helpwanted bugs, starting from Bug 356606 and Bug 419931.

Pending Reviews

Other

  • Be aware of the issues when changing e-mail. For suggestions about that, you can contact Ilya, who wrote a list of steps for changing e-mail in Eclipse Bugzilla & c.

Closure Compiler (CC)

  • Gorkem is working on that. the DOM Converter is almost done. There are still cases in which the CC DOM is totally different w.r.t. AST, so there is some conditional code to consider the different cases.
    • i.e. in some case a CC DOM node can correspond to three different Esprima AST nodes.
  • Overall CC looks good, as it can detect much more errors, and give better suggestions.
    • CC Offers also a callback function that, in case of error/warning, can be invoked even during parsing. So, When we get the IJavaScriptUnit from the parser, we might handle errors, as they happens, perhaps via that callback. [internally: CC provides the interface IErrorReporter{} with thwo methods #error() and #warning(), that are implemented in our internal code, but not exposed externally]
  • For now, the actual CC implementation parses and just returns an IProblem[]. From first tests., the parsing looks very tolerant. The AST model of ClosureCompiler is flexible, as you can put a -no-type- ast node, and convert it later.

This is more flexible as, as an example, it can detect a function declaration as a node with no name. (opposite to Esprima, where we can't get the F() ) Perhaps we can introduce a missing AST node, to model those "missing things". And, overall, it is really helpful, as it can detect errors and indicate them.

Formatter

Back to the top