Archive for the ‘Open Source Software’ Category

Google Chrome dev 18.0.1025.7 is Out

Wednesday, February 8th, 2012

Google Chrome

This morning I saw that Google Chrome dev 18.0.125.7 was out, and the release notes say there are a few bug fixes with regards to the settings pane. Good enough. I like reading in the comments the praise for the speed of fixing these issues. It shows me that the folks finding the issues are really happy with the team fixing them in a reasonable time frame. Says a lot, because if I had a problem, I'd like to know it was being addressed. Just nice to see.

[2/11] UPDATE: Interestingly, this morning I saw that the beat channel was updated to 18.0.1025.25 - a jump over the dev channel. This makes no sense as the dev channel is supposed to the be more often updated and less stable of the channels. So something much be going on… like maybe the dev channel is going to 19.x.x.x, or something. In any case, it's an odd move that certainly means something… I'm just not sure what it is.

Updated Git to 1.7.8.4 on My MacBook Pro

Monday, February 6th, 2012

gitLogo.gif

This morning I thought that git on my MacBook Pro might be a little behind the times. I don't honestly think there's a huge difference from 1.7.4.1 to 1.7.8.4, but you never know, and it's simple using the Mac OS X installer. Just download it, double-click, and it's ready to go.

It's nice to see:

  $ git --version
  git version 1.7.8.4

Nice. Love it when things "just work".

Interesting… I just noticed that Mac OS X 10.7.3 comes with git - and it makes perfect sense that it does. Xcode uses git now, and so it'd require that the OS - at least the developer tools, would have to have it. So it's not necessary for me to worry about updating this any more. It's nice to have a secondary source, should Apple decide to drop it's support, but I'm guessing that's not going to happen anytime soon.

Interesting stuff…

Google Chrome dev 18.0.1025.3 is Out

Friday, February 3rd, 2012

Well… it's only been a few days since 18.0.1025.1 was released, but I guess the Google Chrome team realized that there were a few outstanding issues that warranted a new release and a few ticks in the version number. Nice that they all appear to be fixes for crashing bugs… way to keep on the crashers, guys.

Bloomberg Gets a Pretty New Face

Thursday, February 2nd, 2012

GeneralDev.jpg

Yesterday, I heard about Bloomberg's new Open API initiative. It's a new .Net, C++, Java, and C API that is "Open" for all to use and make use of. The catch is that all the data you'd want to get is really still exceptionally expensive, but that's Bloomberg, eh? The last time I used a Bloomberg API it was the Bloomberg Server API, which was a mild modification on the old Bloomberg Terminal API that came with every Bloomberg Terminal - Windows and Solaris, going far, far back into the past.

I've just briefly scanned these docs, and it's a new API alright. Much easier to deal with, and hopefully far easier to decode the data once it's returned from Bloomberg. I like that they are trying to really make it easier to use - both in the pub/sub and the req/resp modes. It's an improvement.

Heck, almost anything is an improvement.

Still, the kicker is the cost of the data. When last I looked, it was still some of the most expensive data around. I mean outta sight prices. I don't think it's gone down in the last two years, but I could be wrong.

Yet I can't blame them. They have a nice gig - they have a great reputation on the street for their data, and so they can charge a ton and use that to keep away the riffraff. It's working for them, and who am I to give them grief. Sure… I'd love to build a system off this for the Mac and build in all the bells and whistles, but that's a really hard sell as the data is so expensive and all the online brokerages are giving their data away - with decent tools.

Still… if I hit the lotto, I'm all over this.

Google Chrome dev 18.0.1205.1 is Out

Wednesday, February 1st, 2012

Google Chrome

This morning I noticed that Google Chrome dev 18.0.1025.1 was out and it looks like a few nice things for me in the release notes. SPecifically, the latest V8 javascript engine (3.8.9.0), and then a few nice Mac-specific things like fixed Lion gestures, fixed momentum scrolling in frames, and an issue about the devtools closing prematurely. All nice things to have. I'm really glad that aren't focusing on Windows and leaving Mac OS X a version or two behind. That would be sad.

Google Chrome dev 18.0.1017.2 is Out

Wednesday, January 25th, 2012

This morning, the Google Chrome team released 18.0.1017.2 and the release notes indicate it's got several nice things like the latest V8 javascript engine (3.8.7.1) as well as several nice-to-haves like popup window fixes and flashing window fixes on the Mac. Nice to see the improvement in the V8 engine, as that's where so much of the work is going these days - heavy javascript on the client for thin client deployments.

Hope they keep up the good work.

Adium 1.5rc1 is Out

Wednesday, January 18th, 2012

Adium.jpg

Without question, the best multi-protocol IM client for Mac OS X has got to be Adium, and today they tweeted that a few days ago, they released a release candidate for 1.5. This is just one of those amazing programs for the Mac that Just Works and while it's not on the kind of release schedule that, say, Google Chrome is, it's stable, works well, and I've never had a problem with it. Just amazing.

I've been running the different 1.5 betas for a while, but it'll be nice to see official 1.5 support as it means that it's mainline. Nice to see.

Google Chrome dev 18.0.1010.0 is Out

Wednesday, January 18th, 2012

This morning I saw that Google Chrome dev 18.0.1010.0 was out, and the release notes have a few nice things like PDF rotation and a few Mac-specific fixes as well. Good to see these user-experience additions and fixes, but I'm still waiting to see if Google tries to put in something that again opens up the wild development in browser technology again. Can't imagine what it'd be, but that's part of the fun!

Google Chrome dev 18.0.1003.1 is Out

Wednesday, January 11th, 2012

Google Chrome

Yes, today we jump the century mark! The Google Chrome dev release 18.0.1003.1 marks the first release of the 18.x.x.x branch, and answers the question I've had for a while when it came to the third number - would they go past 1000? And the answer is Certainly! They are engineers!

So we have several things in this release - a new version of the V8 javascript engine (3.8.4.1) as well as several under-the-cover items, better zooming, and several crashing bugs. All in, I'd say it's nice to see that they are still working on major issues. Good to know.

Reading a GZip File in C++ – Boost Wins

Tuesday, January 10th, 2012

Boost C++ Libraries

Today I needed to be able to read compressed files for a service I was writing. Sure, I could have shelled out and run gunzip on the file and then gzip-ed it up after reading it, but I wanted something that would allow me to read the gzipped file in-place and uncompress it into a simple std::string for processing.

Enter boost to the rescue.

This is one of the more difficult things to get right in boost… OK, I take that back, it's pretty easy by comparison to the serialization and ASIO, but it's not something that is simple to see from their docs. Also, some of the more obvious attempts to use the boost filtering iostreams yielded some pretty bad results. Still… as I kept with it, success emerged.

Here's what finally worked for me:

  #include <zlib.h>
  #include <boost/iostreams/filtering_stream.hpp>
  #include <boost/iostreams/filter/gzip.hpp>
  #include <boost/iostreams/copy.hpp>
 
 
  std::string     contents;
  std::ifstream   file(aFilename.c_str(),
                       std::ios_base::in | std::ios_base::binary);
  if (!file.is_open()) {
    error = true;
    cLog.error("can't open the file %s", aFilename.c_str());
  } else {
    using namespace boost::iostreams;
    // make the filter for the gzip with the right args…
    filtering_streambuf<input> gin;
    zlib_params   p;
    p.window_bits = 16 + MAX_WBITS;
    gin.push(zlib_decompressor?);
    gin.push(file);
    // now let's get a string stream for a destination
    std::stringstream  ss;
    // copy the source to the dest and trap errors
    try {
      copy(gin, ss);
      contents = ss.str();
      cLog.info("read in %u bytes from %s", contents.size(), aFilename.c_str());
    } catch (zlib_error & err) {
      error = true;
      cLog.error("decompression error on %s: %s (%d)",
                 aFilename.c_str(), err.what(), err.error());
    }
  }

What's the point of all this? Well, it turns out that boost isn't about the general decompression file streams, it's about pipelined filters and one of the filters is a gzip compressor and decompressor. It's more flexible, yes, but it's a little harder to do, and it ends up with an intermediate std::stringstream that we don't need. But in the end, this is only about 100msec slower than reading the file uncompressed. That's a reasonable performance hit for the fact that I didn't have to do the messing with the zlib libraries.

Yeah boost!