We are happy to announce that PetaMem supports YAPC::Europe 2012 as a silver sponsor.
The PetaMem Group stands for substantial competence in human language
technologies, namely natural language processing and natural language
understanding. Our systems cover all areas from language
identification over machine translation to discourse systems (virtual
agents) and are used worldwide by top-profile corporations as well as
governmental institutions.
We consider Perl not just a programming language. For us, it is the
key technology responsible for the performance and success of our
systems. Designed by a linguist and applied in computational
linguistics, Perl allows us to declass those competitors who are not
using it.
I've been thinking about the way I write Perl subroutines and methods as compared to some other Perl programmers, and I've decided to write a post about it.
To make my subroutines and methods more reusable, extensible, and maintainable, I make them receive a hash reference as their only argument and return a hash reference. This has multiple benefits.
First, the parameters going into the subroutine are named when passed in, and these names are used to identify them inside the subroutine. This means that new parameters can be added with keys in the hash, a very minimal change. The same is true of the return hash. Using keys in a hash is far simpler to maintain than using positions in a list. I've spent enough time wrestling with indexed parameters in subroutines that I never use lists of parameters in code that I expect to use more that once (which is basically all of it).
Despite of what's expressed in this blog post, I am generally responsive (as can be seen from my RT track record) and willing to be cooperative (or rather, not really willing to be uncooperative). I even often do the opposite of what I wrote below. It's just that sometimes you need to vent.
On people suggesting to use File::Spec (or Path::Class) everytime... Have using hard-coded "/" failed these days (on platforms that I care about)? Why do I have to subject myself to the verbose file('a', 'b', 'c') or even the masochistic File::Spec->catfile('a', 'b', 'c'), when 'a/b/c' works? The platforms which do not use "/" path separator are either old, dying, rare, or all of those. And new platforms being written won't even dream of not obeying the /. It's already becoming the overwhelming majority that assuming it works everywhere is the best practical approach.
On the other hand, issues like case-sensitivity or encoding in filesystems are still very real and common...
It was a pain to debug clang -faddress-sanitizer instrumented executables, because variable values were not visible, though they should be. It was caused by wrong stack realignment, triggered by -faddress-sanitizer, but it really was a clang bug.
My major interest is in parsing theory.
But,
according to Google Analytics,
most of my web hits are for a side interest.
A few years ago I discovered
the
Lost Morgenstern Document,
an account of
Kurt Gödel's citizenship hearing which had
gone missing for so long there was doubt it had
ever existed.
Einstein was at the hearing and
Einstein's fame,
plus the fact it's a good yarn,
make the Lost Morgenstern Document
a matter of fairly wide interest.
This post is about another Gödel document
which recently surfaced.
This document does not make a good yarn.
In fact, in terms of reading difficulty,
it ranges from the moderately hard to the low-grade cryptographic.
But the
Rucker Notes
are considerably more important
than the Lost Morgenstern Document.
I’ve been writing programs in Perl since about 1999. Wow, that’s a long time now. That was way back when I was studying Computer Science and working for the IT department of the University I went to. I still write Perl programs these days, at my current job, where we call it Application Development.
Since I like Perl development a lot, and I like learning about Perl, I figure I might like writing about Perl too. So that’s what I’m thinking of doing in this blog. I hope some of you find it interesting and useful. After all these years of experience, I might have something to say that you might find useful and/or interesting, especially if you are starting out with programming and/or Perl coding.
People should write (more) books on CPAN instead. Here are some ideas.
1) The best of CPAN. A curated list of modules, picked by the editor. I would prefer a task-oriented organization. Every mention of modules should also at least mentions its maintenance status (is it actively maintained? is the author responsive? bug queue? are bugs getting fixed?), performance characteristics, strong points, drawbacks, interface. Tasks doable by Perl's builtins and core modules can be mentioned too, although the editor should not dwell too much on those.
2) Creating and maintaining your own CPAN. minicpan, Pinto, carton?, ... Potential reader base include Perl shops and corporate users.
3) Definitive guide to Acme::. Fun things, stories behind the modules, (mostly) useless tricks employed by the modules. I want to a fun, entertaining, light read. Should be 100 pages or less. In the age of ebooks, could perhaps sell for $5-$10? I'd buy it.
4) The worst of CPAN :) A bit like #3 in spirit, but more "coding horror" style.
This is the first part of what will be several parts. The next part may be more interesting to a general audience: what are some of the cool new features of the debugger? But since I am assuming we are all geeks here, I want to talk about some of the geeky aspects first. And be warned -- there are much more geeky things I'd like to talk about. This then constitutes then the more general and less involved geeky aspects...
I should say at the outset that I did this with a lot of trepidation. The Perl debugger that comes with Perl is venerable and has a long history. In fact, one of the 3 or 4 things that attracted me to Perl4 over the competition at the time — the Korn or Bourne Shell — was its debugger. And over the years various features have been added to the standard Perl debugger that make it very powerful.
Deven Corzine is revitalizing the Advanced Perl Users group on LinkedIn, and I've volunteered to help. We're going through all of the join requests to approve everything we can, delete the obvious spam and HR requests, and figure out what to do with the rest.
But, besides clearing out the backlog, I want to quadruple the number of members in the group by the end of summer (which is sooner than Christmas). We have 250 members right now. I want that to be 1,000.
LinkedIn is essentially a trust network that relies on connections and recommendations for other people to get a quick read on strangers. That's amplified with controlled groups, such as Advanced Perl Users group on LinkedIn, which is set up so "new members will only be approved if an existing member is willing to personally vouch for the new member". Deven's intent is to have a group of serious Perl programmers who we'd want to hire ourselves.
I’ve been writing tests for a web service in which one of the methods would occasionally take an inordinate amount of time. The amount of time was inconsistent and it would be useful to capture some timing data to provide the vendor. But, I didn’t want to litter my test files with code to calculate the elapsed time. Eventually, the bugs would be worked out and the timing information would just be noise.
So I wanted to somehow hook into the test framework itself to give me the timing data.
Is including Changes information in main module's POD a good idea?
You bet. Typing "man Foo" or "perldoc Foo" beats having to go to search.cpan.org or metacpan.org and search for Foo and click some more. Or having to download the distribution, extract the tarball, and viewing the Changes file.
Well, actually, it's a good idea as long as module authors don't have to do it manually.
UPDATE 2012-09-07: I changed my mind :) After creating an alias chg to a command that views Changes in my local repositories, and chgr to cpan-listchanges, I no longer find Changes in the POD appealing. So all I needed was an easy access to Changes.
I am happy to announce that Galileo CMS is now available from CPAN! This project has been my on-train side-project, but its come a long way in a short time. The most exciting thing for me is that its entirely installable from CPAN. To try it out, simply do
$ cpanm Galileo
$ galileo setup
$ galileo daemon
of course, you can also run it using the servers provided by Mojolicious, or using your favorite psgi-compliant server (as long as they support websockets).
Authorized users edit pages using markdown with a live-preview. All updates to pages, menus and users are sent via websockets. Styling is courtesy of Twitter’s Bootstrap library.
The first issue of the Perl Weekly was sent out on 1st August 2011. Almost a year ago.
In case you don't know what it is: It is a weekly e-mail with a curated collection of links to the most intersting, Perl-related articles of the previous week. As seen by myself.
I wrote about it several times on this forum, but I think this might be a good opportunity to mention it again. There was also a suggestion that people should brag about the stuff they build. I totally agree.
If you are already a subscriber, let me thank you for your support!
If you are not yet a subscriber, let me invite you to check out the web site, the archive and to subscribe to the Perl weekly newsletter.
Not always. In user-facing applications, where the list of installed and enabled plugins is clear, then plugins are often a good thing. This article is concerned not with end-user facing applications, but with libraries. Libraries that allow their functionality to be extended through plugins. In particular, libraries that automatically detect and load all installed plugins.
Plugins aren't always obviously plugins. In this article, I'm defining a plugin as a software module that adds additional functionality or modifies the externally observable behaviour of the existing functionality of the core piece of software. Call it a "plugin" or an "optional dependency" - it's the same thing.
Just an FYI, if you're using Business::Shipping in your app and also Log4perl, then Business::Shipping will clobber your Log4Perl config with it's own. A quick work around for this is:
use Business::Shipping;
Log::Log4perl->init($your_own_config_file_path_goes_here);
Basically clobber Business::Shipping right back.
If I get some round-tuits I'll submit a patch to fix this problem. If the author of Business::Shipping were using something like Log::Any then he could spew out his logs, and the consumers of Business::Shipping could simply load the appropriate adapter rather than having Business::Shipping clobber the Log4perl global config. I guess technically this could be a bug in Log4perl using globals too. Anyway, this little work around should get you by in the mean time until a patch can be authored to remedy the problem.
I just uploaded to Crypt-SSLeay 0.60 to PAUSE to address RT #77167 and CPAN testers failures with the previously released version. The former was due to the fact that SSL v2 is no longer supported on various platforms, and the latter due to the fact that LWP::Protocol::https was not specified as a dependency.
Most of the changes leading up to 0.59_03 were similarly minor and straightforward. However, one addressing RT #64054 attempted to deal with incomplete reads and writes in a better way, and is a significant change from the original codebase.
A grand tradition of the YAPC::Europe are the Lightning Talks, 5 minute presentations
about any topic. We plan three sessions of Lightning Talks, one every day.
Léon Brocard has graciously agreed to host the Lightning Talks.
I dislike the interface because it forces me to remember/decide/do too many things. I don't want to have to remember whether to use timethis()/timethese(). I don't want to have to pick the appropriate $count. I don't want to have to label the subs. With Bench I can just type:
% perl -MBench -e'bench sub { code }'
% perl -MBench -e'bench [sub { code1 }, sub { code2 }]'
Guess what, I got tired of having to type the above too :-) So now with the latest release of Bench, a command-line script bench is provided. You can now just type:
