Dave Cross posted a photo:

via Instagram bit.ly/2J5PaoG

author: Sean Platt
name: David
average rating: 4.30
book published: 2013
rating: 0
read at:
date added: 2019/06/24
shelves: currently-reading
review:

author: Louise Wener
name: David
average rating: 4.25
book published: 2010
rating: 0
read at:
date added: 2019/06/24
shelves: currently-reading
review:

Dave Cross posted a photo:

via Instagram bit.ly/2Y3RQtt

Dave Cross posted a photo:

via Instagram bit.ly/2IvqNBG

Dave Cross posted a photo:

via Instagram bit.ly/2L7VTBo

Dave Cross posted a photo:

via Instagram bit.ly/2IvO9Hx

I’m not sure that I’ll have time to do these every week, but here are my answers to this week’s two Perl Weekly Challenges.

Challenge #1

Write a script to replace the character ‘e’ with ‘E’ in the string ‘Perl Weekly Challenge’. Also print the number of times the character ‘e’ found in the string.

use strict;
use warnings;
use feature 'say';

$_ = 'Perl Weekly Challenge';

my $count = tr/e/E/;

say;
say "$count changes";

Nothing really complicated here. We can discuss why I reached for tr/.../.../ rather than s/.../.../. I just think it’s silly to invoke the full power of the regex engine when you’re only changing a few letters.

Challenge #2

Write one-liner to solve FizzBuzz problem and print number 1-20. However, any number divisible by 3 should be replaced by the word fizz and any divisible by 5 by the word buzz. Numbers divisible by both become fizz buzz.

perl -E'say +(fizz)[$_ % 3] . (buzz)[$_ % 5] || $_ for 1 .. 20'

This is a bit more interesting. And I have to say that I think this is deeply dirty code. Over the twenty plus years I’ve been writing Perl I’ve trained myself to write code that is use strict and use warnings clean. This code is very much not that and with warnings turned on, you’d see a lot of warnings!

So how does it work?

The core is the (string)[index] construct.  We all know that you can access an individual element in an array with code like $my_array[$index]. But you can also do this with a list of values. For example:

('foo', 'bar', 'baz')[1]

returns “bar”. I often use this when I only need some of the values returned by localtime().

my ($d, $m, $y) = (localtime)[3, 4, 5];

Here, I’m using something very similar. (fizz)[$_ % 3] is looking up a value in a list that contains only a single value (the string “fizz”). So if the index is zero then we get the first (and only) value in the list. If the index is anything other than zero then we’re looking for an element that’s off the end of the list and Perl gives us undef, which is interpreted as an empty string. And the index expression, $_ % 3, gives us zero if $_ is exactly divisable by 3. There are two things here that would throw warnings under use strict and use warnings. Firstly, “fizz” is a bareword and secondly, we’re using undef in a concatenation.

We then repeat the same logic using “buzz” and 5 and we concatenate together the results of those two expressions. That gives us either “fizz”, “buzz”, “fizzbuzz” or the empty string. Of those values, only the empty string is seen as false, so we can use || $_ to replace that with the original number.

There’s one mystery left. Why have I put that + before the first expression? I think I’m going to leave that as an exercise for the reader. If you work it out, please leave a comment.

And there we have it. A solution that is simultaneously both horribly dirty and yet, I think, rather clever.

Have you come up with your own solution yet?

Update:

It’s been pointed out to me that my solution for challenge #2 prints “fizzbuzz” for 15, when the specification clearly asks for “fizz buzz” (with a space). So here’s a version which fixes that:

perl -E'@a=((fizz)[$_ % 3]//(),(buzz)[$_ % 5]//()), say @a?"@a":$_ for 1 .. 20'

The post Perl Weekly Challenge – 2019-03-25 appeared first on Perl Hacks.

I'm pretty sure this will make no sense whatsoever without me talking in front of it

The European Perl Conference this year is going to be held in Riga in August. That might seem a long way away, but it’s never too early to start thinking about these things. For example the conference web site went live earlier this week, enabling users to register for the conference and buy their tickets.

And people who are planning to speak at the conference or run workshops alongside the conference need to get their act together early so that people who are planning to attend the conference know what is going to be happened. In particular, it’s a good idea to get the workshops organised and announced early so that people booking flights and hotels for the conference know that there are workshops taking place in the days before (and, sometimes, after) the conference and can book travel for the right dates.

So I’ve been thinking about what I want to do in Riga this summer and I think I have a plan.

I’m planning to re-run the “Modern Perl Web Development with Dancer” workshop that I ran in Cluj in 2016. It was easily the most successful YAPC/PerlCon workshops I’ve ever run with a full class of twenty people working through the day to build a simple web application using a number of modern web  development tools. This will be an updated version of the course as things have moved on a bit in the three years since I last ran the workshop.

Nothing is set in stone yet. I’ve submitted a proposal to the organisers and I hope we can get details tied down and tickets on sale as soon as possible. I’ll report on progress as I here what’s going on.

I’ve also come up with a talk that I’ve proposed for the main conference. It’s called “Measuring the Quality of your Perl Code” and it will be a look at was to measure the “quality” of your Perl code – on the basis that only once you start to measure something, can you start to make improvements. Again, it’s currently just a proposal. It hasn’t been accepted (but I’m taking the fact that it’s currently displayed on the front page of the site as a good sign!)

I should come up with a lightning talk too. Currently, I have no idea what that might be.

How about you? Are you planning to come to Riga in August? Will you be giving a talk?

The post Plans for Riga appeared first on Perl Hacks.

Earlier this week, I saw this code being recommended on Stack Overflow. The code contains a nasty, but rather subtle bug. The version I saw has been fixed now, but I thought there were some interesting lessons to learn by looking at the problems in some detail.

Let’s start by working out what the bug is. Here’s the code:

open my $fh, '<', $file
  || die "Can't open '$file': $!";

On first glance, it seems fine. It uses the common “open or die” idiom. It uses the modern approach of using a lexical filehandle. It even uses the three-argument version of “open()”. Code like has appeared in huge numbers of Perl programs for years. What can possibly be the problem?

I’ll give you a couple of minutes to have a closer look and work out what you think the problem is.

[ … time passes … ]

So what do you think? Do you see what the problem is?

The problem is that there is no error checking.

“What do you mean, Dave?” I hear you say. “There’s error checking there – I can see it plainly.” Some of you might even be wondering if I’m going senile.

And, yes, it certainly looks like it checks for errors. But the error checking doesn’t work. Let me prove that to you. We can check it with a simple command line program.

$ perl -e'open my $fh, "<", "not.there" || die $!'
$

You would expect to see the “die” message there. But it doesn’t appear. Ok, perhaps I’m lying. Perhaps I really do have a file called “not.there”. Let’s try another, slightly different, version of the code.

$ perl -e'open(my $fh, "<", "not.there") || die $!'
No such file or directory at -e line 1.

And there we see the error message. That file really doesn’t exist.

So what went wrong with the first version? Of course, a good way to start working that out is to compare the two versions and look at the differences between them. The difference here is that when I put parentheses around the parameters to “open()” it started working. And when you fix things by adding parentheses it’s a pretty sure bet that the problem comes down to precedence.

The order of precedence for Perl operators is listed in perldoc perlop. If you look at that list you’ll see that the “or” operator we used (“||”) is at position 16 on the list. But what other operators are we using in our code? The answer is lurking down at position 21 on the list. When we call a Perl built-in function without using parentheses around the parameters, it’s known as a list operator. And list operators have rather low precedence.

All of which means that our original code is actually parsed as if we had written it like this:

open my $fh, '<', ($file
  || die "Can't open '$file': $!");

Notice the parentheses that have appeared around $file and (crucially) the whole “or die” clause. That means that the bracketed expression is evaluated and passed to “open()” as its third argument. And when Perl evaluates that expression, it does that clever “Boolean short-circuiting” thing. An expression of “A || B” evaluates A first and if that is true, it returns it. Only if A is false will it go on to evaluate B and return that. In our case, the filename will always be true (well, unless you have a file called “0”) so the second half of the expression (the “or die…” bit) is never evaluated and, effectively, ignored.

Which is why I said, back at the start, that this code has no error checking at all – that’s literally true as the error checking has no effect at all.

So how do we fix it? Well, we’ve already seen one approach – you can explicitly add parentheses around the arguments to “open()”. But Perl programmers don’t like to use unnecessary punctuation and I’m sure I’ve seen this written without parentheses, so how does that work?

If you take another look at the table of operator precedence and look down below the list operators, you’ll see another “or” operator (the one that’s actually the word “or”, rather than punctuation). It’s right at the bottom of the list – at position 24. And that means we can use that version without needing the parentheses around the parameters to “open()”.

open my $fh, '<', $file
  or die "Can't open '$file': $!";

And that’s the version that you’ll see in most codebases. But, as we’ve seen, it’s vitally important to use the correct version of the “or” operator.

The worst thing about this bug is that it appears at the worst time. If your file exists and you can open it successfully, then everything works fine. Things only go wrong when… well, when things go wrong. If you can’t open your file for some reason, you won’t know about it. Which is bad.

So it’s important to test that your code works correctly when things go wrong. And that’s why we have modules like Test::Exception. You could write a test program like this:

use strict;
use warnings;
use Test::More;
use Test::Exception;

dies_ok {
  open my $fh, '<', 'not.there'
    || die $!;
};

done_testing;

And it would fail every time. But if you switched to the other “or” operator, it will work.

There’s one other approach you can take. You can use autodie in your code and just forget about adding “or die” to any of your calls to “open()”.

use autodie 'open';

# Dies if the open fails
open my $fh, '<', $file;

This is an easy bug to introduce into your code and a hard one to track down. Who’s confident that it doesn’t appear in any of their code?

The post A Subtle Bug appeared first on Perl Hacks.

It’s the last day of 2018, and I know I’m not going to a gig tonight, so that sounds like a very good time for my annual review of the gigs I’ve seen this year.

Songkick tells me that I saw 35 gigs in 2018. That’s the lowest number since I’ve been counting them. It’s even one fewer than 2012 when I had the excuse of having my leg in plaster for six months. I’m not sure why the number is so low. Perhaps I’m getting pickier about what I see.

Let’s start by talking about a few of the disappointments. I don’t know what I was expecting when I booked to see Kristin Hersh, but she didn’t deliver and I left just after she sang “Your Ghost”. I was similarly disappointed by The Primitives – I left after a few songs and didn’t even wait to hear “Crash”. But easily the worst show I saw this year was Tiffany. Yes, I know. I admit it was a bit of a gamble. But when I wondered aloud on Twitter about seeing the show, Tiffany replied, so I felt it was rude not to go. I lasted three songs before leaving.

On the other hand, here (in chronological order) are my ten favourite gigs of the year.

• Superorganism at Oval Space. If there’s any justice in the world, this will be one of those gigs that people claim to have been at. But only a few hundred of us were. If you haven’t heard Superorganism’s album, then I suggest you give it a listen. And then try to see them live as soon as you can.
• Lily Allen at the Dome. I’ve seen Lily Allen at the Brixton Academy before and she was pretty good. But I wasn’t going to miss the chance to see her in a small venue like this. It didn’t matter that most of the set was made up of her new album – she was great.
• Arcade Fire at Wembley Arena. Not many bands can persuade me to visit the soulless box that is Wembley Arena. But I’m glad I made an exception for Arcade Fire. They were (as always) sensational.
• Florence + the Machine at the Royal Festival Hall. I’m not a huge Florence fan but when she announced this sudden gig at the South Bank, I jumped at the chance to see her again. Through the magic of my South Bank membership, I got a front-row seat and loved every minute of the show.
• Pale Waves at Heaven. I saw Pale Waves twice this year, but I think the smaller show at Heaven just trumped the bigger show I saw later in the year at the Shepherd’s Bush Empire. I’m looking forward to seeing them again soon.
• David Byrne at the Hammersmith Odeon. It’s one of my great disappointments that I never saw Talking Heads live. This was my second time seeing David Byrne (the first time, he was playing with St Vincent) and this show was absolutely amazing. He did it again later in the year at the O2 Arena, so I’m glad I saw it in a smaller venue.
• The Cure at the Royal Festival Hall. This wasn’t billed as the Cure (for contractual reasons, I think) but everyone knew that’s what Robert Smith was planning. This was an incredible, chronological journey through the band’s music.
• Amanda Palmer at the Queen’s Hall. It’s been a couple of years since Amanda Palmer made this list and it’s great to report she’s back on top form. These shows at the Edinburgh Festival were a prototype for a tour she’s planning to take around the world over the next two years. I suggest you try really hard not to miss it. (I’ve just remembered that I saw her earlier in the year too – but that show is not on Songkick as it was a private event for her Patreon supporters. That was awesome too.)
• Soft Cell at the O2 Arena. I never saw Soft Cell when they were first around and I walked out of a Marc Almond show a couple of years ago. But there was no chance I’d miss this. Even the O2 couldn’t suck the life out of a Soft Cell show.
• All Saints at the Hammersmith Odeon. A little bit of cheese to end the year. All Saints were a bit of a guilty pleasure twenty years ago and they’re still a lot of fun these days.

Although I saw fewer shows this year, they must have been of higher quality than usual. I can’t believe that Sunflower Bean (who I saw twice), the Art of Noise, Belle and Sebastian or Heaven 17 didn’t make the top ten. Even Yes were far better than I’ve ever seen them before.

So that was 2018. I already have some interesting things lined up for 2019 – a Tears For Fears show that was postponed from this year, Chvrches (for what seems the first time for far too long), ABC and Nick Mason playing some old Pink Floyd numbers are among the tickets I’ve already bought. I also have ticket to see the Buzzcocks for the first time, but I’m not sure if that will still go ahead following the death of Pete Shelley.

What about you? What did you enjoy seeing live this year?

 

The post 2018 in Gigs appeared first on Davblog.