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:
Team RPerl will be in Brussels, Belgium two weeks from now for FOSDEM 2019, the largest open source computer conference in Europe (and possibly the world). We will be present the whole weekend, helping out at the Perl booth and promoting the RPerl compiler.
Also, RPerl founder Will Braswell is scheduled as one of the main track FOSDEM speakers, on Sunday February 3rd at 2pm. His topic will be Perl 11, a philosophy that promotes Perl projects aiming to re-unify Perl 5 and Perl 6. RPerl is one such project, and there are several others as well.
David Farrell's Perl.com article Validating
untrusted input: numbers got me thinking, specifically about
the role of \d in sanitizing input. I am not going to talk
here about looks_like_number(), because the referenced
article covers it.
The thing is, on any Perl recent enough to be Unicode-aware,
\d matches digits, whether or not they are
ASCII. This may be a problem if you are sanitizing data for numeric
conversion, because typically conversion routines expect ASCII
digits. There seem to me to be at least two ways to deal with this:
restrict your regexp patterns to ASCII, or have the conversion routine
deal with the full range of unicode digits.
Restrict Patterns to ASCII
If you truly want ASCII digits for your system, there are a number of
ways to restrict a regular expression pattern to ASCII.
Use two-level validation, a.k.a. brute force
By this I simply mean explicitly validating anything that matched
\d by also matching it against [:ascii:] in a second regular expression.
What is the status of a replacement for this blogging platform? I imagine the community as a whole is reluctant to blog in a central place because of the difficulty just logging in to this particular site.
Is there an alternative site where Perl bloggers post?
(Mis) Using Perl 6 Grammars : Decompressing Zelda 3 GFX
Grammars combined with actions allows to parse strings and produce something from it. It's not far fetched to say that any compressed data follow a structure that is likely 'parsed' by the corresponding decompression algorithm.
So why not using Perl 6 grammar for this kind of work? Especially a compression I am familiar with.
A look into Nintendo compression
Nintendo used the same base compression format for their SNES games with some variant depending on the game. It's pretty straight forward and it's easy on the ~2Mhz of the SNES CPU.
The last event of 2018 for Team RPerl was the Austin.pm Christmas Party. Our beloved President (AKA "Prez"), Will the Chill, gathered all of us for pizza and Perl projects.
Throughout the evening, we discussed the possibilities for us to develop the use of Perl, promote Perl jobs and Perl projects in the Austin area.
Our main ideas include:
- Hosting Hackathons for Perl projects
- Inviting a guest speaker once a year
- Teaching free Perl classes
Among our members present that evening was Jim Choate, one of the three original Austin.pm founders, along with some of the younger generation of Perl enthusiasts. The party was about the past and future of Austin Perl Mongers, in every way.
And it wouldn't be a Christmas party without a few presents, Perl presents of course! (Thanks to Wendy & Liz for furnishing some of the Perl gifts at past YAPC/TPC conferences.)
Currently I'm working to getting rakudo.js to pass (our choosen subset of tests) in Chrome rather then on node.js.
For that I'm using the karma test runner (which should also allow testing all the other browsers easily).
The way the process works is that the Perl 6 test files get compiled to JavaScript and bundled by the parcel with everything they needs to run. The bundling includes the setting, runtime and even the whole Rakudo compiler (tests use EVAL a lot).
As as side node it turns out that for debugging purposes node bundled-everything.js emulates running in the browser very closely.
I'm working on a few projects right now, most notably one that helps me create a CPAN distribution so that I can create a Perl Lambda in the AWS environment. This has led me to some yak shaving exercises, most notably investigating how to check for Perl dependencies.
Without getting too far into the weeds on Perl Lambdas (that's another blog post in the writing), suffice it to say I need to vendor Perl modules and deploy them in the Lambda environment. I briefly looked at carton and that may solve the problem neatly, but my early dive indicated to me that another path might be a more direct shot on goal and produce a cleaner Lambda deployment methodology.
Back to the issue at hand...specifically this blog is going to discuss Perl dependency checking using these tools: