Sun, 14 May 2017
I didn't get as much done on the final day of the Perl Toolchain Summit because I needed to get home for work on Monday. But I did manage to enlist others in helping me, which is even better.
Devel::Cover has always had a problem in that top level statements (those not in a sub) in modules cannot be covered. This is because perl throws away the optree as soon as it has executed. My knowledge of the internals has never been good enough to even work out a sensible plan for how to solve this, but fortunately Aaron Crane is a good deal cleverer than me and thinks he might be able to develop a solution. It may need perl to have extra hooks, or it might involve deep magic, or both, but at least the end of the tunnel is not pitch black any more. Thanks Aaron!
Then I was discussing how to improve cpancover with Olaf and mentioned that a queue for newly uploaded modules would help to reduce latency for the coverage reports. Joel Berger was sitting right there too, and he knows something about Minion, the job queue for Mojolicious. Joel kindly offered to put together a queue system to replace my naïve shell script. Thanks Joel!
I took part in the discussion about the future of the PTS (spolier - we like it, and have a few ideas on how to make it better still) and then it was time to head back home.
Thanks to Neil, BooK, and Laurent for organising such a great event. Thanks to Wendy to keeping us all healthily fed (or not so healthily, if desired). Thanks to everyone who attended and helped make the event such a success. And, as ever, thanks to the sponsors: Booking.com, ActiveState, cPanel, FastMail, MaxMind, Perl Careers, MongoDB, SureVoIP, Campus Explorer, Bytemark, CAPSiDE, Charlie Gonzalez, Elastic, OpusVL, Perl Services, Procura, Oetiker+Partner.
My third day at the Perl Toolchain Summit (PTS) was primarily spent in trying to make the cpancover server and infrastructure into more of a production-ready system and less of a Devel::Cover playground. The first step in this direction was supposed to be easy - I made a login for the metacpan group with the idea that they could regularly rsync the coverage results for backup purposes. Unfortunately, this lead me down a yak shaving path I wasn't planning on travelling until later.
When setting up cpancover, I decided to take the easy option and chuck all the results into a single directory. I made the filesystem ext4 so I wouldn't have to worry about hitting limits. Unfortunately, the metacpan box doing the rsync is set up on ext3 and won't support more that 32k subdirectories. So I need to fix up the way that results are stored. I knew this would come sooner or later, even if only because I would surely one day get sufficiently tired of typing ls and immediately regretting it.
In order to make such a change, I need a proper development area to test it. Cpancover has basically just been running since I set it going about three years ago, when I pretty much built it in place. So before making such a large change I need to be able to control things like the docker image being used and the directories being written to. This is also important to be able to allow anyone else to work on the system. So much of the day was spent on this.
Two people separately came to me with the problem that some of their tests
require extra modules to be installed and so, by default, these tests aren't
run and the coverage suffers accordingly. Four years ago, at the QA Hackathon
in Lancaster, a number of clever people got together, and I was there too. We
thrashed out The Lancaster
which, thankfully, included a solution to this problem. The environment
$EXTENDED_TESTING can be set to indicate that
the user or process
running tests is willing to run optional tests that may take extra time or
resources to complete. So I make cpancover set that environment variable, and
Graham and Tux altered Moo and Spreadsheet::Read respectively to pay attention
to it. I mention this in detail for such a simple change (for me) just to
point out (again) the value of the summit, not just for the work which takes
place at the time, but also for how it smooths subsequent work, even years
I did a few other bits and bobs, and ended up watching an Italian dancing gorilla and a horse on a ladder from Azerbaijan whilst waiting for some modules to install, which can't be bad. (Thanks Eurovision.)
Thanks again to all the sponsors who made this possible: Booking.com, ActiveState, cPanel, FastMail, MaxMind, Perl Careers, MongoDB, SureVoIP, Campus Explorer, Bytemark, CAPSiDE, Charlie Gonzalez, Elastic, OpusVL, Perl Services, Procura, Oetiker+Partner.
Sat, 13 May 2017
My first day at the Perl Toolchain Summit (PTS) was largely spent coding, or dealing with pull requests, tickets, and releasing. The second day had far less of that sort of stuff, and a lot more of the sort of stuff that it's much harder to do away from the summit.
But it started off with a new pull request from Todd Rinaldo resurrecting a closed RT ticket. There is a whole class of problems Devel::Cover has to del with which stem from the program being exercised changing the environment as it runs. The most obvious, perhaps, is changing directory, which is also something I looked at again yesterday. But this time it has to do with dropping permissions during the run. Todd and I had a discussion about it and, with the principles in place we'll deal with the technical matters in the coming days.
Then I had a productive discussion with Leo and Olaf regarding cpancover. With a bus number of somewhat less than one, we want to make cpancover.com more resilient. As a first step, the coverage data will simply be backed up to the metacpan infrastructure, meaning that in the event of hardware failure, or a mistaken rm -r, we can get ourselves back up again with the historical data.
Then I spent some time reviewing the way in which the cpancover server is set up, and improving and documenting the process, with the idea that it should be fairly simple for anyone to be able to reprovision the server, or set up a new one.
I should note here that the cpancover server is generously provided by Bytemark. I also have a personal server there and they provide an excellent service.
After dinner, Leo and Lee helped me through the process of setting up metacpan locally, using vagrant and virtualbox. The process was painless due to the fine work they had done in automating it.
I also managed to process a few odd tickets here and there during the day and do other bits and bobs. All in all, it was the type of day that is only really possible at an event such as this, so thanks again to all the sponsors for making it possible: Booking.com, ActiveState, cPanel, FastMail, MaxMind, Perl Careers, MongoDB, SureVoIP, Campus Explorer, Bytemark, CAPSiDE, Charlie Gonzalez, Elastic, OpusVL, Perl Services, Procura, Oetiker+Partner.
Thu, 11 May 2017
This year the Perl QA Hackathon has been rebranded as the Perl Toolchain Summit on the advice of the marketing team. This is the tenth year that the event has been held and, after missing the first few due to scheduling conflicts with my (then young) children's birthdays, I suppose I have now become something of a regular. This year the event is being held in sunny^W rainy Lyon - a shortish train and car (thanks Lee) ride for me.
The Perl Toolchain Summit (hereafter PTS) has become the most important Perl event of the year for me. It's a chance to get together in one room (two actually) as many of the people as possible who work on the Perl infrastructure. This is not the perl core, but the entire toolchain that fits around the core - primarily focussed on CPAN, the archive of Perl modules. CPAN was one of the first such archives, and the infrastructure around it - especially with regard to CPAN Testers and the MetaCPAN architecture, is generally regarded as without peer.
PTS brings together about 35 Perl developers from around the globe to work on this infrastructure together, and to thrash out the sort of problem in which five or six people can sit together and find a good solution which might otherwise have taken months of discussion to reach.
These discussions often mean that people leave with longer TODO lists than when they arrive, which is probably as it should be. But apart from the discussions, there's also a lot of hacking work that takes place, and it's remarkably efficient, when working on code that uses someone else's module, to be able to lean over and ask them a specific question about that module.
In short, if you or your company cares about Perl, you should probably care about PTS.
PTS started on Wednesday afternoon for me. On the train I was able to merge a pull request for Devel::Cover that I had been putting off for too long. I carried on merging pull requests on Thursday, the first full day of the PTS, and fixed various problems and closed a number of tickets. Then I released Devel::Cover 1.25.
In the evening we had a joint meal at an Ethiopian restaurant, sponsored by cPanel (thanks!) and Lyon almost beat Ajax by enough to get to the Europa League final, but just missed out.
Looking forward to day 2 being as productive.
Many thanks to all the sponsors without whom this event would simply not be possible:
Sat, 29 Apr 2006
I wanted to build a local CPAN mirror using CPAN::Mini. Since it takes a little time to download all that data I wanted to choose a nice fast mirror. This little command was helpful:
$ netselect -vv `wget -O - http://www.cpan.org/SITES.html | \ perl -lne 'print $1 while m!>((ht|f)tp://[^<]+)!g'` | \ sort -k 4 -n
It grabs the CPAN mirrors file, extracts the URLs and feeds them to netselect, which tests the mirrors and outputs its information. This is then sorted numerically on the fourth field, which is the number of hops.
The sorting is necessary because although netselect does tell you which mirror it thinks is the best, it doesn't really select very well. In fact, some of its output seems downright dodgy, so I selected a mirror which seemed plausibly fast, close and reliable. For me that was http://cpan.wanadoo.nl/.
For useful information on using CPAN::Mini, take a look at Mark Fowler's 2004 Perl Advent Calendar. You might need to get that from the Wayback Machine at http://web.archive.org/web/20060214214713/http://perladvent.org/2004/5th/ (which is another URL kwiki has managed to mangle).
Mon, 13 Feb 2006
This is probably obvious to a lot of people, but it's fairly rare that I learn a new Perl programming trick these days, and I don't recall ever having seen this one before, so I thought I would make a note of it here.
Now, some people will tell you that a function should only have one exit point. If you subscribe to that opinion then this trick probably isn't for you. Personally I find multiple exit points can frequently simplify logic and avoid the need for temporary status variables or conditional blocks. They can also be abused of course, but I don't consider that a reason to ban them outright. Maybe this attitude is why I get on so well with Perl.
Anyway, sometimes you have a block from which you would like multiple exit points. If this happens to be a loop you can use last to exit from it. But if it is not a loop you might not want to create a function just for this purpose. Well, the solution turns out to be trivial. Just use last in the block. It's even documented in perldoc -f last.
Note that a block by itself is semantically identical to a loop that executes once. Thus "last" can be used to effect an early exit out of such a block.
I used this for the first time in my calandar and todo script. I'll probably use it again.