Alien::Base was first released in alpha form five years ago this month!
The good things that Alien::Base (runtime) and Alien::Base::ModuleBuild (its installer ABMB) did
when it was unleashed on the world are many, but chiefly:
- It suggested a standard way of providing the compiler and linker
flags needed to use an already installed alien. The
was pretty flip in terms of standards or best practices.
- It made it dead simple to create an Alien distribution that
“alienized” a package that used
pkg-config, which probably covers a majority of open source libraries
that you would be likely to want to “alienize”.
(For those who are unfamiliar, autoconf provides a similar
functionality to ExtUtils::MakeMaker in the C world
and pkg-config is used to deal with dependencies in the C
- It made it possible with some work to create an Alien distribution
that wrapped around a package that used vanilla Makefile's,
CMake, and in some cases crazy custom installers.
So when I was working on:
A few weeks ago, SROMANOV sent me a patch for Git::Database adding initial support for accessing the Git object database references via Git::Raw. He had already contributed a partial implementation for a Git::Wrapper backend some time ago.
This motivated me to explore that module further, and implement the methods that were missing from Sergey's patch. So I asked JACQUESG to implement a few features that I needed. He was amazingly fast at responding, and I found myself asking for more and more features. And he just kept adding them!
So, thanks to a motivated contributor and a very reactive maintainer, Git::Database 0.08 can now access data from a Git repository using any of these seven Perl Git backends:
There are in fact more Git backends on CPAN... Anyone interested in adding support for Git::Class must have understood by now that patches are welcome.
Like all subjective decisions in technology, which log level to use is the cause of much angry debate. Worse, different logging systems use different levels: Log4j has 6 severity levels, and Syslog has 8 severity levels. While both lists of log levels come with guidance as to which level to use when, there's still enough ambiguity to cause confusion.
When choosing a log level, it's important to know how visible you want the message to be, how big of a problem it is, and what you want the user to do about it. With that in mind, this is the decision tree I follow when choosing a log level:
Following is the p5p (Perl 5 Porters) mailing list summary for the past week.
I wrote about using the Perl debugger with Moose. In that post, I showed how to use DB::Skip to make it easier to use the Perl debugger with Moose and other modules whose guts you don't want to wade through.
Today's debugger hack will make using the debugger with DBIx::Class much easier.
The more I
think about the “single-quote as alternate package separator” thing I mentioned
in my last post,
the more it bothers me. The problem I ran into, trying to
print "$user's crontab is
missing!\n", generated an “uninitialized
value” warning. It did NOT get picked up by
strict mode—which was on—because packaged-qualified variables
are always OK.
me as a source of hard-to-find and relatively easy-to-generate bugs. Given all
the other stuff that has been deprecated out of Perl over the years, I am
surprised this hasn’t been tagged for deprecation. Especially given that,
a comment from preaction, the single-quote as a package separator was
considered archaic as of Perl 5.6.
If you saw my FOSDEM talk about Building a Universe in Perl, I show some examples of the code we use to model behaviors in our universe. I start talking about out test suite at one point and that's probably the most exciting part. You see, we've been fixing our leaderboard system in part because I can do this:
That's a truncated version of our test failure report for tests failing on
master. Leaderboard tests show up twice in there.
Ever have an failing test and trying to remember if it failed before? Is it fragile code? Is it fragile tests? Has it ever failed on your
master branch? What percentage of your tests fail? Well, now you can find out.
while attempting to do
print "$user's crontab is missing!\n"
I got the
error “Use of uninitialized value in concatenation (.) or string…”, and after a
bit of testing, I discovered that “
apparently an alias of “
$package::varname” (in my case,
Perl was trying—and failing—to print
Did everyone else know this? This is literally the first time I have run across this in almost 20
years of Perl programming
(Of course a
quick Google search turns this up in the opening paragraphs of the perlmod docs—I wonder if it’s time to
read all of that stuff cover-to-cover?)