The thing about the internet is that noone cares. I mean, it is more uncaring than a sidewalk full of people walking over a dead body in their way. It is more uncaring than the person who stops only to take his wallet, and more so than the garbage man seriously considering just throwing it into his garbage truck and hauling it away, except his union contract doesn't stipulate biohazard waste removal so he leaves it for the next guy.

I love the internet for this reason. Noone will look at my stupid posts, noone will care, and noone should. I'd be scared if people did. Do I look important? If I did, you'd know about me and I wouldn't be a faceless Eliza program spewing drivel into the world. I do so because I'm fascinated that noone cares. It is like screaming for help in a department store and everyone walks past you in willful ignorance at worst or complete obliviousness at best. The wonderous ability of the internet is to allow one to fool themselves into believing they've achieved validation.

Anyway, here are some pumpkin pictures from Halloween 2008.

This first one is my wife's that she traced from a book.

This second one is my own design, because I didn't like the ones in the book.

End of Line.

Someone I know had asked me about an example of a bug that made me write the previous post. Here is what one of these calibers of bug I had run into looked like:

My bug was that I was debugging why a fortran program would segmentation
fault when run with an address of 0x0 and you couldn't even start it in
the debugger--meaning the debugger wouldn't even get the signal that a
segfault happened, instead saying there wasn't a process to debug.

It sorta looked like this (recreating it on a machine):         

(gdb) r
Starting program: /tmp/a.out

Program terminated with signal SIGSEGV, Segmentation Fault.
The program no longer exists.             
You can't do that without a process to debug.
(gdb)

What a pisser, eh?

An strace showed something like this:

Linux black > strace ./a.out              
execve("./a.out", ["./a.out"], [/* 78 vars */] <unfinished ...>
+++ killed by SIGSEGV @ 0x0 +++

The problem was that linux kernels (a while ago) had an undocumented
and unlogged internal limit in how big the bss section could be for a
program and exec() had gone far enough to destroy the initial process           
so it couldn't return failure. The fortran program had a gigantic
global array whose size exceeded the internal kernel limit. So when the
kernel tried to allocate the pages that the bss ELF section requested,
the kernel sent a segfault to the process--which wasn't even set up in
memory yet! Since this happened before exec() returned, you couldn't even
attach a debugger to it since the process died before the trace signal
could be sent to the debugged process and no core would be dropped since
there wasn't anything in memory to constitute a core.

I debugged it by modifying the *first* instruction of the executable
to be an illegal instruction and noticed the segfault still happened 
instead of the expected SIGILL. This told me that even before the first         
instruction of the linker loader got executed the fault was happening and
that meant the kernel was doing it and didn't like something about the          
program. From that point on, I kept bisecting the program into smaller
and smaller pieces by removing or stubbing out ELF sections until I found  
it was the bss definition which caused it. Then I looked at the bss,
noticed it wanted a 300 Meg chunk of space, and figured it out.                 

In modern kernels, they fixed it to have a much higher limit (985Megs
instead of (IIRC) ~100Megs) and changed the killing signal so gdb and strace
now tell you the process got a SIGKILL instead when it happens. Nice.

End of Line.

Deep in the crevasse of sanity one becomes blind to the subtle horror of inexplicable behavior. Normalcy is defined and bound by consistent rules in one's interaction with the world: if you drop a ball, it hits the ground, if you speed in front of a police officer, you get a ticket, and if you scream obscenities at the passing car on the I-5 whom just cut you off, you get shot. These rules and countless others smooth our movements through life at least enough to give us the illusion of control or happiness. Oh such fleeting deceptions, how I miss thee.

There is certainty in these rules that tricks us into believing the world is a sane and rational place. The fundamental tenant of cause and effect form not only the seeds of civilization, but beget the Gods themselves.

Enter programming, which should be defined as "The moment one realizes something is inconsistent."

One may have chosen wrong instead of inconsistent, but that is incorrect because when something is wrong, like a flat tire, it stays wrong. Inconsistency leaches away rationality until the primal core of chaotic rage surges forth through the shards of intellect and tears asunder life and happiness, until determination and insight wreck themselves on its jagged shore, and until the spark of hope and desire to resolve causation sputter and die.

Programmers spend their entire lives in a vicious cycle of engendering inconsistency and then wallowing in it. Horror encircles tragedy in an ever decaying orbit until the event horizon of insanity is passed and one grows permanently numb to the pain.

I propose a special kind of yearly contest--one that puts the spotlight on the actual skill of a programmer. The skill to write inconsistent programs that cannot be reasoned about.

The goal of this contest is to produce a piece of code (max 10,000 lines in any language) or interaction with an OS that exhibits a preferably non-deterministic bug in such a manner as to elude detection by tools such as gdb, valgrind, coverity, statistical debugging methods, etc. For extra points, the bug should be in a mainstream language and successfully eludes human code inspection. The code should not only look perfect to the crude tools we have, but it should look perfect to the human as well. The judging shall be done by attempts of other programmers. Each audience member will reasonably document an attempt to solve the bug. The contest will be open a certain number of weeks, and after that, the program(s) with the largest number of attempts to understand the bug will be the winner. Bonus points awarded if the bug never gets solved. The author must never reveal the bug--it must only be found by others by breaking their minds against them. There will be a lifetime achievement award for programmers whose entries survive far beyond the lifespan of an individual contest.

The name of this contest shall be:

A Simple Hack

End of Line.

I've been doing some more GTK+/glade coding: mostly because I really should be writing an interactive fiction game that's 85% of the way completed and I'm procrastinating instead. These little GTK projects basically have a time limit of 8 hours to learn whatever it is I need to know, write it, and make it so it doesn't suck (or at least not leak memory). I have some future project in mind so I figure getting right to the money shot is more worth my time.

Having such a restricted amount of time removes much of the polish and glitz which often surrounds GUI programs, you know, the stuff that makes it usable.

So, I present to you, in a manner that a dog presents to a fire hydrant, Chasm 0.1. This program simply takes a piece of C on the left, and shows you the assembly conversion of it to the right. For those of you with directional dyslexia, here is a picture:

I'm probably never going to work on it again, hence it being "Unfinished Junk". Maybe someone out there who needs some example of something, like what not to do, can find it useful.

End of Line.

Have you ever wanted to embed gvim into a GTK+ 2.0 application that you've been writing? Wouldn't it be so nice if it just showed up in your container widget and made comfortable cooing noises as it acted like the perfect editor for you while your strew all of your widgets and crap around it like so many failed dreams in your life?

Well, today is your lucky day! For reasons I will not elaborate upon, except to say I am not allowed in Utah anymore, I've found out how to do this.

Of course, the first place one would think to look for this knowledge is the GTK+ 2.0 tutorial. There is a lot of information there, so how about we go look at the one page we need, which apparently is on GTK Plugs and Sockets.

Oops. I guess that tutorial page isn't done yet. Sadness 10000. Maybe vim can shed some knowledge in their free time destroying help pages.

Stumbling around in vim's help like a drunkard looking for a place to urinate, I find two very helpful pages on how to do this.

By very helpful, I mean "WTF?!?". That helps me about as much as a McDonalds menu written in Linear A. However, I now know how to get gvim to do something interesting with a magical incantation, but who's picking up the phone on the other end? What does the phone even look like?

Huzzah! I find a dirty wad of intellectual gum that I can chew on for a while. The information to which that page leads is technically correct, but simultaneously hard to use--like an implicit surface equation. Armed with this knowledge, however, let's see if I can do something.

After sufficient screwage with the interface, I wrote a piece of trash which accomplishes the task. There were previous more buggy revisions of this code sitting in this very entry, along with other text. But, thank god for the internet easily enabling revisioninst history. If it works for major onilne news publications, it'll work for me.

Compile this program in the usual GTK+ 2.0 manner:

/* Written by Peter Keller <psilord@cs.wisc.edu> Oct 2008 */
/* This code is a piece of trash but is under the BSD license. */

#include <stdio.h>
#include <stdlib.h>
#include <gtk/gtk.h>
#include <gtk/gtksocket.h>

void plug_add_cb(GtkSocket *socket_, gpointer user_data)
{
    g_print("Added a plug!\n");
}

gboolean plug_removed_cb(GtkSocket *socket_, gpointer user_data)
{
    g_print("Removed a plug!\n");

    /* be able to reuse this socket */
    return TRUE;
}

int main(int argc, char *argv[])
{
    GtkWidget *window;
    GtkWidget *gtksock;

    gtk_init(&argc, &argv);

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_widget_set_size_request (GTK_WIDGET (window), 200, 200);
    gtk_window_set_title (GTK_WINDOW (window), "Embedded vim test");
    g_signal_connect (G_OBJECT (window), "delete_event",
        G_CALLBACK(gtk_main_quit), NULL);
    g_signal_connect (G_OBJECT (window), "destroy",
        G_CALLBACK(gtk_main_quit), NULL);

    gtksock = gtk_socket_new();
    gtk_widget_set_size_request (GTK_WIDGET(gtksock), 200, 200);

    g_signal_connect(GTK_OBJECT(gtksock), "plug_added",
        G_CALLBACK(plug_add_cb), NULL);

    g_signal_connect(GTK_OBJECT(gtksock), "plug_removed",
        G_CALLBACK(plug_removed_cb), NULL);

    gtk_container_add(GTK_CONTAINER(window), gtksock);

    gtk_widget_show(gtksock);
    gtk_widget_show(window);

    g_print("The ID of the socket window is 0x%x\n"
            "Run the command 'gvim --socketid 0x%x'\n",
        gtk_socket_get_id(GTK_SOCKET(gtksock)),
        gtk_socket_get_id(GTK_SOCKET(gtksock)));

    gtk_main();

    return EXIT_SUCCESS;
}

And follow the directions when you run it. If it works, you'll see the gvim window open up in the idle window.

Somewhere, a dog barks.

End of Line.

In some deep part of me, hidden in a place where even psychologists for the criminally insane can't penetrate after years of study and inhuman experimental psychopharmacological drug therapy, I want to learn APL. I find its iconographic character set and powerful functions and operators intoxicating in a seriously unhealthy manner.

I've made mention of this before and have tinkered with it over the years, learning bits and pieces as I go with the wonderful patrons of comp.lang.apl giving me their excellent help.

Today, I figured out how to make gvim use the unified keyboard layout for APL along with a standard APL font called the APL385 Unicode Font. You can read my efforts here. Sadly, I don't know if any vendor APL interpreters could read those files, but at least it makes it easy for me to write it for other purposes.

End of Line.

The happy little elevator in the building in which I live has one of those push buttons which automatically calls 911 when you are in need of assistance, like say bleeding to death or vomiting a lung, while in the elevator. Once pushed, ahem, a prerecorded voice emits, in a very computer generated manner, that sooner or later an actual 911 operator will call back and talk to you over the little speaker phone in the elevator. Hopefully, during this time, the murderer, nightmare spawned demon, Joan Rivers, or whatever, in the elevator with you has not finished eviscerating you and begun dancing around wearing your entrails as a stole, and you can gurgle out through the blood flecked foam coming out of your mouth a garbled message to be aired on the news the next day to shocked and frightened viewers.

The other day, I walked into the elevator and heard an automated and scripted telemarketer speaking through the phone is what was obviously a robotic dial of the elevator's phone number. I must say, I stood quite stunned at such a scene.

The drumming of hatred in my brain for that telemarketing company was so great, I lost my memory for the next 5 minutes. There is simply a hole in my memory now patched with a vast and incalculable rage.

End of Line.

Five or six months ago, an acquaintence of mine and I were talking on the long bus ride home. He is getting a PhD in polymers and was building a device to measure the coefficient of friction of polymers by some method where a period of oscillation of the polymer was directly proportional to its coefficient of friction.

He was lamenting about how he'd wish to have some sort of a device that would use an infrared beam and could send beam break/resume events to a computer to time the period. I told him that something like that could be made pretty easily, even by an idiot.

He looked at me with a pair of eyes that said what his mouth confirmed, "Hey, uh, could you build something like that for me?" I looked at him long and hard, remembering all of the free time I didn't have. So, I threw the Hail Mary pass, which always works in situation like this where I can politely decline when I don't think I have enough free time to do something even though I very much wanted to build this thing for him. "It'll cost you X dollars in parts and labor", I slid in under my breath. He sat in repose.

A few days later, having thought I was free from his request and greatly saddened since I really did want to build it, I had thought about it in greater depth than an OCD patient aligning 5 months worth of finger nail clippings just so on his bathroom floor. Luckily, that day he called me up and said "Ok, I'll pay you X dollars.".

Damn, I thought--here I am, ready to get into electronics and an application with funding shows up at my feet. You bet I took the job. :)

So, here is the picture of the device as I had finished it. My drill slipped a bit for one of the holes on the cover, but other than that it looks fine.

Here is a picture of the inside of the device.

Here is a picture of the device plugged in and working. The digital camera picked up the IR light and it is displayed as a lightish purple in the emitter jig. The lit red LED on the box indicates the beam is present. Also, I might add that it is not on fire.

And here is the thing which most people leave out when they put some do it yourself project on the web--Theory of Operations Document. I get so pissed off when someone has really cool pictures of some hot shit thing they made and don't have theory documents explaining them.

For projects that I make which I don't patent or don't think from which I'll make any serious money, there will be pictures and full theory/construction docs to explain them.

End of Line.

One day recently I realized that I--the product of 4.5 billion years of evolution, use my portion of the vast and bountiful power of the Sun to very carefully order magnetic field orientations on hard drives that I will never see in my life. Sometimes, I might order a few dozen thousand of them in one day--a pretty good number for pushing around little things that noone can see and are only understood by consensus.

Needless to say, and obvious to those who know me, this is depressing. I've decided that I'm going to take a break from hobby programming for a while. And when I mean hobby programming, I mean software for software's sake. Basically, any idiot can write code these days, and most idiots do, I'm afraid. Computing is so cheap at this point that some drooling moron can poke around to find a bunch of badly written libraries and cobble something together which never really works well, but always works just well enough as long as you're looking at it. The world has proven to us that this is good enough.

Frankly, most of the good stuff has been written already, and if not, it is only because it'll take thousands of man years to write the disturbingly incremental cool thing and only companies with lots of people and resources can support creating them.

What I just wrote might make it appear like I'm some naive idiot (and maybe I am, but since there is no comment feature for this blog, I'll never know). However, if one notices that an incalculable amount of man hours--probably billions, went into XML for what is, as far as I can tell, a shiny replacement for grouping things with open and close parentheses, one gets a bit sick to their stomach. How many quantum leaps of human advancement have we so carefully avoided by spending our resources so unwisely?

Much of Computer Science is like the red-headed step child in the family of Mathematics. The part that is not is detailed in Knuth's books and other founding fathers like Church and Turing. But even so, at the practical every day level, whenever a new language is designed or something, a different syntactic form with a slightly different interface of a hash table (as an example) is created. I mean, it isn't like when the Jacobian determinant was invented, you had to change the syntax and slightly alter the meaning of addition all the way down to the core. Even complex numbers, which did alter addition merely extended it into a new abstraction.

For a while I spent looking at and skimming a lot of the computational science papers from 1940 to 1975. It is surprising how many of the modern things which people re-think up in some "not invented here" orgasm was thought of, expanded upon, and moved to logical conclusion over 50 years ago. Honestly, it was simply the rise of fast machines which brought the forward thinking ideas and implementations of those far away times possible today and appear "new" to the unintiated. The web does a lot to disseminate said information to the gibbering masses, but sadly, it appears they don't read it.

Having grown tired of this problem of thinking of cool software which would take me tens of years to type in during my free time, not really finding anyone who wants to or has the ability to help, and not ever having enough money to hire people to type it in for me, I've decided to think about something else for a while.

Lately, I've arrived at the opinion that the rise of digital computers based upon boolean mathematics have stunted the field of Artificial Intelligence. A bold claim, to say the least. But of you look at the roots of AI, cognitive science, and even the underpinings of the mathematics with which we try and describe how to world behaves, you will eventually realize that the world's "nominal operating state" is not boolean arithmetic. The world is made up of frequencies, periodic waves, probability fields, differential equations on continuous manifolds, and many other analog constructs. Digital computers can deal with these things, but at a terrible cost of time for simulation and loss of complexity representation. Digital computers are rational computers, but the world is simply irrational.

So, I've decided to think/learn about and begin building analog computers and meld it with the hindsight of the last decades of computing algorithms and theory which arose while analog computers were out of favor.

These computers, at the point of mainstream abandonment in the 1970's, were left in a state where they were being created to solve systems of differential equations and feedback control problems. They still exist today and control things like oil refineries, radios, and many other things, but in my opinion they've sort of gotten into a rut in their application space. However, since I personally think systems of differential equations and control theory are fundamental components to implement meaningful AI, it is pragmatic to understand how exactly to implement complicated mathematics in analog computers. More importantly though, most of this computation happens in what amounts to real time. This is so much of an appeal to me, it is worth spending significant amounts of my life to see if analog computers can be somehow "evolved" with modern ideas.

And if I fail and nothing comes of it, so what... It is worth to try.

End of Line.

When you look at this, it is the mental equivalent of biting into an apple and only seeing half a worm.

I have the solved sudoku. Later, if I haven't forgotten, I'll put it up.

Also thanks to Alan De Smet for being so disgusted at the original sudoku HTML, that he made some CSS classes for me to use for the sudoku grid.

End of Line.