I recently blogged about installing a 64-bit build of Emacs for Windows because I was dealing with a bunch of large and very large files.

While the 64-bit build definitely handled the really large files much better than the 32-bit build, there were still some performance issues. The main advantage of using the 64 bit build was that I could finally load a couple of files that I wasn’t able to load on the 32-bit build, but opening the files severely tested my patience.

I grew up as a software developer on a steady diet of Dr Dobb’s magazines. I was hooked the first time I came across an issue of the magazine as a student in the university library and for most of my career I have been a subscriber to it, until the print magazine was cancelled. I was sad to read this morning that after 38 years of publication, first in print and then on the web, the online edition has now met the same fate.

In a previous blog post I explained how you can substantially improve the performance of git on Windows updating the underlying SSH implementation. This performance improvement is very worthwhile in a standard Unix-style git setup where access to the git repository is done using ssh as the transport layer. For a regular development workstation, this update works fine as long as you keep remembering that you need to check and possibly update the ssh binaries after every git update.

In my previous post, I discussed various strategies for managing third party libraries. In this post I’ll discuss a couple of techniques you can use to ensure that a specific version of your source code will get compiled with the correct version of the required libraries.

Yes, you can rely on your package management tools to always deliver you the correct versions. If you’re a little more paranoid and/or spent way too much time debugging problems stemming from mixing the wrong libraries, you may want to continue reading.

Every reasonably sized C++ project these days will use some third party libraries. Some of them like boost are viewed as extensions of the standard libraries that no sane developer would want to be without. Then there is whatever GUI toolkit your project uses, possibly another toolkit to deal with data access, the ACE libraries, etc etc. You get the picture.

Somehow, these third party libraries have to be integrated into your development and build process in such a way that they don’t become major stumbling blocks. I’ll discuss a few approaches that I have encountered in the multitude of projects I was part of, and will discuss both their advantages and problems.

Yes, I promise I’ll shut up about Emacs package management via ELPA any minute now.

Based on the feedback I had on my last post about using a combination of melpa and melpa-stable, I looked into using pinned packages via the package-pinned-packages variable that’s new in Emacs 24.4’s package.el. I couldn’t find any simple examples on how to use it, but a quick look at the source code and some playing around in ielm got me there. Well, after I finally upgraded to Emacs 24.4 on my main machine.

I’ve blogged about a little elisp snippet I use to install my preferred base set of Emacs packages before. Thanks for all the feedback, it definitely helped improve the code.

One issue that kept annoying me is that there is no simple way to tell ELPA to mainly pull packages from melpa-stable and only fall back to melpa for those packages I can’t get on melpa-stable yet. I decided to extend my code to handle that situation with some manual inputs as I know which packages can’t be found on melpa-stable. It proved surprisingly easy to do so after mulling over the problem a little.

Reposted from my old blog. Here’s the news from 2009…

I’m currently in the final stages of converting a library from raw pointers to boost::shared_ptr. I’m mainly doing this to ensure the correct pointer/pointee ownership rather than the outright prevention of memory leaks, but the latter is a nice side effect of the former.

One problem I ran into was that the library I’m updating and its clients make rather heavy use of polymorphism. Of course in 99% of the code that was fine as the objects were accessed through pointers to base classes, but the last 1% was causing problems because that part of the code contained lots of dynamic_cast statements. These classes unfortunately need to know the exact type they were dealing with so there was no easy way around the use of these idioms. It probably isn’t news to most of the people reading this blog that dynamic_cast and boost::shared_ptr don’t play that nicely.

Looks like the Windows build of Emacs 24.4 has been released to http://ftp.gnu.org/gnu/emacs/windows/ on November 15th. As usual, I appear to be a few days behind the times.

Time to upgrade and see how it compares to the unofficial 64 bit builds I’ve been using recently.

Top new feature in 24.4 for me so far is the new rectangle-mark-mode. I’m doing a bunch of code conversions right now - basically transferring a bunch of manual assignments into a big lookup table - and it’s seeing a lot of use because of it.

I originally published this post on my old blog in 2009. I’ve edited it a little for readability but left the contents unchanged, so it may be out of date and not reflect the current state of the pantheios library. I also haven’t been using pantheios for logging since about 2010, and have been using Boost.Log instead.

I recently had to come up with a logging solution for C++ code a JNI DLL/shared library that is providing the data translation layer between Java and underlying native C and C++ libraries. As usual, some logging was required to aid fault-finding in a production environment, if necessary. A quick survey of the state of C++ logging showed that not a lot had changed since I last looked at logging libraries. In fact, a lot of them seem to have survived unchanged for several years. I’m not sure if that is a good thing and a sign of maturity or a sign of “making do” and the low priority most projects assign to a performant logging library. Eventually I settled on pantheios as it offered several features that were crucial for this application. The major one was that pantheios it is extremely modular and will only link in the parts you really need. I consider this a major advantage over the more monolithic libraries that pull in all their functionality all the time, especially when you link them in as a static library (yes, log4cxx, I’m looking at you). Linking in the logging library as a static library was necessary to avoid conflicts with other libraries that are being used in the same process.