What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
Main | Next month (May 2004) »

20040430 Friday April 30, 2004

Randomizing a list Needing to to randomize the contents of a Perl array, I was just about to write the code myself but decided to snoop around CPAN first. Lo and behold, I found that there was something in the Perl distribution already that did what I need.

As of Perl 5.8, there's a module in the standard library with a boat load of things you need to with a list from time to time. It was nice to stumble upon the List::Util class; it's got a method called shuffle that does the trick. Here's an example of getting a randomized list using shuffle: 


use List::Util 'shuffle';

my @list = ('a'..'z');
my @shuffled = shuffle(@list); 
# @shuffled is randomized, @list is unchanged
print "@shuffled\n";
There are more useful methods like min, max and sum that should make dealing with aggregations of values much easier. ( Apr 30 2004, 11:45:45 PM PDT ) Permalink


20040419 Monday April 19, 2004

Perl6 and Apocalypse 12 Those wild and crazy guys behind Perl6 are at again. Larry Wall published "Apocalypse 12" the other day and it discusses many of the deficiencies of Perl5's object support.

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.
A little later, in discussing how roles are kinda like second class classes but not really, we see some hypothetical code:

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])
The universe is a big place. And it keeps getting bigger. I guess I'll wait for Damian Conway to chime in. If Larry Wall writes the bible; Damian has to write the talmud.
Shalom, Salaam, Shalom, Salaam ( Apr 19 2004, 11:06:01 PM PDT ) Permalink


20040412 Monday April 12, 2004

YAQPM: Debian's software package manager Over the weekend, I had my initiation with Debian's package manager(s). While I've never been in love with RPM's or Solaris packages, I wasn't particularly eager to have to contend with Yet Another Quirky Package Manager.

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