What's it all about, Alfie?

This afternoon I was working on my unsigned 128-bit integer class, UINT128, and realized that I needed to be able to swap byte orders in place, and so I wrote a little method on the class:

  #include <byteswap.h>
 
 
  void UINT128::byteSwap()
  {
    mBlocks[0] = bswap_64(mBlocks[0]);
    mBlocks[1] = bswap_64(mBlocks[1]);
  }

and the thing I love about GCC today is that bswap_64() is a built-in function. Could it be any better? I did a little googling on byte swapping in GCC, and sure enough, there was exactly what I needed. Previously, I had been individually assigning bytes, and while it allowed for optimization, I'm guessing that this is way faster.

I need to remember to google first. It's almost always worth it.

Well, this morning I got another little treat - iTerm2 Alpha 15 is out and has a rather impressive set of features (scraped from the Sparkle update dialog):

Alpha 15
This release has one big feature: split panes! You can divide a tab into rectangular regions, each showing a different session. Also, you can now save your window arrangement and have it automatically restored when you start iTerm2.

Big new features
- Horizontal and vertical split panes. Use Cmd-D to split vertically, Cmd-Shift-D to split horizontally, and Cmd-Opt-W to close a pane. Navigate panes with Cmd-Opt-Arrow keys (but note that you may have conflicting key mappings in your bookmark, as this had been a default setting).
- Save your window arrangement including window positions, size, tabs, and split panes. You can open new windows with the saved arrangement with a keypress or use a new preference ("Open saved window arrangement at startup") to do it automatically.

Small Enhancements
- Make window title and tab labels more configurable so you can remove window number and job name.
- Add global keybindings for cmd-arrow, cmd-pageup/pagedown, cmd-home/end to scroll.
- Make opt-arrowkey send proper escape codes.
- Preferences and Bookmarks windows can now be closed with Esc key.
- When the "hotkey" is pressed, prevent the running app from getting the keypress.
- Made Find With Selection (cmd-E) behave like a normal cocoa app.
- Allow the OS to pick the initial window position if smart placement is off and no saved location exists.
- Improved wording of context menus.
- Fixed context menu's "send email" feature.

Bugs fixed
- Fix arrow key behavior in paste history and autocomplete windows (bug 407)
- Various memory leaks fixed.
- Improved behavior of full-screen tab bar display.
- Fixed applescript bug with setting window size before adding session.

While I'm not a huge fan of the split screens, I have a lot of friends that swear by them - and interestingly enough, they are emacs users. Hmmm... coincidence? Maybe not.

In any case, it's a nice update because I can get rid of the instance number on the window title and just get what I want. Also, the saved window positions is as nice as Terminal.app, and I don't have to deal with the scroll bars any longer. Unfortunately, the window positions don't include the Space they were on. I'm really hoping that Apple fixes this soon as it's one of the most annoying things about the Terminal.app (after the mandatory scroll bars).

This morning I was lamenting that the US Options Expiration calendar that I've been subscribed to for a few years now had a problem, and it was no longer available on iCal Exchange. I think from this note, it was lost, and the author never republished it. So I got tired of lamenting and did something about it. I went to the CBOE page and created a new US Options Expiration calendar. It took me all of about 15 mins and I'm sitting here now wondering why I didn't do this a long time ago.

Anyway... it's got the normal equity option expiration, as well as the VIX expiration and even the quarterly expirations. It's nothing fancy, but it's decent. I tried to keep the event titles as small as possible to make them look nice on my small iCal window, but it's a matter of taste, and that's the way it goes.

Use it if you want. I'll update it every year so you won't have to worry about that.

Whew! It's been a heck of a day... again. Today I was able to get a complete first cut of the lisp-like parser all done and checked-in. As with yesterday, the bulk of the work was really on the variant class and then just a little work in the functions of the parser. Today it was math operations and equality tests. I didn't think about it at the time, but my equality tests were more restrictive than I really wanted.

For example, originally, if I had the code:

  variant   v(25.0);
 
  if (v == 25) {
    ...
  }

it would fail. Why? Because the variant is a 'double', and the test is an integer. I had two different data types for these - as opposed to one "number" type. While that seems like a little thing, it's not - the rounding and the storage, not to mention the serialization size, all favor heavily the two distinct types.

So I had to go in and re-write all the equality and inequality operators to take this into account. Not horrible, but again, it was a few hours to get everything done right.

Thankfully, it's all done now, and the tests run great.

This morning I noticed that after a year of nothing, HandBrake 0.9.5 is out, and it's hardly a "bug fix" release. There are some major new features, and thankfully, it's going to keep do the job I need it to do - ripping DVDs, as long as I need it. There are new UI features, and the ability to run more than one at a time. I can't imagine doing that, but OK.

Fantastic update.

Today I've been hard at work filling in the parser I'm creating with the obvious collection of functions that any script is going to need. Things like add, subtract, multiply, divide... plus the more advanced math calculations - they all need to be done, but what makes this all slow going is the fact that to do this right, we need to implement these features in the variant class first, and then use them in the parser. In fact, using them in the parser is the easy part. It's getting them all in the variant class in the first place.

The reason it's slow going is that it's not enough to make a simple inequality set:

  bool operator==( variant & anOther ) const;
  bool operator==( const variant & anOther ) const;
  bool operator!=( variant & anOther ) const;
  bool operator!=( const variant & anOther ) const;

we're going to need the complete compliment of inequalities:

  bool operator==( variant & anOther ) const;
  bool operator==( const variant & anOther ) const;
  bool operator!=( variant & anOther ) const;
  bool operator!=( const variant & anOther ) const;
  bool operator<( variant & anOther ) const;
  bool operator<( const variant & anOther ) const;
  bool operator<=( variant & anOther ) const;
  bool operator<=( const variant & anOther ) const;
  bool operator>( variant & anOther ) const;
  bool operator>( const variant & anOther ) const;
  bool operator>=( variant & anOther ) const;
  bool operator>=( const variant & anOther ) const;

For the most part, this isn't too terribly hard, but you have to remember that I've got more than a dozen different types of values to check in a variant, and then there's the real work - all the convenience methods.

To make it easy to write:

  variant    v(25.0);
  if (v < 12) {
    ...
  }

I need to have a lot more operators as well. If I look at just the equality operator, I end up with something more like this:

  bool operator==( variant & anOther ) const;
  bool operator==( const variant & anOther ) const;
  bool operator==( varmap & anOther ) const;
  bool operator==( const varmap & anOther ) const;
  bool operator==( varlist & anOther ) const;
  bool operator==( const varlist & anOther ) const;
  bool operator==( uint8_t aValue ) const;
  bool operator==( int aValue ) const;
  bool operator==( int64_t aValue ) const;
  bool operator==( uint64_t aValue ) const;
  bool operator==( float aValue ) const;
  bool operator==( double aValue ) const;
  bool operator==( bool aValue ) const;
  bool operator==( std::string & aValue ) const;
  bool operator==( const std::string & aValue ) const;
  bool operator==( char *aValue ) const;
  bool operator==( const char *aValue ) const;
  bool operator==( uuid_t & aValue ) const;
  bool operator==( const uuid_t & aValue ) const;
  bool operator==( secID_t & aValue ) const;
  bool operator==( const secID_t & aValue ) const;
  bool operator==( error_t & aValue ) const;
  bool operator==( const error_t & aValue ) const;

So even if we are as clever as can be, this is a ton of code to write, and test. It's just brutal at times to make sure you haven't made any typos in the code.

I will say that I was very pleased with the one simplification I made. It's pretty easy to see that you can write the inequalities in terms of one another. However, that can take a while, and you might not end up with valid inequalities. For example, when you have two lists - which one is greater than the other? It's not easy.

My solution was to implement the:

  bool operator>=(...) const;
  bool operator<=(...) const;

methods, and then define the others in terms of them:

  bool variant::operator<(...) const
  {
    return !this->operator>=(...);
  }

So that I could be assured of at least having the "equality" in the code. Then, the others are logical combinations of these. It's not perfect, but it saves time and code, and it's a lot less headache than trying to implement a greater than on a list.

I'm back from a nice week off and it's nice to get back into the swing of things. I'll admit it was a little tough this morning, but it really worked out pretty well. Now that I've caught up with email, and reading, it's nice to be back in the full swing of things.

Vacation is nice, but it was also a lot of work with the house. It's nice to be creative once again. Ahhh...