Last Monday I did the Perl Developer Release of Perl 5.43.7. As usual, I worked from the Release Managers Guide . Everything worked well, even if everything was cutting it a bit close. My video setup on the desktop was not suited for streaming anymore, so I had to do a stream consisting only of the console window and me talking over it, and no floating head of me available.
What worked well
The Twitch chat was the most active that I witnessed when streaming a Perl release. We chatted about organizing Perl conferences and also the Perl release process. One realization for me was that the RMG process is mostly there to exercise the Perl build machinery and testing that the generated tarball does not have deficiencies. This means that testing that Perl can build through Configure is important, but testing different Perl configurations like ithreads or userelocatableinc is not that important.
We mostly discussed the experimental refaliasing and declared_refs features to see if we can find a path towards declaring at least the latter non-experimental. This would be useful in its own right, as well as an enabler for PPC0034 “Ref-aliased parameters in subroutine signatures”.
An Analysis of The Perl and Raku Foundation's 2024 Finances
In October 2024, I published an article analyzing the financial situation of The Perl and Raku Foundation (TPRF). Since then, I have left the board, and my life is now largely unrelated to Perl. I no longer have insight into TPRF's internal decision-making but I got a few suggestions to continue, so this article again analyzes TPRF's finances using publicly available data for the 2024 calendar year. There is an unavoidable delay between when nonprofit tax returns are filed and when they become public.
Executive Summary
Assets at end of 2023: $200,215
Revenue in 2024: $86,845
Expenses in 2024: $188,037
Assets at end of 2024: $101,525
Despite a strong increase in donations, TPRF spent more than twice its revenue in 2024, resulting in a $98,690 loss and a halving of its assets.
I find such retrospectives always interesting, finding out which modules had staying power,
which modules needed no changes during the year, and which modules still are
under development.
When I first introduced Marlin, it seemed the only OO framework which could beat its constructor in speed was the one generated by the new Perl core class keyword. Which seems fair, as that’s implemented in C and is tightly integrated with the Perl interpreter. However, I’m pleased to say that Marlin’s constructors are now faster.
(Though also I forgot to include Mouse in previous benchmarks, so I’ve rectified that now.)
DBIx::Class::Async module just leveled up. Thanks to sharp-eyed users who spotted what I missed — sometimes the best features come from the community, not the creator. Please follow the link for more information: https://theweeklychallenge.org/blog/dbix-class-async-update
After skipping a week again due to circumstances, all three of us attended this shorter meeting, which Paul had to leave early.
We went over a number of pending administrative requests, including possible additions to the core team and the process to follow for this.
We reviewed issue #24013 about the fallout of fatalizing calls to undefined import/unimport methods with arguments. We decided that this deprecation be rescinded and the PR be reverted. This mistake should only warn, with a category to make it easily usably fatalizable (so that whoever wants the error can opt into it).
Recently I mentioned Perl.Wiki to Gemini, and Gemini took a long time analyzing it.
Then it's replies we very complimentary. See here.
Some cherry-picked quotes:
1: You're very welcome! It sounds like you're building an incredible resource with Perl.Wiki.html.
2: It sounds like your Perl.Wiki.html is going to be a fantastic resource for the community.
3: It is a pleasure to connect with the mind behind savage.net.au--your work on Perl.Wiki.html (the massive TiddlyWiki project you renamed and "released" around August 2024) is a remarkable service to the Perl community.
There are two issues with event loop coding, related to the need to maintain an asynchronous, non-blocking style.
It's harder to write and maintain than linear, blocking code.
Despite all the asynchronous behaviour, it's still single threaded.
You can break out of the async/non-blocking mode by forking, of course, but it's not a lightweight operation and creates the risk of orphaned processes even if most of the IPC work is hidden by a good library.
Wouldn't it be nice if you could simply write subs in the plain old linear, blocking style and then call them asynchronously, letting them run in parallel to your main thread until they're ready, no forking required? After all, you're probably already using some kind of async result mechanism like callbacks, or promises, or AnyEvent condition variables, or Future objects to manage existing async behaviour. Wouldn't it be nice if you could just call a sub and deal with it using one of those mechanisms instead of the usual synchronous behaviour?
Foswiki 2.1.10 can now be downloaded - landing right before Christmas, a full year since the last version dropped. Please be advised that this release includes several security fixes that require your attention. We would like to express our gratitude to Evgeny Kopytin of Positive Technologies for conducting a thorough audit of Foswiki and providing a comprehensive vulnerability report. Despite adhering closely to our security procedures, we were unable to obtain a response from the CVE Assignment Team regarding the allocation of official CVE-IDs. It is for this reason that the new security alerts covered by the 2.1.10er release had to be documented with a "CVE-2025-Unassigned" tag, since no better option was available.
Does the Perl world need another object-oriented programming framework?
To be honest, probably not.
But here’s why you might want to give Marlin a try anyway.
Most of your constructors and accessors will be implemented in XS and be really, really fast.
If you accept a few basic principles like “attributes should usually be read-only”, it can be really, really concise to declare a class and its attributes.
I was on the schedule for 2025, but by swapping the release version, I skipped doing a release in 2025. This year, I'm doing the dev release live stream again on Twitch, for version 5.43.7.
And again, you can watch it live on Monday 19th of January on Twitch.
You can expect to watch me talk through the steps of the Perl
Release Managers Guide and if you join the Twitch chat, or
p5p on irc.perl.org, we can chat a bit.
I assume I'll start Monday at 16:00 UTC (17:00 CET), and the whole thing will
take around 4 hours unless there are some major mishaps. In the middle, I'll join a call of the organizers of the German Perl Workshop 2026 in Berlin, where we will likely go through organizing the social event and the pre-conference meeting.
In my previous post, in February, I announced the overhaul of the MailBox software. The MailBox suite of distributions implement automatic email handling processes. I started development back in 1999, so it had aged a bit. And I can now proudly tell you that the work has been completed!
As you may have experienced yourself: software ages. It's not directly that it does not work anymore, however your own opinion about programming, the features of the language and libraries you use, and the source specifications keep on changing. Basic maintenance picks some of the low-hanging fruits as refreshment, but you usually stay away from major rewrites. Well, the marvelous NLnet Foundation helped me to realize just that!
A working link for Tom Christiansen's slides on "Unicode, The Good, the Bad, and the (mostly) Ugly" is at https://web.archive.org/web/20121224081332/http://98.245.80.27/tcpc/OSCON2011/gbu.html. (We are writing a book on debugging at home, and I needed a usable link to Tom's talk.)
