What's it all about, Alfie?

Last evening I noticed that there was a new release of GAIM - the AIM/Yahoo/MSN instant messaging client that I run all the time. I downloaded it and patched the src/perl.c file to properly work with perl 5.005_03 on Solaris. You see, perl makes an assumption about the environment array - namely, that it is mutable. On Solaris/SPARC that is not the case, and moreover, there's no documentation/reason to believe that it should be. I've talked to the Perl folks, and they've patched their code but it's still in perl 5.005_03. So, I've got a work-around that I patch into GAIM (and other code that uses this same perl plug-in feature). Then I built GAIM.

What I found was that there was an error when I ran GAIM 0.11.0pre5:

        Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
          serial 61 error_code 131 request_code 131 minor_code 2
        Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
          serial 76 error_code 131 request_code 131 minor_code 2

that I traced down to a call to XLoadQueryFont() in the stack trace:

        gdk_font_load()
        gtk_style_new()
        gtk_widget_get_default_style()
        gtk_widget_peek_style()
        gtk_widget_init()
        gtk_type_new()
        gtk_window_new()

When I stepped through the call to XLoadQueryFont() I could occaisionally get it to work - but when it did, I didn't get the proper icons on the buddy list for expanding and collapsing the groups in my buddy list. I reverted to gaim 0.11.0pre4, and everything is fine.

I've posted a message on the GAIM SourceForge page, and we'll see if anyone comes up with something. I have a feeling that it's got something to do with the more lax Linux/i86 architecture versus the SPARC/Solaris platform. I've run into this with perl, and I can easily imaging that the 0.11.0pre5 is doing something that's throwing off the subsequent call to XLoadQueryFont(). In any case, I'm back to 0.11.0pre4 and it's working very nicely. We'll see what happens when and if I get an answer from the GAIM folks.

Some days I hate DHCP and MediaOne. OK... it's not DHCP, it's just MediaOne's use of it. If I had a fixed IP address then I could possibly work up a few DNS records somewhere that would point to the machines. Why's this important? Well... without forward and reverse DNS entries sendmail won't really function. At least I've tried, and the version on Solaris 7 isn't being helpful. I went through this on my NeXTSTEP 3.3 machine and got it working but the version of sendmail is changed and the configuration changes used in the version I have on NeXTSTEP don't do what's necessary on Solaris. Not that this is that surprising, but it'd be nice if sendmail had a simple configuration file default to hand off to another SMTP server. I know I could figure it out, but it's not that important, but it is a pain.

I tried sparky, barney and mao - representing Solaris, Irix, and Linux, and on each I was unable to simply mail out of the box because of sendmail. Oh... I can do it with Netscape because it allows me to communicate directly with the SMTP server, and put in a login to that SMTP server, and while sendmail seems to allow the specification of a great number of things, these don't easily pop up to be configured.

I know that if I had proper DNS I'd be able to handle this because the default configuration of sendmail on Linux does this fine - I've got it working on another host. It's just MediaOne who isn't allowing us to register names. What a pain...

For now I'm stuck with making my own mail client and sticking with Netscape. Looking at those two opportunities, Netscape is best.

UPDATE: I found a site called easyDNS that does exactly what I need. For $55/yr I can get a domain name registered (through them) and have their DNS servers hold the DHCP addresses of my machines. There are little clients for Linux/Solaris/Windows that send any DHCP-related IP changes to their service so that their DNS is constantly being kept up to date. With this, I could easily get DNS for my machines and then sendmail would be working just fine. Certainly something to think about.

Over the weekend I spent more than a little bit of time working on getting an old Jaz drive working on barney, my SGI Indigo2 machine. The SGI FAQ says that it's as easy as pie, but what I found was something different - at least for me. In the beginning all was going well, and then I heard what I believe to be the "Click of Death". After that, nothing I could do would bring the Jaz disk to life.

When I looked inside the drive mechanism, it appears as though the drive heads had been mashed. It was the oddest sight. I have no idea what caused the problem, but I'm worried that putting a new Jaz drive on barney will only act to increase it's hunger for more drives, so I decided not to try again. Besides, I really didn't need to the Jaz drive on barney - it was just a good use of an available resource to backup important files that sat on that machine.

Then this morning I checked out a few more web sites for possible jobs. My search hasn't been as successful as I'd hoped, but thankfully there's no hurry. What I'm looking for in the meantime is an interesting project to keep my mind occupied and my skills sharp. I've been working on CIA pretty much non-stop for the last several days, and need a break. Don't know what it'll be, but I need to find something to balance it out.

I have been working on the Journal through the pgaccess interface, and while it's good enough to get the job done in a pinch, it's not nice enough for me to be able to make the kinds of updates that I want to. So... I looked into making a pgaccess form and seeing if that would solve the usability problems. No good. So I decided to see if PHP could do the trick. I was in luck.

The key for me is the security. I wanted to be able to do this on the web, but I also wanted to secure it so that I'd be the only one able to modify the journal. Thankfully, PHP gets the remote browser's IP address, and saves it. This means that my two pages - the viewer, and this, the editor, can check that address and compare it to the address of the machine on which I'll do all the updates. Then, it was a simple matter of creating this update page and enhancing the viewing page to allow for updates coming in. Pretty simple, really.

The result is that I get a very nice editor for my journal entries. I can go back and edit entries, and add new ones as I see fit. No need to worry about URLs or other problems. It's nice and clean. I think this is going to be even nicer than the older version. What a deal!

Over the course of the last two days I've been adding an edge detection filter to the cell analysis code in the hopes of being able to better identify the cell nuclei. The belief from the Guys was that an edge detector followed by the existing feature extraction would easily give us representative nuclei. What I've found is, unfortunately, not good news.

I went searching on the net for any edge detection code. What I had originally found was that most of the good code was not available for just anyone. They wanted to make a profit on it. That's understandable, but it leaves me at a disadvantage. I still needed the code. I thought of the Sobel code in The GIMP, but didn't want to deal with the GPL that comes along with it. So I went back to the web. This time I got lucky.

I found a codebase called SUSAN. I also found an implementation of the base Sobel algorithm and one called Canny. With these two I was sure I could get a working edge detector going. And I was right.

I've cleaned up the code on the SUSAN algorithm and incorporated it into the base cia code. I've added a few arguments that indicate what channels to use for the gray scale conversion, and whether or not to output the edge detected image for viewing. In all, I'm pleased with this part of the work. What isn't so pleasing is the results, or lack thereof.

It seems that it really doesn't make a difference if I use edge detection based on RGB, Hue, Red - they all give results that aren't as good as just intelligent selection of Hue or Red. This is a shame, because Richard seems to think that it's easily done with programs he has. Alas, that's not what I'm finding out.

I finally got the search and scan features working on the page. It's interesting that it's all being done with a single PHP script - doing different things based on the different user-supplied inputs. It's nice to see that I still have the chops. Small, fast, solid code that works with a variety of inputs to reach a single goal. Nice indeed.

On an historical note, I've decided not to import the diary entries from the previous incarnation of my on-line journal. There's a lot of good information in that diary, but it's almost all in relation to the projects I worked on at BankOne. And while I don't think there's a thing that's really business critical I think I'll put it off for at least a while. It's always possible to import it later, if I really feel the need.

This is interesting... I'm looking at pgaccess and seeing that it's a lot more like Microsoft's Access than I originally thought. It might be the perfect tool to build a simple little form for inputting these journal entries. I haven't worked a lot with it, but tomorrow I'll certainly play with it and see what the possibilities are. My goal is not to have a professionally done tool yet, I'm just looking to get something that automatically handles the CURRENT_TIMESTAMP so I don't have to worry about the time I enter these entries, and something where I can do a little bit of editing.

Today I finally started the second-generation of my daily journal system. I have wanted to come up with a better way to do it, and this morning it seemed like a natural to simply keep the contents of the journal in a PostgreSQL database and update it as necessary. With this structure I now have to ability to search the database, as well as not having to worry about the format of the viewing page. It's all in PHP. Excellent work.

In the future I want to create a simplified way for entering the journal entries - as opposed to using pgaccess, as well as adding search and scan capabilities to this page. For searching, I'll probably just use a character string with date limits, and for scanning I think I'll allow the user to enter date ranges and see what's in the journal between them.

I've been looking for a new position as BankOne just isn't doing it for me anymore, and I had some really good talks this afternoon. I hope they turn out to be positions similar to what First Chicago was when I joined here. That was a wonderful place spoiled by BankOne.