Here's an E-Mail that was sent to Hinrik:
I want to buy a Marklov pluggable engine, Where can i buy one, i am coming to
Iceland for a visit, can i come to your shop?
And, in another E-Mail sent to me:
Hi,
I would like to buy a Hailo. Where can i get one and how much do they cost?
Thanks Julie
Clearly I should quit my dayjob and start selling copies of Hailo on CD in a dedicated store just for this purpose.
More seriously though, is anyone else getting similar spam these days about their CPAN distros? It seems odd to get a couple of these E-Mails within a few days.
We did have someone contact us a couple of years ago legitimately wanting to buy a license for of Hailo. It took quite a long E-Mail exchange to convince that person that yes, we were in fact giving it away for free.
]]>Moose will simple die if you pass it a value that violates a type constraint, in an environment where you control the whole stack this is usually what you want, but when you're dealing with data from other people and user-supplied parameters you often want to handle the situation more gracefully.
Curtis pointed this out on the Moose mailing list, and quickly found that this was something covered in the Moose FAQ.
I hacked up something that would change the behavior globally, but of course this is something you want to do on a per-attribute level. Jesse Luehrs provided a basic implementation of it which I expanded on, and which I've now uploaded to the CPAN as MooseX::Attribute::TypeConstraint::CustomizeFatal
The module allows you to tweak what Moose does when a type constraint fails on a per-attribute level. The default is to die as Moose does by default, but you can also make it warn and accept the bad value, or warn and fall back on the default value, or just silently ignore the bad value and fall back on the default value.
]]>So I wrote a short one-off script to find out what words I cound construct from the flags.
Now it just gives you one word that contains as many of the flags as possible, and gives you the remainder. What would be more interesting would be to detect cases where multiple valid words can be made from the flags. E.g. "mix" and "uploads". It just detected that by accident.
I leave that as an exercise for the reader.
]]>#distzilla. Most modules depend on other modules, but some don't depend on an explicit version. So if you use the module with an ancient version of one of its dependencies it'll break, because the author never tested that version.
We've probably all run into problems as a result of this and grudgingly upgraded the dependencies as a result, but could CPAN clients handle this better?
Technically they're doing the right thing already. The CPAN clients are unable to distinguish between "explicit 0", "any version will do" and "author didn't say".
So what would be a better heuristic? Some suggestions:
Make sure that dependencies aren't much older than the module that requires them. Something in the spirit of:
Are you sure you want to install this shiny new version of Web::Some::Thingy but still use your 4 year old copy of DBD::SQLite? Install the new DBD::SQLite? [Y/n]
Query some publicly available submission system like the CPAN metabase:
You're trying to install Web::Some::Thingy with a 2 year old DBD::SQLite, but test results show that you need the 6 month old version not to get test failures. Install the new DBD::SQLite? [Y/n]
I should reiterate that CPAN clients are doing the right thing already with regards to the relevant standards. But it can be useful to also account for the human factor.
Update: chromatic pointed out on the Modern Perl Books blog that you could set the recommended minimum version to whatever the developer happened to have installed when testing the module (and I'm replying here since it seems that his OpenID method is broken).
I think that alternative is probably the worst of the lot, some CPAN authors do that and it causes all sorts of problems for people using downstream distributors of the CPAN.
For example if you develop on v5.13.5 as I do, and depend on Test::More you'd implicitly depend on version 0.97_01 using this method. Even though the 0.92 version included with perl v5.10.1 would probably do just fine.
By depending on the latest version someone trying to use your program with Debian, RHEL or other third-party package systems will run into problems. Uers show up on IRC all the time with this problem, and more often than not the answer is "ignore the prerequisite versions, your old module will work just fine". At best they're using the CPAN directly, and will have to needlessly upgrade & test a lot of their dependencies.
Adding automatic soft dependencies as one commenter points out would probably be more useful.
But either solution would require awareness and diligence by CPAN authors, and new releases of the offending distros. Given the human factor of this problem a change in the CPAN clients would probably work better, and would trickle down to existing releases.
]]>git diff as the context line in diff
hunks. Git includes presets for several
languages
but no presets for Perl and Perl 6. I'd like to change that.
If you have no idea what these are, consider a file that contains this code:
sub foo {
my $x = "a";
my $y = "b";
my $z = "c";
my $poem = <<"POEM";
This is a
Long string
In a heredoc
POEM
I'm::On::A::Horse();
}
Now, if you change the last statement in that subroutine to
something more clever and run git diff you'll get this:
diff --git a/file.pl b/file.pl
index 7ed4207..ffb1ff9 100644
--- a/file.pl
+++ b/file.pl
@@ -7,5 +7,5 @@ This is a
Long string
In a heredoc
POEM
- I'm::On::A::Horse();
+ The::Tickets::Are::Now::Diamonds();
}
In that diff this is the context line:
@@ -7,5 +7,5 @@ This is a
Having "This is a" there doesn't provide very useful context, but that
can be changed with userdiff, just add this to .gitattributes:
*.pl diff=perl
And this to .git/config:
[diff "perl"]
xfuncname = "^\\s*(sub.*)"
And the hunk context is now more useful, and shows the name of the subroutine that's being changed:
@@ -7,5 +7,5 @@ sub foo {
I'd like to extend the Git defaults to include Perl, but I'm
probably forgetting some cases where something is subroutine-ish
that doesn't match simply "\\s*(sub.*)". Other cases I can think of are:
Then there's the issue of Perl 6. I'm completely unfamiliar with it, but I can add it while I'm at it if I'm given some examples.
The userdiff facility also has support for defining a "word" for the
--word-diff
option to git diff. I don't use this option, but I wouldn't be
surprised if it did the wrong thing for Perl code.
when (m[//twitter\.com/(?<user>[^/]+)/status/(?<id>\d+)]) {
require LWP::Simple;
LWP::Simple->import;
my $user = $+{user};
if (my $content = get($ARGV[0])) {
my ($when) = $content =~ m[<span class="published timestamp"[^>]+>(.*?)</span>];
my ($twat) = $content =~ m[<meta content="(?<tweet>.*?)" name="description" />];
if ($when and $twat) {
say "Twat by $user $when: $twat";
It prints the full contents of a tweet to IRC given a URL, here's the full program.
In a previous life I'd have used HTML::TreeBuilder, but after I actually wrote a bunch of simple scraping programs I found that I was wasting my time. Proper HTML parsing where you're extracting the value of a tag given a class breaks just as hard when the other side completely changes their HTML layout.
That's what they usually end up doing in my experience. I've rewritten the guts of POE::Component::IRC::Plugin::ImageMirror's _mirror_imgshack at least 5 times now, none of which would have been helped with a proper parser.
Of course I'd use a proper parser for something like getting the nth element of a table, I'm not crazy. I just can't be bothered for something simple like the above.
Don't be afraid to use powertools, but don't be afraid to use the incorrect and stupid version whose API you don't have to figure out all over again when stuff breaks unexpectedly either.
]]>Before switching over I ignored Debian's perl library packages, and installed everything with cpanm into /usr/local. But since I wanted to use the new post-5.10 features of Perl I thought I might as well replace all of it and use a newer perl.
What I did:
v-perlbrew user. All users on the server can use this centrally managed Perl and its modules.bashrc: test -f ~/perl5/perlbrew/etc/bashrc && source ~/perl5/perlbrew/etc/bashrcgrep -v ^# cpan-modules | cpanm to get all the required modules with the new perl.PATH in crontabs, Apache settings etc. so that everything that isn't internal to Debian itself uses perlbrew's perl instead of /usr/bin/perl.Getting the PATHs right everywhere turned out to be the hardest part. A lot of things in Debian have a path like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin. I haven't found out how to change that, presumably some of them are hardcoded into executables like bash.
To get around that I have to hardcode the PATH to perlbrew in every crontab that uses perl. For a full list of these and other changes I've made the output of git --git-dir /etc/.git log -p --reverse -Sperlbrew available as a Gist.
The only caveat I've encountered is that there's one global perlbrew bashrc in ~/perl5/perlbrew/etc/bashrc. So if I can't use perlbrew switch to only switch some users onto a given perl. It would be neat if perlbrew supported having the current symlinks in a local ~/perl5 while the actual binaries and modules were in ~v-perlbrew/perl5.
The compatibility problem with Devel::Declare code like Module::Signatures::Simple that I previously blogged about has been fixed. It can now profile inside string evals, and more.
Update: Tim Bunce now has a posting about NYTProf 4.00 on his blog.
]]>Here's the latest version of the patch series I posted to the Git mailing list.
For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.
Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.
Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.
There was a recent-ish study of social networks on GitHub where it was evident that a lot of Japanese Perl users had formed a social-ghetto amongst themselves. I've seen a few trending Perl repositories that only have README files in Japanese.
Maybe better localization tools - and most of all - a commitment to use them would help to bridge some of that.
]]>Now I've tested out Method::Signatures::Simple. It's powered by Devel::Declare and doesn't seem to incur a any runtime penalty. However, since it needs to do some work when the subroutines are compiled, there's a 3-4% compilation hit for my tests:
But on runtime there's no hit at all:
Here's what I needed to do to convert Hailo to it. Unfortunately using it breaks interaction with Devel::NYTProf. When I generate profiling output with nytprofhtml what were previously links to my subroutines aren't links at all.
That's a big price to pay for just turning this:
Into this:
So unless I can figure out a workaround for that I won't be merging that branch.
]]>license = DWTFYWWI in Dist::Zilla, and anything else that uses Software::License.
It's the first Software::License::* not in the core Software::License distribution (RJBS refused my patch to integrate it). It might not be for long, FLORA has threatened to release WTFPL support.
blead and one new feature. The prctl() support for $0 that I previously blogged about just got commited by Steffen Mueller.
With this patch you can finally killall programs you write in perl on Linux without killing all of your perl processes indiscriminately.
Here's how you can do that:
All tests should have been successful. To install it (without touching your existing perl!) do:
Now you have an installed perl-5.12.0-RC3 in ~/perl5-rc3/installed/bin/perl. Now just configure CPAN to install modules without nagging:
And then maybe try installing your favorite CPAN modules, or bundles that suck down a lot of them (using sudo here because my ~/.cpan is owned by root):
Of course the most useful think you can do is test it on your own in-house code. All the code on the CPAN has probably been tested with 5.12 already.
If you encounter any issues first check if they're listed in the errata or mentioned in the perldelta for 5.12.
if you think you've found a new bug please report it with the perlbug tool installed with perl-5.12.0-RC3.
]]>