One thing that always bothered me of Ruby-Elf and its tools (cowstats, the linking collision script and the rest) is that they don’t really make good use of the 8-way system I have as main workstation, which is not really good considering that it also means that the cowstats run after each emerge in my main system blocks on a single core, and I don’t even want to try it on tinderbox as a whole. It also means I cannot replace scanelf with a similar script in Ruby (neither are parallelised but the C-based scanelf is obviously faster).
To address this problem, I considered moving to JRuby as interpreter; it’s already using native threading with the 1.8 syntax, and it would have been decently good to get cowstats multithreaded, the problem is that the startup time is considerable, which wasn’t very good to begin with. So I decided to bite the bullet and try Ruby 1.9 to see how it performed.
Beside some slight syntax change, I started already having problems with Ruby 1.9 and Ruby-Elf. The testsuite is still written using Test::Unit, because RSpec didn’t suit my needs well at all, and for that reason I prepared an ebuild (masked for now; remember I hate overlays unless very necessary, I’ll go deeper inside on that issue in the next weeks hopefully) for the improved test-unit extension (not using gem, as usual). It should work with Ruby 1.8 too, although I found some test failures on the test framework itself with both 1.9 and 1.8.
The following problem has been with the readbytes.rb interface I am using, which is gone in 1.9, stating that the interface is implemented already in the IO class. Unfortunately the only interface that gets near is IO#readpartial but it’s not actually the same thing and has a quite different meaning in my opinion, but again, let’s not get anal about that, it could be fixed quite easily.
What became a big problem are the changes in the String class, which is now encoding-aware, and it expects each elements in it to be a character. While this is tremendously good since String would then work more like a String than a character array (like is done in the underlying C language), it lacked a parallel ByteArray object for handling sequences of bytes, and a binary file interface into IO. This is a very huge deal because the whole of Ruby-Elf is doing little more than binary file parsing.
Now to be honest I didn’t spend too much time running through the changelogs of Ruby 1.9 to identify all the changes, but since the changes seem to be quite huge by themselves, and I could even get simpler binary file handling in PHP than what I’ve seen in the two hours I spent trying to force Ruby 1.9 under submission, I’m afraid to say that Ruby-Elf is going to stagnate and I’ll end up looking at a different language to implement the whole thing.
Luca suggested (as usual) for me to look at Python, but I don’t really like Python that much myself, while the forced indentation may help to make the code more readable, take a look at Brian’s (ferringb) code and you will never say that Perl is the only SSL-based language (sorry Brian, but you know that I find your code quite encrypted). I’m sincerely considering the idea of moving to C#, given that the whole Mono runtime is adding less startup overhead than Java/JRuby would.
Or I could go for the alternative route and just try to write it in Objective C.
