It didn't take long - just a few days, and now Google Chrome dev 23.0.1255.0 is out with a nice array of fixes for crashing bugs - including a video problem on retina MacBook Pros. There are a few things about the security of apps in the browser, which I don't use, but I'm sure there are quite a few Angry Birds fans out there.
This morning I noticed that Google Chrome dev 23.0.1251.2 was out with a few nice fixes for crashing bugs. I haven't noticed them, but I'm not hammering on it with Javascript like a lot of the other folks are. Still, it's nice to see the decent release notes, and the improvement in Chrome continue.
I'm sitting here this morning smiling quietly to myself after working a while on some problems. I realize I'm smiling because the keyboard is just such a wonderful piece of work - the Apple (small) wireless keyboard and wireless mouse, to be precise. These are simply the best input devices that I've ever used. The keyboard is low to the desktop, responsive, small, and without a cord. The trackpad is large, the gestures wonderfully thought-out. It's amazing what I can do so effortlessly on this machine.
Then there's the machine. I'll admit I'm not a fan of the glossy Apple displays. I never have been. The HP 30" is really the best I've used in a long while. I think Apple could make a nice 30" display, but they don't want to, and there's no making them do something they don't want to do.
But back to the laptops… they are, without a doubt, the best in the industry - and have been for a long while. Really, the only solid competition was the IBM ThinkPad, and IBM sold that to Levono, and the quality has become so very ordinary now. Nothing to write home about.
But great hardware gets out of your way. You stop thinking about how to do something, and focus on the doing. In some cases, it even enables you to see things that you might have not seen - large displays with more code in them really are very beneficial.
So I have to tip my hat to the folks at The Shop that see this as well, and outfit the developers this way. It's really quite amazing.
Now this is probably not amazing news to long-time Ruby developers, but the simplicity and ease with which it's possible to make thread-local variables in Ruby is simply shocking. The ruby developers just don't know how good they have it. This morning I was looking at a threading problem with the CouchRest CouchDB client, and realized that it's not thread-safe. This isn't really shocking as thread-safety is something I've come to realize is not standard in Ruby libraries.
Still… I was determined to make it work.
What seemed logical was to have multiple database connections - one per thread, and then just have thread-local database connections. As the threads are born, they need a connection, create it, and use it. When they die, the connections are cleaned up automatically. Sweet. Simple.
But I know that dealing with thread-local storage in pthreads is not horrible, but it's certainly not "easy". I dig into the Ruby support for thread-local storage, and it's trivial:
Thread.current[:foo] = {}
This creates the tagged thread-local variable foo. How simple! This is something that I never expected to see. Never! So why are these Ruby guys having so much trouble with thread-safety? I have no idea.
With the tools I've seen in Ruby, there's really no excuse for why there aren't more thread-safe libraries. All the tools are there - they're just unused. Lazy coders.
This morning I read that the latest Gimp on OS X had a native GUI build - very exciting! They didn't abandon the X11 GUI, they simply made a version that looks the same, but has the native Cocoa GUI so that you don't have to be running X11 in order to use it.
This is really neat! I'm not a huge Gimp user any more, as I've found some really great replacements, but it's got a lot of power, and some of the provided scripts are simply amazing. So to see them port the GUI to Cocoa is a really nice feat. I'm very impressed with these guys.
Well done!
My manager at The Shop forwarded something he read today about an interesting little package called drip. It's essentially something that will pre-launch a JVM instance for a set of command options so that repeated calls of the same command will not have the overhead of starting a JVM. This would be ideal for JRuby - if it was supported. Unfortunately, this is a bash script and you need to be able to hook it into the code you're using - or at least replace the java command with drip.
Sadly, JRuby hides the java command, so we can't easily replace it. The JRuby team will have to make it possible with some kind of environment variable, etc. Given that Java on most platforms I've used starts pretty nicely, I'm guessing they are not going to spend a lot of time with this. It's really a bad problem on Mac OS X, but maybe that will be changing in the future. Who knows?
But it's certainly something to hang onto and maybe it'll be useful in the future.
This morning I noticed that Google Chrome dev 23.0.1246.0 was out, and the release notes are back to being a little more descriptive. This guy a new V8 javascript engine as well as a new cut of WebKit and addresses a few other bugs. Nice to see the notes are back to what they used to be, and that we're still seeing progress. Nice.
I've been building a little visualization based on ZingChart, and using jQuery as the general-purpose support library which I've come to realize is simply amazing, and deserving of the acceptance it's received. The code to do a simple AJAX request is amazingly simple:
$.getJSON(url, function(data) { parse_series(data); redraw(); });
where the code in the block is an anonymous function that runs on the return data which will be called data in the block. Very slick. I remember what I had to do to get this working in Chrome a few years ago… it was not pretty.
But there's so much more as well. I think I'm a convert. If I end up doing more javascript pages, I'm going to use jQuery and even if I end up using Google Visualizations, I'll use jQuery to get the data and do some of the nastier stuff.
I'm trying to implement user-defined functions in LKit. and I'm having a really hard time with it. I'm not at all sure how to handle things with this addition - especially since I want to have recursion and pass-by-value work as you'd expect in a lisp-based language. The parsing of the code isn't the problem - that I've got figured out. But when I compile the code into an evaluation-tree, it's going to point to variables - some of which are defined outside the user-defined function, and some of them are the arguments to the function.
If they are the arguments, then we can't really have a static evaluation-tree… I'd have to have some kind of dynamic evaluation of the arguments for each invocation. It's getting to be a lot harder than I'd expected.
Now it's true that this was something that I didn't even attempt in my previous version of the code, but I was really hoping for something more this time. I'd even thought that I could bang out this function definition code today. Not so fast, it seems.
I need to handle the question of a calling stack. Really. I need to be able to "dive into" the evaluation of a function and then return to where I was. This is really a different layer than what I'm doing now, and it's going to take some significant time to think about it.
Well… maybe my next vacation.
I was looking for something to do as a good excuse not to solve this problem in LKit today, so I dug into the latest news on GeSHi and the version I'm running on currently is 1.0.8.6, but 1.0.8.11 is out, and the language count is now above 200. Nice. Not that I usually write in more than 200 languages, but the odds that APEX code, for instance is supported goes up as the number increases.
Anyway, the first thing was to download the GeSHi package and place it into my repo for CodeHighlighterPlus. It's basically the root of the repo, but I hadn't realized that in the last time I updated GeSHi.
The only thing I needed to watch out for were those few edits that I made to geshi.php the last time, and those were pretty easily isolated. I'd repeat them here, but the fact is with the repo on GitHub, you can just go there and get everything you need. Simple.
The new language support is:
4cs dot lscript pycon 6502acme e lsl2 pys60 6502kickass ecmascript lua python 6502tasm eiffel m68k q 68000devpac email magiksf qbasic abap epc make rails actionscript erlang mapbasic rebol actionscript3 euphoria matlab reg ada f1 mirc rexx algol68 falcon mmix robots apache fo modula2 rpmspec applescript fortran modula3 rsplus apt_sources freebasic mpasm ruby arm freeswitch mxml sas asm fsharp mysql scala asp gambas nagios scheme asymptote gdb netrexx scilab autoconf genero newlisp sdlbasic autohotkey genie nsis smalltalk autoit gettext oberon2 smarty avisynth glsl objc spark awk gml objeck sparql bascomavr gnuplot ocaml-brief sql bash go ocaml stonescript basic4gl groovy octave systemverilog bf gwbasic oobas tcl bibtex haskell oorexx teraterm blitzbasic haxe oracle11 text bnf hicest oracle8 thinbasic boo hq9plus oxygene tsql c html4strict oz typoscript c_loadrunner html5 parasail unicon c_mac icon parigp upc caddcl idl pascal urbi cadlisp ini pcre uscript cfdg inno per vala cfm intercal perl vb chaiscript io perl6 vbnet cil j pf vedit clojure java php-brief verilog cmake java5 php vhdl cobol javascript pic16 vim coffeescript jquery pike visualfoxpro cpp-qt kixtart pixelbender visualprolog cpp klonec pli whitespace csharp klonecpp plsql whois css latex postgresql winbatch cuesheet lb povray xbasic d ldif powerbuilder xml dcl lisp powershell xorg_conf dcpu16 llvm proftpd xpp dcs locobasic progress yaml delphi logtalk prolog z80 diff lolcode properties zxbasic div lotusformulas providex dos lotusscript purebasic
Then it's time to check it all into GitHub and then pull it down on the servers and see how it goes.
After the pulls were done, all was well, and things are looking very nice. Success!