Talked about the two “match case” proposals. The two seem to cover different intents, so it’s not clear that either just replaces the other. The destructuring concept is nice in principle but needs further discussion. We will let discussions continue on the mailing list for now.
The PrePPC about @INC dirs seems good enough to progress to a full PPC document for further discussion of details; in particular specifics about non-UNIX operating systems.
We want to find a more coherent concept for “hooking core functionality” and possibly the %{^HOOKS} hash in particular, before considering such possibilities as a replacable random number generator. E.g. do $SIG{__WARN__} and $SIG{__DIE__} belong in here?
Specifically on providing a hook for generating random data, it feels like the rand() (and srand()) function interface provided by Perl is itself a limitation for getting good behaviour. This might need looking into before simply replacing a better source of randomness.
We have just released Dancer2 2.2.0. It is a maintenance release containing a number of bug fixes, several important security updates, and one breaking change (see below).
First and foremost, please read the following security announcements; if you are running affected versions of Dancer2, you should plan to update immediately:
The previous post - pperl 0.6.12+ - Shall we play a
game? -
closed with a promise: the next release will compete in every
benchmark of the Computer Language Benchmarks Game with the best
scripted language entry there. The current build already takes several
rows outright; the tally belongs to the release post. This one is
about a row where the promise cannot be kept with the guns we have. On
regex-redux the opponent is V8's Irregexp, a compiler that turns
regular expressions into machine code, and no amount of work on the
Perl JIT will close that gap, because the time is not spent in Perl
ops at all. The answer is a second compiler: ReJIT.
Since almost forever, Emacs supports editing Perl sources with CPerl mode. As of now, CPerl mode is not only shipped with Emacs, but also available on GNU ELPA. ELPA stands for Emacs Lisp Package Archive, it is for Emacs what CPAN is for Perl. This means that to use the newest CPerl mode, you do not have to wait for the next Emacs version: If you use
M-x list-packages, you should see cperl-mode in the list and can install it if you have Emacs 27 or newer.
The current version of CPerl mode supports Perl syntax up to Perl 5.44.
For bug reports and change requests, you can use M-x report-emacs-bug from within Emacs (be sure to add "cperl-mode" to the subject), or create an issue on my GitHub mirror. Development will not happen on GitHub, though, this happens in the GNU Emacs repository at savannah.
We did some initial handover tasks (github groups, mailing lists)
We intend to do some point releases for 5.44 and 5.42 to include some security fixes and build issue bugfixes. We will take suggestions on what other fixes to be included.
We began discussing ideas on what it would look like to support the idea of local::lib and similar techniques better by perl core itself, handling perl version upgrades and so on.
We discussed improving the dual-life module release process to make it easier and prevent mistakes.
Every 8-12'ish months I get sentimental/nostalgic over the good 'old days. I'll head over to CPAN and look at the latest releases investigate a few projects, maybe even make a contribution. I'll then head over to Perlmonks to see what's going on.
Well yesterday, and still today all I see is a fastly "Opps, something went wrong" screen. Is Perlmonks dead? The title of the page is "Client Challenge" so I hope that it's some fastly issue and not that the plug has been pulled on PM.
I’ve released WebDyne 3.0, an update to the Perl-based dynamic HTML engine I have created.
The biggest addition in 3.0 is support for PAGI, alongside the existing PSGI and Apache/mod_perl backends.
PAGI support brings an asynchronous/event-oriented interface to WebDyne and allows WebDyne applications to handle more than conventional HTTP request/response traffic:
Server-Sent Events (SSE) for streaming events from Perl applications to browsers
WebSocket connections for bidirectional, long-lived connections
Normal asynchronous HTTP requests
PAGI application lifespan startup/shutdown events
WebDyne’s PAGI implementation has dedicated handlers for HTTP, SSE, WebSocket and lifespan scopes, while exposing the PAGI request environment through the normal WebDyne request interface. This means existing WebDyne concepts can be used while taking advantage of event-driven servers.
WebDyne continues to support HTMX, JSON and API concepts in .psp pages.
There’s also a new webdyne.pagi runner, so getting a PAGI-backed WebDyne application running is straightforward:
PAGI 0.002002 is a specification release. It does not change the runtime shape of a PAGI application. A running application is still one asynchronous code reference:
Die Webseite und der Call for Papers sind bereits online unter https://act.yapc.eu/gpw2027/cfp.html. Wir freuen uns auf viele interessante
Vorträge!
Über Unterstützung durch Sponsoren freuen wir uns immer. Wenn Ihr bzw. Eure
Firma den Workshop unterstützen möchtet, wendet Euch gerne an uns. Wir finden
gemeinsam sicher eine Möglichkeit!
Wenn Ihr Fragen an die Organisatoren habt, erreicht Ihr uns am besten
direkt unter orga2027@german-perl-workshop.de .
Wir freuen uns auf Eure Teilnahme,
Max Maischein für die Organisatoren und Frankfurt.pm
Wir arbeiten noch an
Hotelempfehlungen und veröffentlichen diese auf der Webseite.
More or less by accident, I recently came across an old project of mine from around 2013/2014. In it, I had tried to approximate Pac-Man using Perl and Tk.
It was never intended to be an exact reimplementation of the original game. There are plenty of those in almost every programming language imaginable. What interested me more was a different question: how could the structure of a game like Pac-Man be represented as a relatively simple data structure, with the Perl/Tk user interface merely visualizing that structure on a Canvas?
Back then, of course, there was no generative AI sitting next to me explaining what I had built.
More than ten years later, there is.
So I fed the old implementation to an AI and asked it to describe the underlying concept. Maybe, the approach is interesting for you.
So here it is.
Have fun reading.
The current implementation
Here is a short video showing the current state of the implementation:
There is no release attached to this post - the second half will
explain why. It is a post about measurement, twice over. Earlier
posts claimed that pperl is under high-velocity development, and a
claim like that should be quantified - so we do, with
the same statistics perl's own release notes use, epigraph
included. And we have started playing the Computer Language
Benchmarks Game: one program is finished, the result is a 36x
speedup on the game's terms, and the conclusions have reset our
speed goals.
If you work anywhere near vulnerability management, you've run into the CVSS problem: a single severity number that tells you almost nothing about what to actually do. CVSS was never designed to be a triage tool, and treating it like one is how organizations end up "patching everything" or, worse, patching nothing because everything looks equally urgent.
SSVC (Stakeholder-Specific Vulnerability Categorization), developed by Carnegie Mellon's SEI (CERT/CC) and later adapted by CISA into its own decision tree, takes a different approach: instead of a score, it's a decision tree. You feed in a handful of factors specific to your role - exploitation status and technical impact for some methodologies, safety and market-share considerations for others - and it hands you back an actual decision: track it, act on it, attend to it now. Which factors matter, and what decision comes out, depends on who you are in the vulnerability management chain - a vendor, a deployer, a coordinator, a finder - because a coordinator publishing an advisory and a deployer patching a fleet of servers are answering completely different questions with completely different inputs.
All of us turned up. There wasn’t much other than administrivia to discuss. We will be initiating the process for the new PSC election in the coming days.
Over twenty-five years ago, when PetaMem was still in its infancy but
the use of Perl for its NLP/NLU systems was already a given (Natural
Language Processing / Natural Language Understanding - we did not
dare to call it AI back then), slightly before the 5.8 era and in a
still-young SMP environment, I envisioned a perl that would
autoparallelize. That is: dispatch your code onto the available CPUs,
automatically. The idea was not mine. I had seen it sometime in the
nineties at the CeBIT computer fair, at the SGI booth, where their C
compiler was doing exactly that.
The vision evolved into a wish, and the wish, refined over the years,
into a resolution: should PetaMem ever have the resources to fund the
R&D team this would need - realistically at least twenty people, or
five Jonathan Worthingtons - we would do it. 2025 was a remarkable
year for us technology-wise, and when Christmas came, the decision
was made: requisition said twenty … or fifty
“people”,
and build an autoparallelizing perl with a JIT.
From my homepage https://savage.net.au/ you can now download:
Perl.Wiki.html V 1.51
cpan.metacurator.tree.html V 1.27
Mojo Wiki V 1.22
CSS.and.JS.Wiki V 1.04
The major improvements in cpan.metacurator.tree.html V 1.27 are:
Many topics (eg AiEngines) have extra entries. Usually the first is called '⊕ See also', which can be opened up to reveal a list of items copied from the corresponding entries in Perl.Wiki
And scattered among the pre-existing leaves there are new ones called '⊕ Notes for: $module_name', where $module_name is the immediately preceding module. Opening up this reveals a list of items which in Perl.Wiki are after the 3 standard lines per entry. See for example (under CachingStuff) '⊕ Notes for: Cache::Memcached::Fast'
Next, from CPAN you can download:
o CPAN::MetaCurator V 1.27
This module ships with a TODO.txt file, and has had a significant restructure.
I'm pleased to announce the release of perl-lsp version 0.6.0; you can install it from Github releases, from crates.io via cargo install perl-lsp, or as a vscode or vscodium extension. If you are a zed user, you can opt in using the zed-perl extension following these instructions.
