Monday April 19, 2004

There are a lot of funky things about Perl5. Paradoxically, sometimes these are beautiful things as well. But oftentimes, they're just funky. As I've said before "I suspect with Perl 6, I'll only hate it on Tuesdays". I could rag about the weak encapsulation and the lack of useful method signature support in Perl5. But since I've really come to love Java's use of interfaces to compose an object's capabilities and disallowed multiple inheritance, I was interested in reading about Perl6's roles. Yes, in Perl6 a class can have a bunch of different roles. Here's a little bit of Larry from Apocalypse 12:

Roles can encompass both interface and implementation of object relationships. A role without implementation degenerates to an interface. A role without interface degenerates to privately instantiated generics. But the typical role will provide both interface and at least a default implementation.

If you want to parameterize the initial value of a role attribute, be sure to put a colon if you don't want the parameter to be considered part of the long name:

    role Pet[IDholder $id: $tag] {
        has IDholder $.collar .= new($tag);
    }
    class Dog does Pet[Collar, DogLicense("fido")] {...}
    class Pigeon does Pet[LegBand, RacerId()] {...}
    my $dog = new Dog;
    my $pigeon = new Pigeon;

In which case the long names of the roles in question are Pet[Collar] and Pet[LegBand]. In which case all of these are true:

    $dog.does(Dog)
    $dog.does(Pet)
    $dog.does(Pet[Collar])

but this is false:

    $dog.does(Pet[LegBand])

Monday April 12, 2004

At first I started messing around with Debian's vt100 utility, dselect (which it turns out is just a cheesey wrapper around dpkg) hoping to find something of the same caliber of the FreeBSD's package manager. 90% of the time, the FreeBSD tool won't give you too many surprises, it JFW's. I was not so lucky with dselect, what a POS! If you misfire some selection keystrokes and then leave your dselect session, you'll never be able to just undo what was there -- you can item-by-item set flags to "hold" the current state of individual packages but there's no way to just say, "the current state of the packages is how it is, don't flag anything for installation, removal, holding or whatever."

In the end, I read the man pages for apt-get and apt-cache; between the two of them, it looks like everything you'd want as far as package management tasks are available. My next foible was realizing that an installation can have a mix of packages from stable and the amusingly named unstable streams of Debian's deliberate development branches. Geez, I just needed libperl5.8 so I could compile something that embedded perl but the requirement to go to a different branch wasn't readily apparent from the dpkg -l listing (i.e. it required poking around a little research to discover that unlike the rest of the stable goodies, perl-base was from unstable).

And while I'm bitchin about how braindead linux distro's can get, what's with having libraries and header files in separate packages? What's I recall being so righteous about FreeBSD's ports-n-packages was that when you installed, say, zlib, you got the libraries and the headers -- there should be no need to install zlib-dev or something just to get the header files! What, are we concerned about diskspace usage? Why not just install the ding dang headers with the base package??

I remember a few years ago celebrating the news that the Open Packages project was going to bring the ports-n-packages thing of beauty to Linux and hopefully do for Linux what it'd been done for the BSD's a long time ago: a consistent, reliable and yet flexible package management system. IMO, RPM, Debian packages and Solaris packages all fall short. ( Apr 12 2004, 09:03:53 PM PDT ) Permalink

Friday March 26, 2004

The first one was a little bit about tricks with server side includes ("SSI's") and some of the crude things you can accomplish with them that, while falling short of a "real" programming language, are surprisingly powerful. The browser detection stuff is very old and yet still very pertinent today when folks want to determine on the server side which CSS style sheet to send the browser. The other HOWTO is some notes I'd had about messing with HTTP cookies.

So I performed some minor updates on these things and reposted them:

Thursday March 18, 2004

It's definitely a case of the something old/something new/something barrowed/something blue... there's a lot of stuff in Perl6 to like and yet it seems like some of the opportunity to unclutter the language appears to have passed us by.

Oh, darn.

Anyway, my thoughts on the matter are captured here ( Mar 18 2004, 08:41:25 PM PST ) Permalink

Tuesday March 16, 2004

Here's the deal:
The tutorial covered SOAP interoperability between implementations in Java (using Apache Axis) and Perl (using SOAP::Lite). Some components on the Perl side required writing a few little modules. Nothing CPAN-worthy but still I wanted to package the modules nicely so users of the code samples can get the Perl side running without a lot of hand-work.

I read the man page for h2xs, the perldoc for ExtUtils::MakeMaker, I grabbed ExtUtils::ModuleMaker off of the CPAN and checked out it's docs ...the latter seems like an improvement but my needs were, IMO, real simple and I just wanted an appropriately simple set of steps. In the end, I followed a procedure similar to the one described here, bascially bootstrapping the package with structure with h2xs and manually tweaking the file system layout into something nice. Makes me wish Perl had a well defined self contained packaging structure similar to Java's jars.

Of course, then I'd want ant implemented in Perl to handle the packaging! So it goes. At the end of the day, the tutorial is at last online. ( Mar 16 2004, 09:14:49 AM PST ) Permalink

Friday February 27, 2004

I'd installed RH9 on a box for a specialized use (a reverse proxy server built on mod_perl 2.0). It's basic deployment requirement was simply that it'd sit in the server room on a rack (i.e. headless). Everything went fine on the system installation and the software that I setup thereafter. However, after I racked it and put a little startup script in /etc/rc.d/init.d for the mod_perl instance I'd deployed, I rebooted it in it's "production" mode i.e. without any input devices attached. Lo and behold, it hung with a message about the power management stuff, something like
apm: BIOS version 1.2 Flags 0x03 ...
[it just stops there ]
So I set out to recompile the kernel. Since I don't do these kinds of things regularly anymore, I had to poke around and read through the procedures. Just for posterity's sake, this is what I did:

• cd /usr/src/linux-2.4
• make mrproper
• make menuconfig (de-selected APM and some other unneeded junk like sound support)
• make dep
• make clean
• make bzImage
• make modules
• make modules_install
• make install
• /sbin/mkinitrd /boot/initrd-2.4.20-6-noapm.img 2.4.20-6
• cat /boot/grub/grub.conf (checkout the filenames so I know what to use for the next command)
• /sbin/grubby --set-default=/vmlinuz-2.4.20-6custom
• reboot

I used use FreeBSD for everything I possibly could. It's been a few years since I've had to custom build kernels for BSD but I recall the process being super straight forward; the amount of dickering around with different configuration tools was nil -- just edit a kernel config file and go compile that suckah.

I miss that. Unfortunately, all of the work that I do with Java is not compatible with sticking with BSD; my work is tuxified. If fortune shines upon me, my work in the future will be on Mac OS X where: no kernel dickering should ever be needed, it's BSD and it's slick. ( Feb 27 2004, 11:29:15 AM PST ) Permalink