Recent blog entries for dlc

bashlib, 0.2

I'm getting ready to release another version of bashlib (finally). This one will feature an actual API (no more messing with environment variables), modeled (more or less) on the interface to Perl's CGI module.

Other projects: WebMail in Perl

I've had trouble finding a good, solid, extensible web-based mail client, written in Perl, that I'm 100% happy with. Too many are written in PHP -- I don't have a problem with PHP, but I'm a Perl programmer. I think it's a little silly to learn the ins and outs of a new language just for one application (I have no real interest in PHP, for the most part. I've found that everything PHP can do can be done in Template Toolkit under mod_perl, and faster too.) My employer is looking to possibly offer free web-based mail soon, so it looks like there may be the possibility that I will be writing one soon. It will probably be written with a database backend, and completely templatized (via Template Toolkit).
:wq

slackware 7.1

It was inevitable, I suppose -- I started with Slackware GNU/Linux four years ago, and I've come back to it now. I must installed Slackware 7.1 on my laptop (I clobbered Debian 2.2 to do it), and I'm pretty happy with it. Almost every disctribution that I've tried has required that I install additional packages to get things like VIM to build (I like to embed Perl in my VIM, so I always need to rebuild it when I setup a new machine), but with Slackware, it worked right away, with the default install. Sweeet.

packaging systems, and reading code

All the talk lately of packaging systems got me thinking about them, and, of the three that I have used (rpm, deb, and slackware's tgz), I have to say that I prefer the slackware style tarballs. This is mainly, I believe, because I like to handle dependencies manually; I have a terrible habit of trying to read through the code for everything I install (or as much as is reasonable). This is one of the reasons that binary distributions of anything annoy me; I think that any packaging system "standard" should mandate the inclusion of source code as part of the package. Binaries go into /usr/bin, man pages into /usr/man, source into /usr/src.

:wq

20 Sep 2000 (updated 26 Dec 2000 at 20:18 UTC) »

ActiveState

I have to hand it to ActiveState -- I think they've done a pretty good job packaging up Perl into ActivePerl. I just grabbed and installed the latest build for my wife's Win95 box, and I'm pretty impressed. I even went so far as to download the .deb of 5.6.0 for my Potato box, and I'm really quite impressed. They've done a good job of packaging many of the groovier modules, like libnet and libwww, and the XML::Parser stuff, and they've come a long way since the 500 versions, which were the last ActivePerls I used regularly.

Writing

I've been trying my hand at writing lately; I just finished an article about compiling Apache, and the various standard modules. I am currently writing an article about using Perl to do interesting things with the RSS files that everyone and their mother seems to be publishing nowadays (have you seen GeekBoys?). Here's a hint -- it will involve Perl, XML::RSS, and DBI/DBD::mysql. I think it's coming along nicely. Hopefully I'll be able to post a draft on Advogato, if I get certified as something other than an Observer soon. It is based on a few modules and scripts that I use on my own box, but cleaned up and de-idiosyncratized (is that a word? Is that even a concept?) so they will be readable and usable by someone other than me.

bashlib

I realized yesterday that one of the key things bashlib is missing is a templating system. Well, other than a usable API, the main thing it's missing is a tem-- oh yeah, it's also missing users. But of the three main things that bashlib is missing, a way to implement a templating system occured to me last night. It mostly awk, and a little bit sed. I wonder, has anyone else done anything like this, using common shell tools? I haven't to date been able to find anything on the web. Or should I take that as a hint...?

bashdot

The idea for bashlib arose out of a pissing contest at work (we take turns coming up with the most off the wall ideas we can, and then try to implement them); I won this one, by declaring I was going to rewrite Slashdot in bash, and call it bashdot. (This was right after the first release version (0.9) of the Slash code, and, since we are all Perl programmers, we were a little (!) disgusted with it.) Any large scale project needs libraries, of course, and so bashlib was born. In time, bashlib may evolve into bashdot, but I, for one, and not holding my breath.

Happy Birthday, Casey!

On a personal note, my son turns 1 year old today (Wednesday). Happy birthday, Casey! Daddy loves you!

I noticed that a slew of debian developers joined recently. I wonder what happened that they all took notice of Advogato at once?

19 Sep 2000 (updated 19 Sep 2000 at 03:13 UTC) »

First diary entry; I don't know what to say. I guess I'll just talk about what I've been doing at work, and use that as an introduction.

I spent a few weeks writing a Perl module to do threaded discussions, which runs as a subrequest under Apache/mod_perl with a mysql backend. It came together very well, under 1000 lines of code, including the web-based administration interface, all the templates (Template Toolkit), and more documentation that the code warrants. But the higher-ups decided against using it -- we're going to go with a separate product, made by another company that we happen to own, so now I have all this code, just waiting to be used. I am waiting for the go ahead to Open Source it; it's already been discussed, in passing, and is probably going to happen soon. Now all I need is a name for it...

I installed OpenBSD 2.7 for the first time the other day, on a Sparc 4. It went surprisingly well; I was expecting some difficulties, and had none. The problems arose after the install was completed, and the machine was up and running -- there are many fewer ports available for OpenBSD on sparc than there are for OpenBSD on other architecures. It ran quite well, despite its older processor. It does have 128 Megs of RAM, which I'm sure helped quite a bit. The only thing that was slow enough to worry me was the key generation on the initial boot.

Normally a lack of prepackaged applications wouldn't be a problem for me (I'm not afraid of my compiler), but the packages I wanted to install (vim 5.7, specifically) was giving me many problems (they looked like problems with the curses library, but I haven't followed up on them yet). I have yet to begin looking for the answer; with any luck, its a well-known one. Once I get it to compile, I'll see about contributing the port back to OpenBSD.

I've been neglecting my other projects, especially bashlib (a cgi library written in bash). My plans for the immediate future include doing an update to the bashlib code -- I want to add an API, rather than just make the user play with raw environment variables. Perhaps some HTML generation routines, in a separate source file.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!