What's it all about, Alfie?

This morning I saw that WordPress 3.0.1 was released, and SimpleScripts at HostMonster was telling me that it was time to upgrade. The upgrade took all of 5 min for all my journals, and when I was done, I was once again, safe for the time being. WordPress gets hacked a lot, and I try to stay up to date with it just because of that fact.

This morning I noticed that Google Chrome dev 6.0.472.14 was released with the exact same release notes as 6.0.472.11 - "UI tweaks and no Flash loading". OK, I can see it's not a really exciting time in the Chrome group, but I wonder why they are doing all these releases and not fixing the Flash loading. Probably won't ever know...

Once more unto the boost... this time to try and get the boost::variant working. In my particular application, I've got a self-defined data stream that can include:

• Map - all keys are up to 256-character strings, values are variants
• List - all elements are variants
• Integer
• Double
• String
• Boolean
• NULL
• UUID
• Date
• Error - which is a boost::tuple of a UUID, an integer, and a variant

and with the recursion in the definition with the map and list, I wanted to try the boost make_recursive_variant capabilities.

I sure do wish boost had better docs, because even getting to the point that the code compiles was an all-day affair. Primarily due to two lines of code:

  void variant::set( std::map<std::string, variant> & aMap )
  {
    mValue = aMap;
  }

and:

  void variant::set( std::list<variant> & aList )
  {
    mValue = aList;
  }

In theory, and in practice, this should set the value of the ivar mValue, the boost::variant, to the map and list, respectively. But I got the most insane compiler errors I've ever seen. Oddly enough, when I do:

  void variant::set( std::string & aValue )
  {
    mValue = aValue;
  }

everything works just fine. So it's clearly something about the recursive definition in the code. Possibly in the const-ness of one of something, but I tried all possible permutations I could think of. Nothing worked.

Finally, I tried this:

  void variant::set( std::map<std::string, variant> & aMap )
  {
    mValue.get< std::map<std::string, variant> > = aMap;
  }

and it compiled, but when I called this code and the value in the variant was not already a map, this threw a "bad cast" boost exception. Very understandable... I'm saying give me the existing map, and then set this guy there, but there's no existing map.

Exceptionally frustrating, but I'll have to hit it again on Monday.

This morning I noticed that Google Chrome dev 6.0.472.11 was out with a very small set of release notes:

This release contains

• UI tweaks and clean up
• Additional stability fixes

Known Issues

• PDF plugin does not load on Linux (Issue 49702) and Mac (Issue 49800)

I'm glad I'm not trying to use PDFs with Chrome. In any case, it's nice to stay up to date.

I saw a nice tweet from GitHub this morning about some really nice pro git tips, and at the top of the page, it points out that some of these features require git 1.7.2. That got me thinking about what version I was on because I know I updated a little while ago. So again, I did the magic:

  $ git --version
  git version 1.7.0.3

and it looked like I needed to spend a few minutes getting up to date.

I'm a fan of the Mac OS X Git installer on Google Code as it's a clean package to download and get installed.

Took only a few minutes and now:

  $ git --version
  git version 1.7.2

Perfect!

I'll need to get this installed on my other boxes in my office tonight.

I was able to spend another 20 mins on the code conversion to a single ZeroMQ socket for my ZMQ receiver this morning. I then ran the tests, and BINGO! it worked like a charm! Excellent. I still need to do a lot more tests, but this is an amazing step in the right direction.

Today I need to test multiple multicast channels sending to a single receiver, and then I need to get a little deeper into the actual data messages that we'll be sending as I need to do some load tests to see what it's all capable of.

Very exciting times.

The design we have for my ticker plant is to have the different products and exchanges spread out over a large number of reliable multicast channels, address and port combinations. In order to do this with ZeroMQ, I was under the impression that I needed to have a zmq::socket_t for each channel - which in ZeroMQ terms is really a URL like: epgm://eth0;225.1.1.1:55555. After all, the basic code for a multicast receiver looks like:

  #include <zmq.hpp>
 
  // make a ZeroMQ context to handle all this - use one thread for I/O
  zmq::context_t   context(1);
  // make a simple socket, and connect it to the multicast channel
  zmq::socket_t    socket(context, ZMQ_SUB);
  socket.connect("epgm://eth0;225.1.1.1:55555");
  // now set it up for all subscriptions
  socket.setsockopt(ZMQ_SUBSCRIBE, "", 0);
  // receive a single message
  zmq::message_t   msg;
  socket.recv(&msg);

So in many ways, the ZeroMQ socket looks and acts like a regular socket. But I've read in many of the mailing list posts, and even talking to a guy here at The Shop that has dug into the code, that these aren't really sockets - they are just the logical way the ZeroMQ guys made their code appear to the users of their stuff.

This is never more obvious than the mailing list post I read today about having multiple connections to a single zmq::socket_t. The maintainer of the library said that there can be multiple connections to a single socket:

  #include <zmq.hpp>
 
  // make a ZeroMQ context to handle all this - use one thread for I/O
  zmq::context_t   context(1);
  // make a simple socket, and connect it to the multicast channel
  zmq::socket_t    socket(context, ZMQ_SUB);
  socket.connect("epgm://eth0;225.1.1.1:55555");
  socket.connect("epgm://eth0;225.1.1.1:55666");
  socket.connect("epgm://eth0;225.1.1.1:77777");
  socket.connect("epgm://eth0;225.1.1.1:88888");
  // now set it up for all subscriptions
  socket.setsockopt(ZMQ_SUBSCRIBE, "", 0);
  // receive a single message
  zmq::message_t   msg;
  socket.recv(&msg);

and the recv() will then pick off the first available message on any one of the connected sockets. That's great news! As opposed to needing n sockets for n channels, I can have just one, and that simplifies my code a huge amount.

So that's what I'm working on. I'm nearly done, and then I can test. Can't wait to see how this works.

This morning I checked, and Google Chrome was updated to 6.0.482.4 with some interesting new features for the Mac:

All

• [r52790] Chromium stops saving files for any large downloads (Issue 49216)
• [r52693] Fix crash with SSL client auth (Issue 49197)
• [r52850] Option clicking a link now saves a resource directly without triggering a “Save As...” dialog (Issue 36775)

Mac

• [r52911] Implement the upgrade available notification on the Wrench menu (Issue 45147)
• [r52485] Implement the new, unified Wrench menu (Issue 47848)

And I have to say, the new, unified "wrench" menu is pretty interesting:

I'm not sure how the non-standard menu items like cut, copy & paste, and the zoom are going to go over. It seems like they went for the "common denominator" here, but even then, the edit operations are all pretty standard on all the platforms - only the shortcut key-bindings are different. Hard to see why they went this way, but they did.

Anyway, it's nice to be up to date.

I finally got ZeroMQ integrated into my application library and wrote a few test clients - one to send and the other to receive. When I tried to run them I got the following error:

  $ zmqReceiver
  ..(startup)...
  (process:8444): Pgm-WARNING **: DSCP setting requires CAP_NET_ADMIN of ADMIN
  capability.

I seemed to remember something about this in the mailing list, but try as I might, I wasn't able to find that bloody reference again, and so I was stuck trying to figure this out from scratch.

Basically, because of the way OpenPGM runs, it essentially requires "privileged" access on the network drivers. OK, I can believe that. So how to I accomplish that? My limited google fu yields that the command setcap should do the trick, but that command is not on the CentOS 5 install I have, and yet the command execcap is.

It seems that the execcap runs the single command with the specified capabilities, so if I do:

  $ sudo /usr/sbin/execcap 'cap_net_admin=eip' ./zmqReceiver

then all runs well.

Sort of.

We still run into the problem of LD_LIBRARY_PATH not being transferred, so I ended up making a simple script that set the LD_LIBRARY_PATH and then called the command and that script I put in the execcap command to get things working.

And they worked wonderfully.

Now I need to find a way to make it "stick" without running it as root.

[7/26] UPDATE: when I came in this morning, the linux server I code on had been rebooted. Odd... so I decided to check and see what the state of the CAP_NET_ADMIN capabilities was. Lo and behold... it was fixed! Seems the admin guy had to reboot the box to make the change, and made it he did. I can now launch these processes without the grief of the launch script or execcap. Sweet!

In the latest MacBook Pro lineup, there's an automatic switcher from the built-in Intel graphics chipset to the NVidia chipset. Which is great, but there's been quite a bit of complaining that this is a power stealer - even the simplest of apps force a switch to the high-power, high-performance, graphics, and then your battery life drops to the floor.

So this guy has made a new menu bar app that tells you what is in use, what applications are forcing it's use, and even allows you to force it to a mode. Pretty neat.

If I am lucky enough to get one of these before Apple addresses the problem in some update, then I'll want to get this to make my life a lot easier. Slick coding.