Actually, the song is called "Rock and Roll", but it has been a long time.
It all started in late September, as I've mentioned in a previous post. We rolled out a massive project, and spent quite some time picking up the pieces. Shortly thereafter, I was involved in a new massive project, and it kept me busier than usual until late January. During this time, I had little energy left to pursue my personal projects. On the other hand, I did pick up the guitar again, which I hadn't done in months. And, while there haven't been any more massive projects since that time, there has been enough research to keep this busy schedule.
Still, I haven't been idle on the personal project front. And, in some cases, there has been some overlap - lessons learned on the personal front that carry over the professional, and vice-versa. So, what has happened during this long time? Actually, it's still happening, it's a Work in Progress.
I've started working on programming puzzles, and I quickly became aware that my math knowledge is lacking, since the vast majority of such puzzles is math-based. I began working on this, but I have a very long road ahead. It's been progressing slowly.
I've also realized my knowledge of C, and how it interacts with C++, is also lacking. So, I'm - slowly - starting to learn some of C's particularities. It's making me realize, among other things, how much I really like C++.
I've been extending my systems knowledge. This is the area where most of the above-mentioned overlap happens. Due to requirements on one of the projects (mentioned above), I began with the working of certificates, DNS, and http requests. During the project, it was all very task-oriented, i.e., getting the knowledge necessary to perform specific tasks. Now, I'm going for a more systematic approach.
I've set up a VM with CentOS and built a local gcc installation from scratch (which is actually something a friend had suggested to me a long time ago). I've set up an environment similar to what I have on Windows, with Qt Creator and gcc 4.8, and I've built ICU and Boost. Then, I've decided to take a step back because the method I used to build gcc was quite time-consuming and involved, and I'm now investigating if there's an easier/faster way to do it. Also, from what I can see here, building CLoog together with gcc is now supported (I didn't see this a few months ago, when I built gcc), so I'll definitely give it a try.
I've also started learning more about linking, both static and dynamic, after being bitten by an unexpected versioning issue. As I've said above, I've built ICU and Boost, and used the latest versions available at the time. However, the version of ICU I've built was 52.x, and the version included with Qt was 51.x. I didn't think much of it, trusting I could use symlinks to the same version for both Boost and Qt. No such luck. When I tried using ICU 52.x for both, I got an error from QtCore about an undefined symbol:
u_strToLower_51. Puzzled by the version numbering on function names, I searched online and learned that DLL/SO symbol resolution works differently on Unix/Linux and Windows. This means I'll have to plan my building process more carefully. I don't want to carry different versions of the same libs around (especially ICU, which is huge). Since I get Qt pre-built, that will mean using the ICU version that comes with Qt, instead of building my own.
I've been taking on logging again. Not only taking a better look at Boost Log, but also at Poco Logger. I've already seen something I've missed the first time around - Poco Logger has a stream interface; however, I found no way to set the value of
__LINE__on the format string. So, I've decided to move forward by writing those values out with the message. On Boost Log, there is a way to do it, using custom formatters, but I've decided to use the same "solution" I've used for Poco Logger, i.e., write
__LINE__in a sort of faux-format before the message. I'll probably implement a proper solution later on; I have an idea of how it may be done on Boost, but not yet on Poco.
And I've decided to get rid of my logging bridge class template and stick with macros. Yes, evil, probably. But... I've been saying from the start I won't get rid of macros because I want
__LINE__, and I want to write it only once, on the macro definition. And my goal of being able to swap logging implementations can be achieved solely with macros. Also, by using variadic macros, I can deal with the case where different implementations have a different number of arguments, which was the reason for using the class template and SFINAE in the first place.
Local scripting environment
Due to work requirements, I've been setting up a scripting environment for a local user, on a Red Hat server. Among other things, I wanted to avoid building from source. And, as an added bonus, the machine has no internet connectivity. At first, I decided to user Perl. And, after much gnashing of teeth (and of many other body parts, some of which I had no idea were capable of gnashing), I gave up. Why? Too many hurdles, and the realization that the only viable alternative would be building from source. So, I turned to Ruby. So far, it's going much better, and I see two main reasons for this:
- Ruby, unlike Perl, has not become a "system component". This means we can ask the sysadmins to install it from the RPM repo without fear of breaking anything (e.g., system scripts).
- I found the module (gem, in Ruby parlance) management simpler. Installing Ruby Gem locally with no internet connection was simple, and so was installing gems. I still have to deal with dependencies manually, but even that has been simpler. And there is a possibility that the gem for connecting to Informix DBs may not require native building, which was not the case in Perl.
I've added some of the simple code I've done recently to github, here, including an evolution of the AppOptions class template. The design remains mostly the same (some minor interface changes), and even the implementation changes are minor.
Well, that's it. I'll try to return to a more regular posting schedule.