blogs.perl.org — blogging the onion

blogs.perl.org — blogging the onion
Feedback?
Contact
blogs.perl.org
There's more than one way to blog it
Importance of Repositories in Public
By
Mikko Koivunalho
on
April 23, 2026 8:39 PM
It used to be so that a
repository
was only a place of work
and the
distribution
was the actual result of that work.
Only the contents of the distribution mattered. People would
read the files
README
and
INSTALL
from the distribution
after having downloaded it.
Not so anymore. Today the repository is out in the open in
GitHub
GitLab
Codeberg
or other shared hosting site.
On the other hand, the documentation in the distribution is often
discarded as distribution packages are rarely downloaded manually
but rather via a package manager which installs them automatically.
Publicly viewable repository has in fact become much more
than just a place of work. It is also an advertisement
for the project and of the community behind it, if there is
more than one author or contributor.
0 comments
Continue reading »
AI as a Chance - Opinion
By
PetaMem
on
April 23, 2026 12:17 PM
Use AI. Use it more and better. If you are not yet equipped to use it
well - that is fine, learning takes time - but please do not inhibit
those in the community who are.
That is the whole argument. The rest of this piece is why I think it
is correct, and why I think the current register of the Perl community
around this topic is costing us something specific and avoidable.
0 comments
Continue reading »
AI Contributions to CPAN: The Copyright Question
By
Todd Rinaldo
on
April 22, 2026 11:55 AM
This is a developer's perspective, not legal advice. I'm not a lawyer. What follows is my personal reading of publicly available licenses, policy documents, and one court decision. If you're making decisions about your module's legal exposure, talk to a lawyer.
The open source world is actively debating whether to accept AI-assisted contributions. QEMU, NetBSD, and
Gentoo
have said no. A lot of CPAN maintainers haven't written down a policy but have a reflex — if a PR looks AI-assisted, close it without a real review.
Two very different concerns sit underneath that reflex, and they usually get mashed together:
Quality.
AI can produce plausible-looking code that doesn't actually work, hallucinates APIs, or subtly misunderstands the problem. This wastes reviewer time.
Copyright.
AI might reproduce memorized training material the contributor has no right to relicense. The output itself may not even be copyrightable. The contributor may not actually own what they're submitting.
2 comments
Continue reading »
Compiling Google::ProtocolBuffers::Dynamic on Debian Trixie
By
Dean
on
April 17, 2026 10:52 AM
I found this sufficient of an obstacle that I wanted to post about it for future posterity.
I was able to
cpanm Google::ProtocolBuffers::Dynamic
after installing these packages on Debian Trixie.
build-essential (unsurprisingly)
cmake
libprotobuf-dev
libprotoc-dev
The last library eluded me and caused the most frustration. Anyway on to other things.
0 comments
Permalink
Faster UTF-8 Validation
By
Christian Hansen
on
April 17, 2026 12:16 AM
A while back, I received a pull request suggesting that I update the performance comparison with Encode.pm in my module,
Unicode::UTF8
. When I originally wrote
Unicode::UTF8
Encode.pm
used its own UTF-8 validation implementation. Since then, Karl Williamson has done extensive work improving Perl, and Encode.pm now relies on those validation routines based on Björn Höhrmann’s
UTF-8 DFA decoder
. It’s an elegant piece of code, widely adopted across many projects.
That said, I wasn’t particularly motivated to revisit the comparison, so I decided instead to look into faster scalar C implementations. While it has been suggested that Unicode::UTF8 should gain a SIMD implementation, and that may well be worthwhile, I wanted to first explore improvements to the scalar path, which would still be required as a fallback.
After some searching, I came across a
tweet
by Russ Cox showing performance numbers for a shift-based DFA implementation in Go, along with a link to a
gist
by Per Vognsen describing the technique.
0 comments
Continue reading »
PDL in Rust -- Part Two
By
PetaMem
on
April 19, 2026 4:01 PM
Two weeks ago we posted
"PDL in Rust - A Native
Reimplementation of the Perl Data Language"
. At the time the
score was 45 tests, all green. That was enough to say "it compiles,
it runs, here is the arithmetic surface." It was not enough to say
"you can use this."
We are now on the second number. The current PDL implementation
in
pperl
covers roughly 3,000
assertions end-to-end: about 1,400 on the Perl-facing connector side
and about 1,600 on the engine side. As of this writing roughly 98%
of the connector assertions match upstream PDL 2.103 exactly, and
most of the remaining couple of dozen we already know why they
fail. By the time you read this the numbers will have drifted a
little in our favour - give or take - but the shape is the point,
not the decimal.
Everything described below is shipping, today, at
2 comments
Continue reading »
This week in PSC (221) | 2026-04-13
By
Perl Steering Council
on
April 14, 2026 2:52 AM
All three of us attended this long meeting consisting entirely of dealing with release blockers.
0 comments
Continue reading »
Happy sharing
By
vividsnow
on
April 13, 2026 9:31 PM
So you've got a bunch of Perl worker processes and they need to share state. A work queue, a counter, a lookup table - the usual. What do you reach for?
Perl has solid options here, and they've been around for a while.
File::Map
gives you clean zero-copy access to mmap'd files -
substr
index
, even regexes run directly on mapped memory.
LMDB_File
wraps the Lightning Memory-Mapped Database - mature, ACID-compliant, lock-free concurrent readers via MVCC, crash-safe persistence.
Hash::SharedMem
offers a purpose-built concurrent hash with lock-free reads and atomic copy-on-write updates.
Cache::FastMmap
is the workhorse for shared caching - mmap-backed pages with per-page fcntl locking, LRU eviction, and optional compression.
2 comments
Continue reading »
CPAN Dependencies, static and dynamic
By
Grinnz
on
April 11, 2026 10:45 PM
Dependencies or prerequisites are an integral feature of the CPAN software repository. They define what other CPAN modules are required for a particular CPAN distribution to be built, tested, or ultimately to function, as well as optionally to improve or add functionality. To define them properly for a distribution, it is helpful to understand exactly how they will be used, and what all the different distribution files like
Makefile.PL
Build.PL
META.json
, and
MYMETA.json
are for.
sidebar:
In this post, I will focus on the "requires" relationship for dependencies, which are hard dependencies that must be satisfied, but "recommends" and "suggests" relationships are also defined that indicate strongly and weakly optional dependencies respectively; CPAN installers may install these based on the options that are passed.
Most commonly and at a basic level, dependencies are defined in a (generated) file called
META.json
in the root of the CPAN distribution, but this may not be the complete picture. CPAN installers historically would determine what is needed at the time that the user requests to install the distribution ("install time"), and though there is now the formal concept of static prerequisites (the most common case where they are the same for every install environment), some distributions need to determine prerequisites at install time, using the original dynamic configuration process.
0 comments
Continue reading »
Manage the health of your CLI tools at scale
By
Dean
on
April 10, 2026 2:21 AM
I wrote a follow up of my
previous article
on dev-to. It is titled
Manage the health of your CLI tools at scale
and explores how you might approach instrumenting your cli tools to ensure they run properly.
0 comments
Permalink
How you too can improve Perl 5
By
Karl Williamson
on
April 9, 2026 6:11 PM
tl;dr
Choose a bug that has a reproducing case from the
list of open issues
. Get the Perl source from GitHub, and put the reproducing case into a test file that we have designed for the purpose, and submit a pull request to GitHub for it. That's it.
The test is marked as expected to fail. Having this test in place helps us in several ways. One is that sometimes having to write a test is the straw that leads a developer to think it's just too much trouble to tackle this. Another is that, not all that infrequently, a change made for some other reason fixes one of these bugs, and we don't know it. But having this test would cause us to get notified that the bug is now fixed. It might even be that your work would show that the bug is already fixed.
1 comment
Continue reading »
Quick and dirty string dumping
By
mauke
on
April 9, 2026 3:15 PM
Sometimes, when you're trying to debug encoding issues in Perl code, it is useful to quickly get an idea of what code points Perl thinks are in your string. The straightforward approach of
say $string
(or
print $string
) isn't a good way to look at an unknown string: The results depend on what encoding layers (if any) are set on
STDOUT
and how your terminal renders the resulting bytes. In some cases,
"\xe2\x82\xac"
(a three-character string, UTF-8 bytes) may look identical to
"\x{20ac}"
(a one-character string, Unicode text) when printed, for example. (And some control characters are invisible or can clear (parts of) the screen or reposition the cursor, etc.)
Data::Dumper
isn't great, either: For one thing, you have to load it first and second, a naive
use Data::Dumper; print Dumper($string)
can still dump non-printable control characters on your terminal. You have to remember to set
$Data::Dumper::Useqq = 1
first, which is a hassle (and takes another line of code).
1 comment
Continue reading »
Evolution strategy for SQL::Abstract::More : call for feedback
By
dami
on
April 8, 2026 8:36 PM
I am preparing a new version of
SQL::Abstract::More
, aimed principally at solving several long-standing bugs when param ‘quote_char’ is non-empty (i.e when the user wants to generate SQL of shape like
"SELECT `Foo`.`col1`, … FROM `Foo` etc."
).
While working on this I need some input from users, because the situation is a bit complicated:
1 comment
Continue reading »
575 Pull Requests in Three Weeks: What Happens When AI Meets CPAN Maintenance
By
Todd Rinaldo
on
April 7, 2026 6:21 PM
On March 17th, I installed a bot called
koan
on my personal Claude account. It's designed to monitor your four-hour usage limits, maintain a queue of "missions," and efficiently use your credits — even while you're sleeping.
Three weeks later, I had reviewed and merged 575 pull requests across 20 CPAN repositories, cut 58 releases across 17 of them, and caught memory leaks, security holes, and long-standing bugs that nobody had gotten around to fixing in years.
Some people think that means I let an AI commit unchecked code to critical Perl infrastructure. I want to explain what actually happened.
The Numbers
Here's what those three weeks produced:
Repository
PRs Merged
Releases
XML-Parser
95
IPC-Run
68
YAML-Syck
64
Net-Jabber-Bot
38
Net-ACME2
38
Net-Ident
33
Crypt-RIPEMD160
33
IO-Stty
30
Razor2-Client-Agent
27
Tree-MultiNode
24
IO-Tty
22
Business-UPS
20
Test-MockFile
17
Safe-Hole
17
Tie-DBI
15
Regexp-Parser
11
Sys-Mmap
Template2
Crypt-OpenSSL-RSA
CDB_File
Total
575
58
20 comments
Continue reading »
This week in PSC (220) | 2026-04-06
By
Perl Steering Council
on
April 6, 2026 5:29 PM
We were all present.
We noted that core team membership votes are concluding on this day.
We are waiting for voting to conclude before we kick off the discussion about an LLM policy.
Release blocker triage continues. We are now fully caught up and marked a few more issues as blockers – all of them minor.
We unmarked several issues as blockers and marked
#23131
as such instead, because it was the root cause for them all. We then spent a long time deliberating what to do about it and debating approaches. We have not reached a conclusion yet and will be keeping an eye on it.
P5P posting of this summary
0 comments
Permalink
PerlOnJava Gets a CPAN Client
By
Flávio S. Glock
on
March 28, 2026 10:16 AM
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.
3 comments
Continue reading »
March articles on beautiful Perl features
By
dami
on
March 29, 2026 8:26 AM
Continuing the dev.to series about beautiful Perl features, here are the recent articles (March 2026) :
two-sided constructs, in list or in scalar context
reusable subregexes
"heredocs", multi-line strings embedded in source code
0 comments
Permalink
Graphics::Toolkit::Color 2.0 feature overview
By
lichtkind
on
March 24, 2026 4:43 PM
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
3 comments
Continue reading »
28th German Perl Workshop (2026, Berlin)
By
Max Maischein
on
March 22, 2026 12:46 PM
Cross-posted from
my blog
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 comment
Continue reading »
ANNOUNCE: Perl.Wiki V 1.42 & 2 CPAN::Meta* modules
By
Ron Savage
on
March 19, 2026 6:01 AM
Available now from my
Wiki Haven: Perl.Wiki.html V 1.42 & the JSTree version
Also, I've uploaded to CPAN 2 modules:
1: CPAN::MetaCurator V 1.13
2: CPAN::MetaPackager V 1.00
Q & A:
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.
0 comments
Permalink
Page 2 →
About blogs.perl.org
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
Search blogs.perl.org
Perl & The Community
perl.org
perl.com
pm.org
yapc.org
perlmonks.org
Free blog hosting for users of the
Perl programming language
(but
not for spammers