Taking clue from Gabor Szabo, the Chief Editor of PerlWeekly newsletter, when he tweeted last week and asked his followers what they would like to read in the next edition of PerlWeekly newsletter.
I would like to introduce "Perl Weekly Challenge" where anyone can put forward the challenge for others. It can be Perl5 or Perl6. We, developers, come across many challenges on a daily basis at work. Why not throw the same challenge and see how others would approach the challenge. Or if you have found the solution, share that as well by writing a very small blog either on blogs.perl.org or perl.com. I am sure the Chief Editor, David Farrel, would not mind to have it.
If you find writing blog is a challenge in itself then I can help you with it. Just send me the plain text and I will try to get it published on blogs.perl.org.
As part of my Perl/Lambda adventure, I wrote a make-a-perl script that provisioned an EC2 to compile a version of perl. I suspect everyone has their favorite way to compile a perl binary (either for free or not) but here's yet another way to leverage the many tools that AWS has to offer. TIMTOWTDI of course!
My blog entry of a couple weeks ago,
Untrusted Numeric Input,
dealt mainly with the problem of ensuring that supposedly-numeric input
actually consisted only of ASCII digits. One of the ways to do this was
to use the bracketed character class [0-9] instead of
\d. This was documented as being portable as of Perl 5.21.5,
and I made the statement that "I believe this behavior goes back further
..." This was clearly just hopeful hand-waving, and not very
helpful.
This blog post documents my efforts to try to quantify the
versions of Perl under which [0-9] is portable. For those
disinclined to read further, my conclusion is that [A-Z],
[a-z], [0-9], and their sub-ranges are
portable among character sets as far back as Perl 5.8.0.
Ever since, I submitted the 1500th Pull Request at the end of last year, I have been thinking of doing some kind of data analysis. I love playing with data as it can tell you something interesting every time you poke. I had so many questions in my head with regard to my PR journey e.g. How many authors I have contacted so far? How many distributions on GitHub I have submitted PR against? etc.
Luckily, I have been collecting data about every PR (nearly) that I have submitted so far with details like author, distribution name and pull request id. I have used that in the graph that I have on my personal website.
We are chuffed to announce The Swiss Perl Workshop 2019. This year the workshop will return to Olten, the venue that hosted the workshop in both 2014 and 2015. The workshop will be held in English, although of course other languages are welcome.
We are yet to decide on a date and have three options:
Friday 16th and Saturday 17th August 2019 (one week after TPC in Riga)
Friday 4th and Saturday 5th October 2019
Friday 11th and Saturday 12th October 2019
We have decided to take the Swiss approach and ask the people. So if you plan to attend this year's Swiss Perl Workshop please let us know which date you would prefer using either this link or the embedded poll below. The survey will remain open until the end of February.
Please spread the word, register, submit talks, and come enjoy a perl workshop in the cosy Flörli Olten.
We are looking for more sponsors. Interested? Please check the sponsoring page.
My start of the year 2019 wasn't very good. I welcome the new year with Flu, suffered till nearly the end of the month. One thing I missed last month was "Pull Request Challenge". No more email from Neil Bowers with random distribution for the month. Thanks to "Pull Request Club", I was still able to contribute.
Let's take a quick look through.
Pull Request
Git Commits
Pull Request Club
Perl Blog
PerlWeekly Newsletter
Adopt CPAN Module
Pull Request
65 Pull Requests submitted in the month of January.
1518 Pull Request altogether.
Git Commits
491 commits recorded in the month of January.
Overall 491 commits recorded so far in the year 2019.
Pull Request Club
Last month, I received OPAR and I submitted 1 Pull Request. It has already been accepted and merged by the author Renee Baecker.
By now, everyone has heard that HTTP/3 is coming. Based on Google's QUIC protocol that began as an experiment circa 2012, IETF QUIC and HTTP/3 are likely to become standards this year.
My employer, LiteSpeed Technologies, has been actively participating in the standardization process. We have also open-sourced several of our C libraries, QUIC Client and QPACK among them.
It would be cool if Perl were one of the first to get its own HTTP/3 or QPACK library. This is a call for a volunteer -- someone who is looking for a new project that is sure to get a lot of mileage. I would be glad to help augment our libraries to facilitate this process.
I'm not positive about this, but I'm not sure that things are behaving as I would expect. What would you expect the following lines to output?
perl -E 'say "x"; say -"x"; say -"-x"; say -"+x";'
For me, lines 1 and 2 make sense. Lines 3 and 4 are different than I would expect, but I'm not sure that they are really wrong. Does somebody want to explain what is really happening, and why it is that way?
Type::Tiny is probably best known as a way of having Moose-like type constraints in Moo, but it can be used for so much more. This is the seventh in a series of posts showing other things you can use Type::Tiny for. This article along with the earlier ones in the series can be found on my blog and in the Cool Uses for Perl section of PerlMonks.
For small projects, the type constraints in Types::Standard and other CPAN type libraries are probably enough to satisfy your needs. You can do things like:
The kindest thing I can say about the built-in Perl debugger is that it doesn't drink even though it's old enough to. Using it is painful but there are many things you can do to make it nicer. Heck, I even had syntax highlighting working once.
One of my major pet peeves with the debugger has been how it dumps variable data. Have you ever used it and typed "x $dbic_object" or "r" to return from a method and gotten hundreds of lines of near useless output spewing across the screen? To make matters worse, it takes a long time to dump all of that, making the slow debugger even slower than normal. It's very frustrating. Here's how to fix it.
When running the debugger, Perl loads a script named perl5db.pl and internally, when it needs to dump some variables to the terminal, it runs some code which looks like this (edited for clarity):
Type::Tiny is probably best known as a way of having Moose-like type constraints in Moo, but it can be used for so much more. This is the sixth in a series of posts showing other things you can use Type::Tiny for. This article along with the earlier ones in the series can be found on my blog and in the Cool Uses for Perl section of PerlMonks.
While Types::Standard provides all the type constraints Moose users will be familiar with (and a few more) there are other type libraries you can use instead of or as well as Types::Standard.
At re:Invent 2018 AWS announced custom Lambda runtimes. This makes it possible to create Perl based Lambdas. Although theoretically it was possible to create a Perl Lambda prior to this announcement by invoking a shell from Python for example, the new custom runtimes make it possible to use almost any language to create Lambdas.
I've been developing a Perl based custom runtime framework so that creating a Perl Lambda is pretty much as simple as: