What does this variable represent?
my $thingie =<<'END';
Thaddeus Droit
4616 NW Washington Place
Beaverton, OR 97006
END
It's obviously an address, but what does Perl know about it? Perl knows it's a string. Perl knows it's some 60 characters long. Perl may even know that it's a valid string of Latin-1 characters.
Perl doesn't know where the string came from, nor that it contains a street
address or a legal name nor a zip code (and not a zip + 4). Any meaning to the
program beyond "It's a string of some 60 characters and is valid in the Latin-1
encoding" is far beyond what Perl knows about it. That's why the name of the
variable is $thingie; even though Perl doesn't care about variable
names, calling it $address instead could have led you to believe
there's more structural meaning to this chunk of memory than actually
exists.
Names are important, at least to people maintaining source code. This code is obviously wrong:
$user->set_address( $birthday );
... but to Perl it might as well be:
$foo->bar( $baz );
... for all of the semantic meaning it understands. There's no obvious
intent.
I know you're smart and you're way ahead of me and you think "If I wanted a
good static type system, I know where to find Haskell or OCaml and I'd never
let code that bad get out of code review and why aren't you writing tests." but
that's not the point. You can be super careful or make
APIs which restrict the most natural way to write code in the host language in
favor of extra security. That may be the right approach. (You have to be
careful, though: the ease of interpolating untrusted user input into a raw
string or the use of register globals in PHP seems analogous to the attractive
nuisance doctrine, where people who don't know any better can't analyze the
risk appropriately.
There may be another way.
Suppose I annotated the address:
my Address $thingie =<<'END';
Thaddeus Droit
4616 NW Washington Place
Beaverton, OR 97006
END
It's still a chunk of memory with certain characteristics, but now it has an
extra piece of metadata related to the program itself (and not merely Perl
itself). A clever compiler could detect certain places where the semantics of
an operation don't match:
method set_address(Address $addy) { ... }
... though you do have to be able to resolve this kind of dispatch at
compilation time to prove the type safety of the entire program at compilation
time. (I've seen suggestions that even Smalltalk programs can resolve some
85-90% of dispatch targets in a static fashion.)
You don't have to go that far; runtime verification with a good test suite
is effectve, can be fairly cheap, and is available right now in Perl 5 with Moose.
There's still another way. Consider again the untrusted input example. If
you enable tainting, you might read user input into an address:
my Address $untrusted_addy = $req->get( 'address' );
You don't see it in the declaration, but the "This is tainted!" metadata is present in $untrusted_addy. How do you deal with that?
You could be picky about always untainting untrusted data, but can you do
that accurately and effectively? Can you rely on everyone always getting it
right?
What if you could write:
SQL {{
UPDATE users SET address = { Address $address } WHERE user = { User $user }
}}
... and Perl could verify that $address is an appropriate
Address (and $user is an appropriate User), could quote and escape and validate both of
them effectively, could extract the primary key from $user, and
could untaint any tainted $address or $user?
If your language supports multiple dispatch, lets you define your own types,
lets you override stringification, and can override interpolation for cases
like these, you can do such things.
In other words, you could turn what would otherwise be a raw string into an
embedded little language with its own syntax and semantics, interoperate with
native data structures in the host language, and provide composable
safety—and users don't have to know much of anything about how this
works, as it pretty much does what they expect.
I can imagine a language like that.
In this post I’m going to talk about the java2perl6api project. What its goals are, why I think it’s important, how it relates to a Perl 6 DBI, what exists now, what’s needs doing, and how you can help.
Firstly I’d like to point out that, funnily enough, I’m not very familiar with Java or Perl6. It’s entirely possible that I’ll make all sorts of errors in the following details. If you spot any do please let me know.
Background
The Java language ecosystem is big and mature after years of heavy investment of time and money.
It doesn’t have a central repository of Open Source modules like CPAN (though Maven repositories like these are similar I guess). It does, however, have a number of mature high quality class libraries, and a very large number of developers familiar with those libraries (more on that below).
Goals
The primary goal of the java2perl6api project is to make it easy to create Perl 6 class libraries that mirror Java equivalents. By mirror I mean share the same method names and semantics at a high level (though not at a low-level, more on that below).
Secondary goals are to do that well enough that:
- the documentation for Java classes can serve as primary the documentation for the corresponding Perl 6 classes. The Perl 6 classes need only document the differences in behavior, which these should be minimal and ‘natural’. The same applies to books describing the Java classes.
- Java developers familiar with the Java classes should feel comfortable working with the corresponding Perl 6 classes.
- and, hopefully, some way can be found to convert test suites for the Java classes into Perl 6 code that’ll test the corresponding Perl 6 classes. (I appreciate that this is a non-trivial proposition, but there are viable approaches available, like xmlvm.) Even if that can’t be done, extracting and translating tests manually is less work, and more effective, than creating them from scratch for a new API.
Why?
Firstly, creating good APIs is hard. Java APIs like JDBC 3.0 and NIO.2 are the result of years of professional effort and demanding commercial experience. Why not build on that experience?
I appreciate that Java APIs are often limited by the constraints of the language, such as the lack of closures, and that Perl 6 can probably express any given set of semantics more effectively than Java. My point here is that some Java APIs embody, however inelegantly, years of hard won experience that we can benefit from. I’d rather make new mistakes than repeat old ones.
Secondly, there are many more Java developers than Perl developers. Many many more if job vacancies are any indication:
I think we’d be foolish not to try to smooth the path for any Java developers who might be interested in Perl 6. The java2perl6api project is just one small aspect of that.
I really hope someone starts writing a “Perl 6 for Java Developers” tutorial. Perl 6 has the potential to become a very popular language1. Getting just a tiny percentage of Java developers (and Computer Science majors and their teachers) interested in it could be a big help.
Thirdly, any future DBI for Perl 6 and Parrot needs a much better foundation than the very limited and poorly defined one that underlies the Perl 5 DBI. I plan to adopt the JDBC 3.0 API and test suite for that internal role. (You could call this a “Test Suite Driven Strategy”.) I’ll talk more about that in a future blog post.
The History java2perl6api
I’ve been kicking around various ideas for integrating Java and Perl6/Parrot for years. I think I first decided to use JDBC as the inspiration for the DBI-to-driver API in 2006.
You may remember back in 2004, around the 10th anniversary of the DBI, the Perl Foundation setup a “DBI Development Fund” that people could donate to. I’ve never drawn any money from that fund. I want to use it to oil other peoples wheels.
In 2007 Best Practical sponsored Perl 6 Microgrants through the Perl Foundation. I asked if I could piggyback my idea for a Java to Perl 6 API translator onto their microgrant management process but using money from the DBI Development Fund. TPF and Best Practical kindly agreed. I posted a description of the task and Phil Crow volunteered and was awarded the microgrant in April 2007.
At OSCON in July 2007 I gave lightning talk called “Database interfaces for open source languages suck” which explained the rationale for using JDBC as a foundation for the DBI-to-driver API and mentioned Phil’s java2perl6 project.
Development ground to a halt around the end of 2007 for various reasons. It picked up again for a few months after OSCON 2009 (where I gave a short lightning talk asking for help) then stalled again in October. Partly because we seemed to have hit a limitation with Rakudo and partly because I was focussed on Devel::NYTProf version 3 and then version 4, which took way more time than I expected.
There’s life in the project again now. We’ve dodged the earlier problem, put the code on github, brought it into sync with current Rakudo Perl 6 syntax, and generally instilled some momentum.
The Current java2perl6api
Let’s take a look at a simple example.
To generate a perl6 file that mirrors the API of the java.sql.Savepoint class you’d just execute java2perl6api like this:
$ java2perl6api java.sql.Savepoint
loading java.sql.Savepoint
wrote java/sql/Savepoint.pm6 - interface java.sql.Savepoint
checking java/sql/Savepoint.pm6 - interface java.sql.Savepoint
That’s loaded and parsed the description of the java.sql.Savepoint class (from the javap command), generated a corresponding perl6 module, and run perl6 to validate it.
The generated module (with some whitespace and cruft removed) looks like this:
use v6;
role java::sql::Savepoint {
method getSavepointId (
--> Int # int
) { ... }
method getSavepointName (
--> Str # java.lang.String
) { ... }
};
=begin pod
=head1 Java
Compiled from "Savepoint.java"
public interface java.sql.Savepoint{
public abstract int getSavepointId() throws java.sql.SQLException;
public abstract java.lang.String getSavepointName() throws java.sql.SQLException;
}
=end pod
The pod section shows the description of the class that javap returned. The java2perl6api utility parsed that Java interface and generated the corresponding Perl6 role. The ‘java.sql.Savepoint’ has been mapped to ‘java::sql::Savepoint’. The generated methods are stubs using ... (the “yada, yada, yada” operator). The types int and java.lang.String have been mapped to Int and Str. Because the only types used were built-ins, no type declarations were added.
Currently java2perl6api handles the above plus overloaded methods (which generate multi methods), multiple implements clauses (which generate multiple does clauses). There’s also partial support for class/interface constants (which currently generate exported methods).
The default behavior is to recursively process any Java types referenced by the class which aren’t mapped to Perl 6 types. So executing java2perl6api java.sql.Connection, for example, will generate 48 Perl 6 modules! (Because java.sql.Connection refers to many types, including java.sql.Array which refers to many types including java.sql.ResultSet which refers to java.net.URL which refers to java.net.Proxy etc. etc.) The --norecurse options disables this behavior.
Normally you’ll want to use the recursion but instead of letting it drill all the way into the Java types, you would supply your own ‘typemap’ specification via an option. That tells java2perl6api which Java types you want to map to which Perl 6 types. So instead of recursing into the java.net.URL type to generate a java/net/URL.pm6 file, for example, you can tell java2perl6api to use a specific Perl 6 type. Perhaps just Str for now.
How this relates to JDBC / DBDI / DBI v2
I want to start applying java2perl6api to the JDBC classes now to create a “Database Driver Interface” or “DBDI” for Perl 6.
Starting with the DriverManager class and the Connection interface I’ll use java2perl6api to generate corresponding Perl 6 roles with heavy stubbing out of types. Basically anything I don’t need to think about right now will be mapped to the Any type.
I’ll start fleshing out some basic implementation logic for each in a Perl 6 class that does the corresponding role. I’ll probably use PostgreSQL as the first driver and the guts of MiniDBD::Pg as inspiration.
The first minor milestones will be creating connections, then execute non-selects, then selects then prepared statements. Somewhere along the way I expect they’ll be a Perl 6 DBDI driver implemented for the Perl 6 MiniDBI project. The next key step would be to start refactoring the code heavily so anyone wanting to implement a new driver should only have to implement the driver specific parts. (There are some JDBC driver toolkits that can provide useful ideas for that.)
What needs doing
There’s a TODO file in the repository that lists the current items that need working on.
One fairly simple item is to add a --prefix option to specify an extra leading name for the generated role. So java.sql.Savepoint with a prefix of DBDI would generate a DBDI::java::sql::Savepoint role.
Another item, less simple but more important, is to automatically discover the values of constants and embed them into the generated file. Probably the best way to do that is to extend the parser (which uses Parse::RecDescent) to parse the verbose-mode output of javap, which includes those details.
There are plenty of others.
How you can get involved
Firstly, come and say “Hi!” in the #dbdi IRC channel on irc.freenode.net.
The code is on github. You can get commit access by asking on the #perl6 channel.
There’s also a mailing list at dbdi-dev@perl.org which you can subscribe to.
I look forward to hearing from you!
When I say “Perl 6 has the potential to become a very popular language” I do so with typical British Understatement.
Filed under:
perl,
software Tagged:
dbdi,
java,
perl,
perl6 
16 July, 2010 i
dbdi,
java,
perl,
perl6,
software |
Comments Off
Some people believe that security problems and other severe bugs are inevitable. Some of these people believe that conscientious design and clear thinking about how languages and APIs work is irrelevant; bad code is possible in every language.
Bad code is possible in any language and wrong code is possible with any API. Even so, it's possible to create languages and APIs which make the right thing so much easier than the wrong thing that only the most incompetent (or dangerously malicious) write bad code.
Imagine, for example, a database access layer which forbids the use of raw strings to create SQL queries. You might have to write:
my $sth = $dbh->select( @tables )->join( %relations )->where( %conditions );
That's not necessarily a beautiful interface dashed off after a moment of thinking, but it has an important security property: it avoids the interpolation of untrusted user input. All data sent to the database may go through a quoting or untainting process without the user having to remember to do so.
A similar library could help avoid malicious user input from interfering
with the display or operation of a web site, for example. These are both
specific cases of a general principle: replace
unstructured string data with structured data. In both cases, the
structure of the data makes the intent of the data clear, which allows the
library to ensure as much safety as possible.
This principle has other implications as well; more on that next time.
In case you missed the recent launch announcement, CPAN Testers 2.0 is live and the email mailing list used to submit CT 1.0 reports will be shut down around August 31, 2010. I consider this the start of the "public beta" period for CT 2.0. Most of the beta testers so far have been experienced testers, but I'm sure we'll see lots of new questions and issues to fix as more people start switching over to CT 2.0 before the deadline.
If you are already a CPAN Tester, a "profile file" has been pre-generated for you and you should submit a request that it be emailed to you. This pre-generated profile will identify your new CT 2.0 reports in a way that will make it easier to link them to the CT 1.0 old reports as those are converted.
If you are new to CPAN Testing, you will need to generate a profile file. Install Metabase::Fact and then run the metabase-profile program from the command line. It will prompt you to provide some information and output a profile file. The first time you use this profile file to submit a report, your profile will be automatically registered on the CT 2.0 server.
While the CT 2.0 server has launched, the clients that submit reports are, for now, the same ones used for CT 1.0 -- either CPAN::Reporter or CPANPLUS (or one of the smoke frameworks written for them like minismokebox or CPAN::Reporter::Smoker). The transport framework originally intended for email gets hijacked to send reports via http to CT 2.0 instead.
To send reports to CT 2.0, you will need to install the Test::Reporter::Transport::Metabase module and then configure your client to use that transport instead of the default one. Instructions are available on the CPAN Testers Wiki. While the docs are a bit sparse as I write this, I expect they will continue to evolve and improve as more people contribute to them.
If you're really stuck, please check the FAQ or ask for help on the CPAN Testers Discuss mailing list. If you are a CPAN Tester, I highly recommend joining the list to keep up on the latest issues and solutions in the migration to CT 2.0. If you do ask for help, please be sure to include the version number of all the relevant testing modules you're using along with your perl -V output.
Another good place to go for quick questions is the #cpantesters-discuss channel on irc.perl.org.
In other news, I'll be speaking about CPAN Testers at OSCON in my Free QA! talk. If you or someone you know will be there, please check it out or recommend it.
Way back in the late '90s and early 2000s, many Perl fans could rattle off a list of big projects using Perl: Slashdot, Amazon.com, IMDB. Eyebrows popped up (maybe at one point), as if the fact that billions of dollars of online sales went through Perl were validation of a language.
Perhaps it is.
Today much of the online Perl community discussion reads as reactionary, at least to me. Some random Internet argument will degrade into "Perl? Isn't that insert negative description here?" versus "Nuh uh, Perl isn't insert negative description here!"
Me, I'd rather hear about interesting new projects written in Perl. Take the recent Duck Duck Go written in Perl story. Repeat this a few dozen times (especially with new projects created in the past year or two) and responses will move from "Perl? People still use that?" to "Wow, people who know Perl can certainly do a lot of interesting things!"
I'd rather see the latter message spread than almost any other marketing message—so tell the world, what are you working on with Perl?
10 July, 2010 i
marketing,
perl |
Comments Off
Please forgive the title!
Perl has three regular expression match variables ( $& $‘ $’ ) which hold the string that the last regular expression matched, the string before the match, and the string after the match, respectively.
As you’re probably aware, the mere presence of any of these variables, anywhere in the code, even if never accessed, will slow down all regular expression matches in the entire program. (See the WARNING at the end of the Capture Buffers section of the perlre documentation for more information.)
Clearly this is not good.
I’ve long planned to add detection and reporting of this to Devel::NYTProf, along with things like method cache invalidation, but it’s never risen to the top of the list. In fact, now I look, I see it never even got entered into the ever-growing collection of ideas recorded in the HACKING file.
After the 4.00 release, plus few minor releases, I’d put NYTProf on hold and was starting to focus on my java2perl6 API translation project (more news on that soon).
Then I saw a recent blog post by Josh McAdams, one of the authors of Effective Perl Programming (along with Joseph N. Hall and brian d foy) about detecting these variables using the Devel::SawAmpersand and Devel::FindAmpersand modules. Firstly it reminded me of the issue, and then it struck me that few people would bother using those tools because they simply wouldn’t know they had the problem in the first place.
Someone with a performance problem is likely to use a profiler like NYTProf to see where time is being spent in their code. That might point out that significant time is being spent in regular expressions, but even then they might not make the leap to consider these special match variables as a possible cause. The profiler should point it out to them!
NYTProf version 4.03 didn’t. Clearly that was not good. So NYTProf version 4.04 now does!
In the list of files on the index page it highlights the file and adds a comment:
On the report page for the file itself it adds an unmissable, and hopefully self-explanatory, note to the top of the page:
I’d be very interested to hear from anyone who now discovers these problem variable lurking in their application code or any CPAN modules.
Go take a look!
Filed under:
perl Tagged:
nytprof,
perl 
9 July, 2010 i
nytprof,
perl |
Comments Off
The name Buzz Moschetti probably isn’t familiar to you. Buzz was the author of the Perl 4 database for Interbase known as Interperl.
Back in those days Perl 5 was barely a twinkle in Larry’s eye and database interfaces for Perl 4 required building a custom perl binary.
Buzz was one of the four people to get the email on September 29th 1992 from Ted Lemon that started the perldb-interest project which defined a specification that ultimately lead to the DBI. (The other people were Kurt Andersen re informix, Kevin Stock re oraperl, and Michael Peppler re sybperl. I joined a few days later.)
Update: It turns out that it was actually Buzz who sent that original email, Ted just forwarded it on to others, including me. So Buzz can be said to have started the process that led to the DBI!
I hadn’t heard from Buzz for many years until he sent me an email recently.
This is his story:
Thought I’d share a quick story with you.
Recently, I was frustrated with a development team’s efforts in putting
together some DB-oriented reconciliations. The candidate solution was a
blend of precompiled SQL in COBOL code, file dumps and ftps, programs to
read files, more programs to read other DBs, etc. etc. Not only was
the process orchestration a project in its own right, the end-to-end
logic required to accurately perform the reconciliation was distributed
across several programs and platforms, diluting the knowledge base. I
knew a perl program using multiple DBD drivers to different DB engines
could do it in a much cleaner way, but over the years my job has changed
and although I still use perl regularly, I don’t do much in the way of
DBD/DBI. To make matters worse, one of the targets was mainframe DB2
and very little work had been done here with DBD::DB2. Also, the
Sybperl module continues to be heavily used in addition to DBD::Sybase,
so local DBD/DBI expertise in general is thin. I decided to get it
working on my own.
The infrastructure team spun up for me a Linux virtual machine with a
modern build environment on it. This had the latest gcc compilers and a
firm-approved build of perl 5.8.5 right out of the box. It took a few
days of low-priority requests to get the appropriate 32bit Linux
client-side SDKs for the DB2 and Sybase products but soon enough I had
an environment set up with headers and shared libs. I was ready to
build some perl modules, something I haven’t done in years.
I went to CPAN and downloaded DBD::DB2, untar’d it, and ran perl
Makefile.PL and make. Everything worked perfectly and the whole
exercise took minutes. ‘make test’ sets PERL_DL_NONLAZY and warned of
some unused symbols not being found, but that was OK. The rest of the
tests that I expected to work with my level of permissions worked fine.
‘make install’ worked perfectly. Buoyed by this success, I wrote a
4-liner test program just to connect and fetch some data from a table I
knew about. Outside of the test environment, however, the shared libs
for DB2 were not found so I cheated and relinked and reinstalled DB2.so
with the -Wl,-rpath option to “cement in” the location of those libs so
I wouldn’t have to fuss with LD_LIBRARY_PATH. My test program now
worked fine. Newly comfortable with the process, I downloaded
DBD::Sybase and built and installed the module in scarcely more time than
it took for the compiler to run. In my excitement I skipped over the
DBD::Sybase 4-liner test program and went straight to a slightly bigger
script that used both modules and grabbed data from both DBs. It
quietly and quickly executed.
Total time from initial download with almost no clues to a running
example: about 40 minutes. Later, for grin’s sake, I threw in
DBD::Oracle for good measure. That went even faster — about 5 minutes
– from CPAN download to printing “Oracle connected!” because I was more
familiar with the connection string syntax that is bespoke for each
engine.
As I watched the program run, it made me reflect on how far we’ve come
and how easy yet sophisticated the perl module ecosystem has become.
There is no question that this multi-DBD perl program is easier to
understand and support than a solution involving a set of disconnected
programs, platforms, and files. But I think it is the organization and
design of the resources as a whole — DBI, DBD, CPAN, MakeMaker, pod,
binary and non-binary library locations, etc. — that makes the whole
environment so clear, symmetric, and easy to use with confidence. I
think back to the build environment that I used to create interperl, and
the progress that has been made in terms of both breadth of module
functionality and depth of framework for module build portability is
simply amazing. Perl has grown far beyond just being another language.
It has a value proposition as an able integrator of widely disparate
functionality.
I exited the Perl mainstream some time ago but I am watching from the
side and I applaud the work you’ve done in this space.
Take care.
Thanks Buzz!
Filed under:
perl Tagged:
cpan,
dbi,
perl,
perl4 
8 July, 2010 i
cpan,
dbi,
perl,
perl4 |
Comments Off
I'm half-way through my tenure as Perl release manager of the month. In just two weeks, I'll be releasing Perl 5.13.3 while I'm at OSCON. Here's what I've done so far:
- Writing a command-line tool to keep perldelta notes for each commit to the core repository in git notes and collate them for me by section to add to the perldelta
- Writing a command-line tool to propose specific commits for cherry picking back to the Perl 5.12 maintenance branch
- Actually working through the first week or so of commits for perldelta
- Applying a lot more patches from the p5p mailing list than I usually do
- Fixing a couple bugs
- Cherry picking the commits from 5.12 maintenance needed to "forward-port" the perl5121delta file to blead
I haven't been as diligent about marking up commits as I'd hoped, partly due to personal commitments and partly due to the extra distractions of the CPAN Testers 2.0 release announcement. Now it's a big enough backlog to be intimidating, so I need to pick off small pieces and work through it.
It looks like one of the big changes in Perl 5.13.3 will be updated dual-life modules. Chris (BinGOs) Williams has done a heroic job bringing dual-life modules up to date with the versions on CPAN. That's a great step forward and gives us a long lead time for testing in advance of Perl 5.14.
8 July, 2010 i
ironman,
perl programming |
Comments Off
Defensive programmers anticipate what might go wrong. Robust code handles the unexpected, partly by minimizing the surface area of potential problems. The fewer things that can go wrong, the fewer things that will go wrong. (Things will still go wrong, but you can write safer code if you're clever.)
Yuval Kogman asked Are we ready to ditch string errors? I am; there's a general principle of API design beyond his question.
One problem with die "Some error!" is how to identify what error that represents—not to a programmer or user, who ostensibly speaks enough English and problem domain jargon to have some idea of what the error means—but the rest of the program. How does your code catch this error and distinguish it from some other type of error? Can you determine which of the two you can handle and which you must delegate?
Break out split or the regular expression engine and prepare to write heuristics which guess, and woe to you if someone someday internationalizes your error messages or runs all of your exceptions through a logging mechanism which changes their formatting slightly or....
The problem is that you can't take advantage of the structure of the exception data because it's not present in the string. The same goes for DBI's connection strings:
my $dbh = DBI->connect( 'dbi:DriverName:database=database_name;host=hostname;port=port' );
As the documentation suggests in the very next sentence:
There is no standard for the text following the driver name. Each driver is free to use whatever syntax it wants.
Compare this to a keyword argument form:
>my $dbh = DBI->connect(
driver => 'DriverName',
database => 'database_name',
host => 'hostname',
port => 'port',
extra => 'arguments',
);
This has several advantages. The method doesn't have to guess (or
parse) the string. The layout and vertical alignment makes the
keyword form easier to read and to modify. DBDs can decorate and augment this
argument list without parsing and recreating a string. Verification and
default arguments are much easier.
The same argument goes for using a module such as File::stat instead of parsing the output of `ls -l filename`.
The same argument goes for... you get the point. It's far too easy to
unfold the regex widget from the swiss-army chainsaw when a little bit of
caution decomposing data into structured data makes your programs safer, easier
to use, more flexible, and more robust.
(I consider sometimes how a language would look if it had only keyword arguments and how you could optimize them with immutable, internable strings and cached call sites and a zero-copy register allocation mechanism, but I made it as far as writing a self-hosting garbage collector before I had real work to do.)
These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.
