Personal Programming Python Testing

My Bad Memory, High Load, and Python

About a month ago the new Ubuntu 8.04 was released and I wanted a clean install. I downloaded an image and burned it to a CD. Just before installing, I tried “check CD for defects” and found a few. Turns out (*) this was because of bad memory – and memtest confirmed it.
So I went to the shop, replaced the bad memory, and also bought two new sticks. I went home to install the new Ubuntu, and after the installation, Firefox crashed. After rebooting back to memtest, I saw this:

memory errors in memtest

Back at the computer shop, they asked me to reproduce the errors. Just firing up the computer and booting directly into memtest didn’t seem to do the trick, so I suspected that I had to overwork my computer a bit to reproduce this.

Since I was at the lab, I didn’t want to muck around too much.
So I thought, “what’s the quickest way to give your CPU a run around the block?”
That’s right – a tight loop:

while True:

However, this snippet doesn’t really play with the memory.

The next simplest thing to do, that also jiggles some ram is the following (and one of my favorites):

In [1]: x = 4**(4**4)
In [2]: y = 4**x

I will talk about this peculiar piece of code at a later post.

In any case, this snippet also didn’t reproduce the error. It is also quite unwieldy, as it raises a MemoryError after some time. Later at home I tried two more scripts.
The first is a variation on the one above:

x = 4**(4**4)
while True:
        y = 4**x
    except MemoryError:

I ran a few of those in parallel. However, my Ubuntu machine actually killed the processes running this one by one.

The second is smarter. It allocates some memory and then just copies it around:

import sys
import copy
megabytes = int(sys.argv[1])
x1 = [["a"*1000 + str(i) for i in range(1000)] for j in range(megabytes)]
while True:
    x2 = copy.deepcopy(x1)

After both of these scripts didn’t reproduce the problem and it still persisted arbitrarily, I returned the computer to the lab. Turns out that the two replacement sticks and the two new sticks weren’t exactly identical, and that was the cause of the problem. So now my memory is well again.

As for the scripts above, I once wrote a similar script at work. I was asked to help with testing some software in some stress testing. The goal was to simulate a heavily used computer. A few lines of Python later and the testing environment was ready.

(*) – Finding out that it was a memory issue wasn’t as easy as it sounds. I didn’t think of running memtest. I checked the image on my HD with md5, and the hash didn’t match. I downloaded a second image, and again the hash didn’t match. I checked twice.
At this point I was really surprised: not only the second check didn’t match the published md5, it also didn’t match the first check. Some hours and plenty of voodoo later, a friend suggested running memtest, and the culprit was found.


Ubuntu – small nuisances

It’s been more than a year since I switched to Ubuntu, and so far I’m happy. Apart from some small details, the experience has been very good.
I didn’t yet get a chance to use Openoffice. A few months ago I found myself needing to create a small table for some homework, and thought, hey, I could use Excel, Openoffice Spreadsheet. Well, that didn’t quite work out. At first I just wanted to write some simple equation so I clicked the fx button… but it crashed. A lot. Getting burned, I decided that I’ll try it again only after the next release.
The only big document I’ve written so far was with Kile and Latex, and I’ve been very pleased with the result.
Another thing: some games crash. I’m not talking about games with Wine, but your regular Linux games, like Nexuiz. I don’t mind the games crashing that much though, it happens rarely enough. What I do mind is that after crashing, X doesn’t restore the original resolution, and there is no ‘easy gui’ way to do so apart from ctrl-alt-backspace. However, this combination which restarts X, also kills my running applications, which isn’t very nice.
After some Googling I came up with the solution, the nice little command xrandr. Worked like a hack charm.

Another annoying bit is the clipboard. It works quite fine – I can copy from the Firefox address bar, and paste in gedit. However, after I close Firefox, the text copied is no longer available! Took me a couple of times to figure out what happened, and that it wasn’t just me ‘pressing the wrong keys’…

All in all, these aren’t that troublesome. As I said, I’m quite happy with Ubuntu, and I’m not going back to Windows any time soon.

Linux Programming

A quick note on fonts and Ubuntu

It has been about half a year since I switched to Ubuntu as my main working environment (longer article on the subject is upcoming, sometime in the future). The hardest part for me was getting back to programming productivity. Strangely enough, I found out that the thing that was preventing me from working well, was the fonts. It didn’t take me long to discover that I prefer white background to black while programming. This is true just for programming, not for other activities – I can’t use a white background command prompt…

Back to fonts. I tried to adjust them, and it was really slow progress. I downloaded some programming fonts, and it still didn’t feel right. Also, when I enlarged the fonts, or made them smaller, they looked really bad. I didn’t remember this ever happening to me on Windows. After some more back-and-fourth, I discovered I just like the plain old Courier New, at size 10. Currently my programming environment (for Python) is Eric, and its pretty much OK. I feel more or less at home.

This made me think on how important are the little things in a desktop environment. Good design seems to be important for other things however, for example, see Measuring Font Legibility. Usually, when I find a piece of human engineering that is really solid, and well thought, I stop for a moment of appreciation. This might be a good lesson for any programmer, let alone one trying to compete with already successful software.