My work on ruby-bombe seems to be proceeding nicely; for now it’s a very nice Ruby library that … seeks. The only thing I’ve implemented up to now, and not yet entirely, is seeking. Why this? Because it’s probably the trickiest part, since on some backends has to be emulated, on others it has to be adapted. Reading is going to be probably easier to implement.
Together with writing support for seeking, I also added tests, a huge amount of tests to make sure that my code works as I want; I have to thank Jason again, since RSpec makes it much easier to understand if the tests are being enabled, and makes it also easier to split the tests to reuse the same logic, which Test::Unit makes much more difficult.
But this is not what I’m here to talk about, I’m rather trying to flesh out, to myself and to those interested in ruby-bombe, some notes about consistency. In particular, I found that using ruby-mmap to access file is totally inconsistent with accessing them through the File class. In particular, the ruby-mmap extension always raises ArgumentError exceptions when the path used points to a file that does not exist, or when the file is unreadable. I’ll have to add quite a few more tests, for instance to make sure that when giving the path to a directory rather than a file.
As of this moment, ruby-bombe has its own exceptions to handle FileNotFound and PermissionError cases, rather than using the Errno module exceptions, since I’m not really sure if they would apply properly to network cases like HTTP and similar. For the rest, I’m trying to use all the possible Ruby exception, when they make sense (ESPIPE sincerely is not very userfriendly in my opinion).
Unfortunately, of course, I don’t know all Ruby’s facets myself, so here is why I’m blogging: I’d be very happy if somebody could help me to ensure tha tthe behaviour, the naming, and the tricks used in my library are consistent with the rest of the language. I think I was able to get a similar enough interface, even when the backend libraries are pretty inconsistent with the rest of Ruby (like ruby-mmap).
As of now, I have backends for IO streams (like pipes), in particular files (with path-based access), and sockets (both TCP and UDP), gzip-compressed files (with emulated seek), memory mapped files and string/arrays. Planned there is at least the bzip2 compressed files with no seeking, bzip2 files with seeking (using lots of memory) and http-downloadable files. The two backends I’m particularly interested in completing, for ruby-elf, are the Gzip and mmap backends. The reasons are very practical, the first is needed to reduce the space taken up by the testsuite of ruby-elf, since the files don’t have to be executed they might as well be compressed, the second is interesting if I get to implement scanelf.rb or something like that, since mapping the ELF executables and libraries into memory is most likely going to find some data already loaded in the system memory, mapped for files that are loaded for execution. This might actually improve its performances, but before judging that I’ll have to write the code.
On a different note, if you’re interested in Ruby packages, I’ve added two more ebuilds in portage: dev-ruby/uuidtools and dev-ruby/flickr, both are extensions used by Typo; while the upstream version gets them from Subversion, I’ve decided that to try reducing the amount of code I cannot easily control I’m going to pick them up from Portage, like I did for the original 4.0 version on Gentoo/FreeBSD. So enjoy them, if you need them.
Are you still actively developing this project? It sounds interesting.