I’ve got the wonderful opportunity to work for Processing in this year’s GSoC. My mentor for this project is Daniel Shiffman. I’m developing real time syntax checking and compilation error checking functionality for the PDE (Processing Development Environment). These features are implemented as a contributed Mode. Here's a video preview of XQMode (alpha) in action:
But does it blend?
No. But imagine writing lines and lines of code, and to see the result, you hit run. Sadly, there’s some compilation error. The PDE compiler points to some ambiguous line in code, with a weird error message, like “unexpected token void”, “maybe missing a semi-colon ? ” etc. A missing semicolon or curly, or other typos, often have similar results. Well, all these days are gone. XQMode is here to help! Anytime you forget to add a semicolon, bracket, or make a typo, you’re immediately notified – syntax checking happens on the fly. You can correct it right then and there.
And what about compilation errors? Like passing a float variable to a method that needs an int? Or a typo in the function/variable name? XQMode has got you covered there too. With background compilation happening in real time, you get instant feedback! It even warns you about unused variables, methods, etc. leading to less cluttered code.
When you hit run, you can be sure that your code will always compile!
Under the Hood
Some of you might have understood by now this is very similar to the Eclipse Java Editor. That’s somewhat true. I’ve used the Eclipse JDT API for implementing these features. Eclipse JDT (Java Development Tools) is responsible for many cool features of Eclipse like generating AST, syntax checking, code-completion, etc. I’ve used the AST Parser for finding syntax errors and batch compiler for finding compilation errors. The following diagram shows the process workflow:
|XQMode Error Checker Workflow|
Here pre-processing means converting Processing code into pure java code. XQMode’s pre-processor grabs code from the editor and converts it into pure java, but not compile ready, code. This code is passed through the AST Parser. Eclipse’s AST Parser detects all syntax errors which are shown to the user. If no syntax errors are present, Processing’s pre-processor further converts this code into compile ready pure java code. This is then passed on to the Eclipse compiler which compiles and detects compilation errors which are reported to the user. The reason for using two pre-processors is that Processing’s pre-processor uses the ANTLR parser for conversion. ANTLR syntax error messages can look like Greek to the uninitiated. Therefore additional pre-processing helps in filtering out errors in a more user friendly manner.
Here’s what works:
- Syntax Checking in the background running in a parallel thread.
- Compilation Checking in the background running in the parallel thread (mentioned above).
- Import statements for contributed libraries processed on every change.
- Errors reported in the Problems window in a tabular format.
- Error bar displayed on the right with error markers.
- Clicking on an error marker or from the table, scrolls to the error location.
- Mouse hover on error marker displays error message.
- Error Checking can happen with the Problems Window closed as well.
- Ctrl + Click on the Problem Window to pause error checking.
- Problem Window is “sticky”. Sticks to the Editor window #likeaboss.
Here’s what doesn’t work:
- Sketches using OpenGL will not run. For some, this can be a deal breaker. You can edit code, but on hitting run, you’ll get a package not found error. This bug should be fixed in the next update.
- Some error statements are not reported. For example, “color color = #ffffff” - It would be nice if you can help us find more such anomalies. We hope to fix them in future updates.
- If an import statement for a contributed library is present in code but the library files are missing from the sketchbook folder, only error messages are shown. This would be improved.
- Imports (additional jars) from “code” folder of a sketch are not detected.
- Some error/warning messages may not look user friendly. We’re working to improve on that.
XQMode currently requires some modifications to Processing 2.06a in order to run. XQMode is still in development. The features and UI seen here may change in the final release.
Wish me luck!