What's it all about, Alfie?

I'm looking at the plans for my next project, and the guy I'll be working with side-by-side is pretty much set on C++ for his project, and since it feeds into mine, I really would need a spectacular reason not to pick the same thing. So I started looking at the current version of the project I'll be updating and seeing what it had that I might find difficult to get my hands on in C++. The key components I could come up with were:

• Good Database Tools - with SQLAPI++, there's no problem there. We can connect to MS SQL Server which is the "standard" at the shop.
• In-Memory Database - it might be very nice to have something like H2 in C++ so that should I choose to go down that path, it would be as easy to use as an external database, but much faster.
• Web Server - the current project does a lot of serving of requests via 29 West and http requests (it's a Tomcat web app). If I"m going to make the transition as simple and easy as possible, then I need to be able to handle http requests.

When I started looking at the in-memory database, I realized that SQLite can be used to create in-memory databases, and since it's also supported by SQLAPI++, it's a perfect solution for what I might need. You only need to open a connection the the special file named :memory: and the connection returned will be to a blank, in-memory database. Close the connection, however, and the database goes away.

Additionally, if you open another connection to the same special file, you'll get a completely different in-memory database. This is really interesting in that it allows the user to create as many unique in-memory databases as they wish. Unfortunately, it's not as nice as H2 in that the connection can be set to stay open, but it's a reasonable compromise for an in-memory database.

Even if I didn't use the in-memory database, the SQLite filesystem database is strong enough to not corrupt the file through power outage, and it's very fast for a single system to hold data - so should I want to use it to hold configuration details or parameters, it's certainly more than up to the task.

So I think I have more than enough on the database front for this project in C++. But the real question was the web server interface. I needed to have an embeddable web server that was going to be reasonably fast, small, easy to interface to, and handle all the things I needed. I had to hit Google for this one.

After a lot of poking around, I found several that might fit the bill. The most interesting is Lighttpd - pronounced "Lighty" by the author, and it's goal was to be able to handle 10,000 connections on a single server. Admirable goal, and it's being used by some heavy hitters out there. The big problem seems to be that it's a complete web server with CGI capability. That means that I'd need to create something to use as CGI and then put that into the web server. Not a lot different from using Apache, except the loading capable with the server. So I kept looking.

I found a GNU project: libmicrohttpd which is a C library that you can embed and gives you tons of the goodies you'd need - and far more than I'd need in this application. It's in C, which means it's going to need to be wrapped at least a bit, but it's a strong possibility in my mind because it's a GNU project, and they tend to be pretty bug free.

Probably the most promising candidate seems to be mongoose hosted on Google Code. It appears to be a nice C/C++ library that runs on a ton of platforms and handles all the things I need a web server to do. Additionally, it boasts a simple, clean API to plug into for request processing.

After looking at mongoose, I think I have enough to get started - technically, on this project. It's not necessarily ideal, but I have to say that if I ported my Google DataTable code from Java to C++ and put it in CKit, I think there's not a lot I couldn't do in the existing project. The real problem is that there's a ton I want to do in the new project that's a lot more complex than what's being done in the current project that I'm still going to need to think about it.

I just don't want to get to the point that I have to re-write huge chunks of functionality from one language to C++ in order to get things working. It's a waste of time and a maintenance nightmare.

This morning I decided it's been almost a year since I've gotten the latest FORTRAN compiler from the HPC for Mac OS X web site. They typically update ever couple of months, and with the release of Snow Leopard, I was in for a wonderful treat - they had a Snow Leopard version that generated 64-bit executables. This is fantastic news!

I downloaded the package, updated my uninstall script based on the tarball's contents, and then gave it a whirl.

  peabody{drbob}275: gfortran --version
  GNU Fortran (GCC) 4.5.0 20090910 (experimental)
  Copyright (C) 2009 Free Software Foundation, Inc.
 
  GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
  You may redistribute copies of GNU Fortran
  under the terms of the GNU General Public License.
  For more information about these matters, see the file named COPYING
 
  peabody{drbob}276: 

Sweet.

I love that they build this package with auto-vectorization and OpenMP built in. This is just one of the most wonderful treats of life: to be able to work with such a wonderfully simple programming language on such wonderfully complex problems. Face it - there's no GUI for FORTRAN, it's standard out. Period. That means that you're not going to be making a cool web browser in it. It's not meant to do that. It's meant to push bits around and solve problems like never before.

There's no doubt that FORTRAN was one of the things that drew me into computers back in the 70's. It's just that incredible. I feel incredible joy in being able to use it. Thanks to the HPC on Mac OS X guys for making my day.

I've heard a lot about ClickToFlash, and I have stayed away from it so far because I didn't think it was that bad. I mean sure, a few stolen cycles here and there, but I didn't think it was a really serious problem. But still... I've seen Liza's computer. She's always going to very heavy Flash sites and she could really probably use this.

So I decided to get it and give it a spin. It comes highly recommended, so it's not junk. We'll see if I don't like this better. Certainly, it's something to try with Liza.

I was working at home today and needed to get into a Windows box from home. I fired up the Cisco VPN from within Shimo (incredibly app), and then fired up CoRD. I noticed there was an update to 0.5.1, so I got it.

I have to say this is what I like about folks that write code for Macs. It's stellar. Superlative UI, clean, simple, well thought out. It was a joy to use. I almost didn't mind that I was connecting to a Windows box when it looked this nice.

I got what I needed done quickly, and things shut down as gently as could be. What a wonderful experience. Loved it.

Today I wanted to upgrade my PostgreSQL install to 8.4.1 (from 8.3.x) based on the KyngChaos package I'd just started using. It's as much a test of the upgrade process as it is about any 8.4.x feature in PostgreSQL. It's really not all that hard, just a few steps in the right order.

First, open up a Terminal.app window and become the user postgres:

  su - postgres

then, dump the database. Assuming you're in the postgres user's home directory - /Users/postgres, you can do something like:

  /usr/local/pgsql/bin/pg_dumpall > postgresql_20090930.dump

and the dump will be tagged with the date. Easy.

Next, turn off the existing PostgreSQL engine, and set set the old install aside:

  sudo launchctl unload /Library/LaunchDaemons/org.postgresql.postgres.plist
  cd /usr/local
  sudo mv pgsql pgsql_old

Next, install the new package. If things are going well, the new engine will be started by the installer. As long as the launchd file exists, you should be OK.

Next, load the databases. Back in the postgres user's Terminal window:

  /usr/local/pgsql/bin/psql -d template1 -f postgresql_20090930.dump

Check that the databases are back and functioning. Then it's just a matter of a little cleanup:

  sudo rm -rf /usr/local/pgsql_old

This morning I saw that Camino 1.6.10 was released. It's not my favorite browser, it's Mac-like, sure, but it's not as Mac-like as Safari. Also, it's going to be hard to beat the Safari experience on Snow Leopard, and they need to build it for multiple Mac OS versions. Still, I use it probably once a week, and when I do, it's nice to know I'm up to date and have the latest security fixes, etc.

Not quite the best browser, but it's nice to have around when I need it.

This morning I noticed that Growl 1.2 is finally released, and had to update. This is one of the big things that didn't work well with Snow Leopard, and I'm glad the developers stuck with it to get everything fixed up as soon as they could. Things take time.

I was looking at a few git-related things this morning and noticed that the open source Mac OS X git GUI client, GitX, was now at version 0.7.1 which was a nice jump from the last version I'd gotten. In this version, it's picking up the user's images from Address Book, like Mail.app, which is really neat - nothing fancy, but neat.

Also, there are a lot of fixes and features in this new version. Very nice indeed.

Once again, the Growl team has published another beta, this time 1.2b5. The list of remaining issues is shrinking rapidly, and I've got to believe in a few more weeks they'll have them all worked out. But for now, it's nice to see that progress is being made.

This morning I saw that VLC 1.0.2 is out with an improved Mac OS X interface and a slew of updates and fixes. It's the "working part" of HandBrake, so I like to keep it up to date so I can rip DVDs.