What's it all about, Alfie?

This morning I noticed that Google Chrome dev 7.0.544.0 was out, with several fixes including some Mac changes in the accelerated drawing code. Well, isn't that nice? Written proof that there might actually be accelerated drawing in the browser - that would be very interesting. But it really doesn't matter - it's a good browser, and it's nice to see progress.

This morning I checked and iTerm2 Alpha 10 was out, and the release notes for this update are impressive:

The focus of this release is bug fixes. It also features a major performance improvement as well as better internationalization support. This is the first 64-bit release.

• Rewrote drawing code for up to 10x speedup.
• iTerm2 is now a 64-bit binary!
• Improve text rendering by making baselines always line up when mixing fonts and in IME.
• Input method editor improved.
• Bold selections have proper foreground color (bug 106).
• Fix bug where cursor remains I-bar in title (bug 88).
• Resynchornize properly after invalid utf-8 sequence (bug 73).
• Fix bug where opening a tab changes window size.
• Fix race condition when toggling full screen and a draw occurs.
• Fix drawing bugs.
• Fix some minor memory leaks.
• Fix bug where tab bar would not draw correctly after window resize (bug 167).
• Fix bug where one-word commands in a bookmark didn't work (bug 166).

I'm most pleased with the move to 64-bit and the speed-up of the rendering code. Fantastic work!

This morning I noticed that Google Chrome dev 7.0.536.2 was out, and the release notes look a little better than the last few updates:

The Dev channel has been updated to 7.0.536.2 for Windows, Mac, Linux and Chrome Frame

All

• Fixed saving passwords containing non-ASCII characters (Issue 54065).
• Accelerated compositing and support for 3D CSS transforms enabled by default (Issue 54469)
• WebGL support enabled by default (Issue 54469)
• Regression fix: keep the download shelf visible when multiple sites are saved. (Issue 54149)
• Add a lab for the Page Info Bubble for Windows and Linux; Mac coming shortly.

Mac

• More keyboard shortcuts for Tab Overview.(Issue 52834)
• Add sqlite and javascript memory columns to task manager

So it looks like they are back on getting new features into the code - as opposed to security fixes, etc. Nice to see. In a related note, I also saw that they took the 'beta' channel to 7.0.517.24 which is the first time 'beta' has seen a 7.x release. Nice confidence in the code, guys. Keep it up.

I noticed this morning that Google Chrome dev is now at 7.0.517.24 and while to sum total of the release notes is:

This release focused on resolving minor bug fixes or crashes. More details about additional changes are available in the svn log of all revisions.

it's something that makes sense upgrading. I'm just curious when the Mac client is going to get the hardware acceleration that they are putting into the Windows version? It'd be nice, but it's not bad now... just would love to see more widespread use of the GPU in software... it's a great untapped resource.

I've been working with the STL std::map for quite a while, but recently I use it as the core of a data structure where I wasn't finding an exact match - I was looking for a "lower bound" on the key to see where I needed to start looking for a match to the data. It's probably easier to start from the beginning. The data I'm dealing with is a std::map where the key is a uint32_t and the value is a boost::tuple of a uint32_t, another uint32_t, and a std::string. Like this:

  typedef boost::tuple<uint32_t, uint32_t, std::string> Channel;
  typedef std::map<uint32_t, Channel> ChannelMap;

Where the data looks something like this:

where the 'key' is the first value of the tuple, and the two numeric values in the tuple form an arithmetic range for a uint32_t. What I need to do is to take an arbitrary uint32_t value and find the string that it fits with. If it's less then the least range there's nothing, and if it's greater than the last, it's nothing.

The problem was that I was using STL's lower_bound() and assuming that it was going to give me what I thought was the "lower bound" of the value in the keyspace. But it doesn't. What lower_bound() returns is:

Finds the first element whose key is not less than the argument

Simply put, it find the key whose value is greater than or equal to the argument. So this is almost the "upper bound" in my book. But there's more.

The upper_bound() method returns:

Finds the first element whose key greater than the argument

which is no better. What I wanted was something like: the largest key less than or equal to the argument. Put that way, I'm not really surprised that I didn't find it. So how to I make it out of the methods I have?

What I needed to do was to look at values of both of these functions and try to make some sense of it. So I made the following test code:

  #include <iostream>
  #include <string>
  #include <map>
  #include <stdint.h>
 
  int main(int argc, char *argv[]) {
    std::map<uint32_t, uint32_t>   m;
    for (uint32_t i = 10; i <= 100; i += 10) {
      m[i] = i + 1;
    }
    std::map<uint32_t, uint32_t>::iterator    it;
    // print out the entire map
    for (it = m.begin(); it != m.end(); ++it) {
      std::cout << "m[" << it->first << "] = " << it->second << std::endl;
    }
    // now check the lower_bound and upper_bound methods
    it = m.lower_bound(45);
    std::cout << "lower_bound(45): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(45);
    std::cout << "upper_bound(45): " << it->first << " == " << it->second << std::endl;
 
    it = m.lower_bound(50);
    std::cout << "lower_bound(50): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(50);
    std::cout << "upper_bound(50): " << it->first << " == " << it->second << std::endl;
 
    it = m.upper_bound(45);
    --it;
    std::cout << "--upper_bound(45): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(50);
    --it;
    std::cout << "--upper_bound(50): " << it->first << " == " << it->second << std::endl;
 
    return 0;
  }

which returns:

  m[10] = 11
  m[20] = 21
  m[30] = 31
  m[40] = 41
  m[50] = 51
  m[60] = 61
  m[70] = 71
  m[80] = 81
  m[90] = 91
  m[100] = 101
  lower_bound(45): 50 == 51
  upper_bound(45): 50 == 51
  lower_bound(50): 50 == 51
  upper_bound(50): 60 == 61

From this, it seems like the two really aren't all that different - and they aren't. What's important to see, though, is that really the definition of greatest less than or equal to is something like one less than the one just greater. With that, I tried using the upper_bound() and then backing off one:

  #include <iostream>
  #include <string>
  #include <map>
  #include <stdint.h>
 
  int main(int argc, char *argv[]) {
    std::map<uint32_t, uint32_t>   m;
    for (uint32_t i = 10; i <= 100; i += 10) {
      m[i] = i + 1;
    }
    std::map<uint32_t, uint32_t>::iterator    it;
    // print out the entire map
    for (it = m.begin(); it != m.end(); ++it) {
      std::cout << "m[" << it->first << "] = " << it->second << std::endl;
    }
    // now check the lower_bound and upper_bound methods
    it = m.lower_bound(45);
    std::cout << "lower_bound(45): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(45);
    std::cout << "upper_bound(45): " << it->first << " == " << it->second << std::endl;
 
    it = m.lower_bound(50);
    std::cout << "lower_bound(50): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(50);
    std::cout << "upper_bound(50): " << it->first << " == " << it->second << std::endl;
 
    it = m.upper_bound(45);
    --it;
    std::cout << "--upper_bound(45): " << it->first << " == " << it->second << std::endl;
    it = m.upper_bound(50);
    --it;
    std::cout << "--upper_bound(50): " << it->first << " == " << it->second << std::endl;
 
    return 0;
  }

which returns:

  m[10] = 11
  m[20] = 21
  m[30] = 31
  m[40] = 41
  m[50] = 51
  m[60] = 61
  m[70] = 71
  m[80] = 81
  m[90] = 91
  m[100] = 101
  lower_bound(45): 50 == 51
  upper_bound(45): 50 == 51
  lower_bound(50): 50 == 51
  upper_bound(50): 60 == 61
  --upper_bound(45): 40 == 41
  --upper_bound(50): 50 == 51

If I was careful and checked for the limits, I think I'd have something. So that's exactly what I did.

My final code for finding the string in the tuple looks something like this:

  const std::string ZMQChannelMapper::getURL( const MessageMapCode aCode )
  {
    std::string     url;
 
    if (!mChannelMap.empty()) {
      ChannelMap::iterator  itr;
      if (mChannelMap.size() == 1) {
        // if there's only one... try it - we might get lucky
        itr = mChannelMap.begin();
      } else {
        // find the high-end of the enclosing range in the table
        itr = mChannelMap.upper_bound(aCode);
        // if it's not at the ends, back off one to the start
        if ((itr != mChannelMap.begin()) && (itr != mChannelMap.end())) {
          --itr;
        }
      }
      // from this starting point, check the range for a match
      if (itr != mChannelMap.end()) {
        Channel & tupleInfo = (*itr).second;
        if ((tupleInfo.get<0>() <= aCode) &&
            (aCode <= tupleInfo.get<1>())) {
          url.append(getBaseURL());
          url.append(tupleInfo.get<2>());
        }
      }
    }
 
    // all done - return what we have
    return url;
  }

It works, and it's OK, but it's clear why they didn't make something like this in STL - far too specialized. But I have it now.

I was updating the configuration of WP Super Cache on my WordPress installs at HostMonster this afternoon and noticed that Google Chrome was saying there was an update - I said 'yes', and saw that it's up to 7.0.517.13. OK... nothing in the release notes on this, maybe I'm just a little early.

As for the "Don't be Evil"... the problem is that Chrome is a really good browser. It's a few in the management that I have issues with. So that's the rationalization I'm going with. Yup. It'll work.

This morning I got a tweet about a new beta of the IM client I use every day: Adium 1.4b19. There are a lot of little things that have been fixed, and several localizations have been updated. Nice stuff. I wasn't aware that they had added twitter support to Adium, but it makes perfect sense as the all-purpose instant messaging client. Even better.

I've been a big fan of Google over the years. A really big fan. I have appreciated their clever interview questions posed as adds in trade magazines... I have really loved and used their Google Visualization API... but the company seems to have taken a turn for the worst. These problems with Skyhook are really too much.

If Google is going to behave that badly, I'm heading back to Firefox 4 and stopping using Chrome. It's not that I need that great a secondary browser, and I just have a hard time backing a company that is doing such bad things when clearly they don't need to. They are letting power corrupt them. They should have known better.

So until I see something that really convinces me, I'm back to Firefox.

UPDATE: it turns out that Firefox 4 takes a little less memory than Chrome 7.0.517.8 - nice. I'm hoping that what I've read about the performance of the JavaScript engine in Firefox 4 is as good as they say. I just would hate to have to move back to Chrome to get something that was responsive. Don't Be Evil - indeed.

Looks like Google Chrome dev has a few more bugs fixed, but the blog of the release notes is a little sketchy about what the exact nature of these bugs are. So I take it on faith that I'm going to like these changes, and install the update. Can't do a lot else.

This morning I noticed that they had released another update to Cyberduck: 3.6.1. The 3.6 update was a few days ago, and I got it, but hadn't the time or inclination to write about it. It's now got a "nag tag" in the title bar, and while I don't begrudge anyone the ability to do what they want with their own code - especially if it's free, I do realize that I'm far happier with Transmit 4 given it's new design. It's all about file transfer, but I just enjoy the interface of Transmit 4 more.

So I got it, and then the 3.6.1 update as well, but I'm not sure I'm going to be doing a lot with them in the near-term future.