What's it all about, Alfie?

I know I've been at this for days, and I'm making some progress, but it's tortuously slow, and several times today I wondered if this was even the right path. I could pull up my old CKit stuff and be productive in minutes. The problem is, I need async I/O. There's no two ways about it. If I cheat here and skip async I/O on these TCP sockets, I'll regret it forever.

So I have to slug through this no matter how bad it seems.

I just hope it gets better soon... I'm getting discouraged.

Today was spent trying to get a handle on the boost serialization and asio libraries to get some handle on the moving of messages over the tcp sockets that this project is going to use. If I had seen the "Serialization" example on the Asio Examples page, I'd have saved myself a ton of time, but I didn't until much later.

Ugh. What a horrible afternoon. I was trying to understand what they were doing with very limited examples and the docs on the classes aren't all that good. It's a mess.

Well... I think I have a lot better idea now.

Today has been a very hard day where I've been trying to get on top of boost and it's asio package as well as threads and serialization. It's a lot, I know, but the point of this project I'm on right now is to stop using all these home-grown classes and start to work in something like boost which will be a part of the standard moving forward. It'll make bringing up the next guy a lot easier if it's all using boost and then they only need to focus on the usage of boost, not the low-level threading, socket, and serialization libraries. It's an admirable goal, but it's a ton of work.

So today has been trying to figure out threading. I can appreciate the model boost has for threading, but I'd also like something that looks a little more like the Java Thread object - where you subclass it, have a method you implement and then can start this instance and away it goes. It's just targeted at different market - you could do the same thing, in theory, by having a method in a class the launch point for the thread, and then have everything in that one method.

Possible, but there will be times that a simple class like this will be handy - so I wrote it.

Next, I needed to deal with the atomic integers. Boost has the 16-bit versions, which is nice, but there were already applications of an atomic integer in the code (in the transfer statistics class) where I needed to have an unsigned 32-bit integer. So boost was not going to get me where I needed to be. Additionally, I really haven't liked the very C-like usage of a lot of these atomic operations on non-atomic data types. Why not just make a class that is an atomic 16-bit (and 32-bit) unsigned integer? So I did that as well.

What I ended up using were the GCC primitives which did everything I really needed - but it took some thinking to figure out. For example, with only:

  T __sync_fetch_and_add (T *ptr, T value, ...);
  T __sync_fetch_and_sub (T *ptr, T value, ...);
  T __sync_fetch_and_or (T *ptr, T value, ...);
  T __sync_fetch_and_and (T *ptr, T value, ...);
  T __sync_fetch_and_xor (T *ptr, T value, ...);
  T __sync_fetch_and_nand (T *ptr, T value, ...);

how do you do the "atomic set"? It struggled with this for a while until I also saw:

  bool __sync_bool_compare_and_swap (T *ptr, T oldValue, T newValue, ...);

and then it hit me: I just want to make sure that it always compares as "equal". Easy:

  auint32_t & auint32_t::operator=( const uint32_t aValue )
  {
    __sync_bool_compare_and_swap(&mValue, mValue, aValue);
  }

So I'm using the idea that the existing ivar is always going to equal itself, and because of that, we'll have a swap that puts the new value into place. Hey, it's not rocket science, but it wasn't clearly laid out, either.

In the end, I had two really nice atomic unsigned integer classes with all the nice operators overloaded so you can do the prefix "++" and the postfix as well, and the sum and difference. It's all there. They look and act like their non-atomic counterparts, but they are thread-safe without using any locks.

I just noticed that this afternoon that Google Chrome dev 6.0.453.1 is out and so I updated right away. I noticed that the page refresh was a little snappier, and the release notes don't really give me a great lead:

• Continued feature parity work

So we'll see... I'm all for snappier, and I'm all for more features, I just wish I knew what they really changed.

This morning I decided that it's better to make an RPM of Boost 1.43.0 and install it than to try and package this stuff on my own. So I started out on what looks to be a long and painful journey. In the end, I'll have this as a record of what to do correctly and in what order. I'll have thankfully edited out all the errors and re-dos to come up with something that really explains what I've done.

At least I hope it's going to turn out that way.

Laying the Foundation of RPM Building

First, let's figure out what we need to build an RPM. Pretty simple: a place to do it. So I created a build directory and set up everything for a build:

  $ cd ~/vendor
  $ mkdir rpm
  $ cd rpm
  $ mkdir BUILD RPMS SOURCES SPECS SRPMS
  $ cd RPMS
  $ mkdir athlon i386 i486 i586 i686 x86_64 noarch

Then in my home directory, I created the file .rpmmacros that contained:

  %_topdir /home/rbeaty/vendor/rpm

where clearly, the point of the .rpmmacros file is to tell RPM where it's supposed to look for things as it goes about it's business. This is a huge load off my mind as I now can build in peace and not have to worry about deploying until I'm 100% sure it's ready to go.

At this point, I need the sources.

Getting the Sources in the Right Place

One of the tricks I'm using is to base this build off the boost-1.33.1 SRPM spec that I can get from CentOS. So I need to get the source RPM for the older version from CentOS 5's site:

  $ cd ~
  $ wget http://mirror.anl.gov/pub/centos/5/os/SRPMS/boost-1.33.1-10.el5.src.rpm

and then I can "install it" into the building location with:

  $ rpm -i boost-1.33.1-10.el5.src.rpm

At this point, I don't need boost-1.33.1-10.el5.src.rpm any longer.

If I go into the $RPM_BUILD_ROOT as we'll call it in this process (and it happens to be called that in the scripts) we can then:

  $ cd ~/vendor/rpm/SOURCES

and we'll see the contents of the source tree. Not bad for a few simple steps! Now we need to get the latest version of boost and place it here as well. With a simple:

  $ wget http://sourceforge.net/projects/boost/files/boost/1.43.0/
         boost_1_43_0.tar.bz2/download

(all one line) we will get the latest version of the code into the SOURCES directory as: boost_1_43_0.tar.bz2. It turns out that the bzip version of the file is important as the spec file expects to see it and we don't want to disappoint (or unnecessarily modify) it.

Update the Spec File for Boost 1.43.0

I decided to go a "minimal impact" plan on the spec file. I needed to change a few things. First, the version of Boost that I'm building. The spec file is in the SPECS directory in the main rom directory. The simple differences are:

%define tarball_name boost_1_33_1
 
Name: boost
Summary: The Boost C++ Libraries
Version: 1.33.1
Release: 10%{?dist}

becomes:

%define tarball_name boost_1_43_0
 
Name: boost
Summary: The Boost C++ Libraries
Version: 1.43.0
Release: 1%{?dist}

and since I've built it already I knew I didn't need a library I didn't have on this box, so I could comment it out. If you don't need to do this, even better.

BuildRequires: libicu-devel
Obsoletes: boost-doc <= 1.29.2
Obsoletes: boost-python <= 1.29.2

becomes:

#BuildRequires: libicu-devel
Obsoletes: boost-doc <= 1.42.0
Obsoletes: boost-python <= 1.42.0

In the %package section, I needed to change what this obsoletes:

%package devel
Summary: The Boost C++ headers and development libraries
Group: System Environment/Libraries
Requires: boost = %{version}-%{release}
Obsoletes: boost-python-devel <= 1.32.2
Provides: boost-python-devel = %{version}-%{release}

becomes:

%package devel
Summary: The Boost C++ headers and development libraries
Group: System Environment/Libraries
Requires: boost = %{version}-%{release}
Obsoletes: boost-python-devel <= 1.42.0
Provides: boost-python-devel = %{version}-%{release}

Then, in the %prep section, I commented out the patches that I didn't think needed to be made as it was running fine for me as-is.

%prep
rm -rf $RPM_BUILD_ROOT
 
%setup -n %{tarball_name} -q
%patch0 -p0
%patch1 -p0
%patch2 -p0
%patch3 -p0
%patch4 -p0
%patch5 -p0
%patch6 -p0
%patch7 -p0
%patch8 -p0

becomes:

%prep
rm -rf $RPM_BUILD_ROOT
 
%setup -n %{tarball_name} -q
#%patch0 -p0
#%patch1 -p0
#%patch2 -p0
#%patch3 -p0
#%patch4 -p0
#%patch5 -p0
#%patch6 -p0
#%patch7 -p0
#%patch8 -p0

Finally, the %build section could be drastically simplified due to the new build tools in boost:

%build
BOOST_ROOT=`pwd`;
# build jam
./bootstrap.sh
 
# build boost with bjam
./bjam

and then completely commented out the %check section as I have no need of running any tests on boost - it is what it is.

Building and Verifying

Now that I have the spec file modified, I can build the RPMs:

  $ cd ~/vendor/rpm/SPECS
  $ rpmbuild -bb boost.spec

when this is all said and done, you should have the RPMs in the RPMS directory in the main 'rpm' directory - organized by the machine architecture.

To verify the contents of the RPMs, simply go into the directory and have a look at one:

  $ cd ~/vendor/rpm/RPMS/x86_64
  $ rpm -q -p boost-devel-1.43.0-1.x86_64.rpm

What you'll see is all the files that are in the RPM and it's just what you need.

Going for the Whole Burrito

If I want to build the i386 RPMs as well, I need to do two things. First, I need to edit the spec file to tell Boost to build 32-bit and to put the libs in the right place:

%define tarball_name boost_1_43_0
%define _libdir %{_exec_prefix}/lib
 
Name: boost
Summary: The Boost C++ Libraries
Version: 1.43.0
Release: 1%{?dist}

and:

%build
BOOST_ROOT=`pwd`;
# build jam
./bootstrap.sh
 
# build boost with bjam as 32-bit
./bjam address-model=32

and then I need to build the rpm with a slightly different command:

  $ cd ~/vendor/rpm/SPECS
  $ rpmbuild -bb --target i386 boost.spec

Of course, now that I think about it, it'd be just as easy to have two spec files - one for 64-bit and the other for 32-bit and then have two commands that build their RPMs, etc. Not a horrible situation at all, really.

This morning I noticed that Google Chrome dev 6.0.447.0 was out and they did a few nice little things this time:

• PDFs are now centered
• Ctrl-Click a link opens it to the right of the current tab
• Unified the Page/Wrench menus on the upper-right
• Fixed a few crashes with tabs and bookmarks

In all, a nice update. I really like the 'unified' page and developer menus as I was constantly getting confused about what was in which when I needed something. This is far better in the long run.

This morning I saw that VLC 1.1.0 was out, and thought I'd give it a look-see to see if they had picked up enough Mac OS X developer support to be able to build a 64-bit VLC on Mac, as I'm a huge fan of Handbrake, and it needs the libdvdcss that's included with VLC - but I needed the 64-bit version. Up till now, I've been using the last 64-bit build of VLC which is the 1.0.4rc release - quite old.

So this morning I downloaded 1.1.0 - which claims to be 32/64 on the web site, and then open up the app wrapper, and look. Holy Cow! it's got the FAT binary for libdvdcss which is now i386 and x86_64! Incredible! I'm able to replace 1.0.4rc with the latest shipping 1.1.0 and still keep the 64-bit Handbrake.

What a luck break for me! Super glad I checked.

OK, this is a little funny, but I just saw that there's another release of Google Chrome (dev) for the Mac! Amazing. There's nothing new on the release notes, but that's not a total surprise. There seems to be some issues with crashing, but I've honestly not seen a group as big as Google move this fast in a very long time. There must have been something really wrong with the 6.0.437.2 build.

So it goes. I'm glad to know that it's auto-updating just fine now, which is a big relief.

This morning I noticed that WordPress 3.0 was out (I had seen that it was in the final beat testing a little bit ago), and glad to see that SimpleScripts at HostMonster already had it ready to go for me. As usual, every upgrade went very smoothly, and in just a few minutes, I had everything upgraded - including the WP Super Cache plug-in. It is really nice to have access to such a great hosting service. Things just run exceptionally smoothly.

So there we have it - WordPress 3.0... I wonder if I'll even notice the difference? Maybe.

Interestingly, I read about this and still my 6.0.427.0 didn't see it as an update... so I went to Google's site and got the app directly from them to avoid any possible issues with trojans, etc. In any case, there are a few nice things in this release:

• Detach Reload from omnibox, combine with Stop, and eliminate Go.
• Implemented initial version of extension syncing. (Issue with instructions on how to enable)
• The onChanged event is now working in the extensions experimental cookies API.
• Faster scrolling on 10.6
• Fix a bug where menu items would be disabled if no windows were open.

And it's the faster scrolling that interests me most. Good enough. Up to date from the source. I hope this doesn't keep happening, it's a little creepy and I start to suspect someone's gotten into the code.