What's it all about, Alfie?

I was working on my latest price feeder today and got word that I wasn't sending enough information to the receiving system for it to make proper use of the data. Basically, I needed to get more data about the instruments from this system and then feed it back to the system with each price for each instrument. Problem was, that really made the way I was storing data for each instrument a royal pain and I needed to go from a simple STL data structure to a class that will hold all the data for each instrument and then put these instances into a data structure for efficient access.

What I did was something a lot like this test code:

/*
 * This trys to reproduce the bug I was seeing in the initialization
 * of the CKString while in a CKVector in a std::map.
 */
#include <iostream>
#include <map>
#include "CKVector.h"
#include "CKString.h"
 
typedef struct tuple_t {
	CKString	one;
	CKString	two;
	CKString	three;
 
	// constructors
	tuple_t() :
		one(),
		two(),
		three()
	{
	}
 
	tuple_t( const CKString & aOne,
			const CKString & aTwo,
			const CKString & aThree ) :
		one(aOne),
		two(aTwo),
		three(aThree)
	{
	}
 
	tuple_t( const tuple_t & anOther ) :
		one(),
		two(),
		three()
	{
		*this = anOther;
	}
 
	virtual ~tuple_t()
	{
	}
 
	tuple_t & operator=( const tuple_t & anOther )
	{
		one = anOther.one;
		two = anOther.two;
		three = anOther.three;
 
		return *this;
	}
 
	bool operator==( const tuple_t & anOther )
	{
		bool	equal = true;
		if ((one != anOther.one) ||
			(two != anOther.two) ||
			(three != anOther.three)) {
			equal = false;
		}
		return equal;
	}
 
	bool operator!=( const tuple_t & anOther )
	{
		return !operator==(anOther);
	}
 
	CKString toString() const
	{
		CKString	retval("[one=");
		retval.append(one).append(", two=").append(two).
			append(", three=").append(three).append("]");
		return retval;
	}
} tuple;
 
typedef CKVector<tuple> TList;
typedef std::map<CKString, TList> TListMap;
 
int main(int argc, char *argv[]) {
	// make the map - no entries
	TListMap	myMap;
	// this is the first key we'll be using
	CKString	myKey("key");
	// create the first map entry
	TList	& list = myMap[myKey];
	// create a tuple to place on the list
	tuple	t("a", "b", "c");
	std::cout << "tuple = " << t.toString() << std::endl;
	// put the tuple on the list
	std::cout << "list has " << list.size()
			<< " elems with capacity of " << list.capacity()
			<< std::endl;
	if (!list.contains(t)) {
		std::cout << "tuple not in list, adding..." << std::endl;
		list.addToEnd(t);
	}
	// print out the map
	std::cout << "here's the map now: ";
	TListMap::iterator	mi;
	for (mi = myMap.begin(); mi != myMap.end(); ++mi) {
		std::cout << mi->first << " = [";
		for (int i = 0; i < mi->second.size(); ++i) {
			if (i != 0) {
				std::cout << ", ";
			}
			std::cout << mi->second[i].toString();
		}
		std::cout << "]" << std::endl;
	}
} 

Lines 10-76 simply creates the object that is going to hold the instrument data - in this case, three pieces of data. Line 78 creates a type that is a simple vector of these tuples. Line 79 creates an STL map where the key is a string and the value is a vector of these tuples. Seems like a reasonable data structure, given that I'm basing this all on CKit.

In the main method, I'm basically creating a map of these string-list pairs, then creating a tuple and seeing if the new key isn't there - it's not, and then adding the tuple to the end of the list. This all works fine on Mac OS X 10.5.2 and GCC 4.0.1 (Xcode 3.0). But on RHEL 5 (CentOS 5) with GCC 4.1.2 we get an entirely different result.

At line 97 we get a very spectacular core dump. The gdp session is basically showing me that the initial value of one in the existing allocated storage in the vector for the first element is not being properly initialized. This initialization is done properly on OS X, but on RHEL5 it's not. When I change the typedefs to say something like this:

typedef CKVector<tuple> TList;
typedef std::map<CKString, TList*> TListMap; 

thus making it necessary for me to new a TList and place that into the TListMap, and then delete it when I'm done, then things work just fine and the initialization is properly done.

I'm not that big of a stickler for compiler bugs - they happen, but so rarely that it's not worth getting all bent out of shape over one that's so easily worked-around. But I'll admit, it's a little frustrating to think that it's your fault for several hours only to find out that it's not, that at least a part of me wants to send in a bug report, but I probably won't. Just glad I got it figured out.

Today I had to move my development of my latest price injector to a RedHat Enterprise Linux 5 machine (RHEL5) due to some third-party libraries that required version of libs that were present on RHEL5 but not RHEL3. No worries, I think, I have the machine, I just need to get a few things from the CentOS 5 site to complete the development tools installation, and then I'm ready to go.

I'm a Vim guy... love it. Don't even think about what I'm typing most of the time, so it's natural to put Vim on the RHEL5 box so I can edit the source. No surprise there. But what was a surprise is the fact that the menu redraw was exceptionally slow. I mean way way too slow for the machine and network I was using. Clearly, something was wrong.

So I started to investigate GTK themes a bit. Turns out, the one I was using (GTK-Step) uses bit-mapped graphics for the menus. This is a lot slower than we need. There's another called Smooth-Metal that was every bit as nice and after a few hours I was able to make it downright appealing to me, that uses a fraction of the bandwidth for the X11 GUI. The trick was having a tool to change the GTK Theme.

Enter gtk-chtheme. This is a wonderful little program that allows you to see the theme in action and then apply it to the window manager and voila! This is an important link to remember because I did a lot of searching to find something that worked as nicely as this little guy. Saved me a lot of grief.

UPDATE: gotta watch out though... the GTK Theme I like (Smooth-Metal) I've hacked up a touch to look even nicer uses the GTK Engine 'smooth' and that's not on RHEL3 - or FC3 systems. You have to get a reasonably recent build to get the 'smooth' engine. I've even tried compiling it from scratch for my RHEL3 boxes but it requires GTK 2.4+ and that is again more than is on the RHEL3 boxes and getting that on the boxes is too much because of the RPM dependencies. In short - it's too much grief for the benefit. So just be clear about what you're getting into with some of these themes.

[3/10/08] UPDATE: seems the theme engine is crucial. So I looked at the engines for FC5, RHEL3 and RHEL5 and came across the engine ThinIce. It works really well, and after about 20 mins of fiddling, I had something that looked as nice as the Smooth engine, but was working great on all the platforms I have. Now
I'm really set. Nice to get that out of the way.

I've noticed this issue with my MacBook Pro's keyboard ever since the update with Leopard - if you let the machine sit for a bit, no need to let it go to sleep, just let it sit for 5 mins, and then hit the keyboard, the first key will be ignored. Seems I'm not the only one to notice. The friendly guys at Apple have seen this and released an update.

One of the most interesting things about this update is that it requires no reboot in order to be put in place. Pretty slick. I should be able to see the difference today, and I'll sure be looking, but I'm guessing the problem is fixed - which is just great.

I've been waiting for this for a while now, and I have to say that I'm really pleased so far with the update. I got the huge 10.5.2 update and then the Leopard Video update, and then the iLife update. Busy updating day.

Some things I"ve noticed already:

• Terminal.app - opening multiple windows at start-up now doesn't leave some of them hanging. Nice.
• TimeMachine - the little menu icon is nice - not earth-shaking, but nice.

I haven't had a lot of time to play with things, but when I do, if I see more things worth writing about, I'll jot them down. For now, it's nice to look at the release notes and see all the work they put into it.

UPDATE: new hidden preferences feature was reported here that keeps Spaces in 10.5.2 from moving to the Space with the application on it when switching to that app. This is something that I didn't like about Spaces originally. I'd want to open a new editor window and when I clicked on the icon on the Dock, I'd automatically go to the Space where that application was already open. Now I don't have to have that happen. I click on the app and I stay on the Space I'm on. Excellent.

To set this up, simply go to the Terminal.app and say:

  defaults write com.apple.Dock workspaces-auto-swoosh -bool NO
  killall Dock

and it's ready to go. To reverse it, make the NO a YES.

I've been trying to get secure SMTP (SMTP with SSL) working with HostMonster for quite a while, and finally this morning I have it all figured out - I think. There are a few parts to this, and the docs on the HostMonster Help Center are pretty close to what you need, but there are a few things that I believe are important to getting this to work successfully.

First, set up the standard POP in Mail.app in Mac OS X. It's pretty simple with the following parameters:

• Port: 995
• Authentication: Password

For the outgoing SMTP you need to have:

• Server Port: 465
• Authentication: Password

Which is all just as the docs say on the HostMonster Help Center. But the trick, I believe to getting Mail.app to work is in the trusting of the certificate that each HostMonster machine uses. Understandably, to save costs, the HostMonster guys created certificates for themselves and set them to expire in 2034. But Mail.app sees that these are not signed by a Trusted Authority, like Verisign, for instance. I don't care about that, but each time Mail.app starts, it connects to the HostMonster machine and sees that the certificate is not from a Trusted Authority, and asks me to agree to connecting anyway.

Here's the trick... when that comes up, ask Mail.app to Show Certificate to get a look at it. Under the name there will be a little check box saying "Always trust machine when connecting to machine". Check that. Then say OK.

At this point, you're not going to get that question on startup of Mail.app, and you're going to be able to use the SMTP/SSL on the host. Now it's possible that HostMonster changed something on their end, but I think from an email I received from the help desk, this is the key.

you would not use password authentication. When enabling SSH you need to be aware that the SSL is self-signed on the server, and many mail programs are going to give you greif about this. They will require that you click accept every time you sent/receive emails.

So what I'm reading here is that the nature of the certificates that they use are that they are not trusted by most systems, and by overriding that in Mail.app, I'm actually able to connect and get the messages sent. I've verified that they are working, which is a great big load off my mind.

I don't trust insecure Telnet/FTP/POP/SMTP - there's just too many people out there that are too smart and too persistent not to write something that can grab anything in plaintext. I just can't see why people would use plaintext protocols when they have secure alternatives. I'm glad that I have this working with HostMonster. Big load off my mind.

I've written about games that have held my interest over the years, and again I have to mention that the game at the top of that list is Risk - on the Mac it's iConquer. It's not fast-paced... the graphics aren't like individual leaves on trees that you mow down with some flame-thrower... but it's a fun game. The problem is more of trying to get the people together.

My kids play the DS, or the PSP, or the Wii - which can be a lot of fun, but it's not the same as a game like Risk. Turn-based, dice-rolling, fun memories of playing with friends in high-school for hours on end. Alliances made, broken... winning, losing, being one of the last two... being one of the first out. It's just an experience with people as opposed to machines.

I guess it's like a lot of things... it's what you bring to the game that makes it special. And on that score, I bring a ton of great memories, and that's what makes it a great game.

It's not as often, that's for sure, but it's still there - the bug in Adium 1.2.1 where when I open my laptop and it wakes up from sleep the sound effects in Adium are missing, gone, silent, whatever you want to say. It doesn't seem to happen every time, and maybe it's in OS X, for all I know, but it would be nice not to have to restart Adium when this happens.

I know there's a new Quicktime 7.4.x update that I need to apply, but I'm doubting that that update is going to really effect me, but I'll give it a go and see if that helps anything. Meanwhile, I'll just have to restart it as I've already sent in the bug report on this already.

UPDATE: I did the Quicktime update. We'll see if this makes any difference on the sound from Adium.

Today two new releases on the FORTRAN front - both nice to hear. The first is that there's a new build of gfortran on the Mac HPC web site. This is the stand-alone compiler that works with the Xcode 3 tools from Apple and gives you basic command-line gfortran compiling. It's an easy install - simply un-tar it and it's ready to go.

The other is that the MacResearch guys have put together a .pkg file for installing the above mentioned gfortran and also an Xcode 3-compatible plugin for gfortran so that you can create FORTRAN projects in Xcode 3 and build them without having to use Makefiles.

I'm a huge fan of the compiler, and I'll probably get the package and install it on my iMac G5 at home to make sure it works OK, but on the whole, I don't do a lot of work with FORTRAN that isn't already covered with Makefiles. This is because there's usually also a few C files and then I'm old school when Makefiles were considered 'new'. So I have them in my projects already and there very fast to write if needed.

But if I were teaching someone about FORTRAN, I'd definitely make sure they had the Xcode 3 plugin installed. Thanks goes out to the two groups for taking the time to update the tools.

OK, this is something I never thought I'd have to do, but this evening I had to password protect my blog. I was getting more grief about it from the management where I work - specifically saying that I could no longer discuss anything related to people or events that took place at the office. In one sense, I can understand my manager's issues - he's told by his boss that this shouldn't have happened, and it shouldn't have, and he responds by trying to make himself look less of the bad guy and more of a sympathetic representative of The Man.

Interestingly enough, you can't do this password protection in the WordPress configuration. At least not unless it's hosted at their site. I don't know why this is, but I found a plugin that allows me to put a password on anything related to the weblog. I'm not sure it's 100% crack-proof, but it's certainly well past a good-faith effort to keep people out of this blog.

UPDATE: If I turn this on, then I can't use MarsEdit to write my posts. That's not something I can live with. What I can do is to post all the messages as drafts so that they aren't visible to the average viewer until I specifically publish them. They are still held on the server, just in a draft state. This way, I can make it appear as though I'm not posting anything else while I am - just not making it visible to anyone but me.

[2/7/08 3:31am] UPDATE: I'm trying to get the password plugin to work with MarsEdit. Hopefully, this will work. Excellent! By excluding the XML-RPC URL from the default password protection, I can allow WordPress' password protection on that to work and the plug-in's password protection to work on everything else. It seems that I have a very workable solution now. No one can look into these pages without the password.

[2/11/08 4:00pm] UPDATE: I've taken it offline simply because I've received more talking to about this weblog. I was meant to help me feel better, enjoy what I've done, and act as a record of the problems I've solved so I don't have to solve them again. But it's become a boat anchor and I've got to shut it down.

Today I was working on loading up my new price injector with the instrument data from the vendor's system and was originally thinking that if they just made their database layer available to me via their supplied shared library, I'd be able to send the query, read the answer and be done. Alas, they don't allow that.

But what they do have is a stand-alone app that takes a file with a request in it and can generate a file with the output of the command. I was a little concerned about how it'd all glue together, but I shouldn't have been. C/C++ really does have just about everything you could ever ask for in a language, and interfacing with stand-alone apps is no exception.

I was able to build the command, execute it to a temp file that I then read after the command was done. It wasn't as clean as it could have been, but it really wasn't that bad either. Thank goodness that all I had to do was get a list of instrument data.

So in the end, my concerns about the clunky nature of this interaction was really much ado about nothing. C++ made it much smoother than I was afraid it was going to be. Then again, when we fill up disk space and the output file can't be written, I might be singing another tune. But that's for another day.