The other day I was at a friend’s house, and while waiting for the oven to preheat, I stumbled across a game I once played as a child, a triangular peg board where the goal is to remove pegs such that there is only one peg remaining. I was thinking of devising a program to attempt to solve the puzzle, much like my programming languages assignment last year to solve a slide puzzle. However, the more I thought about it, the more I realized how attached the conventional computer science paradigm is to rectangular data. It is almost too easy to write a program to play checkers (or at least manipulate the pieces on a board), but it is certainly non-trivial to write a simple and efficient algorithm the maintain the board state. I think it’s rather interesting how the problems we generally have to solve fit rather nicely into their little rectangles, and how few problems require other shapes.

For a solution to the peg board problem, I found this site that documents the author’s process and a code listing. If you’re interested in the game as much (or more) than that the programmatic solution, there are also a number of statistics for possible solutions on the site.

Peace and chow,

Ranok

There are many things that we take for granted when using a computer: the operating system, hard ware drivers, and graphical interfaces. By learning about these tools, it gives a new awareness into how much work it takes to get even a simple system working. Computer programmers also take advantage of a number of software components: compiler, linker, operating system, memory management functions and debuggers. There is quite a bit of behind the scenes that goes on even in a simple program like:

int foo(int a, int b) {
return a + b;
}

int main() {
return foo(3, 4);
}

Still has many layers underneath the obvious, the one I want to mention briefly today is the calling conventions. I was curious what happens when you call a function, and looking on wikipedia, I found an article that very nicely shows how many possible things could happen.

Normally in with gcc, when you call a function, the generated code pushes the arguments to the function onto the stack in reverse order, that is, last argument first, and then pushes the address of the next instruction to execute and jumps to the function. That function then can access the arguments and put it’s return value in EAX and jump back to the pushed instruction address. The caller must then clear the stack and use the EAX return value.

However, a way to optimize your code with gcc is the -mregparm=N command, which will put the N < 4 first arguments in registers EAX, EDX, and ECX respectively and push the rest onto the stack. This is much quicker since it requires less memory access. However, you must make sure to compile all your code this way, otherwise you’ll have some strange interactions when the conventions are mixed.

Peace and chow,

Ranok

After taking off the afternoon due to a migraine, and napping for a few hours until it passed, I was looking over some old projects, and decided to get motivated to work on my various Erlang hackery projects. I checked out a fresh copy of Open Server Platform on my new computer, and decided to hack on it some more. There are a number of loose ends I’d like to tie up before the 0.3 release, but, before I could get down to coding, SVN get my so frustrated that I could no longer deal with it and switched to git, creating a new repository on Github. I will keep the Google Code repository the ‘defacto’ repository, where the safer code gets committed, but use Github for the more bleeding edge development due to it’s simplified branching and merging (among other things).

In the new git setup, I have two branches (aside from master, which follows the SVN repository): otp and no-otp. The no-otp version is currently the stable code that runs just fine, but doesn’t take advantage of Erlang’s OTP framework. The otp branch is the more cutting edge OTP aware version, which I hope to fully migrate to soon. With full support for OTP, I should be able to use an already existing distribution platform, and more battle tested redundancy.

This evening, I fixed a long standing bug in the example HTTPd where the server would crash when opening large files due to a shortcut I took with first implementing the server. Originally, the server would read the entire file into a string and then send that to the client, as you can probably see, there is a problem when the server tries to read in a 3.9 GB file (my test file). Now, my servlet takes a much more sane approach, read in the file 1 kilobyte at time, sending that to the client before reading more. This new approach works perfectly, though I had to add some messiness for handling CGI/PHP files and different MIME types. I also added support for the HTTP HEAD command.

Peace and chow,

Ranok

This past weekend I went home to Vermont for a few days, to relax and decompress from my busy life on co-op. While there, I did some things that I love, hiking and photography. Now that I have my new camera and tri-pod, I can do things I was unable to before. On Friday I hiked Mt. Cardigan in the White Mountains, and on the top, I took a 360 degree panorama, hoping to use Hugin to stitch it all back into one large image. When I returned to my computer, I installed Hugin, and dove right in, stepping through each tab, selecting control points, optimizing, adjusting the exposure and finally, stitching. I ran into two errors on my Xubuntu 8.10 (i386) laptop, first, the enfuse application was not installed automatically (due to a package move), and second, when I installed enfuse, the panorama turned out all curvy, like a sideways ’s’. To install enfuse, I downloaded the jaunty .deb package from here and used dpkg to install it. After tinkering for a while with settings to try and reduce the curvature, I tried returning to the first tab, which was an assistant of sorts, to see if it would help me. I clicked on the align and stitch buttons, and sure enough,a preview window of the panorama appeared, as straight as an arrow! Now that I got the process down, I’ve been taking a number of panorama’s (full 360s or partials) and put them on my Flickr.

Enjoy!

Ranok

There has been a long debate on Windows versus Linux, Mac versus Windows, Apples versus Oranges, etc… I’m going to add my two cents to the fray, but in a way that looks at how each OS plays its role.

Windows: This is the dominant OS, it may not follow industry standards, but regardless is the norm. It has a horrid reputation for security as it is still trying to support legacy applications. It is also buggy, and a pain to develop on, however, the .NET framework is a step in the right direction. Windows made a rise when it was able to make computing both affordable, and simple, it wasn’t perfect, but it was good enough for its users.

Mac: Apple started out lost, using the shotgun approach to selling computers, many different models with very slight differences. However, once Steve Jobs trimmed down the breadth of choices and OS X came out, they had finally hit the sweet spot, selling powerful, easy to use software on high quality hardware. They are in the best position to take the lead, if they can lower their price points, as they will never be able to compete with a $200 computer from Dell. I’d suggest they release some very low end netbooks and cheap desktops to gain market share in both the education sector and as a computer for the ‘basic user’, those who only checks their email and surfs the web.

Linux: An oddball to say the least, it has been mostly community developed since its inception. Very popular with servers and more computer literate users, it still has very little market share. While there may be evidence to support it being the ‘best’ operating system, best is inherently subjective, Linux is made by technically savvy users for themselves, it is just now being looked at from a average user standpoint. While I prefer Linux, I also would consider myself a pretty technically skilled user, therefore enjoy the challenges of getting my system running perfectly, and the customizations it exposes. Linux has a long way to go before it will be considered viable for the average user, as most of the development is to make it better for the current userbase, not the one that doesn’t use it.

Well, now that I’m sure I’ve angered a number of people (please comment, I do like reading responses), I will end this post having put in my two cents, but very eager to see how the next few years change the playing field.

Peace and chow,

Ranok