We are happy that Cosmoshop supports the German Perl Workshop again in 2026!

Just Paul and Aristotle this week.

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”.

[P5P posting of this summary]

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

Get it from my Wiki Haven.

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.

Nice, Gem. Thanx!

We are happy to announce that Geizhals Preisvergleich supports the German Perl Workshop 2026.

Geizhals Preisvergleich zählt zu den größten Produkt- und
Preisvergleichsplattformen im deutschsprachigen Raum.

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).

[P5P posting of this summary]

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?

Enter Thread::Subs.

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.

See the release notes for additional information.

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.

Happy New Year to all! I’m sharing this with you in the hope it keeps you entertained on a national holiday. Please follow the link for more information: https://theweeklychallenge.org/blog/dbix-class-async

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.)

Doomed

It is an unfortunate fact of life reflected in the stages of man, that we start off facing problems looking to others to solve these problems. Later we learn to solve these problems ourselves, we teach others to do the same. After that we delegate problem solving to those we have taught but find that as our own capacity diminishes, those that come after us simply ask an AI to do that which we struggled to learn in the past. A steady spiral ensuring future humanity’s cognitive decline, fuelled by the genius of its ancestors. We had become masters of our destiny only to hand it over to machines, because we hope machines will do it better. Perhaps they will.

The stars aligned and all three of us managed to get together.

We mostly talked about PPCs, both in the general shape of the process, and specifically the latest proposal, PPC0034.

• Given how the PPC process has worked out in practice, we discussed how much sense it makes and whether it solves a problem we actually have. We agreed that the steering council - and Perl overall - would still benefit from having some sort of declared process by which people can suggest and discuss new features, as separate from implementing them.
• The process at the moment doesn’t align very well with existing practice; at the same time, existing practice is not particularly structured. Rather than trying to define a new process, we think it better to clarify the documented process to more obviously match what we actually do, and try to iterate that way.
• PPC0034 is concerned with refalias parameters in signatures. Both the refalias and declared_refs features are still currently marked as experimental, though it is not immediately clear in their overview tickets why. We should clarify the status of these before we fully commit to PPC0034.
• That aside, the overall document of PPC0034 seems good and we’re happy to merge it as a basis for ongoing experiment and a trial implementation.

[P5P posting of this summary]

We're really excited about this line up. We've got some well know returning speakers and some very exciting new contributors. This is a hybrid conference, we encourage local and remote attendees and speakers/contributors to participate.

Register to attend at https://www.meetup.com/austin-perl-mongers/events/305856787/ - if you wish to submit a talk, you may do through 12/15 until midnight US Central time (12/16 0600 UTC).

Check https://perlcommunity.org/ for the latest schedule!

Comments here are disabled, but you may comment over at r/perlcommunity!

A plenv plugin to show which Perl versions have a particular module.

I use plenv daily to manage the many Perl configurations which I use for different projects. Sometimes I have to install huge collections of Perl modules for some specific use case. And then I forget which Perl installation under plenv it was where I installed them.

So I wrote this plugin to fix that.

Example use cases:

$ plenv where Dist::Zilla
5.24.4
5.28.2
5.34.1-dzil
5.39.2

It can also report the actual path and/or the module version:

I attended the London Perl & Raku Workshop 2025 last Saturday. Please find the detailed event report: https://theweeklychallenge.org/blog/lpw-2025

• Perl.Wiki V 1.35
• Mojolicious Wiki V 1.10
• Debian Wiki V 1.11
• (New) PHP Wiki V 1.01
• Symbolic Language Wiki V 1.18 (at symboliciq.au)

All three of us met.

• The refalias draft PPC on the mailing list is looking good. We encourage Gianni to turn it into a full PPC doc PR
• We still would like more automation around making real CPAN distributions out of dist/ dirs. Paul will write an email requesting assistance on that subject specifically
• Briefly discussed the subject of the meta module handling signatures with named parameters. Further discussion will continue on the email thread.

[P5P posting of this summary]