We discussed policy questions that were turned up by the recent submission of some LLM-generated PRs. We need to hold conversation about this among the Core team. No contributions of this kind will be accepted while the discussion is still ongoing.
We finally had a good chunk of time to spend on release blocker triage. We made quick progress, working through half our list and closing some issues in the process. We newly marked 4 issues as blockers.
We took PetaMem's 13-year-old Lingua::* number conversion modules
- dormant since 2013 with 17 languages - and brought them back to
life. The suite now covers 61 languages across 7
writing systems (Latin, Cyrillic, Arabic, Devanagari, Armenian,
Hebrew, CJK), including all 24 EU official languages plus Latin,
Hindi, Yiddish, Mongolian, Uyghur, and more.
New in this release: cross-language numeral
arithmetic with overloaded operators, ordinal
support for 14 languages, capabilities
introspection, and a Galois-field-based transitive
test that walks the entire number space across all languages
- 5000 steps, zero failures.
my $a = Lingua::Word2Num->new("zwanzig"); # German 20
my $b = Lingua::Word2Num->new("šestnáct"); # Czech 16
say ($a + $b)->as('fr'); # trente-six
say ($a + $b)->as('la'); # triginta sex
If you’ve ever tried to run Perl code in a Java environment, you know the drill. Rewrite everything in Java (expensive, risky), or maintain two separate runtimes with all the deployment headaches.
PerlOnJava offers a third path: compile your Perl to JVM bytecode and run it anywhere Java runs. I’ve been working on Perl-to-JVM compilation, on and off, for longer than I’d like to admit. The latest push has been getting the ecosystem tooling right — and jcpan is the result.
Why This Matters
Some scenarios where this pays off:
Legacy integration. You have 50,000 lines of battle-tested Perl that process reports, transform data, or implement business logic. Rewriting it is a multi-year project with uncertain ROI. With PerlOnJava, you can deploy it as a JAR alongside your Java services.
JDBC database access. Perl’s DBI works with PerlOnJava’s JDBC backend. Connect to PostgreSQL, MySQL, Oracle, or any database with a JDBC driver — no DBD compilation required, no driver version mismatches.
Finally - GTC 2.0, an all in one color library, is released ! This post will not be rehash (of) the (very) fine manual, but give you a sense what you can achieve with this software and why it is better than any other lib of that sort on CPAN. If you like to look under the hood of GTC, please read my last post.
Last week, the Perl community came together for the 28th German Perl Workshop. This year,
it was held at the Heilandskirche in Berlin Moabit. Excitingly, we had the nave for the presentations.
While the name is still German Perl Workshop, we now draw attendees from all over the globe.
Presenters came from India, the US and various European countries. Maybe it is time to announce
it as a more international conference again.
1: What is the relationship between these 2 modules?
CPAN::MetaPackager's scripts/build.db.sh inputs
a recent version of the Perl file 02packages.details.txt,
and outputs an SQLite file called cpan.metapackager.sqlite (15Mb).
The latter ships with the module.
Future versions of this module will use the differences between the db
and newer versions of 02packages.details.txt to do the usual thing of
add/change/delete entries in cpan.metapackager.sqlite.
2: CPAN::MetaCurator's scripts/build.db.sh inputs
an JSON export from Perl.Wiki.html called tiddlers.json,
and outputs an SQLite file called cpan.metacurator.sqlite (15Mb).
The latter ships with the module.
Then scripts/export.tree.sh outputs a file called cpan.metacurator.tree.html.
This latter file is a JSTree version of Perl.Wiki.html, as mentioned above.
Note: By setting the env var INCLUDE_PACKAGES to 1 before you run export.tree.sh
the code will read the cpan.metapackager.sqlite table 'packages' and that changes
the output tree a bit, since the code then knows the names of modules released
to CPAN.
A small group of volunteers continue to maintain the DBD::Oracle driver without any sponsorship or funding.
Who have curated yet another dev release which has hit the CPAN in the form of v1.91_5 - probably the last dev release before a new version.
It has grown to be quite large so will probably be released as 1.95 or something to give it some distance from the last release. For that same reason I am hoping for anyone using DBD::Oracle in their stack to help us test it out.
Given the nature of Oracle it is very challenging to exhaustively test it, despite having quite a respectable set of unit tests. There are several current supported OS and architectures, and supported client and server versions, on top of Perl versions. Plus all the historical OS and architectures (and client and server and Perl versions) which are still running in production. Support for which is as I mentioned entirely up to volunteers and folks sending in fixes or enhancements.
On Jan 10th I had said in a post here, that perlmodules.net 's update (to use the new metacpan API) would take 1-2 weeks.
It took 1-2 months. (two in fact)
Now it's up again.
Sorry.
Huge congrats goes to Olaf A. for fixing my code.
Bye.
Note to perlmodules.net's users: Since you must have gotten a ton of emails from the website today regarding all the CPAN module releases that have occurred in the past 2 months, you are advised to check also your spam folder, since some of the emails might have ended there by your mail provider (it might have misinterpreted the deluge of incoming mails as spam). Please move them from the Spam folder to your inbox if you can, to prevent perlmodules.net from being blacklisted as a spammer (not 100% sure that's how blacklisting works, but anyway). Thanks.
Foswiki 2.1.11 is now available to be
downloaded
. This release came earlier than expected due to the severe security issues
found in previous versions, as detailed in CVE-2026-2861. Thanks goes to Jan Seebens of Telekom Germany for finding
the initial issue. While investigating the vulnerability, a few more were found that followed similar patterns in the cpde.
Please note that some long-deprecated endpoints have been removed in order to reduce the vulnerable surface area.
See the
release notes
for additional information.
We're thrilled to announce the release of Dancer2 2.1.0! This release represents a major investment in the health and quality of the project. We've gone deep into the issue tracker and PR backlog, closing out some of our oldest open issues — some dating back years — and significantly grooming both the issue and pull request queues. A big thank you to everyone who contributed.
Bug Fixes
This release addresses a number of long-standing issues:
I'm hoping to reach anyone using Protocol Buffers in Perl, soliciting their experiences and best practices.
A Googler is soliciting help on an official set of bindings just this year. Which is great!
There seems to be Google::ProtocolBuffers which is now 10 years old - I suspect it is not a good choice.
The Google::ProtocolBuffers::Dynamic seems like the best choice right now but wont compile for me on Debian Trixie. I haven't gone too deep in to why, but upb seems to be on a branch, is old, and fails to compile.
A colleague recently just for fun had Claude create a pure perl library that passes all the tests and dropped it on github.
I ask as have been experimenting with protoconf which builds on protocol buffers.
Related. I do like Thrift a lot and it seems to be maintained which is nice, but it seems to have failed to gain traction.
I'm still hoping to attract interest from people from other programming cultures, but so far most comments came from people already in the Perl community. Let's see what the future brings us!
The more I investigate into various programming features, the more I'm impressed by the Perl vision: the initial design and later evolution into Perl5 were incredibly innovative and coherent. Raku is even more impressive, but that's another story. Regarding Perl, I am tired of reading comments on so many platforms that the language is "ugly" and "write-only" -- this is not true! If this dev.to series can help to reverse the trend, I will be happy :-)
Recently I've heard quite a few people comment about how Catalyst can't do
websockets. I'm writing this article to dispel that myth, and
document how you can retro-fit websockets into an existing Catalyst application
in a materially useful way, and without rewriting any of your existing code.
I'll also show a case where it actually makes sense to do this rather than
using a framework designed for that purpose.
(this article has been updated to use Request->io_fh, which is Catalyst's official escape-hatch for supporting websockets and comet polling. Also the earlier version omitted the 'begin' action)
Brett Estrade Review of John P Linderman's Quick Sort Paper
Justin Kelly Perl Supabase
State of the Onions
Perl Can Dev Ops Better Than You Think
Brett Estrade Building Beowulf Clusters with Perl
John Napiorkowski Porting ASGI from Python to Perl
Kai Baker, et al Shiny CMS
Privacy Preserving Applications
4 more have gone out to our exclusive mailing list. And we will have one more round for a total of 16 videos. We will also be releasing videos from the Winter 2025 PCC after our Summer 2026 PCC coming up on July 3rd & 4th in Austin, TX, USA.
