What's it all about, Alfie?

This morning I saw that Cyberduck 3.8.1 is out, and while I had gotten 3.8, I hadn't written about it because I hadn't really even fired it up. I have to say that while I didn't mind the nagware screen asking for you to register the product, the little tag on the title bar is a new level of intrusive.

OK... I'm not a registered user, but then again, I'm a Transmit user and pay for all it's updates, etc. Cyberduck is an emergency back-up when Transmit might not get the job done. But to be fair, for those that don't want to pay for an FTP client, and I know a lot of people in that boat, this is a great tool. It's fast and capable, and the nagging is the equivalent of in-app adds on the iPhone. Something I hate, and will pay to see removed, but something that is just fine with a lot of folks.

This morning I noticed that Google Chrome dev 9.0.597.10 was out, and the release notes indicate that it's just stability fixes and a few UI tweaks. Fair enough... not every release can be amazing, and it's getting into it's final form. There hasn't been a big change in the UI in quite a while, and the improvements in the V8 engine or other infrastructure components are going to be constantly ongoing.

Still... it's nice to see progress.

This morning I was chatting with Martin S. on the ZeroMQ IRC channel and there was a suggestion of how to handle the "socket recovery interval in msec" option in the code. He pointed out that I'd need to change the ZeroMQ code, and why didn't I do that and then send the patch to the mailing list and he'd incorporate it.

Sweet! A request for a (simple) patch to the codebase by the primary maintainer. I like this stuff. It's not hard, but there are a few wrinkles, and the coding standards are at least in existance, which is a huge help to the project. I just need to get a few things figured out, write the code, compile it all up, and then make the diff for the mailing list.

I'm sure there's going to be a lot of little details I learn as I do this, but it's nice to get a chance to contribute to another nice open source project.

UPDATE: I've pretty much got it all done, but the hint I received from the guy that really knows OpenPGM in the group is a little sketchy. He gave me an equation which includes the size of the transport package:

Easy workaround is to calculate the buffer size in sequence numbers in 0MQ and pass that onto OpenPGM. Then you can export socket options for 0MQ to set the buffer size in seconds, milliseconds, etc.

int sqns = (secs * max_rte) / tpdu_size;
pgm_setsockopt (sock, IPPROTO_PGM, PGM_TXW_SQNS, &sqns, sizeof (sqns));

I think I found what should go in that spot, but I wasn't 100% sure. So I replied to the guy on the mailing list and now I'm waiting for confirmation/correction from him. It shouldn't take too much longer to finish this up, and then I'll have a way to set the ZMQ_RECOVERY_IVL_MSEC - which, with a non-zero value, will override the ZMQ_RECOVERY_IVL value and use the value in milliseconds. Should be pretty easy to finish.

I noticed this morning that WordPress 3.0.2 was out with some security fixes. It seems to say that they have now figured out how to update WordPress from within WordPress. If so, that would be very interesting indeed. I still used the SimpleScripts upgrade path that HostMonster has - I didn't see a need to "test" that part today. Maybe the next update.

But hey... I'm all up to date and that's great news.

After quite a silence, Google Chrome dev 9.0.597.0 is out and there are some really nice fixes in this release:

All

• Ongoing work on IndexDB and GPU
• Tweaks/Fixes to Google Chrome Instant
• Extensions/Apps work
• Autofill related fixes

Known Issues

• Page becomes unresponsive when trying to play video - Issue 65772
• Certain HTML5 sites fail to load due to a compositor issue - Issue 64722

I like the GPU updates and the video updates, but I can pass on the "instant"... icky addition in my book, but their app, their choice.

I checked this afternoon and it looks like iTerm2 Alpha 14 is out with another boatload of interesting features. It's something that I think the Apple folks should be looking at, but I doubt if they are. The terminal is just not a "big deal" to Apple, in general. It's for the developers, and it works. But this project is showing them that it could be so much more.

I suppose if enough people point this out they might look more closely at it. We can only hope.

I've found a singular problem with ZeroMQ, and noted in the IRC chat conversations that this should be fixed in the soon-to-be-released 2.1. It's a simple memory leak with the sending of messages. My code is pretty simple: I get the payload for the message, I get the ZMQ socket it needs to be sent on, and then I simply make a ZMQ message and send it. That's about as simple as you can get:

  if (aTopic.first() != NULL) {
    try {
      // lock up this socket while we send the data out...
      boost::detail::spinlock::scoped_lock  lock(aTopic.second());
      // make a ZMQ message of the right size
      zmq::message_t  msg(aPayload.size());
      // ...copy in the data we need from the payload
      memcpy(msg.data(), aPayload.data(), aPayload.size());
      // ...and WHOOSH! out it goes
      aTopic.first()->send(msg);
    } catch (std::exception & e) {
      error = true;
      cLog.error("[sendToZMQ] trying to send the data got an "
                 "exception: %s", e.what());
    }
  }

If I comment out line 10 - the send(), the memory doesn't grow any faster than I might expect based on the cached messages. But leave it in and the memory grows and grows. More interestingly, it's different for the different kinds of payloads I send. Very odd.

Anyway... the ZeroMQ guys said they planned on having a release last week, but it seems things happened, and that's OK with me - this is important. I need to keep the memory under control.

I read a lot about this over the weekend, and the more I read the more it made me smile.

The foundation upon which this project is base comes from the GNUstep community, whose origin dates back to the OpenStep standard developed by NeXT Computer Inc (now Apple Computer Inc.). While Apple has continued to update their specification in the form of Cocoa and Mac OS X, the GNUstep branch of the tree has diverged considerably.

Yeah... they've diverged only in that Apple's Cocoa has moved forward and GNUstep is still using the OPENSTEP guide as it's reference point. And there's nothing wrong with that. OPENSTEP is fantastic... it's just that Apple has decided to keep moving and GNUstep hasn't. Sony isn't content on sitting still either:

We depart somewhat from the GNUstep adherence in that our goal is to thoroughly modernize the framework and optimize it to target modern consumer electronic (CE) devices. These modern conveniences include such features as touch displays and 3D graphics.

I use WindowMaker as my X11 desktop of choice. It's all about GNUstep. I think it's fantastic that Sony is picking this up. It means that GNUstep is going to be getting a much needed shot in the arm with all the added interest. Really great news.

NeXT was right. Took a long time, but they were right. Fantastic.

This morning I noticed that Google Chrome dev 9.0.587.0 was out, and the release notes point to quite a few nice fixes:

• GPU Related Fixes
• Crash Fixes
• Instant Fixes
• [r65953] Move click-to-play to about:flags. (Issue: 62091)

Not a lot of detail about what each of these mean, but I'm encouraged by the GPU fixes as it's possible we're getting closer to that elusive super-browser where things are really exceptionally fast. Here's hoping...

I noticed this morning that iTerm2 Alpha13 is out with a ton of really neat features. The searching, the playback - Holy Cow! These guys are taking the terminal to places I never even thought about. What an amazing piece of work. And it's slick. Very slick.

Excellent work.