This morning I saw that Google Chrome dev 12.0.742.5 is out and the release notes say that this fixes a regression bug with sync and a few other bugs. OK, seems they rushed the last release, and this guy makes up for it. Sounds like a plan.
This morning I saw that Google Chrome dev 12.0.742.0 was out with "stability and performance fixes". Sounds like polish to me - nothing wrong with that. Keep making it better, and while you're at it - throw back in the H.264 will ya?
This morning I saw that Google Chrome dev 12.0.733.0 was out and the release notes say only that the release focused on stability and UI tweaks. I noticed they fixed the centering of the page title in the tab which used to be left-justified, then it switched to centered, now it's back to left-justified. I'm sure there are other things like this, and that's OK, it's a pretty stable browser.
This morning I had an interesting little problem - WordPress 3.1.1 was released with a few nice little fixes, so I went to HostMonster to update my installs. The problem was that since that odd little 3.1 double upgrade, I was unable to upgrade to 3.1.1 because SimpleScripts was saying that the version number was wrong. Not cool.
I'd been upgrading every time SimpleScripts instructed me, but the second upgrade to 3.1 didn't seem necessary, but I did it anyway - and everything worked. But it wasn't without consequences, it seems. So I had to cancel that update - which wasn't obvious, but I figured out, and then I had to upgrade to 3.1.1 within the WordPress site, and then try to upgrade in SimpleScripts.
This second (unnecessary) upgrade finally detected that I had the version that I was updating to, and it just updated the version number in SimpleScripts. This was a big "Whew!" on my part, and it's nice to know what my options are in dealing with these updates. So it's all up to 3.1.1 and things are smooth once again.
I've been working on the conversion of my Broker code to the new replica set-compatible erlmongo driver. It's not horrible, but the worst part is what the worst part always was - getting the data in and out figured out so I can write the correct matches in the code.
They store the arrays differently, and they don't like the long binary-data strings that I've been using, but after I figured out all the gotchas, it's working again. It's just not easy.
Plus... this is more than half a day shot on something that I didn't need to have done had they not switched the database clustering... and I'm on a week-and-a-half deadline. Not ideal at all.
But it's done.
This morning I saw that Google Chrome dev 12.0.725.0 was out and the release notes say it all:
All
- Updated V8 - 3.2.6.0
- Spring cleaning in the code, lots of code cleanup and refactoring under the covers
It's nice to see the clean-out of old code. I'm sure there's a lot that's sitting there - like maybe the H.264 decoder... OK, enough of that. In any case, at least they got the icon back. Baby steps.
This afternoon, Angelina wanted to be able to print from her iPad to the printers in the house. Since AirPrint was not enabled in Mac OS X 10.6.6+, I knew I had a few options open to me: hacking the system to enable it (it was enabled in a pre-release version of OS X), or buying one of the sub-$10 apps that allowed you to share all your printers on a Mac OS X desktop with AirPrint clients. I'm not a fan of the hacking, so I decided to give the apps a try.
When I was going through all the apps for this, I noticed AirPrint Activator. This guy used to be a hack, but now the author says this about the app:
Apple requested that I take down the AirPrintHacktivator page as they stipulate that the application is distributing copyrighted source code and/or software. AirPrint Activator is now replacing the defunct AirPrint Hacktivator application. It provide the same functionality without the use of any Apple files.
You can use AirPrint Activator as a replacement of the previous generation Hacktivator application. If present, it will take care of cleaning any Apple files installed by the previous generation Hacktivator when you “deactivate” AirPrint. It will only inject a single line in a CUPS configuration when you select to “activate” AirPrint.
I really liked that it only injects a single line int he CUPS config file. That's the kind of change I can deal with. Sure, it's liable to be broken in the next release of OS X - or even on an update to CUPS in a subsequent security update. But for now, it's possible, and if I need to learn what this change is, I can, and then I'll be able to update it myself in the future.
The next wrinkle turned out to be that my Mac Mini was sharing a printer that wasn't being shared via LPD any more. Seems Snow Leopard turned off the LDP sharing by default. Well, I found this hint and simply enabled LPD sharing again:
cupsctl 'BrowseLocalProtocols="cups dnssd lpd"'
As soon as I did that, my old LPD-based sharing machines found the printer again, and all was well. With these two things, I have AirPrint working perfectly in the house now. I even printed out a few pictures from my iPhone for Marie who needed them for school.
Very nice.
This morning I saw the expected update of Google Chrome dev to 12.0.712.0, marking the move to 12.x. I say this was expected because they just announced that the 10.x series was in beta (or release), and that meant that they needed to "up the voltage" a bit on the 'dev' channel. The third number is all that seems to matter, and there are still a few nice things to find in this update.
What seems to be missing is any new features that they might want to add after Firefox 4 went final a week ago. I've played with Firefox 4, and it's OK, but the rendering is the biggest issue, and while that's not quite right, I'll stick with Chrome. But Firefox is smooth, and the "Spaces"-like support is very cool and keeps the tab count to a minimum. Very nice indeed.
Note: the old icon is back, too. Seems "plastic" now.
One of my very favorite database libraries is SQLAPI++ because it's very well designed, works with a huge number of databases, is thread-safe, and doesn't require you to link in the underlying database libraries when you build your code. It's nice. So when it came time to hit a database from linux here at The Shop, I naturally turned to an old friend. But there were some ugly truths lurking there for me, and I had to spend quite a bit of time getting things sorted out.
First, off, SQLAPI++ on linux doesn't talk to MS SQL Server through any libraries like FreeTDS. Nope, you have to go through iODBC. Ick. Thankfully, FreeTDS has the ability to work with iODBC, but getting things set up and tested was a pain, so here's what I had to do.
Get everything installed:
then start to configure things.
Get FreeTDS going by editing /etc/freetds/freetds.conf to look something like this:
[devSQL]
host = dbhost
port = 1433
tds version = 7.0
Now you can put in the default .sqshrc and prove that you can talk to the database with sqsh:
$ sqsh -S devSQL -U me -P secret 1>
Success. That's a good first step. Now let's configure ODBC. Edit /etc/odbc.ini to look something like:
[ODBC Data Sources] devSQL = Devel SQL Database [devSQL] Description = Development database Driver = /usr/lib/odbc/libtdsodbc.so Trace = No Server = dbhost.yoyo.net Database = master Port = 1433 TDS_Version = 8.0
and then edit /etc/odbcinit.ini to look something like this:
[FreeTDS] Description = TDS driver (Sybase/MS SQL) Driver = /usr/lib/odbc/libtdsodbc.so Setup = /usr/lib/odbc/libtdsS.so CPTimeout = CPReuse =
At this point, we can run the iODBC admin utility to see that it was set up properly:
$ iodbcadm-gtk &
and the driver should be right there. Use this to "Test" the connection, and you should see that it's there and working.
Finally, use the SQLAPI++ test client to see that everything is working there as well:
$ test64 1. Oracle 2. SQL Server 3. DB2 4. Informix 5. Sybase 6. InterBase 7. SQLBase 8. MySQL 9. PostrgeSQL 0. ODBC 0 Client version: unknown before connection Database name (connection string): devSQL User name: me Password: secret Server: Microsoft SQL Server Release 10.00.2714 Server version: 10.0 Client version: 0.82 $
I was talking to a developer today and we got to talking about the fact that the STL map spec says that it's iterator is not invalidated on insert or removal - except in cases where the iterator is on the removed object. So it got me to thinking - what happens when you invalidate an iterator?
So I wrote this code:
#include "map" #include "string" #include "exception" #include "iostream" using namespace std; int main(void) { map<string, string> map_test; map<string, string>::iterator iter_map_test; map_test["AAAAA"] = "11111"; map_test["BBBBB"] = "22222"; map_test["CCCCC"] = "33333"; iter_map_test = map_test.find("BBBBB"); map_test.erase("BBBBB"); try { string value = (*iter_map_test).second; cout << "got : " << value << endl; ++iter_map_test; cout << "next: " << (*iter_map_test).second << endl; } catch ( exception & e ) { cout << e.what() << endl; } catch ( ... ) { cout << "generic exception." << endl; } return(0); }
and the results are amazing (to me):
$ g++ maptest.cpp -o maptest $ maptest got : next: 11111 $
So the iterator is resetting itself when invalidated. That's very interesting! Now it's not what I expected, and I'm not certain I want to risk it, but it's nice to see that there is something non-fatal about the process. That part, it seems, the spec is right on the money about.
Clever dudes.