With the increasing popularity of Node.js I thought it would be a good idea to have a native module which provides language parsing services for ANTLR4 grammar files, utilizing a fast C++ backend. This could then be used in IDEs/editors to provide ANTLR4 language support. Additionally, I wanted to create an extension for Visual Studio Code for ANTLR4 grammars, so I started writing one.
The module itself is quite small and you can read a detailed description in its Github repository. The installation follows the usual procedure via npm (npm install antlr4-graps). However, since it is a native module, you need a compiler at hand to allow compilation during an installation. On Linux this is usually no problem. On OSX/macOS you have to have XCode installed, while on Windows you either need Visual Studio or the free build tools. Search the web if you wanna know how to build native Node.js modules on Windows, if you need help. To ease usage I have a second branch in the git repo which doesn't contain the sources, but prebuilt binaries. Note however that this branch is not published as own Node.js module.
So far I've been an enthusiastic user of ANTLR3, mostly for the MySQL Workbench product, where I based all the parsing infrastructure on the ANTLR3 C runtime. However, with the appearence of v4 a few years ago this ANTLR version got outdated and the support for it decreased constantly since then. Even though I would like to do so, I could not upgrade to the latest version because it missed an important piece: a C or C++ backend. Since I work mostly in a C++/Obj-C environment, this is an absolutely necessary part.
There were quite a number of requests for a C++ backend in the past and so a few attempts were made to create one. Sam Harwell, co-author of ANTLR and creator of the C# runtime started a C++ backend (utilizing C++14), but could never finish it. Dan McLaughlin and David Sisson then began porting the Java runtime to C++ about 3 years ago. However, this project also got only occasional love after the initial machine translation and had no contributions since summer 2015.
This is why I decided in March to jump in and get this thing done. You can see all the work in the fork hosted by Dan on Github.
One of my current projects I work on in my sparetime is Pecunia, which is an OSX app to manage multiple online banking accounts, organize financial data and provide answers about your money (e.g. monthly income and where it is spent). Pecunia is open source on Github and also available free of charge from the OSX appstore. Read in the README.md file why this is mostly useful for german users only and hence the Pecunia homepage is german-only.
One part of this application is a Swift library to managed IBANs (International Bank Account Numbers) and related data (like the BIC and other financial institutes data, e.g. the name, address etc.). It helps to create valid IBANs for bank codes and account numbers and helps with their validation. The name of this library is IBANtools and in this blog post I'm going to explain it and how it can be used (not only for german users).
One of the most common features in a code editor is without doubt code completion (aka auto completion). Every programmer has seen this before and an explanation is no longer necessary. Still it makes sense to recall what *exactly* code completion is supposed to do. It should provide the programmer with a list of strings that can appear at a given position in the code (usually the one where the caret is). It is also sensible to require code to be syntactically correct up to the invocation point. Otherwise it is really difficult to predict what the user wanted to write actually.
Implementing code completion is a non-trivial task and there are different approaches possible. This posting describes a way to accomplish that with relatively few core code, as I have done it in MySQL Workbench. It delivers very precise results and requires only few changes to adjust it to different languages.
Virtual Treeview 5.4.0 has been released and with that release I'll step back officially from maintaining the Virtual Treeview component. I moved to C++/C#/Objective-C projects a few years ago already and have hence no motivation to develop the control further. I simply don't use it anymore.