Just a Theory

Black lives matter

Tune in Tonight

I’ll be on the radio show Online Tonight with David Lawrence, tonight, in the 11 EST / 8 PST slot. We’ll be discussing Bricolage, its history, and content management in general. This is my first time on the radio, so it should be interesting. The show is a light, humor-oriented tech talk show, and is, along with Online Today, “the most listened to high-tech-oriented talk show on the air today,” according to CNET Radio.

Be sure to tune in, and feel free to call in and show your support for Perl-based applications! Or send IMs to me or to host David Lawrence during the show.

Originally published on use Perl;


Hey, look everybody, I’m officially a pundit!

Originally published on use Perl;

My Adventures with Mac OS X

I recently decided to make the leap from Yellow Dog Linux to Mac OS X on my Titanium PowerBook. Getting everything to work the way I wanted proved to be a challenge, but well worth it. This document outlines all that I learned, so that neither you nor I will have to experience such pain again. The overall goal was to get Bricolage up and running, figuring that if it worked, then just about any mod_perl based solution would run. I’m happy to say that I was ultimately successful. You can be, too.

In the descriptions below, I provide links to download the software you’ll need, as well as the shell commands I used to compile and install each package. In all cases (except for the installation of the Developer Tools), I saved each package’s sources to /usr/local/src and gunzipped and untarred them there. I also carried out each step as root, by running sudo -s. If you’re not comfortable using a Unix shell, you might want to read up on it, first. All of my examples also assume a sh-compatible shell, such as bash or zsh. Fortunately, zsh comes with OS X, so you can just enable it for yourself in NetInfo Manager by setting users -> <username> -> shell to “/bin/zsh”, where <username> is your user name.

Developer Tools

All of the software that I describe installing below must be compiled. To compile software on Mac OS X, you need to install the Mac OS X Developer Tools. These provide the cc compiler and many required libraries. Conveniently, these come on a CD-ROM with the Mac OS X Version 10.1 upgrade kit. I just popped in the CD and installed them like you’d install any other OS X software. I needed administrative access to OS X to install the Developer Tools (or, indeed, to install any of the other software I describe below), but otherwise it posed no problems.

The best time to install the Developer Tools is immediately after upgrading to OS X version 10.1. Then run the Software Update applet in the System preferences to get your system completely up-to-date. By the time I was done, I had the system updated to version 10.1.3.


The first step I took in the process of moving to OS X was to get working the tools I needed most. Essentially, what this meant was GNU Emacs. Now I happen to be a fan of the X version of Emacs – not XEmacs, but GNU Emacs with X support built in. I wasn’t relishing the idea of having to install X on OS X (although there are XFree86 ports that do this), so I was really pleased to discover the Mac-Emacs project. All I had to do was patch the GNU Emacs 21.1 sources and compile them, and I was ready to go! GNU Emacs works beautifully with the OS X Aqua interface.

There were a few configuration issues for me to work out, however. I have become addicted to the green background that an old RedHat .XConfig file had set, and I wanted this feature in OS X, too. Plus, the default font was really ugly (well, too big, really – anyone know how to make it smaller in Emacs?) and the Mac command key was working as the Emacs META key, rather than the option key. So I poked around the net until I found the settings I needed and put them into my .emacs file:

'(default ((t (:stipple nil
  :background "DarkSlateGrey"
  :foreground "Wheat"
  :inverse-video nil
  :box nil
  :strike-through nil
  :overline nil
  :underline nil
  :slant normal
  :weight normal
  :height 116
  :width normal
  :family "apple-andale mono"))))
'(cursor ((t (:background "Wheat"))))
; Use option for the meta key.
(setq mac-command-key-is-meta nil)

Installing Emacs is not required for installing any of the other packages described below – it just happens to be my favorite text editor and IDE. So I don’t provide the instructions here; the Mac-Emacs project does a plenty good job. If you’re not comfortable with Unix editors, you can use whatever editor you like. BBEdit is a good choice.


Mac OS X doesn’t come with a DBM! But since mod_ssl needs it, we have to install it. Fortunately, I found this PDF detailing someone else’s adventures with mod_ssl on OS X, and it provided decent instructions for installing GDBM. First, I created a new user for GDBM. In NetInfoManager, I created a duplicate of the “unknown” user and named it “bin”. Then, I downloaded GDBM from the FSF, and installed it like this:

cd /usr/local/src/gdbm-1.8.0
cp /usr/libexec/config* .
make install
ln -s /usr/local/lib/libgdbm.a /usr/local/lib/libdbm.a

That did the trick. Nothing else was involved, fortunately.


Who doesn’t do something with XML these days? If your answer is, “not me!”, then you’ll need to install the Expat library in order to work with XML::Parser in Perl. Fortunately it’s relatively easy to install, although support for the -static flag appears to be broken in cc on OS X, so it needs to be stripped out. I downloaded it from its project bpage, and then did this:

cd /usr/local/src/expat-1.95.2
perl -i.bak -p -e \
  's/LDFLAGS\s*=\s*-static/LDFLAGS=/' \
perl -i.bak -p -e \
    's/LDFLAGS\s*=\s*-static/LDFLAGS=/' \
make install


Although Mac OS X ships with Perl (Yay!), it’s the older 5.6.0 version. There have been many bug fixes included in 5.6.1, so I wanted to make sure I got the latest stable version before I built anything else around it (mod_perl, modules, etc.).

Being a Unix program, Perl doesn’t expect to run into the problems associated with a case-insensitive file system like that Mac OS X’s HFS Plus. So there are a couple of tweaks to the install process that make it slightly more complicated than you would typically expect. Fortunately, many have preceded us in doing this, and the work-arounds are well-known. Basically, it comes down to this:

cd /usr/local/src/perl-5.6.1/
export LC_ALL=C
export LANG=en_US
perl -i.bak -p -e 's|Local/Library|Library|g' hints/darwin.sh
sh Configure -des -Dfirstmakefile=GNUmakefile -Dldflags="-flat_namespace"
make test
make install

There were a few errors during make test, but none of them seems to be significant. Hopefully, in the next version of Perl, the build will work just as it does on other platforms.


Before installing Open SSL, mod_ssl, mod_perl, and Apache, I needed to get all the right pieces in place. The mod_ssl and mod_perl configure processes patch the Apache sources, so the Apache sources have to be downloaded and gunzipped and untarred into an adjacent directory. Furthermore, the mod_ssl version number corresponds to the Apache version number, so you have to be sure that they match up. Normally, I would just download the latest versions of all of these pieces and run with it.

However, Bricolage requires the libapreq library and its supporting Perl modules to run, and these libraries have not yet been successfully ported to Mac OS X. But worry not; fearless mod_perl hackers are working on the problem even as we speak, and there is an interim solution to get everything working.

As of this writing, the latest version of Apache is 1.3.24. But because I needed libapreq, I had to use an experimental version of Apache modified to statically compile in libapreq. Currently, only version 1.3.23 has been patched for libapreq, so that’s what I had to use. I discovered this experimental path thanks to a discussion on the Mac OS X Perl mail list.

So essentially what I did was download the experimental apache.tar.gz and the experimental lightweight apreq.tar.gz packages and gunzip and untar them into /usr/local/src. Then I was ready to move on to Open SSL, mod_ssl, and mod_perl.

Open SSL

Compiling Open SSL was pretty painless. One of the tests fails, but it all seems to work out, anyway. I download the sources from the Open SSL site, and did this:

cd /usr/local/src/openssl-0.9.6c
make test


The mod_ssl Apache module poses no problems whatsoever. I simply downloaded mod_ssl-2.8.7-1.3.23 from the mod_ssl site (note that the “1.3.23” at the end matches the version of Apache I downloaded) and gunzipped and untarred it into /usr/local/src/. Then I simply excuted:

./configure --with-apache=/usr/local/src/apache_1.3.23


Configuring and installing mod_ssl was, fortunately, a relatively straight-forward process. Getting Apache compiled with mod_perl and mod_ssl, however, was quite tricky, as you’ll see below. A number of braver folks than I have preceded me in installing mod_perl, so I was able to rely on their hard-earned knowledge to get the job done. For example, Randal Schwartz posted instructions to the mod_perl mail list, and his instructions worked well for me. So I downloaded the sources from the mod_perl site, and did this:

cd /usr/local/src/mod_perl-1.26
perl Makefile.PL \
  APACHE_SRC=/usr/local/src/apache_1.3.23/src \
  NO_HTTPD=1 \
make install


Getting Apache compiled just right was the most time-consuming part of this process for me. Although many had gone before me in this task, everybody seems to do it differently. I had become accustomed to just allowing Apache to use most of its defaults when I compiled under Linux, but now I was getting all kinds of errors while following different instructions from different authorities from around the web. Sometimes Apache wouldn’t compile at all, and I’d get strange errors. Other times it would compile, pass all of its tests, and install, only to offer up errors such as

dyld: /usr/local/apache/bin/httpd Undefined symbols: _log_config_module

when I tried to start it. It turns out that the problem there was that I had a number of modules compiled as DSOs – that is, libraries that can be loaded into Apache dynamically – but wasn’t loading them properly in my httpd.conf. This was mainly because I’ve grown accustomed to Apache having all the libraries I needed compiled in statically, so I simply didn’t have to worry about them.

But I finally hit on the right incantation to get Apache to compile with everything I need added statically, but still with support for DSOs by compiling in mod_so. I present it here for your viewing pleasure:

SSL_BASE=/usr/local/src/openssl-0.9.6c/ \
  ./configure \
  --with-layout=Apache \
  --enable-module=ssl \
  --enable-module=rewrite \
  --enable-module=so \
  --activate-module=src/modules/perl/libperl.a \
  --disable-shared=perl \
make certificate TYPE=custom 
make install

This series of commands successfully compiled Apache with mod_perl and mod_ssl support statically compiled in, along with most of the other default modules that come with Apache. In short, everything is there that you need to run a major application with security such as Bricolage.

Note that make certificate will lead you through the process of creating an SSL certificate. I like to use the “custom” type so that it reflects the name of my organization. But you can use whatever approach you’re most comfortable with. Consult the mod_ssl INSTALL file for more information.


Once Apache is installed with mod_perl and mod_ssl, the rest is gravy! The experimental libapreq library I downloaded installed without a hitch:

cd /usr/local/src/httpd-apreq
perl Makefile.PL
make install


PostgreSQL is a sophisticated open-source Object-Relational DBMS. I use it a lot in my application development, and it, too, is required by Bricolage. I was a bit concerned about how well it would compile and work on Mac OS X, but I needn’t have worried. First of all, Apple has provided some pretty decent instructions. Although they mainly document how to install MySQL, a competing open-source RDBMS, many of the same concepts apply to PostgreSQL.

The first thing I had to do was to create the “postgres” user. This is the system user that PostgreSQL typically runs as. I followed Apple’s instructions, using NetInfo Manager to duplicate the default “www” group and “www” user and give the copies the name “postgres” and a new gid and uid, respectively.

Next I downloaded the PostgreSQL version 7.2.1 sources. Version 7.2 is the first to specifically support Mac OS X, so going about the install was as simple as it is on any Unix system:

./configure --enable-multibyte=UNICODE
make install

That was it! PostgreSQL was now installed. Next I had to initialize the PostgreSQL database directory. Again, this works much the same as it does on any Unix system:

sudo -u postgres /usr/local/pgsql/bin/initdb \
  -D /usr/local/pgsql/data

The final step was to start PostgreSQL and try to connect to it:

sudo -u postgres /usr/local/pgsql/bin/pg_ctl start \
  -D /usr/local/pgsql/data /usr/local/pgsql/bin/psql -U postgres template1

If you follow the above steps and find yourself at a psql prompt, you’re in business! Because I tend to use PostgreSQL over TCP, I also enabled TCP connectivity by enabling the “tcpip_socket” option in the postgresql.conf file in the data directory created by initdb:

tcpip_socket = true

If you’re like me, you like to have servers such as PostgreSQL start when your computer starts. I enabled this by creating a Mac OS X PostgreSQL startup bundle. It may or may not be included in a future version of PostgreSQL, but in the meantime, you can download it from here. Simply download it, gunzip and untar it into /Library/StartupItems, restart OS X, and you’ll see it start up during the normal Mac OS X startup sequence. I built this startup bundle by borrowing from the existing FreeBSD PostgreSQL startup script, the Apache startup script that ships with OS X, and by reading the Creating SystemStarter Startup Item Bundles HOWTO.


At this point, I had most

of the major pieces in place, and it was time for me to install the Perl modules I needed. First up was XML::Parser. For some reason, XML::Parser can’t find the expat libraries, even though the location in which I installed them is pretty common. I got around this by installing XML::Parser like this:

perl Makefile.PL EXPATLIBPATH=/usr/local/lib \
make test
make install


In Bricolage, Text::Iconv does all the work of converting text between character sets. This is because all of the data is stored in the database in Unicode, but we wanted to allow users to use the character set with which they’re accustomed in the UI. So I needed to install Text::Iconv. Naturally, Mac OS X doesn’t come with libiconv – a library on which Text::Iconv depends – so I had to install it. Fortunately, it was a simple process to download it and do a normal build:

cd /usr/local/src/libiconv-1.7
make install

Now, Text::Iconv itself was a little more problematic. You have to tell it to look for libiconv by adding the -liconv option to the LIBS key in Makefile.PL. I’ve simplified doing this with the usual Perl magic:

perl -i.bak -p -e \
  "s/'LIBS'\s*=>\s*\[''\]/'LIBS' => \['-liconv'\]/" \
perl Makefile.PL
make test
make install


Although the DBI installed via the CPAN module without problem, DBD::Pg wanted to play a little less nice. Of course I specified the proper environment variables to install it (anyone know why DBD::Pg’s Makefile.PL script can’t try to figure those out on its own?), but still I got this error during make:

/usr/bin/ld: table of contents for archive:
/usr/local/pgsql/lib/libpq.a is out of date;
rerun  ranlib(1) (can't load from it)

But this was one of those unusual situations in which the error message was helpful. So I took the error message’s advice, and successfully compiled and installed DBD::Pg like this:

ranlib /usr/local/pgsql/lib/libpq.a
export POSTGRES_INCLUDE=/usr/local/pgsql/include
export POSTGRES_LIB=/usr/local/pgsql/lib
perl Makefile.PL
make test
make install


The last piece I needed to worry about customizing when I installed it was LWP. Before installing, back up /usr/bin/head. The reason for this is that LWP will install /usr/bin/HEAD, and because HFS Plus is a case-insensitive file system, it’ll overwrite /usr/bin/head! This is a pretty significant issue, since many configure scripts use /usr/bin/head. So after installing LWP, move /usr/bin/HEAD, GET, & POST to /usr/local/bin. Also move /usr/bin/lwp* to /usr/local/bin. Then move your backed-up copy of head back to /usr/bin.

Naturally, I didn’t realize that this was necessary until it was too late. I installed LWP with the CPAN module, and it wiped out /usr/bin/head. Fortunately, all was not lost (though it took me a while to figure out why my Apache compiles were failing!): I was able to restore head by copying it from the Mac OS X installer CD. I Just popped it in an executed the command:

cp "/Volumes/Mac OS X Install CD/usr/bin/head" /usr/bin

And then everything was happy again.


And finally, the pièce de résistance: Bricolage! All of the other required Perl modules installed fine from Bundle::Bricolage:

perl -MCPAN -e 'install Bundle::Bricolage'

Then I simply followed the directions in Bricolage’s INSTALL file, and started ’er up! I would document those steps here, but the install process is currently in flux and likely to change soon. The INSTALL file should always be current, however – check it out!

To Be Continued

No doubt my adventures with Unix tools on Mac OS X are far from over. I’ve reported to various authors on the issues I’ve described above, and most will soon be releasing new versions to address those issues. As they do, I’ll endeavor to keep this page up-to-date. In the meantime, I am thoroughly enjoying working with the first really solid OS that Apple has released in years, and thrilled that I can finally have the best of both worlds: a good, reliable, and elegant UI, and all the Unix power tools I can stand! I hope you do, too.

Looking for the comments? Try the old layout.


So last week, I decided it was finally time to put an end to my years-long mental block and learn some C. Because I’m a crazy bastard, I decided to do so by writing a new DBI driver for PostgreSQL. The existing PostgreSQL driver, DBD::Pg, is a mess, and since it would be harder for me to just jump in and start patching, I decided to follow the instructions in DBI::DBD and start cutting and pasting a brand new driver.

It’s been a great experience for me so far, mostly because of the tremendous support I’ve received from the denizens of the dbi-dev mail list. If it wasn’t for the great answers that so many of them have taken the time to write, I would be getting more sleep at night, but wouldn’t be learning half as much, either!

Speaking of not sleeping, I was in Florida for a business meeting for one night on Tuesday, and I sat up late with Comedy Central on, studying the sources for DBD::ODBC, DBD::mysql, and DBD::Oracle, trying to wrap my brain around the peculiarities of C and XS programming. I was completely absorbed in what I was doing, and thinking a lot about how to parse SQL strings in C. I finally went to bed around 3 am (it was only midnight my time, after all), but lay awake for another hour, parsing SQL character arrays, moving pointers around, trying to identify comments and literals. When I did sleep, I dreamed in C.

What a nightmare.

Now, when I was first really learning Perl, and working very intently in it for hours and days at a time, trying to grok what I was seeing, it was a wondrous path of discovery. Perl is such a rewarding language to learn; it thinks like I think. I even had a few dreams in Perl. Its expressiveness was enjoyable in my dreams. I could communicate in Perl.

Not so with C. In my C dreams, things were rigid and structured, and didn’t always seem so consistent. I was just parsing, parsing, parsing character arrays all night, and desperately needing a good regex to do the job for me. Needless to say, I didn’t sleep well.

I’m going to continue working on my new PostgreSQL driver. I want to make it a top-notch DBI driver implementation. It’s going to take me a few months, but I look forward to the rewards. But, I think, I shan’t be working on it quite so intensely just before turning in late at night any more, especially on those nights when I have to get up in only three hours.

Originally published on use Perl;

Build Apache/mod_perl on Mac OS X

I wrote an article describing how.

Originally published on use Perl;

Voting Irregularities

I voted this morning, but it wasn’t easy. I encountered a series of problems as I went about my civic duty. As a result, I was extremely disappointed with the election system set up here in San Francisco.

My wife Julie and I headed to the polls around 9:30 this morning. We’d read the (long) ballot, made our choices, and were ready to cast our votes. Since we moved into the neighborhood last February, we didn’t know where the polling station was, but I got the address off the sample ballot The City had sent me.

We walked the two blocks to the address, 360 Fourth Street, where we found the door locked. A sign outside notified us that, due to situations outside The City’s control, the polling station had moved to “36 Bluxome Street (Firehouse).” There were no directions, no cross streets listed.

This was the first problem we ran into. Although The City had sent out a post card notifying us of the new address, I had never seen it, and didn’t realize there was a new address. My wife knew about it, but didn’t realize that I hadn’t seen the card and got the address from the sample ballot. That was a screw-up on my part, but I wonder how many other people misplaced that card or never got it? How many people were going to show up at 360 Fourth Street only to find the address had changed, and have no idea where to find the new address? There are a lot of senior citizen residences in the neighborhood, so I wouldn’t be surprised if there weren’t a fair number of people who were confused about the address change and then didn’t know how or where to find the new polling station.

But that’s not the worst of it. Julie and I consulted a map in a bus shelter, and after studying it for a few minutes, saw that Bluxome was between Brannan and Townsend, near Fifth. So we walked up Harrison to Fifth, then the two and a half blocks to Bluxome. Here we encountered problem number two: There were no street signs for Bluxome! Neither were there signs indicating that there was a polling station nearby. On foot, we could see the name of the street imprinted into the sidewalk, but commuters in their cars were out of luck. There’s just no excuse for placing a polling station on an unmarked street – especially when it’s a new, last-minute location for a polling station.

Julie and I walked first one way down Bluxome, then the other, when we realized that we were going the wrong way. The firehouse, it turns out, is almost back to Fourth Street. We had gone a full block out of our way. Had there been directions (or even cross-streets!) on the sign at the old polling station address, we wouldn’t have taken such a circuitous route.

Once at the polling station, we encountered problem number three: They didn’t have our names on their list. The station workers, who were friendly though mostly inexperienced, started to tell us that we needed to go to another polling station at the Salvation Army on Shipley – right next door to 360 Fourth Street! In other words, if our names were on the lists at the Salvation Army, then either a) our sample ballot had listed the wrong polling address for us, or b) the sign at 360 Fourth Street was mistaken. The former seems likely, since the workers at the firehouse on Bluxome had worked at 360 Fourth Street last spring. But either way, we ended up sent to the wrong polling station.

Fortunately, one of the poll workers seemed a little more experienced than the others, and he had us fill out ballots and put them in special envelopes on which we wrote our addresses and he marked the box labeled “Claims to be registered” or some such. We filled out our ballots, turned them in, and he sealed them. I’m hoping that The City will successfully confirm that we are in fact registered and count our votes, but I’m becoming increasingly doubtful it’ll happen. Some ballots were found floating in the Bay last November, and that doesn’t set a very healthy precedent.

The last thing I did was to ask how to formally file a complaint regarding these voting problems. I was somewhat annoyed to have been inconvenienced by this ordeal, but far more concerned that others might have more difficulty – particularly those for whom English isn’t their first language, or for the many seniors in our neighborhood who might more easily be confused that I am. How many of them would simply give up and not vote? I wanted to make these issues known to The City, to at least alert them ASAP to these voting problems.

But then I was told that there is no formal process – I just have to contact City Hall directly. What?? That’s right, there’s no formal procedure to let City Hall know that there were problems – despite the fact that there have been serious voting irregularities here in the past. “That’s city hall for ya,” the poll worker told me.

What I think I’ll do now is send a letter to The Chronicle as well as to City Hall, describing all the problems I’ve narrated here. In this day and age, there’s simply no excuse for this kind of incompetence. It’s hard enough getting a good voter turnout each November without these kinds of logistical problems fouling up the process. In a city as liberal as San Francisco, where voting is considered so important, where high voter turnouts tends to push a liberal agenda, it’s simply reprehensible that The City has to make voting harder than it should be.

Originally published on use Perl;

Bricolage at SV.pm

Just wanted to post a quick note to let everyone know that I’ll be doing a presentation on Bricolage for the Silicon Valley Perl Mongers this Tuesday, 5 November 2002, at 7 pm. I’ll be explaining what Bricolage is all about, why it’s so cool, and doing a demo of document design and template development. Come check it out. Interested? Grab the directions and come on out!

Originally published on use Perl;

The eWeek Effect

Up, up, and away!

Originally published on use Perl;

Bricolage in eWeek

To my utter amazement and delight, eWeek, the weekly IT newspaper from ZD, has posted a review of Bricolage! I had never heard from them, or even noticed that they were interested, but am delighted with the review. It could not be more glowing. Here’s an excerpt:

However, an open-source content management system called Bricolage bucks this trend, providing an open option that isn’t just capable but is one of the best content management systems eWeek Labs has seen, even eclipsing some of the best-known commercial products.

I’m hoping that this has ramifications for getting the message out about Bricolage. I think it’s time for me to start thinking seriously about creating commercial support contracts to sell similar to what Best Practical is doing for RT.

Originally published on use Perl;

OSXCon Slides

I’ve converted the slides from my Mac OS X Conference presentation to PDF and put them on my web site. Check ’em out!

Originally published on use Perl;

Chimera Fonts

Chimera is finally working for me on Jaguar with the new 0.05 release. It’s really nice to use, compared to Mozilla or most other browsers. However, the font sizes were all whacked out on my TiBook. Using Bricolage, a lot of the type was so small that it was almost unreadable. This seemed strange to me, since Bricolage detects Chimera as Mozilla (Gecko), and sets the font sizes appropriately.

The solution turns out to be simple, and I pass it on here for the benefit of my fellow Mac OS X junkies who want to use Chimera. You simply have to edit your prefs.js file, which you’ll find in ~/Library/Application Support/Chimera/Profiles/default/foo.slt/, where foo.slt is a salted directory name. So just open up prefs.js and add this line:

user_pref("browser.display.screen_resolution", 96);

After quitting and restarting Chimera, the font sizes will once again render just as they do in Mozilla.

Originally published on use Perl;

Bricolage 1.4.0

It was a good feeling to finally get Bricolage version 1.4.0 out the door. I’ve been saying for months that it would be released “in a few weeks.” Now I’m no longer a liar.

All the important details are in the use Perl announcement. But I’m really pleased with it. Bricolage has come a long way since its initial release, and it’s all for the better. At least one user has already sung its praises, and my hope is that, as more people start to use it, there will be more contributions and it will continue to acquire great new features and perform better and better.

On tap for the next release are more new features, plus the addition of comprehensive unit testing based on Test::Class. The framework for this is already in CVS, and I’m working on new features even as we speak!

Originally published on use Perl;

DBI Exceptions

A couple of weeks ago, I wrote and uploaded a new module to the CPAN, Exception::Class::DBI. This module subclasses Dave Rolsky’s great Exception::Class module to provide DBI-specific exceptions for all you DBI users out there. I’ve done my best to make it easy to use, too. Here’s an example cribbed from the synopsis:

use DBI;
use Exception::Class::DBI;

my $dbh = DBI->connect( $data_source, $username, $auth,
                        { PrintError => 0,
                          RaiseError => 0,
                          HandleError => Exception::Class::DBI->handler

eval { $dbh->do($sql) };

if (my $ex = $@) {
    print STDERR "DBI Exception:\n";
    print STDERR "  Exception Type: ", ref $ex, "\n";
    print STDERR "  Error: ", $ex->error, "\n";
    print STDERR "  Err: ", $ex->err, "\n";
    print STDERR "  Errstr: " $ex->errstr, "\n";
    print STDERR "  State: ", $ex->state, "\n";
    my $ret = $ex->retval;
    $ret = 'undef' unless defined $ret;
    print STDERR "  Return Value: $ret\n";

Not too bad, eh? Unfortunately, there are a few issues. What the module does is grab all of the relevant DBI attributes that it can. Unfortunately, however, not all of the attributes are fully implemented by all drivers. Furthermore, DBI doesn’t provide default values for all of them.

However, I’m pulling together a list of all the issues I found with DBI attributes, and when Tim Bunce returns from vacation in a week or so, I’ll submit them, along with all the patches I could figure out. I’ll probably also provide a test suite, too, just to try to keep things consistent going forward.

I’m also working on a patch to the DBI itself to have it throw class exceptions whenever possible, too. Right now, it only throws object exceptions, but there are a number of places where they could be thrown in a class context, too, mainly during object construction (i.e., when calling connect(). We’ll see how that goes over.

In the meantime, feedback on the current implementation is more than welcome!

Originally published on use Perl;

Bricolage Presentation

For anyone who might be in the neighborhood, I’ll be giving an informal presentation introducing Bricolage tonight (9 Septbember 2002) to the Mason Users Bay Area group in San Francisco. Here are the details:

When: Monday September 9, 7-9pm Where: Ensenda, Inc. 512 2nd St @ Bryant 4th Floor San Francisco 94107

Bricolage is a full-featured, enterprise-class content management system written in Perl with a Mason-powered UI. It offers a browser-based interface for ease-of use, a full-fledged templating system built on Mason and HTML::Template, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository.

This talk will introduce Bricolage and many of its concepts for defining content structure and building documents. And of course, since this is a Mason group, we’ll take a look at the close relationship between the Mason templating system and the elements of content in Bricolage.

Thanks to Philip Mikal for organizing this meeting!

Originally published on use Perl;

Apple Should Support TPF

Yes, this is a serious suggestion. The design for Perl 6 is truly human-centered, what with its emphasis on creating a language that, even more than Perl 5, works the way people think (well, English speakers, at least [and Klingon speakers, of course!]). This is strongly in line with Apple’s own philosophy of human-centered design. This goes right down to language choice for Apple; to paraphrase Dan Sugalski, “Objective C is like Perl in C; the object model’s damned close.” There’s a lot in common between the two design philosophies.

So I’m suggesting that Apple support the Perl Foundation and, especially, Perl 6 development. Perl plays nice with Carbon, ships with Mac OS X, and, with Parrot, will support just about any other language you could want to use. And much of the development is being done on Macs. I think that there’s a real synergy of vision here, and Perl 6 would make a great high-level language for Apple to promote to Cocoa developers.

So, how best to go about convincing Apple of this, of letting them know that, for a small investment, they can be advancing both its design philosophy and the future of their platform?

Originally published on use Perl;


I just finished downloading a video of Allison Randall’s “Tagmemics” talk. I think that this will be a popular video download from the collection of TPC talks, because it actually offers some insight into the way Larry thinks. It proved to be a very popular presentation, with a packed room, and comments offered by Larry, Damian, Gloria, Chip, and Eric Raymond. The quality of the video is good, too, since the lighting was much better than it was for Damian’s talks.

Anyway, I think that Allison is making a great contribution to the community, because she’s communicating to people some of the linguistic ideas that underlie Larry’s design decisions. A lot of us talk about how much more expressive Perl is, and how it’s more syntactically friendly for people to use than most other programming language (if you speak English, at least), but Allison’s example in this talk really makes it clear. Pretty soon, we’ll all be talking about whether our language feature suggestions are emically or etically driven, and where the syntax we prefer falls within the Tagmemic matrix.

I think that she might make amateur linguists of us all. Other folks at the talk were likewise impressed, and suggest that a similar talk be made in a bigger venue next year. If you agree, let O’Reilly know! Fill out a feedback form if you’re at the conference. I suggested that a similar talk be promoted as a major presentation next year. Who knows, it might bring others around to our way of thinking.

The video will go up as soon as we can transfer it to another box (all 9.25 GB of it) and Nat can convert it to RealMedia or QuickTime format. It’ll be on the perl.org site when it’s ready. No doubt it’ll be posted to use Perl when it’s ready (along with Damian’s two talks and whatever I film tomorrow).

Originally published on use Perl;