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.
GraphicEx has not got much love in the past years but there are still quite a number of users who still have it in their code base. This however means GraphicEx must be updated to compile with the latest compilers/IDEs. Additionally, some bug fixes have been incorporated, plus some enhancements, creating what I internally called GraphicEx II. So far however I have never found the time to publish those changes.