So in case you haven't read about it, I've been starting to code in Ruby. It's a fine language in its own right, and I'm having a good deal of fun using it. For ages I've been a serious Perl junkie. I've used it extensively at my last two jobs, and I totally dig it, because I love punctuation. It was sometime during last year that Caius and npj7y bugged me to learn it, so now I am. I read the fabulous (but badly indexed) Pragmatic Guide to Programming Ruby, written by the same jokers who wrote The Pragmatic Programmer (an excellent book to read if you aspire to programming).

Some parts of the language seemed fairly straightforward. Loops can be done as usual, conditionals (if-else) are normal, functions actually take a parameter list (as opposed to Perl, where they're both passed and returned through a variable called @_). I was pleased at first to see that Ruby is fully object oriented. Fully? As opposed to what? As opposed to Perl's hacked-in excuse for object oriented programming in a blatantly scripted language. Ruby's object orientation is not bad. It has a lot of features, but it also has what I think are its biggest flaws.

Ruby's concept of objects is related mostly to message-passing. When you want to invoke a member function of an object, say, make a bike shift gears, you send a message to the bike, saying, "switch to gear 5." In code-speak, myGaryFisher.changeGear(5). In strongly typed Object Oriented languages such as Java, C#, and C++, at compile-time, the compiler checks your source code to make sure that the object named myGaryFisher really does have a method called changeGear(). It won't let you run your program unless that's true.

More specifically, those languages attach a type to every object reference encountered in the program. So if you ever encounter the myGaryFisher object, it will actually be declared as Bicycle myGaryFisher a bit earlier (if anyone is thinking about polymorphism at this point, hang on; I'm getting there). This means that the compiler rigorously enforces not invoking methods on objects that it knows they do not have. If you try to call myGaryFisher.jointAround(), the compiler will check the type of myGaryFisher, see that it is of type Bicycle, then check the Bicycle class for a method called jointAround(). Of course since that method is not present in that class, the compiler will not produce machine code that tries to do that method invocation.

In Ruby, references are never declared with a type, so there is no type information checked at "compile time." Since Ruby is interpreted, this "compile time" would take place when the interpreter runs through the file and does a syntax check. Without the information that myGaryFisher is a Bicycle, all Ruby does is attempt to send the jointAround() message to the object and throw up its hands in disgust when it doesn't work. Though I believe that this kind of checking, done at compile time, can help eliminate buggy code, there's a more sinister issue behind it. After all, doing a typecast in Java always has the threat of a ClassCastException, which is the same kind of trouble.

The real trouble of this loose typing comes from the polymorphism features of the language. Here's a quick review for those of you who can't remember all those fancy OO words. myGaryFisher is a Bicycle, but if properly defined is also a Vehicle. In view of this, there are two ways in OO programming to consider the bicycle: as a bicycle, a two-wheeled thing with handlebars, a frame, foot pedals, derailleurs, a chain, gears, and everything that makes a bicycle what it is--all in all, a very specific view of the bike; or, as a vehicle, which has as its only real defining factors that it carries a certain number of passengers and that it is moving at some velocity.

In most (all?) OO languages, this is implemented via some kind of inheritance mechanism. In a strongly typed language, every time you see a reference to an object, the type determines what view of the object you have access to. If you get Bicycle myGaryFisher, because the compiler knows you have a Bicycle, you get access to a whole ton of descriptive functionality pertaining to a bicycle. If, instead, you get Vehicle myGenericPersonnelTransport, you instead have access only to a function that tells you how many people the thing can carry, and how fast it's going.

This is an information hiding tool; it allows you to give certain parts of the code access only to specific information that it is allowed to "know about." In a strongly typed language, the compiler checks this and generates code that conforms to these type restrictions. In Ruby, it does not. The only thing enforcing these type rules is you, and that, in my opinion, is just asking for trouble. When you call a function in some library, the only way you know what kind of object exactly the function is expecting is by reading the function's documentation... and we all know how keen programmers in general are about writing complete, up-to-date documentation (or can infer from the tone of this sentence).

I like the inheritance mechanism. It works well, and "mixins" are a good analog to interfaces (abstract base classes) found in Java, C#, and C++. Though I still have the benefit of code reuse through inheritance in Ruby, I lose the benefit of polymorphism. As far as I'm concerned, each of those makes up 50% of the value of inheritance. So I continue to make mixins and superclasses and things, but every once in a while I have to take a deep breath and do some type checking: this function is expecting an instance of this mixin; I must be very careful not to call any methods of the object, only methods of the mixin. I have to be cautious, because it's easy to forget, and the code will still work for the time being.

Moving on to other topics gripe-worthy, the standard library bothers me, because it appears to be hacked together quite randomly. It doesn't help that half the classes in there are lacking documentation. It doesn't help that some classes very much step on each others' toes.

For example, there is a Mutex class and also a Monitor class. The difference? The former does not allow a single thread to lock the mutex multiple times (why not?), but the latter does. The former is part of the Core API, and the latter is part of the standard libraries. I think they should be swapped.

I don't like that there isn't a Collection mixin or superclass or something, so that I can have a uniform way of adding and deleting elements from a Set, Array, and Hash.

I've always had a problem with operator overloading, and Ruby takes this to a whole new level. The | (pipe) operator for a number does a bitwise OR operation, but the same operator for an Array does a set union. Yes, these things are somewhat related, but doing this just seems like obfuscation, not convenience. Your goal should be to make code that's wrong look obviously wrong (this is one of the most brilliant programming articles I've read).

Similarly, Ruby's (and C#'s, for that matter) thing for "properties", that is, statements that look like you're setting a member variable of an object to a value, but actually are calling a function with the right-hand-side as a parameter, bother me. I don't like deception like that. I want to know when I'm doing a simple assignment operation and when I'm calling a function. This is all about performance, isn't it? With the advent of harder, faster, stronger computers, this won't matter! Right? Wrong: what if the function that is secretly called has side effects in the object? Assignment is a relatively simple operation, and I want to know when something that I think is assignment actually is some O(n²) function.

Your response to this may be that I ought to open my eyes and read the docs, but the docs aren't there or are incomplete, half the time. I don't trust this kind of detail to documentation, only to enforcement by the language.

Despite all this, I think any of you programmers out there should learn some of this language. It allows you to do certain things very elegantly, which gives you insight about elegant ways to program in other languages you'll probably use more. Iterators and blocks (Procs), in particular, are very cool.

A Proc is basically a block of code that is stored as an object and can be passed around and used later. What's amazingly convenient about it is that the block can be returned from a function and still work. Normally, all the local variables would go out of scope once that function had returned, but a Proc always has access to all its local variables, even if those variables have gone out of scope.

I'm pleased that working with files and other I/O is just as simple in Ruby as it is in Perl. I am pleased that they have a fully function regular expression library that's integrated into the language (via /pattern/ type of expressions). I'm glad that hashtables have language support as well--for creating and accessing. It really is kind of nice that everything, including numbers, is an object. It saves me the time of considering whether I'm passing a primitive type or an object reference (Java, I'm looking at you).

Finally, I like two interesting naming conventions I've seen so far. For member functions that are queries, such as whether an object is equal to another, or whether some flag is set to true or not, the convention is to make use of a ? in the function name. For example, the equality test between two objects is Object.eql?(). Some member functions come in two flavors: one that does some processing on the object, but returns a new copy that reflects the changes; and one that directly modifies the object. For the latter, the convention is to append a ! on the function name. For example, the function that returns a new copy of a string with all the letters in losercase is String.downcase(), but one that modifies the string is String.downcase!(). It seems intuitive. The exclam alerts you that you're making a change--a potentially unsafe thing to do.

That's all for now. If I find anything else substantial, I guess I have to make a new post. Hope this was informative, and that you're all inspired to go out and try Ruby!

-- Virtual Beacon, ἱστάμενος, likes precious gems and some languages --

I'm not in a very good position at this time. In spurts, I've had to contain myself quite severely to keep from blabbing a lot about my latest programming project. As such, I've been meaning to write a blog entry about it as soon as I had made what I considered to be considerable progress. A few things keep me from gladly writing that entry right now. I don't feel like I've made the progress I want yet. I'm writing this suddenly, so I don't think I can write the kind of entry I'd usually like to make. On the other hand, today might be the last time I'll be able to work on it, let alone write about it, for as long as a month. Time and circumstances force my hand.

I've been working on a MUD. Surely you've heard some of the people on the blogs mention them before. They're basically text-based RPG games. Yes, text-based. No graphics. You type in commands to say stuff, move around, fight, etc. You interact with other people, fight monsters, etc. Yes, it's often like D&D. Yes, it's fairly dorky. Yes, it can be sickeningly addictive to play.

I am building a MUD from the ground up, from scratch. Across the Internet, only a handful of "codebases" account for most of the MUDs you might find: Diku, Circle, LP MUD, Rivers of MUD, and Smaug, to name a few. A codebase is a basic package for starting a MUD. If you wanted to start one, you could download a codebase, say, Rivers of MUD, install it on a computer, and you'd be ready to go!

Now, your MUD would be very, well, generic, because it's essentially out of the box. So you'd want to customize it: change its name, add some new races, new skills, build areas, etc. The point of a codebase is to give people something to modify to make a new mud. Most well-developed muds are extensively modified codebases. Daedal Macabre, for instance (one I used to play), is nearly unrecognizable ROM.

So, to get back to the main discussion, I think my project is to make a MUD codebase that resembles ROM in some respects (since I am most familiar with it), and has some of my own ideas thrown in. It is being made in a fairly new language called Ruby that some of my friends (ahem, Caius and npj7y) pestered me to learn. It's a pretty good language, with some very convenient features, and some other features that lend themselves exclusively to bad programming practices.

OK, so I was asked to stop all the "filler" and write a real entry. That's actually an outright lie, but I read it on someone else's journal and it seemed like as good an introduction as any to a new entry. So here it is, an entry without all the "filler."

gsd4x sent me an email today in which he asked me, "what are you becoming?" My immediate reply, also by email, was to ask him what on earth he was talking about, what kind of question that was, and that I didn't follow what he was asking. Upon closer inspection, I find that I'm slipping into a (shallow) rut. It's lucky that within three weeks I'll be in a much different sort of rut.

Once work starts, after I've taken care of all the things that need to be done with relocation, I'm most likely going to settle into a routine. Unless I am circumspect and mildly cautious, I am going to lose flavor. For years I've been anticipating this long stretch of "stable life" in a vague, far-off way. It's not necessarily that I'm scared of doing boring things for the rest of my life, letting my life slip by me, as they say, but rather I'm afraid I won't notice it if it happens, or until it's too late.

I tend to worry too much. Leia could tell you that [Currently listening: The Calling -- Anything]. See, I think that's a much better format than the little space in the heading of your entry that says what you're listening to. Hopefully you know where I'm going with this: I take longer than an average of four minutes to write an entry! Several songs elapse. I haven't explored the psyche behind this, but I would imagine that the song currently listened to has some effect on the writing, either or both in content and in style. It seems like the sort of thing that can't be observed very accurately introspectively, because introspection is intrusive.

That's another thing I'm worrying about, [Currently listening: skipped Carol of the Bells, skipped Finger Eleven - Above, skipped Tawu Iwasaki - half pain (Witch Hunter Robin OST), settled on Seatbelts - Tank (Bebop OST, come on, fools)], a lack of introspection in my daily life. I used to consider introspection to be something (at this point I hit the "save" button, because crashes wait for nothing, especially not a good sentence) I did almost constantly [Currently listening: Ozric Tentacles - Xingu], but now I think back on myself and feel like I haven't done it at all lately.

In a way, that's introspective in itself, isn't it? Maybe there's hope for me yet. I can't remember what exactly made me more introspective, but blogging helped, and before that MUDding helped. It might also be because my self esteem has gone up a lot on its own over the last year or two. I imagine Leia had a lot to do with that too, but it's not like I ever had a real problem with it.

I have a long list of things to blog about, both technical and non-technical, but I have a rule that I rarely violate that says that I must write entries that are concise, self-contained, properly developed, and focused on a single topic. For this reason, many of my "smaller" thoughts [Currently listening: Welbilt - Everything's Alright] are hard to write a whole, self-respecting entry about. It's a shame, really, but it can't be helped (shouganai) [Currently listening: Andromeda - In the Deepest of Waters].

I'm done writing. I'll write something else later on. Oh, when I said this entry didn't have any filler, I was totally lying.

-- Virtual Beacon, ἱστάμενος, writes about daily life --

This has come up enough times for me recently that it's worth writing something about. This is a short, shallow article about the problems of PIO and a solution, DMA. Yes, this has to do with computers. Yes, the fixes on Windows require registry munging. Still, it's fairly safe anyway. Yes, your computer can get a phenomenal speedup (10x) in many situations from doing this. This article does not apply to SATA drives, as far as I know.

What is PIO?

PIO stands for Programmed Input/Output. It is a method of transferring data to or from a device in your computer, such as a hard disk, CDROM drive, DVDROM drive, CD burner, Zip drive, and so on. By using this method, the CPU, your processor issues a request for every byte of data that needs to be transferred. Depending on which PIO mode your device is operating in, the processor may issue a request for several bytes to move at once. The data is transferred either to the device or from the device into memory or to another device, depending on what's going on. In the case of, for example, playing an MP3, data moves from the device into memory (and later out your speakers).

What is DMA?

DMA stands for Direct Memory Access. It's a method by which access to data on a peripheral device, such as a hard drive, etc. (see list above) is accessed via a special "DMA controller" that is not part of the processor. The CPU initiates the transfer of data, but the DMA controller takes care of the rest of the moving of data, so that the CPU is meanwhile free to take care of other tasks.

DMA is better than PIO. Here's why.

Say that you're copying a 5MB music file from one place to another on your hard drive. 5MB = 5 * 2²⁰ = 5242880 bytes. Suppose the processor is operating in PIO mode, which means it has to move each of those bytes individually. Before anything can happen, the CPU has to be interrupted from whatever it was doing before--drawing your mouse cursor, making some funny little buddy icon animate, whatever--and that takes some amount of time. Then it issues a move request for the first byte, from the hard drive to an internal register. Then it issues another move request from the internal register to the destination on the hard drive. That's two instructions per byte. Multiply that by the number of bytes, and you're looking at 10,485,760 instructions. That's not a small amount!

But wait, you say, my CPU runs at 4GHz. That's 4 billion instructions per second. What's a measly 10 mil instructions to me? A few things. Firstly, the CPU runs at 4 billion cycles per second. Only on a very good day will that mean 4 billion instructions per second. Next and more importantly, those would be 4 billion instructions of arithmetic that hits the cache. Those of you who know things about operating systems will realize that the CPU will be in a busy state while most of the move instructions go out not to L2 cache, not to memory, but to DISK to fetch the data. I don't I know enough to do the math to calculate just how bad that is, but it's very bad.

A modern hard drive performing badly looks something like this. Note the final number, the speed transferring from disk.

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.80 seconds =160.02 MB/sec
 Timing buffered disk reads:  64 MB in 32.05 seconds =  2.00 MB/sec

The same hard drive, after it was set into Ultra DMA Mode 2, looks like this. Note, again, the transfer speed. Uh, that's a speedup by a factor of 11!

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.87 seconds =147.66 MB/sec
 Timing buffered disk reads:  64 MB in  2.92 seconds = 21.95 MB/sec

So shouldn't my hard drives be in DMA mode all the time?

Answer: yes. Reality: no, they may not be. On any system, if DMA mode is disabled in your BIOS (the computer configuration that you can bring up right about when the memory test goes on when your computer is booting up), then the operating system cannot enable it.

On any system, if your drives are old they may not support DMA mode. Also, if your hard drive controller is old, it may not support DMA modes properly or at all. Usually your hard drive controller is old if your motherboard is old. Usually that in turn is synonymous with your computer is old. How old is old? I'm not sure, but I'd guess at six or seven years old. Don't laugh! I'm using all old parts in my Linux box!

On Windows, there is a KB article that describes this behavior. If the device currently in DMA mode receives six read errors EVER, it is reduced to the next lower DMA mode. If this occurs again, its mode is reduced again, and so on until it hits rock bottom, PIO mode. Playing a scratched CD that skips for a long time? Your CDROM drive may have just gone into PIO mode. This shouldn't happen with hard drives, but you never know, I guess, since I've found some of my friends with their hard drives in PIO mode.

On Linux this should only happen if you do not have support for your hard drive controller in your kernel (either built-in or as a module). This happened to me, and I'll talk more about it later.

Windows XP/2003 Diagnosis and Solution

Diagnosing the Problem

I'm providing you with step-by-step instructions. Be happy.

1. Right-click My Computer. Select Properties.
2. Select the Hardware tab.
3. Click on Device Manager.
4. Expand the list (click the + sign) next to IDE ATA/ATAPI controllers.
5. For both Primary IDE Channel and Secondary IDE Channel, right-click and select Properties.
6. Go to the Advanced Settings tab.
7. If either Device 0 or 1 has Transfer Mode set to PIO Only, change it to DMA if available.
8. Note whether either device on either channel has Current Transfer Mode set to something including the word PIO.

Fixing the problem on Windows

If you made any changes to the Transfer Mode or if PIO was set on any of your devices, you need to get Windows to re-detect the settings on the next reboot. This requies some Registry hacking. In general, what I'm telling you to do cannot cause any permanent damage, but perhaps you should back up your registry anyway before doing this. Once you've done that, read on.

Follow these instructions to get Windows to re-detect the DMA settings of your devices.

1. Start Menu → Run...
2. Type in regedit and hit enter.
3. Keep expanding levels (hit the + sign) for the following key:HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Class/{4D36E96A-E325-11CE-BFC1-08002BE10318}
4. Within that key, you'll see keys such as 0000, 0001, and so on.
5. Click on them and look on the right pane for the value of DriveDesc that is "Primary IDE Channel" or "Secondary IDE Channel."
6. In both Primary and Secondary, right-click in the right pane and select New → DWORD Value. Call it ResetErrorCountersOnSuccess. If the value already exists, do not create a new value, but go on to the next step.
7. Double-click the value you just created, and set its value to 1.
8. Select the value called MasterIdDataCheckSum. Delete it.
9. Select the value called SlaveIdDataCheckSum. Delete it.

Explanation of what you just did

Adding the ResetErrorCountersOnSuccess=1 value says to Windows that if you successfully read data from a device, reset the six-strikes-you're-out counter back to six. So if you have a few read errors on a CD, but then successfully read, you're still safe. It's not a complete fix, but it helps a lot.

Deleting the data checksums forces Windows on the next reboot to redetect your DMA settings instead of using what it was using before. Check in your IDE Channel properties (see about diagnosing the problem, above) to see if your current transfer mode is now DMA. Several-year-old hard drives should be able to manage Ultra DMA Mode 2. Newer hard drives can get to Ultra DMA mode 6. More on this later.

Diagnosing and Fixing Linux

Diagnosing the problem

Use the hdparm utility: hdparm -i /dev/hda will tell you all about your hda. You're set at PIO mode if you have a * next to one of the PIO modes or the absence of a *.

Also, test your hard drive's speed, with: hdparm -tT /dev/hda. If your numbers are looking like mine above, then you're probably in PIO mode. If they're above 20MB/sec, then there may be no need to twiddle with your settings unless you find your processor pegged whenever you're transferring files.

Fixing the Problem

You can attempt to set your drive into DMA mode: hdparm -d1 /dev/hda. If you get an error of Operation Not Supported (or similar), it means you don't have kernel support, and you need to recompile your kernel, making sure to include your hard drive controller chipset in Device Drivers. You'll probably have to look up your motherboard specs to find what controller you have.

Once you've recompiled your kernel, check to see if you're in DMA mode yet. If you are, then you're done! Your system automatically selects the highest DMA mode possible with your hardware. If you're not in DMA mode, you can try to set it into DMA mode again manually, as above. Check if this succeeds with: hdparm /dev/hda. If it worked, and the * is not set at the highest DMA mode listed in hdparm -i /dev/hda, then you can attempt to set it to a higher mode, with, for example: hdparm -X udma4. If this doesn't work, well, keep reading, but you might be out of luck.

I can only get Ultra DMA Mode 2. I want more!

You might be able to get more (i.e. Ultra DMA Mode 3-6), but you're going to have to get your hands dirty. This involves opening up your computer and tinkering around. I don't recommend doing this unless you know something about tinkering around in there, and you're willing to get frustrated.

Ultra DMA Modes 3 through 6 are only available with 80-pin IDE (hard drive) cables. Most older systems come with 40-pin IDE cables. See here for a comparison image. Why is 80-pin better? Half the wires carry a ground (0V) signal, so the other 40 wires are physically separated from each other. The idea is that the 0V signals on the wires between "absorb" electromagnetic interference between the other 40 wires, which actually carry data. Because there is less signal noise, data can be sent at higher frequencies (i.e. higher transfer rates).

If you're already using 80-pin cables and you still can't get above Ultra DMA Mode 2, then it's because the drive is too old. My DVDROM drive from about 4 years ago can't support better, but many of my old 5400 RPM hard drives can. You never can tell, I guess.

If you're not using 80-pin cables and you think you're maxing out at Ultra DMA mode 2, you can go to your local computer store and pick up a new cable for about 10 bucks. Be warned, the $10 cables will have the connector spacing too close and set all wrong, so you might end up rearranging the physical positions of your drives within your computer case. It's a new type of hell, says I, the voice of experience at this point.

If you manage to change cables and you find you can hit Ultra DMA Mode 4 or so, congratulate yourself! You've been through a lot. Then tell me so I can pat you on the back, too. It's nice to find other tinkerers like myself.

Well, I hope you found this little article informative. I've really been meaning to vent about this, having fixed four or so computers that were plagued with PIO-sickness.

-- Virtual Beacon, ἱστάμενος, the tinker... sort of --

References

• Where I first found out how to fix this
• An excellent guide for hdparm on the Gentoo Wiki
• A page with neat tricks on using hdparm
• A decent discussion of IDE cables. There are better, but I can't find the page again.

His roomate sent out an email to most of their friends, entitled, "A Testament to College Life." It said: Raising the bar for future generations. In it was a single photograph that he took outside our on-grounds apartment at the end of the year. He'd actually meant to do the same the year before, but didn't have nearly as many then as this year. In their defense, their consumption was higher by a factor of about 1.5 this year. I intercepted the email and the secrat contents.

It's borderline terrifying the things for which they used pizza boxes within their apartment. Someone needs to draw the line somewhere, or risk crossing into a kind of madness. Unimaginative night-stands and generic horizontal surfaces are within the bound of acceptable conceptions. I was able to see him using a stack of about ten to hold up his Xbox, and his roomate another stack of perhaps 12 to hold up his...alarm clock and some various papers.

But two stacks side by side, joined by a single stack on top, used to hold up a table lamp next to their television is something simply did not want to see. Table lamps are meant to go on tables! Tables made of of, you know, wood or maybe even metal. Not cardboard, of all things. I heard them conversing amongst themselves; they said, "My, that's a surprisingly sturdy table for our table lamp! We sure are glad we have it!" I left in a hurry.

But I also saw them use them for absurd horizontal surfaces. While eating dinner, in the absence of a table to eat at, one held a pizza box in his lap and put his plate on top of that, as though it were acceptable in any modern society. The same one, on another occasion, pulled out the topmost drawer of his desk and put a pizza box there, to use as extra desk space for writing on.

Rumor has it that in the previous academic year they used a stack about twenty or so high as a stand for their phone to reach the top bunk of their bunked beds. Whatever truth there be in that does not sit well with me.

Through some correspondents of mine, I came to find answers to the "food mess" problem. Supposedly, as they say, pizza boxes breed no vermin. No rats, no mice, no cockroaches even. I am incredulous, and with as many as they had, they must be covering up, out of shame.

I intercepted the email, yes, and have kept the contents, which I am now able to share with you. I counted: there were exactly 99 of them. Please, I beg of you, do not make the first joke that comes to mind, which involves towers, a location in Italy, and a painful pun.

-- Lysus, investigator, as usual --