We couldn’t do it.  After a second look, I still can’t do it.  Not for all cases, anyway.

perlsub says lists a prototype of (*;$) for open, and discusses being careful not to override open by accident.  It also suggests prototype can show the prototypes for overridable items.

prototype ‘CORE::open’ returns “*;$@”, which is interesting, but not a match for perlsub.  ”*;$@” lets the function get called, though, and matches all the things open has to do.

I wrote a really simple wrapper for open:

 use Data::Dumper;

sub open(*;$@) {

    say Dumper(\@_);

}

I wrote a function to call it a couple of ways:

say "test 1:";

open (FH, '>file.txt') or die "Can't >file.txt: $!";

close FH;

say "test 2:";

open (FH, '>', 'file.txt') or die "Can't > file.txt: $!";

close FH;

say "test 3:";

open (my $fh, '>', 'file.txt') or die "Can't my > file.txt: $!";

close $fh;

Now I can see what those look like:

test 1:

$VAR1 = [

     'FH',

     '>file.txt'

 ];

test 2:

$VAR1 = [

     'FH',

     '>',

     'file.txt'

 ];

test 3:

$VAR1 = [

     undef,

     '>',

     'file.txt'

 ];

Okay.  The two calls with typeglobs get the name of the glob.  I can work with that.

The call with a lexical, though, gets the value.  Where/how do I return the handle?

I messed around some more, and when using lexicals, a Perl open() function is called with the value of the lexical, not with any way to identify the variable itself.  I can’t figure out how to get the variable to pass to CORE::open, or to return something into it.

And there I’m stumped.  Is it possible that the docs in perlsub are from the 5.5 days and don’t work since Perl 5.6 introduced lexicals as file handles?  Or am I missing something?

I could go dig in to CPAN and see if any other modules do this right.  How does Safe.pm do it?  Can it be done in an XS module but not in Perl?

Back to useful work instead of banging my head against this.

I’d been looking for a way to manage having multiple Perl installations on my system.  Ruby has something called the Ruby Version Manager which makes this really straightforward, and I figured there had to be something like it for Perl.  I hadn’t looked much, but what I had didn’t get me anywhere.  The Preface for Modern Perl mentioned it in passing.  The tool is called App::perlbrew and allows you to easily switch from one Perl to another and can help manage those Perl installations.

Combine that with local::lib so you can have your own installed modules, and you’ve almost got rvm.  The ability to have named module sets and turn them on and off at will is missing.  If it’s important, the two could be combined into a complete Perl environment management tool… but I don’t know if it is important.  A per-project Perl with modules installed might be enough.

One useful tool mentioned in Modern Perl is the Perl module Modern::Perl, also by chromatic.  It’s a helper to take some of the boilerplate that a modern Perl program should put in every program and module and condense it to one easy to read, clearer line of code.  It isn’t a big deal, but is nice.  (CPAN, as usual was full of similar things, but I didn’t think they were as well thought.)  I had heard of Modern::Perl because I’d been following chromatic’s blog.

The module I thought was really neat but hadn’t heard of was Task::Kensho.  This is part of the work of a group of folks who are trying to build an “Enlightened Perl” and is mostly references to other modules.  The module list includes some big stuff I’d run into – Moose, DBIx::Class – but also included a lot of just generally useful stuff that I’m sure will be handy.  There was also some things that were not critical but neat, like Smart::Comments.  There’s a bunch of stuff on that list I’ve been Meaning To Look At but haven’t gotten around to yet, like Devel::REPL.

Not only is it released, but chromatic has graciously made the book available  for download as PDF.  His publisher has it as both letter-sized and A4 sized formats for print.  It’s released under one of the Creative Commons (by-nc-nd) licenses so you can use it, share it, and distribute it freely and widely.  The blog announcement mentioned above encourages you to do so.

I’ve taken the time to give the book a first read, and I can only say that I’m impressed.  According to the blog posts, the book was produced in POD which was stored in a public Git repository for constant feedback and refinement from members of the community.  That’s really slick, and the content of the book shows how much work went into it.

The book does some things differently than other Perl books I’ve read, and I approve.  The preface starts of by giving the requirements for running the sample code from the book.  That includes Perl of no later than 5.10.1, and “use strict” and “use warnings”.  There is no example of trying to write code that works in Perl 5.6 or is just like the other things you’ve seen before .

It begins with some interesting sections discussing the philosophy of Perl, and where the community lives and how to find them.  It explains perldoc and search.cpan.org, and leaves it to the reader to use those as references.  These are key items often overlooked in books, and rightly deserve a place at the front of the book.

There are several chapters about Perl, the language.  These chapters cover almost all of the language.  They cover it at some depth, pausing to explain how it works and to shine a flashlight into the dark corners and point out all the odd bits you can trip over.  These chapters manage to be easily readable and to avoid most of the technical jargon they don’t need.  When a technical term is needed, it is introduced, explained and then used properly.

The book includes the best description of arity and fixity I’ve ever seen.  I’d gathered the concepts, but didn’t know the names.   I knew the names of the different kinds of operators – infix, prefix, circumfix, and postcircumfix, but have never seen them described so well.  Similarly, this is the clearest and most concise description I’ve ever read of closures, including what they are, why they work, why they’re called “closures” and why they’re interesting.

In addition, the book has the best explanation of why it is important to handle different character sets properly that I have ever seen.  It demonstrates some of the common pitfalls and shows how simple it is to accidentally produce strings which will be unreadable in any format because they’ve got data from two different character sets.  For anyone who isn’t paying attention to Unicode yet, this should be a mandatory read.

There are two chapters on object oriented Perl.  The book starts with Moose and shows its use and how to use it.  Only then does it show the built-in Perl OO constructs.  They’re a lot easier to explain once you’ve seen how objects should work, so you might have a grasp of why you’d be writing a “new” function.  They are well done chapters.

Then come what I considered the important parts!  There are chapters on how to write maintainable code, and what that means.  A chapter discusses some of the common idioms seen on the Internet and on CPAN.  There is a chapter including testing, warnings, and distributions.  There’s a chapter that goes “beyond syntax” to cover why things are done and how to do them well and explains a couple of the common methods used, such as the Schwartzian Transform.  Finally, there is a “things to avoid” chapter and some things chromatic feels are missing from Perl.

I think all of these things are useful and important, and didn’t see anything in the book I strongly disagree with.  I read things I didn’t know, ranging from silly little features (you can us ++ on a string!) to the names of some of the computer science concepts I’d never heard well explained before.  The coverage of the language and how it works is excellent, and reading this will help people go from fumbling with it, to really understanding how it works and why it does the things it does.

My biggest complaint about the book is that I wish there were more of the discussion about writing good Perl.  One of the common complaints about Perl is that it’s ugly, and unmaintainable.  It doesn’t have to be, and there are a lot of techniques to make it better.  I’d have loved to see more discussion of that in this book.  (I realize I have no one to blame but myself, as this book was produced with the collaboration of many and I could have been involved.)

I also just noticed a language feature it missed discussing – formats.  They are another dark corner, but I’m surprised they aren’t there.  Maybe I missed them, but neither a search nor the index shows them.

As you can see, I don’t have much to complain about here, and I’m going to be sending this book around on the internal Perl mailing lists at work.  I feel it’s an excellent place for an intermediate Perl programmer to go to get a really firm grasp on the language and will be an unbeatable way to help many of the self-taught engineers who write Perl to solidify and put names to the concepts they’ve been working with but may not have had such a clear grasp of.

At this point, I’d consider this a more valuable book than “Programming Perl” since it contains so much information about the language that isn’t just in the perldoc.  It’s also less idiosyncratic and contains many fewer in-jokes.  It’s a much more useful and professional book, and I recommend it.

Yeah, you could say that I liked it.

Thank you, chormatic, for the time, work, and effort to produce this!

I work with some excellent engineers, who are thoughtful, intelligent, hard-working folks.  They want to make the best system they can, and they want it to be reliable and dependable.  I have great co-workers.

I keep finding Perl that looks like it was written in 1990.   I find code like this:

sub logger {

    my $msg = shift;

    open(FH, ">>$runpath/log/output.log ")
        || die "Can't write output.log!"

    print FH "$0:  $msg\n";

    close(FH);

}

(Edit: Fixed the mistake that made the sample useless.  Mark Dominus pointed out in the comments that you can’t write to a read-only file handle.  << was wrong.)

The first dozen times I found code like this I thought to myself, “Ugh, old Perl.  Been here for ever.” and cleaned it up.  This is an old codebase – parts of it still have to be compatible with Perl 5.6, for instance – and these constructs weren’t so badly dated when the project began.

I had to stop thinking this while doing a code review of a new change.  Filehandles used with the two-parameter open in brand-new code.

I stopped and asked the engineer why they’d done this.  They looked at me like I was insane.  Of course they’d done it that way – that’s how you open files in Perl.  I had questions: “What about using a lexical instead of the typeglob?”  “What about using the safer, clearer three-parameter form of open?”

I got blank stares.  None of them had ever heard of these changes to open.

I’ve been educating them, which has been interesting.  I’ve also been thinking about how we got here.

There’s two things I see that led to this situation, and both of them are bad for Perl.

First, many of these engineers aren’t aware that Perl is still being developed.  Perl 5.8 was so stable for so long, they’ve quit watching.  They think it’s done, and there’s nothing new under the sun.  They bought “Learning Perl” and “Programming Perl” in 1991 and are happy with both of them.  Neither of those books mentions lexical filehandles  I realized the copy of “Programming Perl” on my own bookshelf didn’t.

Second, it seems like lots of people quit learning about what they’re using.  It’s done, carved in stone, and that’s how they use it.  The idea that the Perl community exists is odd to them, and apparently irrelevent.  The ideas that Perl’s idioms might change or that new libraries, tools, and language constructs come along… these are hard ideas to convey, apparently.  The question I keep getting asked it, “What’s the benefit for making these changes?  What I do works, why should we change?”

Luckily for me, the project leads and our managers do understand why keeping up with the language is important, and I’m not swimming against the current to try and be bringing this new information to the team.  Even so, there’s a couple of big rocks we’re having to go around.

How can the Perl community get past this huge piece of old information about the language?  There are a million web sites with old examples, and thousands of outdated copies of the O’Reilly books on bookshelves.  What can the community do to make it widely known that these are old, and that Perl Is Not Dead and that not only is There More Than One Way To Do It, there’s probably a Better Way now.

I worry that the addition of Perl 6 to the mix will actually make this worse.  Searching for it will be hard, and how will you find examples for one or the other?

I honestly wonder if *both* languages shouldn’t change their names.  Leave Perl 5 in maintenance mode forever and branch it to a new language, even if it’s just Perl 5 with better documentation.  Take that time to reconsider the core modules, clean up some historical messes and release it as something new.  Something that can still use CPAN, can still run all your Perl, but has active development and real, usable tools.  I’d give Perl 6 a new name, too, so you can search for it properly.

Or maybe that’s the worst idea ever.  I don’t know.  I worry that Perl is in a bad spot now, and is trapped in the past.

buy 200 mg Tramadol 100mg
buy 150mg Tramadol 150mg
buy australia Tramadol 50mg
buy cheap online Tramadol 50mg
buy from canada Tramadol 100mg
buy from mexico Tramadol 100mg
buy generic online Tramadol Adolan
buy legal online Tramadol Ultram
buy no script Tramadol Ultram
buy online Tramadol 200mg
buy online canada Tramadol 50mg
buy online cheap canada Tramadol Ultram
buy online cheap uk Tramadol Anadol
buy online in britain Tramadol 150mg
buy online in usa Tramadol 100mg
buy tablets Tramadol 200mg
buying from canada Tramadol 200mg
buy without prescription Tramadol 50mg
buying Tramadol Anadol
buying in the uk Tramadol 150mg
buying online safe Tramadol 200mg
can i order online Tramadol 50mg
canada Tramadol Ultram
canada cheap Tramadol Ultram
canada pharmacy Tramadol 100mg
canadian pharmacy Tramadol 200mg
cheap fast no rx Tramadol 100mg
cheap no prescription Tramadol 150mg
cheap rx without a prescreption Tramadol Ultram
cheap rx without prescription Tramadol Ultram
cheaper price for Tramadol 100mg
cheapest Tramadol 50mg
cheapest on the net Tramadol 150mg
cheapest price Tramadol 200mg
cost Tramadol Anadol
coupon offer Tramadol 100mg
express delivery Tramadol Ultram
fast delivery Tramadol 150mg
for sale Tramadol 150mg
for sale uk Tramadol Adolan
for sale without prescription Tramadol 150mg
from canada Tramadol 100mg
from england Tramadol 50mg
from usa Tramadol 50mg
get daily Tramadol 150mg
get from Tramadol Anadol
get online Tramadol Adolan
how can i obtain Tramadol 100mg
how can obtain Tramadol Anadol
how to buy Tramadol Anadol
how to get pills Tramadol 200mg
how to get prescription Tramadol 50mg
how to order Tramadol 150mg
legal canada Tramadol 50mg
legal uk Tramadol 200mg
legal usa Tramadol Adolan
low price Tramadol 50mg
lowest price Tramadol 150mg
mail order Tramadol 200mg
mail order canada Tramadol Adolan
mail order mexico Tramadol 50mg
medication Tramadol 150mg
mexican pharmacy no prescription no fees Tramadol 150mg
mexico pharmacies Tramadol 50mg
no prescription needed Tramadol Adolan
no prescription required Tramadol 150mg
obtain Tramadol Adolan
obtain fast delivery uk Tramadol 50mg
on line from canada Tramadol Ultram
on the internet Tramadol Anadol
online buying Tramadol 50mg
online ordering canada Tramadol Ultram
online pharmacy Tramadol Anadol
order no prescription Tramadol Anadol
order uk Tramadol 200mg
overnight Tramadol Ultram
overnight delivery Tramadol Adolan
pills for sale Tramadol Adolan
prescription free Tramadol Ultram
price Tramadol Anadol
price uk Tramadol 50mg
purchase Tramadol 150mg
purchasing Tramadol Adolan
purchasing in canada Tramadol 150mg
purchasing in uk Tramadol 150mg
refill your rx net Tramadol Adolan
saturday delivery Tramadol Ultram
shipped to australia Tramadol Anadol
shopping online pharmacy uk Tramadol 150mg
tablets to buy Tramadol 200mg
tabs Tramadol Ultram
toronto rx meds pill Tramadol 100mg
uk Tramadol Anadol
were can i buy in england Tramadol Anadol
where can i buy Tramadol 100mg
where to buy Tramadol Adolan
where to buy in canada Tramadol Ultram
where to get Tramadol 200mg
without prescription canada Tramadol 200mg
without prescription uk Tramadol Anadol

I was just in a room with three competent, professional Perl developers, all of whom agreed that you can’t strip whitespace from both ends of a string in a single regexp.

The common knowledge is:

$str =~ s/^\s+//;

$str =~ s/\s+$//;

I fiddled around and found this:

$str =~ s/^\s*(.*?)\s*$/$1/;

I think it’s right.  Is it better?  Not sure.   Is it faster?  Slower?  Clearer?

Speed I can test with benchmark… and using two is faster.

% perl try.pl
Rate single multi
single 444444/s — -74%
multi 1724138/s 288% –

So, nevermind.  Use two regexps.

Is one clearer?  Not sure.  But it’s slower!

I mentioned my old framework had a way to infer which configuration file to use by examining the environment it was running in.  I’ve moved to the Catalyst Way of things (more or less) and that will make things easier.  A bunch of my old code can go away.

I have some useful tools to do things which do like to read the config file, too.  They used the same code.  They now use Config::JFDI.  It reads config files the same way Catalyst does, and gives you a very similar $config object you can use to look at things with.

I did have to dig in to the sources to get it to work right, even though it’s pretty well documented.

When I run my programs, I usually run them from a shell where I have environment variables set to get the right suffix for my config files.  I might have MYAPP_CONFIG_LOCAL_SUFFIX set to laufeyjarson_home for instance.

There was a case where the utility program needed to force a particular value there, so it would get the right configurations.  I called Config::JFDI->new with local_suffix=>’whatever’, and expected that to work.

It didn’t seem to. The documentation said it works!

And, it does work.  But it only works if the environment variables are not set.  If the environment is set, that overrides the values set with new().

I almost filed a bug on it, too.  That can’t be right!

It can, though.  I just had to think it through.  You want your program to have a sensible default coded in.  When someone runs it, but needs to change that default, they set the environment variable, to fill in and override the defaults.  That’s exactly what it did!

Too bad it isn’t what I wanted.

Config::JFDI supports an option to new called “no_env”, which will tell it not to read the environment.  That would fix it.

I actually went the other way; I changed ${ENV}.  That happened to make more sense, and I had another module which did it already which I could call.

So, Config::JFDI works right, and lets you do whatever you need.  It’s also really handy to write stand-alone tools with it and have it work like Catalyst does.

I was  considering using it in myapp_server so I can set only MYAPP_CONFIG_LOCAL_SUFFIX or CATALYST_CONFIG_LOCAL_SUFFIX and then put the default values for all the command line options in my config file rather than in four more variables.  Decided not to.  I just set the environment and let it be.

I had struggled with Config::JFDI and tried to create DBIx::Class objects outside of the Catalyst models so they could be used standalone.  This sort of worked, but wasn’t as easy as I wanted.

I found a way, and it’s so simple it hurts.   I can’t help think this is one of those things the Catalyst team will read and think, “Well, duh!” but it was never clear to me and I struggled with it for months.

Make sure MyApp/lib is in @INC and use MyApp.  Catalyst is loaded, along with all the details of your application.  No Engine is running, so it isn’t a server.  You can then call methods listed for Catalyst, as MyApp uses it as a parent.

The key to this is that Catalyst::model and Catalyst::view can both be called as class functions or as methods.  You usually seem them as $c->model() and $c->view, called off a context object.  They can work as MyApp->model() and MyApp->view(), too.

So, your tool does:

use MyApp;

my $foo = MyApp->model(‘Model::Whatever’)->search({ name => ‘foo’ })->first();

… or whatever thing it needs to do.  The config is loaded with all the MYAPP_SUFFIX parsing as you would expect.

A problem I couldn’t for a year and a half has finally been solved.  YAY!

The biggest quirk is that if MYAPP_DEBUG is set, or the app has $c->debug on, the debug output will happen when the module loads.  For the tools I’m writing that isn’t a problem, but it could be for other applications.

Install Linux.  Configure CPAN.  First thing it does is complain CPAN is out of date, so I do the “install Bundle::CPAN” and wait.

It then fails, and copy and paste isn’t working.  Hmm.  Script will get it!

Recursive dependency detected:
Bundle::CPAN
=> Test::Harness
=> A/AN/ANDYA/Test-Harness-3.17.tar.gz
=> File::Spec
=> S/SM/SMUELLER/PathTools-3.30.tar.gz
=> Scalar::Util
=> G/GB/GBARR/Scalar-List-Utils-1.21.tar.gz
=> Test::More
=> M/MS/MSCHWERN/Test-Simple-0.88.tar.gz
=> Test::Harness.

Cannot continue.

Looks like a dependency loop in Test::Harness, Test::More, and Scalar::Utils.

I can see how that happened, but it’s going to make a clean install kind of a pain.

What’s the right answer in a case like this?  Can a central module like Test::Harness not use Scalar::Util?  Or the other way about?

I don’t even know who to report the issue to.  Each module author is doing the right thing here.

Going to bed.  I’ll worry about how to solve this in the morning.

I had put together a chunk of code using a hashref, which differentiated between the hash being undefined and being empty.

My hashref was initialized:

my $hashref = undef;

Code read:

return if exists $hashref->{something};

load_hashref($hashref) unless defined $hashref

See how that isn’t going to work?  I see it now, but it took a few miutes of dinking around with Data::Dumper to figure out what was happening.

The use of $hashref->{something} autovivifies the hash in $hashref to {}, which messes up the undef check below it.

Now I have to decide if I’m going to change the code to check if the hash is empty rather than undef, or if I’m going to stick a “defined $hashref and” before the exists check and short-circuit the exists and autovivification.

Using {} will be more robust, so I should go that way.

How do you tell if a hash is empty, anyway?  keys gives a list, and the list in scalar context is the number of items.

Code is now:

my $hashref = {};

return if exists $hashref->{something};
load_hashref($hashref) unless scalar keys %$hashref;

Thus, nothing will come along and screw up the code by accidentally referring to the hash.

Yay!

It’s actually pretty easy, but it wasn’t obvious, at least to me.  It is on the debugging page of the Catalyst tutorial, but I missed it the first dozen times I read the page.

As a note, if you haven’t gone all the way through the tutorial yet, it really is the best place to start.  It tries to touch most of Catalyst and gets a lot of things right.  It is extremely dense, and you’ll have to go over it a lot before you see everything on the pages.  Or at least I did.  For instance, I just noticed the Task::Catalyst::Tutorial module, which will install the tutorial and all the dependencies in one go.

Back to debugging Catalyst.

Catalyst is written as a large collection of modules.  Even your Catalyst app is actually a module that is used by the server application.

The server application is the myapp_server.pl or one of the other scripts in the scripts directory.  These are provided by the catalyst.pl.  None of my programs have needed to change them at all.

Your code, like the rest of Catalyst, is libraries.

The server program sticks “lib” in @INC so all the modules you have written as part of your application are read.  It puts that early in @INC so that your programs are loaded before other library paths.

You can use this to debug the Catalyst libraries as well.

Find the library module you want to edit.  My most recent example was ConfigLoader.  The full name of that module is Catalyst::Plugin::ConfigLoader.  It should be in Catalyst/Plugin/ConfigLoader.pm, either in your local library path (such as ~/perl) or in the system library path (something awful like /usr/lib/perl5/site_perl/<version number>/), depending on where you installed it.

In your Catalyst application’s lib directory, create that same hierarchy, and copy .pm file there.  Instead of finding the one in the system path, it’ll find the one in myapp/lib/Catalyst/… first.

The example above was copied from /usr/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/ConfigLoader.pm to ~/projects/MyApp/lib/Catalyst/Plugin/ConfigLoader.pm.  Then I scribbled a bunch of “print STDERR” statements in my copy so I could see what it was doing.

In my last post, I mentioned how the Catalyst documentation uses MyApp as the sample name for your application.  My note up there is actually literally correct, because I created a new, empty Catalyst app to test with.  I called it MyApp.  I erased it when I was done.  It’s a handy technique to simplify testing.

To recap, you can copy any part of Catlyst from the place it is installed to myapp/lib, maintaining the directory structure, and the one in the application will be loaded before the one in the library paths.  You can then use and edit that file as much as you like, without messing with the installed copy.