So now when users download and run my programs/scripts for the first time, instead of failing with the dreaded message:
Can't locate Foo/Bar.pm in @INC (@INC contains: [a dozen or more of paths....]).
BEGIN failed--compilation aborted at /some/path line 123
which users or even Perl novices have no clue on how to fix, the program will instead automatically download every necessary CPAN modules into the user's home directory and runs out-of-the-box on the first try!
If you've been using Subversion or (shudder) CVS, you only have the briefest glimmerings of what source control is about. I don't really like having to dig too deeply into tools that I use. I want them to be easy, but I dig when something's hard.
On thing which frustrated me about Subversion is that fact that, as mentioned, I don't think about some things. More than once I've quickly hacked up a change to a module, switched other modules to use that module and do a quick svn rm and svn add.
Oops. I just lost my version history. Damn it.
Not with git. It figures it out for me. My Veure project uses DBIx::Class::Schema::Loader because I don't want to think about building my schema classes. The 0.5003 version is fantastic. It does a better job of naming relationships and the DBIx::Class::Schema::Loader::DBI::Pg support is fantastic.
I stumbled into a tricky situation with Search::GIN that required me to have a reverse indexing with set introspection. This situation isn't so rare, so I thought it would be helpful to share how I did it.
Suppose I have an object. The object has an attribute. The attribute is a set of objects. I need to be able to fetch the objects according to the value of an attribute of the objects in the set in the attribute of the original object. Err.. ya know what? Here's an example!
I have a few music preferences (blues, jazz, etc.), a few simpsons characters (Lisa, Homer, Barney). Each of them likes certain types of music. Lisa likes blues and jazz, while Barney only likes blues and Homer just likes stupid commercial jingles.
It seems that over the last days, around 20% of the mails I have sent from my yahoo.com account did not reached their destinations, didn't I get any notification about the failure.
If you were expecting a reply to some particular mail from me and didn't got anything, you are probably one of the "lucky winners". Just ask for your reply and I will resend it!
But if you're writing scripts/applications (and thus need to "consume" or display the logs as well), it becomes a bit of a hassle. For example, if you want to display logs to the screen with
Log::Dispatch
, this is the incantation you need:
So let's say you're looking around for a Web-based email client. Even though the Application Service Provider industry has struggled, many people want Web-based email. So when you evaluate an email client, what are you looking for?
You probably want to be able to send email. You probably want to be able to receive email. In fact, I'll go out on a limb and suggest you might want to read the email you receive. So when you are looking at email clients, what's the one feature you really, really want?
You might think, I dunno, that email is an important feature of email clients. Yahoo! thinks you want to send e-cards.
How often have you wanted to cut n paste a module name from some error message onto the command line and just edit the damned file? Isn't it a huge pain in the arse changing all the :: into slashes?
function vi {
VI=/usr/bin/vim
INARGS=("$@")
OUTARGS=()
for i in ${INARGS[@]}; do
if echo $i|grep ::>/dev/null; then
OUTARGS=(${OUTARGS[@]} `echo $i.pm|sed 's/::/\//g'`)
else
OUTARGS=(${OUTARGS[@]} $i)
fi
done
$VI ${OUTARGS[@]}
}
There, I fixed it :-) Now you can do this and it'll Just Work:
Even though I helped on various projects, I never really got a bug report on a project of my own. I've gotten offline requests (usually from people who know me personally), but never an actual RT ticket.
Today I got my first RT ticket (in the mail) and I've very proud of it!
Apparently there was a change in Template::Tiny's API. mst made it more compatible with Template::Toolkit and Adam Kennedy released Template::Tiny 0.11 and took the time to open a ticket with Dancer::Template::Tiny to require 0.11 and up, and update the code. I've updated the code, changed the requirement and done the same with Task::Dancer. Both of them on the way to CPAN as we speak.
Why am I sharing this small tidbit? (isn't tidbit a funny word? I think it is)
Completion in bash is hard-wired to understand trailing slashes as “the user might want to do more completion right after this” – we want :: treated that way instead but there is no way to tell bash.
This is still true, but reading the manpage a little less carelessly reveals that passing -o nospace to the complete command tells bash to simply never append a space, which achieves what is desired without hacks.
While I was in there, I found -o default, which means that if the completion generator returned no results, bash should use its default completion generator instead. This is very useful.
This version is completely rewritten to to make it easier to extend later (more like one big dispatch table), and has improved debugging, usage messages, errors etc.
Try: (with a server running on localhost)
use ElasticSearch;
my $e = ElasticSearch->new(
servers => '127.0.0.1:9200',
trace_calls => 1,
);
$e->nodes;
So, you've got a problem with something perlish. What language do you use to solve it?
My particular problem is that my CPAN-testing machines were all fed off CPAN's RECENT file (eg http://www.cpan.org/RECENT), which would update every few hours. This is apparently no longer being updated, instead there's a much more up-to-date YAML file (http://www.cpan.org/authors/RECENT.recent) that updates within seconds of something hitting the PAUSE. But my ugly lash-up of shell scripts expects the old format, so what's a boy to do?
I *could* write some perl that uses LWP::Simple and YAML to grab the file and parse out the information I need. Alternatively, I could do this:
So, you're deep inside of a series of functions and you find that you really, really want what is effectively a goto: that is to say, you want to jump right out of all of those functions to the top level. Many people think "aha!, I'll just throw an exception."
Years ago, many Java programmers used to do this (of course, Exceptions are first class in Java). To paraphrase Mencken, it was simple, easy, and wrong. As understanding grew of how exceptions should be used, it was learned, surprisingly to some, that exceptions should be used for exceptional conditions. One rule of thumb was that exceptions (like aspects later) should be reserved for code where, in theory, if nothing went wrong, they could be completely removed without affecting the program's correctness. So you might throw an exception if you fail to open a file, but if you're iterating over the lines in that file (and if it's OK for that file to have no lines), then you don't throw an exception just because you've reached the end of the file. EOF is expected. Failure to connect is not. Unfortunately, failure to understand failure caused some horrible knock-on effects.
Recently I've spent more time with Dancer development, since it's such a fast, fun and flowing project. I've written Task::Dancer (after bugging a few people on #toolchain - thanks daxim!), Dancer::Template::Tiny and even patched Dancer::Template::Tenjin (and thanks to Ido for released it so quickly!).
Once thing I recently implemented in Dancer is Route Caching. Route Caching is a new term - at least for me - since I don't remember seeing it elsewhere (though I wouldn't be surprised if it's implemented in other frameworks).
When Dancer gets all the routes you want, it compiles them into regular expressions in a registry and then matches each request against the compiled routes, returning the first match. Route Caching allows to cache the path matches.
Today I released Text::BibTeX 0.40_3. I hope it to be the final release (that is, 0.40 will get out with the same code). But I just tested it with Strawberry Perl, Linux (Arch Linux) and Mac OS X (intel, Leopard).
We can't test on all available architectures, and that's why CPAN Testers exist. Long live to them. But sometimes it would be cool if we could use a machine and do some experiments before releasing. Waiting for the module to be picked and tested is not an efficient method.
It would be cool to create a set of queues (one per architecture/operating system) where CPAN authors could submit a module to be tested. The module would be installed, tested, and a report generated. It would be nice to check the current waiting list on each queue, so we can have an idea of how things will evolve.
I'm in the process of writing a test suite for ElasticSearch.pm, but in order for it to run any tests, it requires access to an ElasticSearch cluster.
Currently, I just skip all tests unless $ENV{ES_SERVER} is set, but this requires manual installation / testing.
Alternatively, I could (if $ENV{ES_SERVER} isn't set) try to download and compile a test version, which requires git and java v 1.6 or higher. It doesn't take long to compile, but long enough so that user may not want to do it by default.
So I could ask them if they want the script to build a test server, but again, this requires manual installation.
It'd be nice to use the cpan testers to run the test suite on multiple platforms, which implies building a test cluster by default.
Recently I started a new project at $work in which I'm using a lot of cool projects (DBIx::Class, KiokuDB, Search::GIN, POE and Dancer to name a few) and it involved a lot of layers so I wanted to do this one just right.
I finally started using KiokuDB and it went relatively easy, though Search::GIN is still lacking (and 0.4 still hasn't been released to CPAN, so I'm relying on the code on Github). It's amazing how easily I can write tests with KiokuDB and plug my stuff in and out. Sometimes, I have a hard time realizing it's that simple.
Some of you will be aware of one of my projects that is driven off CPAN-testers data: the cpXXXan. Well, I'm in the process of extending it. Soon it will grow a cpNETBSDan tentacle, and likewise for some other OSes. Once I'm convinced that it works and is reasonably efficient, I'll probably make it so that you can filter by both OS and perl version, using hostnames such as irix.cp5.8.9an.barnyard.co.uk.
Dancer is a simple and lightweight yet powerful web application framework which I recently discovered (and blogged about) when I was looking for a framework I'd actually enjoy using to write web apps.
A (very basic) Dancer web app can be as simple as:
#!/usr/bin/perl
use Dancer;
get '/hello/:name' => sub {
return "Why, hello there " . params->{name};
};
dance;
I adopted Text::BibTeX a long time ago and had a lot of complaints about its installation mechanism. This was mainly due to the fact that Text::BibTeX depended on a C library that needed to be installed prior to the perl module. The C library installation was easy on generic Unix platforms but was a pain to compile under Windows.
After lot of work I managed to include the library C code in the Perl module (now Text::BibTeX has no dependencies on the library), and managed to include code to compile the library in Windows, using the Strawberry Perl distribution (that includes a mingw C compiler).
The package is needing heavy tests, but it seems usable for most users. Probably I will post on the details about its build system in a later post, as it involves Config::AutoConf methodology to detect a suitable method to compile a standalone C library.
