blogs.perl.org

ANNOUNCE: Perl.Wiki V 1.56, CPAN::MetaCurator V 1.33

2026-10-11T11:32:24Z

Get them at my Home Page's Wiki Haven.

This is the first version where ChangeLog[12] are included in the JSTree, so there are still some tiny cleanups to do...

Peta::NN - Surface Detail

2026-10-09T23:43:08Z

Peta::NN is a neural network library written in Perl: models are defined, trained, measured and shipped from a Perl script, with no dependency beyond perl 5.36. It is not a binding to somebody else's framework and it does not try to be PyTorch. It trains micro models - a few thousand to a few hundred thousand weights, each answering one narrow question about a string - and composes them: in a pipeline, or fused into one model that runs a whole batch on the graphics card without coming back to Perl in between. It runs on perl5 and on pperl, on three backends, and under pperl one of them is the GPU. Two models of 18,761 and 10,002 weights form the plural of 98.3% of German nouns they were never shown, and of every single noun of the core vocabulary.

]]> Why this exists

PetaMem has done natural language processing in Perl for twenty-five years, and for most of them the craft was rule sets: inflection, language identification, diacritics, word classes. The Lingua distributions on CPAN are the tiny public part of that. Rules have a known weakness. They answer for what their author thought of, and the language has more words than that.

A small network trained on what the rules and the lexicon say closes that gap: it also answers for the words nobody listed. That is the whole use case, and it is a modest one. The title is meant literally: these models read the surface form of a word, often just its last six characters, and nothing else.

Perl had no tool for this. On CPAN, AI::MXNet binds a framework that has been retired, AI::TensorFlow::Libtensorflow runs models trained elsewhere, the AI::NeuralNet::* family is old and small, and PDL is the numeric base without a network layer on top. None of them trains a model to a stated quality from Perl data, and none composes models. The usual advice is to do the training in Python and carry the result over. We did not take it.

What it is not

Three kinds of layer, gradients written by hand and checked against numeric differentiation, no automatic differentiation, no tensor library, no images, no sound, no large models. Whoever needs those has PyTorch and Keras - for now. ;-) The library is about 7,000 lines of Perl, documentation included, and means to stay small: three concepts - data, a model, a chain - and one way to do a thing.

A model is declared, and trained to a goal

use Peta::NN::Data;
use Peta::NN::Model;
use Peta::NN::Chain qw(chain);

my $nouns = Peta::NN::Data->read('nouns.tsv',
    fields => [qw(singular gender plural)])->hold_out(0.2);

my $plural = Peta::NN::Model->new(
    kind  => 'edit',
    from  => 'singular',
    to    => 'plural',
    given => ['gender'],
    reads => { end => 6 },
    goal  => { unseen => 0.93 },
);
$plural->train($nouns);

print scalar $plural->predict('zeitung', gender => 'feminine');   # zeitungen

That declaration is everything the user decides: which field the model reads, which it answers, what it is told beside the word, how much of the word it looks at, and what it has to reach. There is no layer list, no optimizer, no loss, no device, and no training loop. The kind of model settles the loss. Training settles the rest: it runs until the goal is met on nouns the model was not shown, widens the network if it stops getting closer, and then trains a second model from another random start to confirm that the first was not a lucky draw.

An edit model does not generate characters. Its answer is one of the edits it has seen - "cut two characters, add en" - which makes it a classifier, and its mistakes wrong words of the right shape (Agronome for Agronomen) and never noise.

The data is held to the same standard. Which records are held out follows from a hash of a field's value, so the same noun is on the same side on every run, every machine and every perl. And before training, the library says what no model of that shape can learn:

7 training pairs the model cannot tell from a pair with a
different answer; a wider window would (mutter → mütter as
magnetmutter → magnetmuttern, ...)

Mutter and Magnetmutter agree in gender and in their last six characters and differ in the plural. Nothing that reads six characters gets both, so they are set aside and named, not silently counted as failures of the training.

Small, composable

The philosophy in one sentence: a task that is too much for one small model is usually several small tasks. The German dative plural is three. Change the vowel (Apfel, Äpfel). Rewrite the ending (Mann, Männer). Add the case (Äpfeln). Three models in a row are easier to get right, and to check one by one, than one larger model that has to learn all of it at once.

my $dative = chain(plural => $plural, case => $case);
print scalar $dative->predict('hund', gender => 'masculine',
                                      case   => 'dative');        # hunden
$dative->save('dative.chain');

A chain is itself a model. It is asked, scored, saved as one file, loaded with one line, and can be a part of a further chain. Its parts stay parts: one of them can be trained further, measured and replaced alone, and the rest is untouched. Parameters travel by name, so the chain above takes gender for its first part and case for its second without anyone wiring them.

Chains are not only series. A model can judge a whole text by pooling what it says about each word, and a model's answer can choose which follower runs. The word-class example does both: one model decides whether a text is Czech, German or English, and hands each word to that language's tagger. Four models, one chain, one file.

What this buys, measured on the examples in the distribution:

task	models	weights	not shown	core
German noun, singular to plural	umlaut, ending	28,763	98.3%	100% of 9,778
and on to a plural case	+ case	29,419	98.4%	100%
plural back to singular	singular	23,783	96.2%	99.8%
Czech word classes	class-ces	130,460	93.1%	100% of 4,306
English word classes	class-eng	173,423	80.8%	100% of 3,070

"Core" is the part of the vocabulary a model has to get right without exception; a goal can say so, and training does not stop before it holds. The 0.2% missing on the way back are plurals with two singulars, of which only one can come back. The Czech grammar example trains 108 such models in 87 seconds; 91 of them reach 100% and the weakest 98.5%. The plural chain is a file of 118 kB.

The English row is there on purpose. 80.8% on unseen words is what a model that reads only the spelling of an English word can know about its class, and no amount of training will change that. The remedy is context, which is a further model and not a larger one.

Fusable

A pipeline has Perl between its models: the first model's answer comes back, Perl builds the new string, the second model gets it. That is fine on a CPU and fatal on a GPU, where the transfer costs more than the computation.

A fused chain is the same models, as they are, in one model, with the hand-over inside it. Nothing is retrained and no weight changes. On the CPU the fused chain agrees with the pipeline to the last bit, answers and confidences. On the card it runs in 32-bit floats, and over all 45,218 German nouns not one answer differs.

my $fused = Peta::NN::Chain->load('dative.chain')->on('gpu');
my @forms = $fused->predict_all(\@nouns, gender => 'neuter',
                                         case   => 'dative');

Milliseconds per string, singular to a plural case, three models, by how many strings go through at once:

at once	pipeline	fused, cpu	fused, gpu
1	0.197	0.176	1.52
16	0.124	0.111	0.061
256	0.199	0.185	0.011
32,768	0.170	0.136	0.016

One string alone is ten times slower on the card, and from a few hundred strings on the fused chain is ten times faster than the pipeline. Most of what remains is Perl turning strings into numbers and edits back into strings; the card's own share is under 0.002 ms per string.

There is a third form, fused and consolidated: one model trained on what the chain does. We tried it once - 21,865 weights for 28,828, 98.1% for 98.4% - and it is not the default, because it gives up what the parts were for.

That is the bet of the project: many small models, each trained in seconds to minutes and checked on its own, then composed, as an alternative to training one large model - keeping what a large model gives up, which is knowing what each part does.

perl5 and pperl, three backends

A backend owns the tensors and implements about a dozen operations on whole batches. plain is flat Perl arrays, needs only perl, and is bit-identical on every perl. pdl is the CPU workhorse. gpu is one WGSL compute shader per operation on Peta::WebGPU, the binding the 0.6.20 post, "The Player of Games", introduced for the other kind of games; it needs a pperl built with the webgpu feature. A saved model carries no backend and loads on any.

Training the smallest model of the benchmark set (944 weights, batches of 16), samples per second, ThinkPad P53 with a Quadro RTX 5000:

	plain	pdl	gpu
pperl	31,400-32,000	48,400-51,400	22,300-24,200
pperl `--no-jit`	5,730-5,840	49,400-51,700	22,400-24,400
perl 5.44	5,230-5,430	not installed	none
perl 5.42	4,420-4,570	38,600-40,100	none

Two readings. In plain Perl the JIT is worth a factor of six: the same nested loops over Perl arrays, unchanged source. And the card loses. A training step on the GPU costs about a millisecond whatever is in it, so for a model this small the CPU is the faster engine, and it stays that way until the model or the batch grows:

weights	batch 16: pdl	gpu	batch 128: pdl	gpu	batch 512: pdl	gpu
944	56,000	17,200	160,400	123,400	229,900	306,000
4,136	35,900	15,700	54,500	86,300	60,500	226,600
19,080	14,800	14,500	22,800	104,700	24,400	386,300
37,768	8,600	14,500	12,800	109,200	13,300	615,500

At batches of 16 the two meet at about 20,000 weights, at 128 at about 2,000, and at 512 the card is ahead for every model, 46 times at the bottom right. Further up, at 1.6 million weights, a training step takes 31-38 ms on the card and 1.5 s on PDL.

Nobody should have to carry that table in their head, so a model that is not told where to train finds out: when it is trained, the library times a few steps on every backend this perl and this machine have, and goes on where a step is fastest. It assumes nothing about the order. A graphics card may not be there, PDL may not be installed, perl5 has no JIT, and each of the three wins somewhere.

Keeping the card busy

The first GPU run of the word-class example took 42 minutes, with the card idle most of the time: a second of training, then six seconds of one CPU core checking the model. It takes 4 minutes now. What brought it there was no faster shader but fewer crossings: the check of an epoch runs on the card, through a fused model of that one model, and the samples go up once and stay there, a step picking its batch on the card.

One thing that looked right and was not: gathering the embedding gradient in one pass per table row is a sixteenth of the work and ran five times slower. A hundred long loops do not fill a card; sixteen hundred short ones do.

Try it

Peta::NN is on CPAN, with the German noun data and the three trained chains in the distribution, so the getting-started page runs as printed:

cpanm Peta::NN

Every block of code in the documentation is run by a test, and its output is what the page shows. The suite is 774 tests on pperl; on a perl without PDL or without a card it skips what needs them and passes on the plain backend alone.

The caveats, as always. It is early and there is no API promise yet. A model asked about something outside its world answers anyway: the three-language identifier shown French picks one of its three, sure of itself. And these are models of spelling; what needs a sentence to decide is not in them yet.

Do not take our word for any number in this post. The German noun example ships with its data and trains on your perl, on whatever backend you have, in a few minutes.

Richard C. Jelinek, PetaMem s.r.o.

Minion: The Silent Engine That Turns Perl Into a Modern Architecture Platform

2026-10-06T01:16:09Z

By GoPerl — Architecture, Perl, Go & Node.js for companies that need reliable and scalable systems.

In today’s modern systems, especially in web development, new stacks and new developers grow up with the idea of async/await—in other words, asynchronous systems. Many adopt the concept without fully understanding what lies behind it. The simplest goal is clear: make your application feel fast and responsive, without leaving users waiting.

Let’s take this into the enterprise world, where speed, scalability and resilience define technological competitiveness. One concept that immediately enters the conversation is job queues. Behind every high‑performance system, there is always a subsystem responsible for processing heavy tasks without blocking the user experience.

Within the Perl ecosystem, that subsystem has a name: Minion.

Minion provides a modern job queue with SQL persistence, real asynchronous execution and a simple distributed model. This makes it a more robust and easier‑to‑operate alternative compared to Redis‑based solutions like Sidekiq or BullMQ.

Key Concepts
Job Queue
A job queue is a system that schedules, stores and executes tasks asynchronously—outside the main flow of the application.

Distributed System
Distributed means work is shared across multiple processes or machines, all cooperating to process the queue.

Scalable System
Scalable means it can grow without breaking and without forcing you to rewrite your architecture.

Minion is a modern system designed to run background tasks in an asynchronous, reliable and distributed way. It’s not “just another plugin”—it’s an architectural component that allows Mojolicious applications to operate with engineering standards comparable to Node.js, Go or Ruby on Rails.

What Minion Brings
Real SQL persistence (PostgreSQL, MySQL, SQLite)

Distributed workers

Automatic retries

Native dashboard (a big plus)

Direct integration with Mojolicious

This makes it an ideal solution for companies seeking to reduce operational complexity without sacrificing scalability.

Architectural Patterns Where Minion Shines
Minion is not simply “a job queue”. It’s an enabler of modern architecture:

1. CQRS (Command & Query Responsibility Segregation)
Heavy commands are delegated to Minion, while queries remain fast and lightweight. Perfect for reports, document generation and intensive processes.

2. Event‑Driven Architecture (EDA)
Business events can trigger one or multiple jobs: “user registered”, “payment confirmed”, “file processed”. Minion acts as an event processor and resilience mechanism.

3. Microservices with Asynchronous Tasks
Minion works as an internal queue for each service, avoiding heavy infrastructure like Kafka or RabbitMQ.

4. Saga Pattern (Distributed Transactions)
Break complex processes into independent steps with automatic compensations if something fails.

5. Batch Processing
Massive data processing, migrations, calculations and external API synchronizations.

6. Task Orchestration (Workflows)
Enterprise pipelines without external tools like Airflow.

Why Minion Outperforms Other Alternatives
Using a tool correctly often provides advantages over something “bigger” or more popular. This isn’t about which one is better—it’s about the benefits Minion offers compared to Sidekiq, BullMQ, Kafka or RabbitMQ.

Minion provides:

More robust SQL persistence

Fewer external dependencies

Integrated dashboard

Native Mojolicious integration

Lower operational complexity

Cleaner architecture for small and medium teams

Minion doesn’t compete with Kafka in massive throughput. It competes in simplicity, reliability and speed of implementation.

Implementing Minion is straightforward, and everything comes in a single package with no external dependencies.

Strategic Advantage for Companies
Adopting Minion means:

Faster responses for users

Heavy processes isolated and controlled

Better fault tolerance

Horizontal scalability without rewriting the application

Less infrastructure to maintain

A clear path to modernize Perl systems without expensive migrations

In an environment where efficiency and resilience matter, Minion turns Perl into a competitive platform for modern architectures.

If you already have legacy Perl systems, Minion can modernize them without rewriting code—just by adding a new architectural layer, you gain a modern, optimized and scalable system.

Let’s look at a complete example using Minion from scratch.

Installing and Using Minion in a Mojolicious Project (Step by Step)
1. Install Perl and Mojolicious
You need Perl and the Mojolicious framework installed before using Minion.

On Windows 11, use WSL

On Linux, Perl is usually already installed

Check Perl: perl -v

Install Mojolicious: cpanm Mojolicious

Install Minion: cpanm Minion

Install SQLite: cpanm DBD::SQLite

2. Create a Mojolicious Project
Generate the base structure of your web application.

Run: mojo generate app MyApp

Enter the project: cd MyApp

Verify lib/MyApp.pm and script/my_app exist

3. Configure Minion in the Application
Enable Minion and define the SQL backend.

Open lib/MyApp.pm

Add:

perl
$self->plugin('Minion' => { Pg => 'postgresql://user:pass@localhost/db' });
Or use SQLite for testing:

perl
$self->plugin('Minion' => { SQLite => 'myapp.db' });
4. Create a Sample Job
Define a task to be executed by workers.

perl
$self->minion->add_task(send_email => sub ($job, $address) {
sleep 2;
$job->finish("Email sent to $address");
});
5. Start the Mojolicious Server
Run the application to test the endpoint.

morbo script/my_app

Open: http://localhost:3000/example/queue

6. Run Minion Workers
Workers process jobs in the background.

In another terminal: perl script/my_app minion worker

Run as many workers as needed

You’ll see logs like: Job send_email finished

7. Open the Minion Dashboard
Monitor jobs, workers, errors and retries.

Visit: http://localhost:3000/minion

8. Test Failures and Retries
Simulate errors to understand system resilience.

Modify the job: die "Error";

Enqueue a job and watch Minion retry automatically

9. Scale Workers
Increase processing capacity by running multiple workers.

Open several terminals and run: minion worker

Each worker will pick different jobs

This demonstrates horizontal scalability

You can test everything with a simple POST request to:
http://localhost:3000/send_email

This week in PSC (238) | 2026-10-05

2026-10-05T20:38:48Z

The three of us discussed:

There is overall agreement that @INC handling should be improved, but there are still outstanding questions and issues that overlap with build modules, installer tools, and so on. Plan is to publish a partial document so far as a draft PR and get others to comment further.
The recent change to improve the accuracy of caller reported line numbers in expressions involving anonymous subroutines (Pull #24396) has caused more BBC fallout than might have been expected. So far it doesn’t need any immediate response from PSC but we continue to keep an eye on it.

[P5P posting of this summary]

Perl documentation (including POD) with Markdown and Docbook

2026-10-05T18:53:54Z

Introduction

I have uploaded to CPAN some tooling modules which allow Perl documentation to be authored as Markdown files - or Docbook XML articles - then merged into source files as POD. They can also then be published as HTML to static sites such as Github pages or Cloudflare Workers.

TL;DR here is an example of the end result - documention for the Cloudflare::API module created from the doc/ directory in the GitHub repository and POD for the command-line tool created from a Markdown file in the same repository.

Perl Documentation

Documentation can be tedious - despite knowing how important good documentation is, and that it can make or break open-source software. Nothing is worse than trying to run "man Some::Module" (or "perldoc Some::Manual") and getting nothing back.

POD is the "linga franca" of the Perl world for a good reason - it has stood the test of time, is completely integrated into the Perl ecosystem and is an excellent format for creating manual pages for Perl modules and scripts.

However arguably it doesn't translate well into the modern world of GitHub and other revision control systems, where Markdown is natively rendered by front-end browsers - and it's difficult for users to parse POD from the source code of your Perl file if they just want to understand what it does.

Markdown as POD

I have been using Markdown (and Docbook - more on that later) for documentation in Perl projects for a while now, and have released some tooling CPAN modules that allow Markdown sidecar files to be merged into their source equivalent as POD.

What is a Markdown sidecar file ? It's simply the same name as the source file with a .md extension appended.

Here is what a typical Perl distribution source repository may look like when using Markdown sidecar documentation:

Example-Client/
├── Makefile.PL
├── doc/
│   ├── example-client.xml
│   ├── example-client.md
│   └── images/
│       └── request-flow.svg
├── lib/
│   └── Example/
│       ├── Client.pm
│       └── Client.pm.md
└── bin/
    ├── example-client
    └── example-client.md

Ignoring the doc/ directory for the moment (more on that later) we can see that in the lib/ and bin/ directories each file has an associated sidecar companion file with a .md extension.

Using the CPAN Markdown::Pod::Embed module we can:

# Install the module
cpanm Markdown::Pod::Embed

# Makes the markpod command available
markpod --inplace --nobackup --recursive lib bin

And all Markdown in the companion sidecar files will be converted to POD and appended to their source files.

WARNING: Any existing POD in the source files will be replaced !

Makefile targets for POD merge

Running the markpod command is a bit cumbersome. If you install the supporting CPAN MakeMaker extension module ASPEER::MakeMaker::Markdown::Pod can run make doc as a Makefile target:

# Install the module
cpanm ASPEER::MakeMaker::Markdown::Pod

# Build Makefile with Markdown::Pod::Embed extension
perl -MASPEER::MakeMaker::Markdown::Pod Makefile.PL

# Make the documentation
make doc

This will convert all module and script sidecar files to POD and embed them into their original source files.

Why use the author namespace ? In short I did want to trample over the top level MakeMaker namespace, nor did I want to claim the ExtUtils::Markdown::Pod namespace.

As a bonus if "make doc" detects a README.md file in the distribution root it will convert it (assuming pandoc is installed) to a plain text README file.

What about other documentation ?

Sometimes a README.md or "perldoc Module::Name" isn't enough. You've got a raft of information you want to convey about how your module works, examples, screenshots, code demos etc.

Simple enough. Put it in the doc/ folder as Markdown and it will be available to anyone browsing the Github repository in a format which is reasonably viewable.

Usually that is fairly good, but it would be nice to publish it to Github pages - or another static site - in a simple way. This is where the CPAN module Markdown::Publish comes it. It will convert Markdown files in doc/ to static HTML via publishing engines such as Mkdocs Material, Docusaurus, Vitepress and Astro Starlight and push them to either Github Pages or (if you have an account) Cloudflare Worker Pages.

The Markdown::Publish module will split your Markdown into pages/sections at the heading boundary and sluggify them for navigation.

Assuming you have the directory layout above (and all system prerequisites such as Mkdocs Material installed):

# Install the module
cpanm Markdown::Publish

# Build the site
markdown-publish build

# Preview locally
markdown-publish serve

# Push to Github pages
markdown-publish gh-push

Makefile targets for Publishing

In the same way there is a module to create Makefile targets for the POD merge, there is one for Markdown publishing:

# Install the module
cpanm ASPEER::MakeMaker::Markdown::Publish

# Build Makefile with Markdown::Publish extension
perl -MASPEER::MakeMaker::Markdown::Publish Makefile.PL

# Make the documentation and push to Github pages
make publish_gh-push

Docbook

Sometimes Markdown isn't sufficient for documentation, or using it for large documents is unwieldy. Docbook (specifically a Docbook Article) can be a good format for technical writing, and provides a wider semantic context for material in the article vs Markdown.

Docbook can be eaiser to edit with tools like the XXE XMLMind Visual Docbook editor (sadly going out of support in 2027 but still available free for non-commercial use).

The CPAN Docbook::Convert module can convert Docbook articles to Markdown, which is then published through the standard toolchain.

Assuming the Docbook::Convert module is installed (along with required system binaries such as pandoc ) the MakeMaker::Markdown::Pod helper module will convert any Docbook articles to Markdown, allow publishing.

Examples

You can see and example of the Markdown::Publish module using several of these techniques itself. The Markdown::Publish Github repository contains a doc/ directory with a Docbook XML file which has been converted to Markdown. That Markdown is then published to the modules Github pages location as documentation.

You can also see the Markdown sidecar files in the bin/ directory and the embedded POD in the markdown-publish script (at the bottom of the file)

These modules are also used to publish the WebDyne documentation from WebDyne GitHub repository and the Cloudflare::API documentation from the Cloudflare::API GitHub repository.

AI Disclaimer

Many of these modules predate AI and are human coded. The Docbook::Convert and Markdown::Pod::Embed are largely human but have AI bugfixes incorporated. The ASPEER::MakeMaker family of modules are almost all human coded. The Markdown::Publish module was mostly human coded for MkDocs publishing, but then AI was tasked with with adding support for other publishing engines and decoupling from MkDocs specifically.

Still saving CPU cycles 32 years later: Rediscovering the Schwartzian Transform in Flutter

2026-10-02T23:56:10Z

A few days ago, an article by Flutter developer Hammad Tariq caught my eye: "Rendering 10,000 Machine State Changes on a Timeline Without Freezing Flutter".

It was a solid piece of profiling detective work. Hammad was building a high-density timeline view in Flutter representing 10,000 machine state transitions. But every time the dataset loaded, the mobile UI stuttered and dropped dozens of frames.

Under a section aptly titled "The Original Sin", the author identified the culprit:

sorted.sort((a, b) => DateTime.parse(a.start).compareTo(DateTime.parse(b.start)));

Because sorting makes O(N log N) comparisons, sorting 10,000 items was triggering over 215,000 redundant calls to DateTime.parse() right inside the comparison callback, blowing past the 16ms frame budget and freezing the screen.

To fix the frame freeze, Hammad introduced a clever optimization: map each item to a temporary helper object holding the pre-computed timestamp, sort the list using that cached value, and unwrap it:

// Step 1: Map to a wrapper holding the pre-computed sort key
final parsed = widget.activity.map(_ParsedActivity.new).toList();

// Step 2: Sort using the cheap, cached key

parsed.sort((a, b) => a.startUtc.compareTo(b.startUtc));

// Step 3: Unwrap and process down the pipeline

The UI freeze disappeared. The timeline ran smoothly.

When I read that section, I couldn't help but grin. Watching an engineer independently discover an algorithmic optimization from first principles is pure joy--especially when it's the exact Map → Sort → Map idiom I posted to Usenet (comp.lang.perl) back in 1994, which Tom Christiansen dubbed the Schwartzian Transform!

I dropped a friendly comment on the article letting them know their optimization has a 32-year history. And then I wrote up a full deep dive exploring how modern Dart 3 language features--specifically Records and Extension Methods--bring the idiom full circle, turning it into a type-safe, zero-boilerplate one-liner that runs 13x faster than naive sort.

I also dive into why Dart's official package:collection sortedBy() method doesn't cache keys either (and still burns 127,000 redundant evaluations), and link to the classic History of the Schwartzian Transform on Perl.com.

Whether you know me from the Camel and Llama books or my recent work as a Flutter GDE, it's deeply satisfying to see a 1994 Usenet idiom still saving CPU cycles on a 120Hz smartphone display in 2026.

Read the full article with benchmarks and code on DEV.to:
https://dev.to/gde/rediscovering-the-schwartzian-transform-why-i-had-to-comment-on-a-flutter-performance-article-30l0

pperl 0.6.21 - addendum

2026-10-02T02:52:23Z

This blog entry has no release attached to it. 0.6.21 is an internal version, not for release. In the four days since 0.6.20 a few things happened, but this post is not about new things. It is about old things the 0.6.20 post forgot, about how a project moving at this pace should announce anything at all, and about a question that deserves an answer in public: who pperl is for, at a time when you can ask an AI to port your Perl script to the language of your choice and be done.

]]> What the last post left out

"The Player of Games" covered the Benchmarks Game scoreboard, Memoize, the GPU binding and four bullet points. The two months it reported on contained more than that. The following landed between 0.6.8 and 0.6.20, is in the binary you can download, and was not mentioned:

The JIT rebuild is complete. The restart announced in Shall we play a game? landed, and the previous engine was deleted, about 19,700 lines of it. There is one JIT in the tree.
Encode went from 21 encodings to all 124 of the upstream distribution: the single-byte tables generated from the Unicode .ucm data, UTF-16/32 and UCS-2, the 21 multi-byte CJK encodings, ISO-2022, UTF-7 and the MIME encoded-word codecs.
Storable writes and reads perl5's format, byte for byte, including hooks, code references, regexps and the pre-0.7 streams. A file stored by perl5 retrieves on pperl and the other way round.
POSIX, Fcntl and Socket are complete against upstream's export lists: locking, sigaction, the termios constants, the socket option packers, sockaddr_un.
DBD::SQLite and DBD::MariaDB joined the drivers of the 0.6.8 post, with DBD::mysql now the compatibility layer over the latter. DBD::Pg gained arrays, COPY, savepoints and asynchronous queries. Peta::FFI gained closures, which is what SQLite's user-defined functions run on.
Coro 6.57 runs, the whole stack: EV 4.37 with libev 4.33 and Event 1.28 underneath, AnyEvent and Guard beside it.
HTTP::Parser::XS and Time::Piece are native.
The command line: the program is read from stdin the three ways perl5 reads it, the -d family reaches the debugger, -s, -T, -t, -W and -X behave as perl5's do, an assignment to $0 rewrites the process title, and --cpan installs modules.
The distributions' own test suites run inside our harness: 28 modules, 440 files, each compared against perl 5.44 running the same file.

The four days since 0.6.20 added 147 commits, among them Net::SSLeay with IO::Socket::SSL, the DBM family and the parallelizer on the new JIT (mandelbrot 10.85s -> 4.2s wall time). They belong to the next release post, if it remembers them.

The compression problem

The list above is in a different form from our usual posts, on purpose.

0.6.20 was 1,374 commits and about 454,000 lines of code change. The post announcing it was 12 kB, which is under nine bytes per commit. No prose compresses that far. What the post did instead was select: one topic in depth, two more in a few paragraphs, and the rest dropped. The selection followed what we had been working on in the last weeks before the release, and whatever was finished in August was no longer in view in late September. That is how a complete Encode goes missing.

There are three ways out, as far as we can see.

Less prose, more changelog. The nine items above take about 2 kB, a sixth of the last post. It is the efficient form, and it is substantially drier. A reader learns that Storable is byte-compatible and does not learn why it was not before, what the bump arena under binary-trees has to prove, or why asynchronous compilation lost. Those are the parts we would want to read ourselves.

More posts, smaller ones. A post per topic, when the topic is finished, as Doing a REJIT was. Nothing gets forgotten that way, because nothing waits for a release. The cost is on the reader's side: at the current pace this would be a post every few days, on a blog shared with other people.

Both, in different places. The complete record goes into a changelog that ships with each release and lives on the website, written when the work lands and not reconstructed afterwards. The blog post no longer tries to be that record. It links to it, and spends its 12 kB on the two or three things that are worth an explanation.

We lean towards the third. It keeps the prose where prose earns its space, and it removes the selection problem, since leaving something out of the post no longer means leaving it out. This post is the experiment: the section above is the changelog form, this section is the other one. If you read these posts and prefer one to the other, the comment field is open.

Who is this for, when AI can port your script?

A language model can transcribe code: small programs, medium ones, and with enough patience large ones. Whoever needs a Perl program to exist in another language can have that today, and nothing in this project argues against it.

What a language model cannot do is miracles. Give the best one available the task of writing a Perl entry for the Benchmarks Game that is valid under the Game's rules and beats the fastest node.js entry, and on perl5 it will not deliver, today or in the foreseeable future. On n-body the Game lists the fastest Perl entry at about seven minutes and node.js under nine seconds, and no arrangement of Perl source closes a gap of that size, whoever or whatever writes it. A top Formula 1 driver does not get a Lada Niva to 300 km/h either, and nobody concludes that the driver is the problem.

The scoreboard of the last post is the same statement from the other side. Those ten programs are Perl, they run on perl5 as well, and on pperl nine of them are ahead of the fastest scripted entry and the tenth is level with it. The source did not become cleverer in between; the car changed.

That is what pperl is: an option for Perl. Where the requirement reads "do X with Perl" and X is out of perl5's reach, X may be within pperl's. X can be speed, as above. It can be ease of use: a database script that connects without a driver build, a C compiler or an XS toolchain on the machine. It can be functionality: a GPU from Perl, or a hash whose integer-key access compiles to a probe in a register. Where perl5 reaches X, perl5 remains a perfectly good answer, and where no Perl is required at all, a port may be the shorter way. pperl widens the set of things for which Perl can be the answer, and a language model, however good, can only work inside that set.

Richard C. Jelinek, PetaMem s.r.o.

Dancer2 2.2.2 Released

2026-09-29T04:48:16Z

(yes, that's a lot of twos!)

Dancer2 2.2.2 is now headed to CPAN. This is a small bug fix release.

Bug Fixes

Fixed a crash when using class-method serializers (GH #1837)
Fixed test failures in gen.t affecting CPAN Testers and Debian builds (GH #1843)

Documentation

Updated a contributor's name in the documentation (PR #1844)

There are no security fixes, enhancements, or deprecations in this release.

Thanks to David Precious and Nova Patch for their contributions.

As always, bug reports and pull requests are welcome on GitHub.

Jason, on behalf of the Dancer Core Team

This week in PSC (237) | 2026-09-28

2026-09-28T20:30:34Z

All three of us (plus Graham’s cat) met as usual.

Discussions about some case-matching syntax ideas continue on the mailing list. PSC is following along but for now there does not seem to be a need to come to an official response.
From this it sounds like finding a better solution to controlling Perl’s autovivification (especially in deep hash accesses) is a useful goal and can be pursued independently. Potentially addressed by optional chaining (PPC0021).
Adding a builtin::rand_bytes function as per PR24722 sounds worthwhile. There are portability concerns that still need to be addressed on the subject of platform-dependent entropy sources (such as on VMS).

[P5P posting of this summary]

ANNOUNCE: Perl.Wiki V 1.54, Mojo.Wiki V 1.26

2026-09-28T11:59:46Z

From my Wiki Haven you can now download:

Perl.Wiki V 1.55

cpan.metacurator.tree.html V 1.32

Mojo.Wiki V 1.26

The basic purpose of these is to deal with the upgrade of TiddlyWiki from V 4 to V5.

Up to V 4, CamelCase words were treated as links to be clicked.

From V 5. all links to be clicked must be in double brackets: [[...]].

I have updated Perl.Wiki & Mojo.Wiki to use [[...]] and will progressively upload updated versions of the other wikis to match.

Simultaneous Solutions (GLAM part 1)

2026-09-28T02:49:16Z

New York

Last week I went to visit my teen nephew and niece in New York. A wonderful city of contrasts, where opulence blends with poverty, with shops selling a margherita for 2 bucks a slice next to a place offering margaritas at 20 bucks a sip, and streets full of people either with pots of cash, or those blowing cash on pot. Likewise my nephew, (let’s call him Nathan) and my niece (pseudonymised here to Norma), present equally contrasting mindsets and approaches to life, yet manage to live semi-harmoniously in this subtly harsh environment.

Norma is an impossibly adorable individual, well mannered and courteous while being confident and sharp; were it not for a rather intense interest in the lives of serial killers and their victims, you’d imagine her as a Disney princess. Nathan on the other hand is a man who prefers solitude, gaming and basketball. While startling everyone now and then with his wit and intelligence, he is incredibly self-contained. I can imaging him walking down the corridors of school, leaning back at a gravity-defying angle, looking left and right, but never straight ahead, head tilted back but eyes downwards, enabling him to look down his nose at people much taller than him. While being devoted to each other in secret, they would never agree on anything, and never admit that the other has a point however similar it was to their own, deprecating common interest and amplifying minor differences.

If only one could rationalise their disagreements, prove that their by-and-large on the same side, then surely I would have missed out the entertainment their mini-battles provided. Indeed, while there is an inward joy when you see your sibling’s kids make their parents pull their hair out (as an uncle I am obliged to encourage this kind of behaviour), harmony between the two would indeed be a novel alternative experience in my sister’s household.

Such is the rational for the conflicts that plague the globe today, and indeed the world of Graphical Games programming.

Graphical Coding

I would like to be able to program some games. But I understand graphics so little. As an intermittent coder, each example one comes across appears to have paradigms which make perfect sense yet remain incompatible with each other. One day I am offered one magical example, the next, another day another one from a different book of incomprehensible incantations, both blending actual Game Logic with the alien hieroglyphics representing their respective backends. Hence, until now, I have mainly developed for the terminal, finding no easy entry into the land of graphics. Games require interaction as well as graphics. Examples available typically intertwine Game Logic, Interaction Handling, The Graphical outputs, The Game Loop within the code, the entanglement further complicating the journey into learning.

By some chance, one Redditor u/FirstAd8230 posted a GLFW/OpenGL demo. Within two hours SANKO or u/sthrowawayr posted an SDL3 equivalent yielding and identical output, down to the look and interaction purely because he had difficulty in installing GLFW on his setup. This was the Rosetta Stone I was looking for. Both bits of code had identical Game Logic. Treating these like one would treat simultaneous equations, one is able to extract the common code which represent the game engine easily. The residue then are backend specific code handling the other components mentioned above; still looking complicated but now manageable as it is possible to extract each call to the backends from the game logic.

From this, The Graphics Layer Abstraction Module or GLAM is born. A tool that transforms the complexity of the backends into simple calls, that can use either backend simply by changing one line of code. The simple demo above had all the components to make many possible games and utilities, but to add simplicity one has to have a tool that abstracts away the residual complexity altogether. How? GLAM offers two modules for now (GLAM::OpenGL and GLAM::SDL). These modules provide 1) A means to capture key board and mouse events that can change Game State 2) A means to represent the Game State graphically using only one capability (the ability to draw a triangle) to render all graphical output 3) A way to start and exit the Game Loop.

What is the benefit? Well the simplicity allows the occasional developer, like myself, developer to concentrate on the Game Logic, without remembering complex construction of graphical tools. It further permits those with difficulties in installing one backend for what ever reason, to easily swap in another (currently only two, but more imminently possible). The Rope Demo and the two different iterations with similar outputs, has all the parts required to make quite complex interactive tools. One can easily replicate this using GLAM.

A carrom board game, a South Asian game played on a boards with counters and pockets can be simulated relatively easily. To see how to create similar games using GLAM see Part 2.

Conclusion

By converting the backend specific, complex code into generic, agnostic code the developer can concentrate on the goals he has rather than the paradigm his principles and platforms force him to follow. The results is code for each backend that looks nearly identical and the differences hidden away.

As I witness Nathan and Norma, so similar in so many ways and yet so completely different in others, go through their daily conflicts with the remote, the best spot on the sofa, or who walks the dog, I see all our children; complex individuals we are able to love dearly despite their diversity, future leaders of industry, the world and a source of intense pride in parents (and uncles). Harmony would be a possible illusion if we could abstract out the differences. But failing that, one hopes one day they are blessed with children just like themselves.

pperl 0.6.20 - The Player of Games

2026-09-27T18:13:55Z

pperl 0.6.20 is released, and readers of the two previous posts - Shall we play a game? and Doing a REJIT - know what that means. This post carries the Benchmarks Game scoreboard. It also covers a native Memoize whose cache hit is compiled into the caller, a GPU binding on the wgpu crate for the other kind of games, and a few smaller items.

]]> The scoreboard

The house rules are those of the first post, and every program stays within the algorithms the Benchmarks Game accepts in some language. All of ours are single-threaded.

CPU seconds at the contest sizes, every output byte-identical to the pole's. The pole is the fastest scripted-language entry, node.js unless noted, pinned to four physical cores as on the Benchmarks Game machine, which has no hyperthreading. The unpinned column is given for reference: there node's threaded programs spread onto hyperthread siblings and read differently from day to day. Ratios are pole/pperl, so above 1 pperl is faster.

benchmark	pperl	pole/pperl, pinned	unpinned
pidigits 10,000	1.12 s	7.33x	7.21x
binary-trees 21	4.51 s	3.12x	6.41x
fasta 25M	3.47 s	1.88x	2.06x
reverse-complement 25M	0.87 s	1.53x (python3)	1.48x
spectral-norm 5,500	2.19 s	1.26x	1.26x
mandelbrot 16,000	12.13 s	1.20x	1.57x
regex-redux 5M, Peta::PCRE2	3.09 s	1.07x (python3)	1.25x
fannkuch-redux 12	36.69 s	1.02x	1.57x
n-body 50M	5.87 s	1.01x	1.03x
k-nucleotide 25M, Peta::Dict	38.98 s	0.99x	0.99x

k-nucleotide's 0.99x is against the pole's recorded time; timed back to back with node, pperl took 37.92 s and node 40.42 to 42.39 s.

binary-trees went from 26.1 s to 4.5 s in one day. When one compiled sub builds a tree and the next call in the same statement only walks it, no Perl code can ever see that tree, so the JIT builds it in a bump arena, one small record per node, and frees it with a single store. Every node is still built and walked, and the program is unchanged; any failure discards the arena and re-runs the statement interpreted. It is the freedom V8 takes with objects that do not escape.

mandelbrot went from 31.1 s to 19.4 s once four pixels are computed side by side in SIMD vectors, and to 12.1 s once an interval-arithmetic proof, built on the loop's own escape test, replaces the per-result overflow checks with one guard per group of pixels.

fasta and fannkuch-redux were ordinary compiler work. fasta's generator ran in doubles because a constant carried a floating-point value from an earlier division, where perl5 itself takes the integer path. fannkuch-redux now processes permutations in pairs, as the C and Lua entries do, and a range proof removes the bounds and overflow checks from its swap loop.

regex-redux is won with whatever gun is available, here Peta::PCRE2, a native binding to libpcre2 and the same means the fastest Python entry uses. The ReJIT gun announced in Doing a REJIT is not quite there: it ships in this release, on by default (--no-regex-jit turns it off), and takes the built-in engine from 8,853M to 1,703M instructions on that post's measurement input. That is 5.2x faster than the stock regex engine, against the 3-5x the post predicted; at contest size the built-in engine runs at 0.88x of the pole.

k-nucleotide took a new gun. The published Perl entry counts k-mers as strings in a hash and stops at 0.63x however well the loop compiles, because the time goes into string hashing. node packs each k-mer into a 2-bit-per-base integer and counts in a Map, and the rules allow us the same algorithm. Peta::Dict is that dictionary for Perl: tie my %h, 'Peta::Dict' binds a hash to an open-addressed table whose integer-key accesses the JIT compiles to an in-register probe, the shape that also carries Memoize below. $h{5} is still $h{"5"}, and on perl5 the same source runs on a pure-Perl fallback with identical output.

mandelbrot through PDL was the other gun we had to test, and it is the slower one: at N=2000 pperl with its native PDL retires 14.7G instructions, perl5 with XS PDL 19.0G, the JIT-compiled scalar loop 4.9G. A vector formulation pays all 50 iterations for every pixel, where the scalar loop leaves at the escape.

JIT latency is a bonus on top. A small loop run briefly measures compile time rather than compiled code, and there pperl is far ahead: 141M instructions against node's 1,597M on a 120x120 mandelbrot, and any short loop, synthetic or not, shows the same. V8 spends its longer compile on more optimisation, which is what the table above measures. We aim for both: short compile latency and compiled substrate efficiency.

A dead end: asynchronous compilation

On short runs the JIT compile is a large share of the run time, so we built the usual answer: hand the hot loop to a compiler thread and keep interpreting until the code is ready. It worked, passed the JIT suites, and was reverted, because it never won. At mandelbrot 16,000 the asynchronous build took 141 s against 131 s compiling synchronously, and no smaller size won either.

The result is counterintuitive only at first. While the compile runs, the only useful work the program has is the very loop being compiled, so the choice is between stalling and interpreting that loop. Both spend the compile's wall time; the iterations interpreted meanwhile are iterations the compiled code would have run many times faster, and polling for the finished code costs a little on top. The compile stall was a cost to shrink and not time to fill, since compiled code is so much faster that one wants it as soon as possible. Asynchronous compilation pays where the program has other compiled code to run in the meantime, which a single dominant hot loop never has.

Memoize, faster

Memoize is now a native module, and the JIT knows it. memoize('f') installs a memo CV in place of f; a compiled caller probes the cache in-register and only leaves compiled code on a miss, so a hit costs about 42 instructions per call and never builds an argument list. Source is unchanged, use Memoize; memoize('fib'); as ever.

Hit cost against perl 5.44 with CPAN Memoize, final PGO build:

function	arity	speedup
fib	1	63.5x
dist	2	51.7x
ackermann(2,k)	2, recursive	62.9x
Tak	3, recursive	36.7x

The geometric mean is 52.5x. The compiled path covers numeric arguments of arity 1 to 4, including nested calls, calls in return position, self-recursion and calls from outside the function. A miss-dominated run, ackermann computed once, gains 7.5x, which is the algorithm and not the cache. Non-numeric arguments take the ordinary path and behave as CPAN Memoize does, warnings included, and deep memoized recursion stays compiled with perl's recursion warning intact. A register cache for string keys is specified and deferred, since the payoff is small today.

One divergence is deliberate. CPAN Memoize keys its cache on join chr(28), @_, and a number stringifies to 15 significant digits, so the arguments 0.30000000000000004 and 0.3, two different doubles, both become the key "0.3": once f(0.3) is cached, f(0.30000000000000004) returns that result, which is the wrong answer for its argument. The compiled path keys on the raw bits of each double, which are exactly what the pure callee receives, so a hit always returns what the call would have computed. The reverse case is harmless: 1 and "1.0" are two Memoize entries and one here, and the numeric body cannot tell them apart. We do not emulate the collision.

Perl and 3D graphics

The other kind of games needs a window, a renderer and a GPU.

Peta::WebGPU is a native binding to the Rust crate wgpu, which drives Vulkan, Metal, DX12 and GL behind the WebGPU API. It computes and it draws: adapters and limits as the card reports them, buffers, WGSL shaders, compute dispatch and read-back, and render pipelines and render passes into a surface taken from an SDL2 window. Validation errors, which wgpu reports out of band, arrive as Perl exceptions carrying wgpu's own text, and a panic inside the crate becomes a croak instead of taking the interpreter down. A PDL ndarray uploads straight into a GPU buffer without a pack step. The module sits behind the cargo feature webgpu, off by default, since it links a GPU stack into the binary.

my $win  = SDL2::Window->new(title => 'triangle', w => 800, h => 600);
my $gpu  = Peta::WebGPU::Device->new(window => $win);
my $surf = $gpu->surface;

my $frame = $surf->next_frame or next;
$gpu->render_pass($frame, clear => [0.1, 0.2, 0.3, 1])
    ->pipeline($pipe)->vertices($verts)->draw(3)->end;
$frame->present;

Underneath it the 2D substrate has become real: native bindings to SDL2 (renderer, surfaces, SDL2::Image), GD, Cairo and Imager. The documentation follows the code. The 2D graphics guide has been re-anchored on SDL2, is available in all 41 locales, and closes with a capstone that is a complete small game: paddle, ball, score, keyboard control and a steady frame rate, in plain Perl on the SDL2 binding. The new 3D graphics guide runs from foundations and a software rasteriser through shading, meshes, model formats, modelling operations and scene graphs to the GPU, and closes with three capstones: a world generator, a modeller and a 3D game. Every example was run before its prose was written. Both guides are at https://perl.petamem.com/docs/eng/.

Other tidbits

With --no-jit, the plain interpreter is now about 20% faster than perl 5.44. The JIT numbers above are on top of that and not a substitute for it.
PDL is measured against perl5 running PDL's own test suite, and the native tree went from twelve mismatches to none. Exports now come from the sub-modules as upstream arranges them, the broadcast dimension engine is wired in, xchg, transpose and dummy are views as upstream's are, and glue/append on a lazy slice no longer abort.
Loading POSIX, PDL::Lite, PDL::LiteF or PDL::MatrixOps under -w printed hundreds of redefinition warnings perl5 does not print; they are gone.
A loop that cannot repay its compile time is no longer compiled, which removes a 4-8x penalty on short-running scripts.

Statistics

pperl 0.6.20 represents approximately 2 months of development since 0.6.8 and contains approximately 3,743,000 lines of changes across 42,000 files from 2 authors.

Excluding auto-generated files, documentation, assets, vendored modules and tooling, there were approximately 454,000 lines of changes to 1,700 .rs, .pl, .pm and .t files.

Get 0.6.20 here: https://perl.petamem.com/

Richard C. Jelinek, PetaMem s.r.o.

This week in PSC (236) | 2026-09-22

2026-09-22T20:40:04Z

All three of us met.

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.

[P5P posting of this summary]

A NetAddr::IP Trial Release

2026-09-22T03:08:53Z

After years of quiet, NetAddr::IP has a new maintainer and a new trial release. If you use this module for IPv4/IPv6 address manipulation, here's what you need to know.

Breaking Changes

There are three breaking changes in 4.080_01. Before you reach for the pitchforks, they're all cases where the old behaviour was a bug, not a feature:

re() on IPv6 objects in IPv4 space no longer emits a broken regex (GH#34). Previously it returned a regex that couldn't match anything useful.
re6() now returns a non-capturing group (?:...) (GH#50). The old capturing group was almost never what the caller wanted.
new(undef) returns undef instead of the default route (GH#29). Passing undef to a constructor should not silently give you 0.0.0.0/0.

All three are cases where the documented or sensible behaviour was different from what the code actually did. If your code relied on the old behaviour, it was already broken -- you just hadn't noticed yet.

Deprecation

The :rfc3021 export tag is deprecated (GH#26). hostenum/hostenumref now return 2 hosts for /31 and /127 unconditionally, matching the RFC. The dead $rfc3021 variable has been removed (GH#63).

Bug Fixes (Selected)

The release includes fixes for a number of long-standing bugs. Some highlights:

coalesce now counts subnet addresses, not usable hosts (GH#37)
coalesce works on subclass objects (GH#38)
coalesce validates its arguments and croaks on bad input (GH#40)
new6() prefers AAAA over A for dual-stack hostnames (RT#119858, GH#32)
new6() returns compatible form for IPv4-only hosts (GH#64)
:nofqdn import tag actually works now (RT#111301, GH#1)
canon/short compress the first equal-length zero run per RFC 5952 (GH#13)

Plus neg/abs overloads (GH#67), bracket notation fixes (GH#68), and many more. See the full Changes for the complete list.

Test Suite Modernisation

The entire test suite -- 157 files, nearly 3,000 tests -- has been converted from bespoke TAP output to Test2::V1. The tests now run cleanly on Perl 5.14 through 5.42 on Linux and macOS (Intel and ARM). The XS and pure-Perl code paths are both covered in CI.

Try It Out

This is a trial release. Install it with:

cpanm DJZORT/NetAddr-IP-4.080_01.tar.gz

or clone the repo:

git clone https://github.com/cpan-authors/perl-NetAddr-IP.git
cd perl-NetAddr-IP
dzil test

If you find regressions, open an issue on GitHub. The more smoke reports, the better the stable release will be.

Dancer2 2.2.1 released (security)

2026-09-19T06:18:18Z

Dancer2 2.2.1 is now on CPAN. This is a security release; upgrading is recommended.

Dancer2::Serializer::YAML handed request bodies straight to YAML::Load. A body tagged !!perl/hash:Some::Class could therefore instantiate an arbitrary blessed object, and !!perl/code could ask for a string eval. Both are now refused explicitly rather than left to YAML.pm's defaults.

Note that you can be exposed without having configured YAML yourself: Serializer::Mutable maps both text/x-yaml and text/html to this serializer.

Two packaging notes for this release: the minimum YAML version is now 1.30, and Dancer2 now declares the minimum CLI::Osprey it needs (0.09).

Thanks to David Precious for the YAML work.

Dancer2 2.2.0 released; security updates PLEASE READ

2026-09-16T17:13:34Z

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:

GHSA-6xw8-v24c-m783 (Severity: High; Versions affected: <= 2.1.0)
GHSA-v527-r4px-7vx7 (Severity: Moderate; Versions affected: >= 2.0.0, <= 2.1.0)

A recap of all changes follows.

Security fixes

Path traversal in static file serving. Dancer2::Handler::File could serve files from outside public_dir. (GHSA-6xw8-v24c-m783)
Hook exception handling. If an on_hook_exception handler halted, the route that the hook refused could still run. (GHSA-v527-r4px-7vx7)
Header injection. CR and LF are now stripped from response header names, as they already were from header values.
AutoPage no longer serves a layout as a page on case-insensitive filesystems.
Session IDs are now always generated with Crypt::URandom, and validate_id rejects invalid session IDs more strictly.

Breaking changes

The Data::Dumper serializer has been removed from core, along with the from_dumper and to_dumper keywords. If your app uses them, make sure to download Dancer2::Serializer::Dumper from CPAN.

Bug fixes

send_file now sends the correct error codes.
The path() and dirname() DSL keywords no longer drop their first argument.
Serializer::JSON handles UTF-8 correctly for readonly values and no longer recurses endlessly into blessed objects.
Serializer::Mutable ignores content type parameters such as charset when choosing a format.
Each response content assignment is now encoded, not just the first.
uri_for_route accepts a route parameter of 0 and gives a clearer error for an empty one.
Hooks are compiled only once, however many times to_app is called.
A NUL byte in a static file request no longer produces a warning on every request.
App root directory detection has been fixed.
Several dancer2 gen fixes:
- -g and -r no longer die after writing the app.
- The app directory is named after the dashed distribution name.
- The pattern added to MANIFEST.SKIP is relative and matches correctly.

Documentation

The header precedence documented for Serializer::Mutable now matches what it actually does.
%D has been removed from the documented log_format characters, since it was never implemented.

Thanks

Thanks to everyone who contributed to this release, especially:

Anton Lundin, for fixing the error codes in send_file
Mike Weisenborn, for the path()/dirname() fix
Curtis "Ovid" Poe, for surfacing many of these issues with PAAD
David Precious (bigpresh) and Russell Jenkins (veryrusty) for running with these items and seeing them through to completion

Cheers,

Jason/CromeDome

ANNOUNCE: Perl.Wiki V 1.54, etc

2026-09-15T08:06:26Z

From my Wiki Haven you can now download:

Perl.Wiki.html V 1.54

cpan.metacurator.tree.html V 1.31

Mojo Wiki V 1.25

Two Optimisation Tasks in the Weekly Challenge 391

2026-09-14T21:31:53Z

Array Median

We are given two sorted arrays, our task is to merge them and return the median. Let’s start with the naive approach: just let Perl sort the list and select the median.

#!/usr/bin/perl
use warnings;
use strict;
use experimental qw( signatures );

sub array_median_naive($arr1, $arr2) {
    my @m = sort { $a <=> $b } @$arr1, @$arr2;
    return unless @m;

    return @m % 2 ? $m[ $#m / 2 ]
                  : ($m[ $#m / 2 ] + $m[ @m / 2 ]) / 2
}

]]> My initial idea was to create a sliding window of size 2. Let the window slide over the merging arrays, stop at the middle and report the median. Unfortunately, the code doesn’t stay elegant. We only populate the @m array when at the right position, before reaching the middle we just adjust the indices into the two merging arrays.

use POSIX qw{ ceil };

sub array_median_sliding($arr1, $arr2) {
    my $pos = (@$arr1 + @$arr2 - 1) / 2;
    return if $pos < 0;

    my $size = 2 - (@$arr1 + @$arr2) % 2;

    my @indices = (0, 0);
    my @m;
    for my $step (0 .. ceil($pos)) {
        if ($indices[0] > $#$arr1) {
            push @m, $arr2->[ $indices[1] ]
                if $step >= ceil($pos) - 2;
            ++$indices[1];
        } elsif ($indices[1] > $#$arr2
                 || $arr1->[ $indices[0] ] <= $arr2->[ $indices[1] ]
        ) {
            push @m, $arr1->[ $indices[0] ]
                if $step >= ceil($pos) - 2;
            ++$indices[0];
        } else {
            push @m, $arr2->[ $indices[1] ]
                if $step >= ceil($pos) - 2;
            ++$indices[1];
        }
    }
    return $size == 1 ? $m[-1] : ($m[-1] + $m[-2]) / 2
}

Optimisation usually complicates code. What’s surprising here is that the sliding window is more than twice slower than the naive implementation! On the other hand, it’s memory efficient: it only needs to store two elements from the array, and a couple variables to handle the sliding window. If the two arrays are really large and merging them into memory isn’t possible, this is the algorithm to reach for.

After some attempts, I was able to optimise the naive approach, though. The trick is not to store the sorted list in an array, but instead just use a list slice to select the needed elements:

sub array_median_opt($arr1, $arr2) {
    my $size = @$arr1 + @$arr2;
    return if 0 == $size;

    my @m = (sort { $a <=> $b } @$arr1, @$arr2)
            [ $size % 2 ? $size / 2
                        : $size / 2 - 1, $size / 2 ];
    return @m == 1 ? $m[0] : ($m[0] + $m[1]) / 2
}

You can see the actual benchmark code in my GitHub repository.

         Rate sliding   naive     opt
sliding 111/s      --    -62%    -87%
naive   292/s    163%      --    -66%
opt     869/s    684%    198%      --

Arrange Box

We are given an array of boxes, each box is represented by an anonymous array with two elements, representing the box’s width and depth. Our task is to find the maximum number of boxes that we can stack into each other: a box must be smaller in both dimensions to fit into another box.

Here, the examples are too simple. Let’s have a look at one of them:

Sort by width ascending: ([10, 20], [12, 18], [15, 10], [16, 25], [20, 30])
Extract depths: (20, 18, 10, 25, 30)
[15, 10] -> [16, 25] -> [20, 30]

The result is just the last three elements of the sorted list of the boxes. But in a general case, we can have boxes in between. Once we select a box, we rule out boxes with a greater width but smaller depth.

Let’s modify the input slightly:

[10, 20], [15, 10], [16, 18], [17, 25], [20, 30]

We can’t use the first box, because it rules out boxes number two and three, leading to only 3 boxes stacked in each other. Starting from the second box, though, allows us to stack 4 boxes. And you can imagine this can happen many times in the sequence. In fact, this seems almost like a longest common subsequence problem, which is NP-hard.

Fortunately, it’s not that bad. I proceeded in steps: in each step, I took all the possible sequences of a given length, and tried to extend them by one box.

sub arrange_box(@boxes) {
    my @s = map $_->[1],
        sort { $a->[0] <=> $b->[0] || $b->[1] <=> $a->[1] }
        @boxes;
    my %paths;
    @paths{0 .. $#s} = ();
    my $max_length = 0;
    my $length = 0;
    my $change = 1;
    while ($change) {
        ++$length;
        undef $change;
        for my $path (keys %paths) {
            delete $paths{$path};
            $max_length = $length if $length > $max_length;
            my $last = (split ' ', $path)[-1];
            for my $next ($last + 1 .. $#s) {
                next if exists $paths{"$path $next"}
                     || $s[$next] <= $s[$last];

                undef $paths{"$path $next"};
                $change = 1;
            }
        }
    }
    return $max_length
}

Note that we only work with the depths (see the map at the beginning of the subroutine). We know that widths are already sorted, and if there are several boxes of the same width, they are sorted by their depth in descending order, so we’ll never try two boxes of the same width in the same sequence: $s[$following] is never greater than $s[$box] for the boxes of the same $width.

For a randomly generated list of 100 boxes, the number of possible sequences of length 8 can easily reach 2.5×10⁶ (try adding warn scalar keys %path; at the beginning of the while loop). It’s slow and consumes a lot of memory.

Fortunately, we don’t really need to remember the whole sequences. We are interested in their lengths—and in each step, we build all the sequences of the same length. The only information we actually need is the last element of each sequence. This leads to the following code:

sub arrange_box(@boxes) {
    my @s = map $_->[1],
        sort { $a->[0] <=> $b->[0] || $b->[1] <=> $a->[1] }
        @boxes;
    my %last;
    @last{0 .. $#s} = ();
    my $length = 0;
    while (keys %last) {
        my %next;
        ++$length;
        for my $box (keys %last) {
            for my $following ($box + 1 .. $#s) {
                undef $next{$following} if $s[$box] < $s[$following];
            }
        }
        %last = %next;
    }
    return $length
}

There’s never more last elements of all the sequences than the number of boxes. Finding the solution for a list of 1000 boxes takes about a second on my old machine.

This week in PSC (235) | 2026-09-14

2026-09-14T21:02:00Z

The first meeting of the newly-elected group.

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.

[P5P posting of this summary]

The Lightning Talks of the German Perl Workshop 2026 are online

2026-09-13T11:11:49Z

Thanks to some crafty editing by Lee, the lightning talks are also online on Youtube.

Thanks again to all the past speakers!

Many conference speakers got their start with a lightning talk - maybe on your next conference you want to give a lightning talk too?

These presentations are up to 5 minutes long - the ideal way to introduce your favorite module, TV series, or really just about any topic.

Adventures with Fortran

2026-09-12T21:10:54Z

If you do scientific and/or numerical computing, you probably use or at least know about BLAS, and LAPACK. If you've done much programming with them, you may have passed in data that it cannot handle, and then you'll probably know about xerbla_.

xerbla_ is the error-handler in those two libraries, and by default it terminates the whole process. To do otherwise you have to provide a replacement routine, and have the linker for your program insert that replacement, which the library will then use instead. This is increasingly hard or impossible to do, including on macOS, Windows, and static libraries. There is now an open pull-request in the reference versions of those libraries that will permanently solve this, by allowing client programs to just pass in a new handler, which will then be used. No linker stuff involved.

Implementing this involved figuring out how to achieve this in Fortran. As a test-bed, I made a directory with this simple, no-nonsense Makefile:

FC = gfortran
FFLAGS = -g

.f90.o:
        $(FC) $(FFLAGS) -c $< -o $@
.f90:
        $(FC) $(FFLAGS) $< -o $@ $(LDFLAGS)
.SUFFIXES:
.SUFFIXES: .f90 .o

all: callbacks

The first try was using somewhat modern Fortran, with a module:

module xerbla_callbacks
  implicit none
  private
  public :: active_callback, xerbla_interface
  procedure(xerbla_interface), pointer :: active_callback => null()
  interface
    subroutine xerbla_interface(srname, info)
      character*(*), intent(in) :: srname
      integer, intent(in) :: info
    end subroutine
  end interface
end module xerbla_callbacks

subroutine set_xerbla(cb)
  use xerbla_callbacks
  implicit none
  procedure() :: cb
  active_callback => cb
end subroutine set_xerbla

subroutine get_xerbla(cb_ret)
  use xerbla_callbacks
  procedure(xerbla_interface), pointer :: cb_ret
  cb_ret => active_callback
end subroutine get_xerbla

subroutine xerbla(srname, info)
  use xerbla_callbacks
  character*(*), intent(in) :: srname
  integer, intent(in) :: info
  if (associated(active_callback)) then
    call active_callback(srname, info)
  else
    print *, 'I am the main xerbla'
  end if
end subroutine

subroutine xerbla_replacement(srname, info)
  character*(*), intent(in) :: srname
  integer, intent(in) :: info
  print *, 'I am the replacement xerbla'
end subroutine

program hello
  use xerbla_callbacks
  implicit none
  external xerbla_replacement, set_xerbla, xerbla
  procedure(), pointer :: already_cb
  interface
    subroutine get_xerbla(cb_ret)
      procedure(), pointer :: cb_ret
    end subroutine
  end interface
  call xerbla('Hello, World!', 5)
  call get_xerbla(already_cb)
  call set_xerbla(xerbla_replacement)
  call xerbla('Hello, World!', 5)
  call set_xerbla(already_cb)
  call xerbla('Hello, World!', 5)
end program hello

This didn't work in LAPACK because it has an automatic translation facility to turn its source files into versions that suffix routines with _64 that cannot handle modules well. Using an older idiom that allows stored, persistent data was necessary, using the ENTRY keyword.

subroutine xerbla(srname, info)
  character*(*), intent(in) :: srname
  integer, intent(in) :: info
  procedure(xerbla_interface), pointer :: active_callback => null(), cb_ret
  procedure(xerbla_interface) :: cb
  abstract interface
    subroutine xerbla_interface(srname, info)
      character*(*), intent(in) :: srname
      integer, intent(in) :: info
    end subroutine
  end interface
  if (associated(active_callback)) then
    call active_callback(srname, info)
  else
    print *, 'I am the main xerbla'
  end if
  return
  entry set_xerbla(cb)
    active_callback => cb
  return
  entry get_xerbla(cb_ret)
    cb_ret => active_callback
  return
end subroutine

subroutine xerbla_replacement(srname, info)
  character*(*), intent(in) :: srname
  integer, intent(in) :: info
  print *, 'I am the replacement xerbla'
end subroutine

program hello
  implicit none
  external xerbla_replacement, set_xerbla, xerbla
  procedure(), pointer :: already_cb
  interface
    subroutine get_xerbla(cb_ret)
      procedure(), pointer :: cb_ret
    end subroutine
  end interface
  call xerbla('Hello, World!', 5)
  call get_xerbla(already_cb)
  call set_xerbla(xerbla_replacement)
  call xerbla('Hello, World!', 5)
  call set_xerbla(already_cb)
  call xerbla('Hello, World!', 5)
end program hello

Amazingly, this actually all works, and when the C interfaces for these things are figured out, this facility will become available. That will solve a lot of tricky problems, especially for those who make dynamic-language bindings for BLAS etc, but also for those using it on macOS, Windows, etc.

Running Perl/PAGI applications on Cloudflare Workers via WebAssembly

2026-09-12T07:22:15Z

Background

I've been developing the WebDyne framework to make creation of Perl-based web applications easier (for me anyway). Most of the apps I write now use John Napiorkowski's excellent PAGI design, as it supports modern asynchronous web services such as SSE and WebSockets.

One of the challenges has always been: "where do I host them?"

They run fine in Docker containers, and the demo website currently runs on Sevalla in a relatively cheap container. I could also run them in an AWS Lambda environment, but with either option I have to pick a region, and — especially with full Docker containers — hosting multiple sites can be relatively expensive for "small" applications.

Cloudflare Workers and WASM

Cloudflare Workers have always looked attractive. For a starting price of $5/month on the compute and storage plans you get a fair bit of "bang for your buck", with about 8 CPU-hours/month for Worker isolates (basically Lambda functions), with the added bonus that they are — or at least can be — "Cloud Edge": they spin up close to the consumer on demand, but you are charged for actual usage rather than the number of Workers that are running.

Obviously prices go up with consumption, but you can get a fair bit done with the starting price.

Couple that with access to storage services such as D1 (SQLite-compatible database), KV storage and R2 (S3-compatible object storage), and things start looking reasonably attractive.

But, like almost everywhere today, Perl is a second-class citizen. Cloudflare Workers primarily target JavaScript, TypeScript and Python, with languages such as Rust supported through WebAssembly.

But importantly, Workers can run WebAssembly (WASM).

Enter zeroperl

So, WebAssembly. How does that work with Perl?

Back in 2025 Andrew Sampson debuted zeroperl via a blog post. It was a port of Perl to WebAssembly.

So maybe that could be adapted to support Perl with services such as Cloudflare Workers?

Long story short, that's what I have attempted to do.

I have made some modifications to the original zeroperl to add PAGI support and added a harness which lets it run as a Cloudflare Worker.

The resulting Worker loads a persistent Perl interpreter compiled to WASM, then bridges Cloudflare's JavaScript request/event model into Perl. HTTP requests are presented to Perl as PAGI $scope, $receive and $send interfaces, which means existing PAGI applications can run with relatively little or no modification.

The same bridge also supports asynchronous PAGI features such as WebSockets.

Demos

Demo, you say?

Firstly, before you look at them, let's get the AI bit out of the way. WebDyne is human written, with a few AI bug fixes. The demo apps below are about half and half — I'm pretty crap at UI design, so the Perl code is mostly human but they are skinned by AI.

With that out of the way, some demos:

Firstly, a vanilla PAGI app, a basic "Hello World" example that dynamically returns the Cloudflare Worker server time. The GitHub repo contains the source.

If you just want to see the basics and how to get started very simply with a WebDyne::PAGI app, have a look at Perl Fortune. The GitHub repo gives simple instructions on how to build, test and deploy it.

A more fully fledged demo showcases WebSocket support: terminal-based emulation allowing you to play the Scott Adams text adventures through a browser. Play it here, with the GitHub repo here.

A mock Wine Cellar demo talks to Cloudflare D1 and also uses KV and R2 object storage. The GitHub repo is here.

More info and limitations

I've attempted to make the instructions as clear as possible, but feedback and bug reports are welcome.

The demos attempt to showcase some of the features of WebDyne, including support for htmx, so that there is minimal JavaScript — HTML is swapped in and out rather than built via JavaScript — and the ability for Perl calls to return data as embedded JSON, which can then be read by JavaScript charting libraries etc.

There are limitations.

Pure-Perl CPAN modules are relatively straightforward to bundle; XS modules generally need to be compiled specifically for WASM or replaced with Pure-Perl equivalents. This isn't intended to make every existing Perl application magically run unchanged on Workers.

I've packaged the build/runtime tooling as @webdyne/webdyne-zeroperl on npm, with some sister packages for Cloudflare such as @webdyne/webdyne-cloudflare.

The idea is that an application repository contains the Perl application and its dependencies, while the packages handle building the WASM bundle and the Cloudflare/Wrangler integration.

Cloudflare does offer a free tier that supports Workers, but the limitations on size and startup time make it impractical to fit the current zeroperl/WebDyne bundle within the free-tier limits.

What about just running Perl in the browser?

And one more, not entirely serious, demonstration.

If we've gone to the trouble of compiling Perl and WebDyne to WASM, there's no particular reason the WASM has to execute inside a Cloudflare Worker. A browser can instantiate it too.

Might as well cut out the middle man and just download zeroperl to the browser and run the WASM right on the user's machine to serve HTML, right?

So, if you are prepared to download 4+ MB of WASM, you can run a WebDyne app directly from this GitHub Pages demo. The GitHub repo is here.

I don't see a lot of demand for doing it — but hey, soon 4 MB might count as a small download.

Links

Some more links:

The videos of the German Perl Workshop 2026 are online

2026-09-06T18:21:02Z

The videos are now online on Youtube.

Thanks again to all people presenting their projects and insights!

Much of the credit for the video production goes to Lee Johnson for recording
all of them during the event. The postproduction happened thanks to ffmpeg.

AmberDB - An Embedded NoSQL Database Engine for Perl

2026-09-01T03:53:48Z

AmberDB is an embedded, schema-driven NoSQL database engine for Perl, designed for applications that need structured records, fast indexed queries, full-text search, transactions, and a simple deployment model.

It is built on top of Berkeley DB through DB_File, but AmberDB provides a much higher-level database API rather than exposing the underlying key-value store directly.

Why AmberDB?

AmberDB brings several capabilities together in a single Perl database engine:

a simple Perl-native CRUD API
schemaless and schema-driven data structures
indexed matching and filtering
full-text search
sorting and faceted queries
relational and repeated data blocks
multi-table transactions
concurrency control
high-throughput batch operations
portable database archives and restore tools

The result is a database where operations that often require additional layers, services, or complex query logic can be handled directly by the database itself.

For example, a Perl application can insert, read, modify, search, and delete records using a small and consistent API, while the schema controls validation and indexing behind the scenes.

AmberDB is built around a straightforward principle:

The database should make common application data operations simple, fast, and predictable.

A database operation can be this simple

After creating an AmberDB instance, inserting a record is straightforward:

use AmberDB;



my $db = AmberDB->new(
    cfg  => { user => 'admin', language => 'en' },
    path => { dbase_dir => './dbstore' }
);

my @product = (
    0,
    "Wireless Headphones",
    149.99,
    "Electronics",
    1
);

my $id = $db->insert_id(
    "products",   # table
    @product      # record
);

Reading the record back:

my @product = $db->read_id("products", $id);

Modify it:

$product[2] = 129.99;

$db->modify_id(
    "products",
    @product
);

And delete it:

$db->delete_id("products", $id);

That's the basic CRUD API.

There is no SQL query to construct, no ORM required, and no separate query language between the Perl application and the database.

For many applications, database access can therefore look very similar to ordinary Perl data manipulation.

Using schemas for advanced applications

AmberDB works even without a schema definition. However, schemas can significantly increase the engine's capabilities by defining the structure of a table and how its data should be indexed and searched.

There is no separate indexing system to configure. Once the schema is defined, AmberDB automatically builds and maintains the required indexes.

For example:

{
    name         => "Table Name",
    record_index => 1,              # readall
    search_block => [2,4,5,8],      # blocks to search
    match_block  => [1,3,8],        # blocks to match
    sort_block   => [1,3,5,7,10],   # blocks to sort
}

AmberDB automatically creates inverted indexes for the blocks defined by the table schema. These indexes provide very fast search and filtering operations, even with large datasets.

Indexed reads instead of scanning records

AmberDB is designed to perform much of the work when data is inserted or indexes are rebuilt, rather than repeatedly doing expensive work during queries.

This makes operations such as filtering, sorting, pagination, and searching large datasets possible without requiring an external search server.

For example:

my ($total, @products) = $db->search_table(
    "products",
    "wireless headphones",
    start => 0,
    limit => 20
);

The same database can therefore provide both ordinary record access and full-text search.

AmberDB does not join

A record can contain or be linked to relational data from other tables. For example, an order record might contain customer information, payment information, shipping and delivery information, various dates, and a collection of order items containing the product number, name, price at the time of sale, applied discount, and other information.

AmberDB processes these structures as part of the record model and uses custom indexes to make them easy to query.

This can be useful when the application's natural model is something like:

Order

 ├── Customer
 ├── Address
 ├── Dates [ as array ]
 ├── Payment
 └── Items
      ├── Product
      ├── Quantity
      └── Price

Instead of reconstructing the object from multiple tables through joins, the application can work with the structure directly, in a way that is much closer to Perl's own data model.

ACID Transactions

Although AmberDB is a performance-oriented NoSQL engine, it provides multi-table ACID transactions using an undo journal and Strict Two-Phase Locking (Strict 2PL).

AmberDB also supports concurrent access using OS-level file locking, making it suitable for multi-process Perl applications.

The transact API is simple to use, while the mechanisms behind it provide atomicity, consistency, isolation, and durability across related operations.

$db->transact_start();

# update order
# update customer account
# update stock
# insert payment record

$db->transact_end();

If an error occurs, the transaction can be rolled back, including the corresponding index changes.

The undo journal also provides recovery after an unexpected process or system failure.

Batch operations for large imports

Transactional record operations and bulk data loading are intentionally treated as different workloads.

For ETL, CSV imports, migrations, and large datasets, AmberDB provides batch methods such as:

$db->insert_list("products", @records);
$db->modify_list("products", @records);
$db->delete_list("products", @ids);

For example, when you insert a list of a thousand records using insert_list, AmberDB creates the records and their indexes as a batch operation.

Similarly, a large price list can be modified in a single batch operation.

This makes batch methods particularly useful for imports, migrations, synchronization jobs, and other high-volume data operations.

Portable backups

AmberDB also includes native database tools for backup and restore.

A database can be exported to a portable .amberdb archive containing the authoritative database state and schema. Integrity can be verified using SHA-256, and derived indexes can be rebuilt during restore.

This makes it possible to move or archive a complete database without requiring a separate database server.

Getting started

AmberDB 5.22.0 is available on CPAN:

cpanm AmberDB

The project is released under the Artistic License 2.0.

The source code, documentation, and examples are available on MetaCPAN and GitHub.

If you are a Perl developer working with a significant amount of structured data, give AmberDB a try.

pperl: Doing a REJIT

2026-08-29T16:33:39Z

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.

]]> The promise, and the scoreboard so far

The promise stands as written: every Game benchmark, against the best scripted entry, with a general-purpose JIT rather than one tailored to benchmark code. Several rows already go to the current build; publishing the numbers before the release they belong to would repeat the mistake of printing tables that age in our favour, so they wait. What does not wait is the row that dictated new machinery.

regex-redux: outgunned at home

regex-redux is the Game's regular-expression benchmark: nine alternation patterns counted over a DNA sequence with //g, five IUB-code substitutions with s///g, essentially all of it inside the regex engine. Regular expressions are the domain Perl defined; this should be a home game.

It is not. pperl runs the workload through its regex engine - the Rust reimplementation of perl5's backtracker - at perl5 parity: roughly nine billion instructions on our measurement input, for pperl and perl5 alike. node retires 1.33 billion on the same input. That is a factor of seven, in instruction count, before anyone talks about clock speed.

The reason node is there is Irregexp, V8's regex compiler. It is a backtracker, like perl's engine - leftmost-greedy, capture semantics and all - but it does not interpret a pattern, it compiles the pattern to native code: character classes become mask-and-compare instructions, backtracking becomes a pop and an indirect jump, and each subject encoding gets its own code object. Against that, an interpreter dispatching per character through a switch is structurally behind, however tight the switch.

And this is the point where the existing JIT cannot help. The pperl JIT compiles Perl ops; on this row over 99% of the instructions retire inside a single op, the match itself. An engine gap cannot be closed from the op side. Hence the second compiler.

ReJIT

ReJIT compiles regular expressions to machine code, and the design decision worth explaining is what it compiles. There are three architectures in the field. Irregexp compiles its own pattern graph. RE2-class engines (rust-regex, V8's linear mode) run guaranteed-linear automata over a restricted semantics. PCRE2's JIT does neither: it compiles the interpreter's own compiled-pattern bytecode, arm by arm, and falls back to the interpreter for whatever it declines.

ReJIT takes the PCRE2 shape. perl's regex compiler already does the hard front-end work - parsing, optimization, trie construction with Aho-Corasick start classes, anchoring and substring analysis - and its output, the regnode program, is the specification of what a match must do. ReJIT compiles that program to native code through the same Cranelift backend the op JIT uses, and splices in behind the engine's public boundary: patterns it admits get compiled code, patterns it declines keep the stock engine, permanently and at zero per-match cost. Compiling the engine's own program rather than reinventing a pattern representation is what makes fidelity a construction property instead of a test-suite aspiration.

Irregexp still gets mined - for mechanics, not architecture: the heap-grown backtrack stack of code addresses, captures as a register array saved and restored through that stack, one compiled body per subject encoding, compilation deferred until a pattern is demonstrably hot.

What we will not ship is an RE2-style linear engine, for two reasons. First, perl already ships the tier such an engine would occupy: the substring and start-class presearch machinery in front of the matcher is a prefilter, and duplicating it buys nothing. Second, a breadth-first engine cannot express the backtracking-order phenotype - which branch wins, what $1 holds under alternation, what (*SKIP) and its relatives do - and in Perl that phenotype is observable behaviour, not an implementation detail.

Where the instructions go

We took a census of the row before designing the tier. 83% of the instructions are the count loop, 16% the substitutions, 1% everything else. The interesting split is inside the count loop.

perl's optimizer builds its trie - and the Aho-Corasick scan that makes trie'd alternations fast - only when every branch of the alternation starts with a literal. Five of the nine count patterns qualify and run comparatively fast. The other four start a branch with a character class ([cgt]gggtaaa|tttaccc[acg] and friends), get no trie and no start class, and are scanned branch by branch from every position. Those four cost 64% of the count phase - about 55% of the entire benchmark.

So the single biggest target is exactly the shape perl's optimizer refuses to optimize: a class-headed alternation, compiled into a machine-code scan loop. The trie'd scan is the second target, at roughly a quarter of the row. All fifteen patterns of the benchmark sit inside the first compiled subset - no captures, no lookaround, no backreferences anywhere in the row.

Captures are in that first subset anyway. In our 1,844-file test corpus, $1-style extraction outnumbers backreferences 268 to 14; a captureless tier would compile the counting workloads and decline nearly every extracting one, which is the majority real-world shape of =~.

Semantics are not negotiable

The house rules from the previous post apply unchanged: every gap is fixed as a general construct or not at all, and the semantics are perl's, byte for byte.

One example of why compiled-regex prior art cannot simply be copied. In /(?:(a)|(b))+/ matched against "ab", perl leaves $1 holding "a" - a quantified group retains the last successful value of its inner captures across iterations. ECMAScript clears them at each iteration entry, so JavaScript reports capture 1 undefined, and Irregexp implements exactly that. Copying its register-clearing verbatim would be a wrong-match bug by construction. The engines agree on almost everything; the tier is built for the places they do not.

The enforcement is mechanical, not stylistic. In test mode every compiled match is re-run through the stock engine and compared - not the verdict alone, but the full capture state, since a divergence there stays invisible until $' or @- is read much later. perl's own regression corpus runs under that differential mode, including the 2,210-case table it maintains for the engine and the variants of it that force the trie optimization off and on. And the perl-specific machinery that does not compile - (?{...}) code blocks, pattern recursion, locale-dependent folding - is declined at admission and stays on the stock engine, which remains the universal fallback.

Staging

ReJIT lands in stages: the instrumentation and the differential oracle first, then the scan-loop tier described above, then quantifier depth, then the utf8 axis. For the scan-loop tier alone our prediction on the regex-redux row is a 3-5x reduction in instruction count - printed here so the release post can be checked against it.

As always: no dates. This is to update status: the promise from the previous post now has its missing weapon under construction.

Richard C. Jelinek, PetaMem s.r.o.

Announcing the London Perl & Raku Workshop 2026

2026-08-28T14:01:55Z

The London Perl & Raku Workshop is back again this year!

https://act.yapc.eu/lpw2026

WHEN: Saturday 21 November 2026
WHERE: The Café at Zoopla, The Cooperage, 5 Copper Row, London SE1 2LH

Registrations and talk submissions are now open. As on previous years, we welcome talks for anything and everything people think might interest the Perl and Raku communities, even if it's not specifically about those languages.

We have a large room for the main track, and a breakout room for ~15 people that is available for smaller sessions, BOFs, hackathons, etc. Submissions for use of that room is also open.

We would like to encourage people to register in advance, to make it easier to access the venue and to give us an idea of numbers.

Looking forward to seeing you all, and the crazy things you've come up with.

CPerl mode for Emacs is now on GNU ELPA

2026-08-27T02:58:11Z

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.

Happy hacking!

-- haj, your friendly CPerl mode maintainer

PerlOnJava 5.44.1 released

2026-08-25T15:46:24Z

I released PerlOnJava 5.44.1 yesterday:

https://github.com/fglock/PerlOnJava/releases/tag/v5.44.1

This is a big milestone, with the regex implementation, ithreads, taint mode, and async/await now complete.

ANNOUNCE: Perl.Wiki V1.53, Mojo.Wiki V1.24

2026-08-25T11:29:04Z

As usual, get them and cpan.metacurator.tree.html from my
Wiki Haven.

Is Perlmonks Dead?

2026-08-23T18:30:57Z

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.

WebDyne 3.0 released -- now with PAGI, Server-Sent Events and WebSockets

2026-08-22T06:47:43Z

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:

cpanm Task::WebDyne::PAGI
webdyne.pagi --test

or serve a directory of .psp files:

webdyne.pagi /var/www/html

PAGI support is also built into the WebDyne Docker images.

If unfamiliar with WebDyne, it’s (yet another) Perl dynamic HTML engine that’s been around in various forms for quite a while. It lets you embed Perl in HTML/PSP documents, with compiled-page caching, reusable template blocks and separation of Perl code into modules when applications grow beyond simple pages.

3.0 continues to support PSGI/Plack/Starman and Apache/mod_perl, so PAGI is an additional runtime rather than a replacement for the existing ones.

PAGI gives Perl/WebDyne a clean route into applications that need live server → browser updates or persistent bidirectional connections, without having to bolt a separate WebSocket/SSE service onto the application.

Documentation and examples:

https://webdyne.org/

See the "Advanced Usage" section for examples of SSE or WebSockets code.

Source:

https://github.com/aspeer/WebDyne

Feedback, bug reports and especially experiments with the PAGI/SSE/WebSocket support are welcome.

PAGI 0.002002: Clarifying How Applications Are Loaded

2026-08-21T22:25:58Z

Introduction

(crossposted from dev.to)

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:

async sub app {
    my ($scope, $receive, $send) = @_;

    await $send->({
        type    => 'http.response.start',
        status  => 200,
        headers => [[ 'content-type', 'text/plain; charset=utf-8' ]],
    });

    await $send->({
        type => 'http.response.body',
        body => 'Hello from PAGI!',
        more => 0,
    });
}

What the release clarifies is how a general-purpose runner may reach that runtime boundary.

The gap between Python callables and Perl objects

PAGI's scope, receive, and send runtime shape was inspired by ASGI. ASGI describes an application as an asynchronous callable receiving those three values. In Python, that callable may be a function or an instantiated object implementing __call__; the distinction disappears at the call site.

Perl does not normally treat a blessed object as a code reference. We could approximate Python with callable-object overloading, but making overload magic part of the gateway contract would obscure a useful boundary. PSGI and Plack already give Perl a more familiar convention: use objects while configuring an application, then produce a code reference for runtime dispatch.

PAGI 0.002002 now makes that convention explicit. A general-purpose application runner should accept either:

a native PAGI code reference; or
an already-instantiated object providing to_app.

For example, an application component may retain configuration while it is being constructed:

package MyApp;

use Future::AsyncAwait;

sub new {
    my ($class, %args) = @_;
    return bless { greeting => $args{greeting} // 'Hello' }, $class;
}

sub to_app {
    my ($self) = @_;

    return async sub {
        my ($scope, $receive, $send) = @_;

        await $send->({
            type    => 'http.response.start',
            status  => 200,
            headers => [[ 'content-type', 'text/plain; charset=utf-8' ]],
        });

        await $send->({
            type => 'http.response.body',
            body => $self->{greeting},
            more => 0,
        });
    };
}

# app.pl
package main;

MyApp->new(greeting => 'Hello from an application provider');

A runner adopting this convention calls to_app exactly once for that loaded instance, verifies that it returned a code reference, and uses only that code reference for connection dispatch. It does not call to_app for every request.

This matters for more than performance. Route compilation, middleware construction, and application setup happen at a predictable boundary. A broken provider fails while the application is loading rather than after the server begins accepting traffic. The server, middleware, and application still communicate through one uniform runtime interface.

Deliberately not magical

The provider must be an instantiated object. Neither of these is an application provider under the new convention:

'MyApp'          # A package-name string
MyApp->to_app    # Class-method normalization

A command-line runner may accept a module name as part of its own discovery interface, but it must construct the object--or otherwise obtain a native application code reference--before PAGI provider normalization begins. This keeps module loading, constructor arguments, and plugin policy out of the gateway protocol.

Blessed code references remain code references and are dispatched directly. Their code-reference nature takes precedence over a to_app method.

Application lifecycle is also unchanged. Startup and shutdown belong to the PAGI lifespan protocol. Methods on a provider object do not silently become lifecycle hooks.

A clearer server boundary

The accompanying server integration specification no longer requires every conforming server class to implement a particular new(app => ...) constructor and run method. A server might be a class, function, embedded service, or external process. Conformance is about how it invokes the normalized application and exchanges PAGI events, not the shape of its configuration API.

This separates three responsibilities that had previously been too easy to conflate:

Deployment tooling discovers and constructs an application.
A provider object is normalized once through to_app.
The server dispatches only the resulting PAGI code reference.

The next step is to bring the reference PAGI runner into line with this clarification. This release defines the portable boundary first; it does not claim that every existing runner already accepts provider objects.

One more clarification: what `$send` completion means

PAGI 0.002002 also gathers the $send Future contract into one place. Applications should continue to await every send:

await $send->({
    type => 'http.response.body',
    body => $chunk,
    more => 1,
});

Successful resolution means the server has validated and consumed the event, finished with any application-owned resource tied to it, and accepted the output into its outbound processing path. It does not mean the client has received the bytes. A server may keep the Future pending to apply backpressure, so awaiting $send is how an application self-paces without blocking the Perl thread.

Versioning

The distribution version is 0.002002. The core PAGI specification advances to draft 0.4, while the server integration specification is draft 0.2. WWW and Lifespan remain at draft 0.3. Core and protocol specifications now explicitly evolve independently; an omitted protocol spec_version uses that protocol's documented compatibility default rather than borrowing the core version.

The result is a small but important cleanup: PAGI keeps one minimal runtime protocol while giving Perl applications a conventional, explicit way to carry configuration and structure up to the point where runtime dispatch begins.

The complete change is available in PAGI pull request #60.

]]> Introduction

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:

```perl async sub app { my ($scope, $receive, $send) = @_;

await $send->({
    type    => 'http.response.start',
    status  => 200,
    headers => [[ 'content-type', 'text/plain; charset=utf-8' ]],
});

await $send->({
    type => 'http.response.body',
    body => 'Hello from PAGI!',
    more => 0,
});

} ```

What the release clarifies is how a general-purpose runner may reach that runtime boundary.

The gap between Python callables and Perl objects

PAGI 0.002002 now makes that convention explicit. A general-purpose application runner should accept either:

a native PAGI code reference; or
an already-instantiated object providing to_app.

For example, an application component may retain configuration while it is being constructed:

```perl package MyApp;

use Future::AsyncAwait;

sub new { my ($class, %args) = @_; return bless { greeting => $args{greeting} // 'Hello' }, $class; }

sub toapp { my ($self) = @;

return async sub {
    my ($scope, $receive, $send) = @_;

    await $send->({
        type    => 'http.response.start',
        status  => 200,
        headers => [[ 'content-type', 'text/plain; charset=utf-8' ]],
    });

    await $send->({
        type => 'http.response.body',
        body => $self->{greeting},
        more => 0,
    });
};

}

app.pl

package main;

MyApp->new(greeting => 'Hello from an application provider'); ```

Deliberately not magical

The provider must be an instantiated object. Neither of these is an application provider under the new convention:

perl 'MyApp' # A package-name string MyApp->to_app # Class-method normalization

Blessed code references remain code references and are dispatched directly. Their code-reference nature takes precedence over a to_app method.

Application lifecycle is also unchanged. Startup and shutdown belong to the PAGI lifespan protocol. Methods on a provider object do not silently become lifecycle hooks.

A clearer server boundary

This separates three responsibilities that had previously been too easy to conflate:

Deployment tooling discovers and constructs an application.
A provider object is normalized once through to_app.
The server dispatches only the resulting PAGI code reference.

One more clarification: what `$send` completion means

PAGI 0.002002 also gathers the $send Future contract into one place. Applications should continue to await every send:

perl await $send->({ type => 'http.response.body', body => $chunk, more => 1, });

Versioning

The complete change is available in PAGI pull request #60.

German Perl/Raku Workshop 2027 in Hanover - 14.04.2027-16.04.2027

2026-08-18T22:19:53Z

(English version below)

Hallo zusammen,

wir laden Euch herzlich ein
zum Deutschen Perl/Raku Workshop 2027.

Der Workshop findet nächstes Jahr vom Mittwoch 14. April bis
Freitag 16. April im Stadteilzentrum Nordstadt in Hannover statt.

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.

]]> Hello everyone,

We cordially invite you
to the German Perl/Raku Workshop 2027.

The workshop will take place next year from Wednesday, April 14, through
Friday, April 16, at the Stadteilzentrum Nordstadt in Hanover.

The website and the call for papers are already online at
https://act.yapc.eu/gpw2027/cfp.html. We look forward to many interesting
presentations!

We're always happy to receive support from sponsors. If you or your
company would like to support the workshop, please feel free to contact us. Together, we're
sure to find a way to make it happen!

If you have any questions for the organizers, the best way to reach us is
directly at orga2027@german-perl-workshop.de.

We look forward to your participation,
Max Maischein on behalf of the organizers and Frankfurt.pm

We're still working on
hotel recommendations and will post them on the website.

Translated with DeepL.com (free version)

Pacman in Perl/Tk

2026-08-13T02:27:34Z

Revisiting a Pac-Man Implementation in Perl/Tk

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:

The basic idea: the game world is a grid

At the heart of the implementation is a two-dimensional array.

The Pac-Man maze is not primarily a collection of graphical objects. Instead, every position in the maze is represented by one cell in a table-like data structure.

Conceptually, it looks something like this:

1 1 1 1 1 1 1
1 o o o o o 1
1 o 1 1 1 o 1
1 o 0 0 0 o 1
1 1 1 1 1 1 1

Each value describes the logical state of one tile.

For example:

1 = wall
0 = free space
o = pill
O = power pill
W = warp point

The visual maze that appears on screen is generated from this data structure.

That distinction is important: the Canvas is not the game world. It is a visual representation of the game world.

Pac-Man does not really move in pixels

Pac-Man's position is represented by two integer values:

row
column

The same principle applies to the ghosts.

So from the game's point of view, Pac-Man may be located at:

row = 17
column = 17

There is no requirement for the actual game logic to know that his center might currently be at pixel position 350/350 on the screen.

The pixel position can simply be calculated from the tile position.

In this implementation, a tile is 20 by 20 pixels. Rendering therefore essentially follows the rule:

x = column * 20
y = row * 20

with a small offset added to place the image in the center of the tile.

This creates a useful separation between two different things:

Logical game state
        |
        v
row / column
        |
        v
Rendering
        |
        v
pixel x / pixel y

I planned to make the movement look smoother later.

Movement is a transition between tiles

This also means that movement is discrete.

If Pac-Man is standing on tile:

[17,17]

and moves to the right, the game calculates:

[17,17] -> [17,18]

Before that transition is accepted, the target tile is inspected.

If the target contains a wall, Pac-Man cannot move there.

If it is accessible, his logical row and column are updated.

The basic process is therefore roughly:

Player input
    |
    v
Determine intended direction
    |
    v
Calculate neighbouring tile
    |
    v
Check whether the tile is accessible
    |
    v
Update logical position
    |
    v
Handle events
    |
    v
Update visualization

There is no physics engine involved, no collision rectangle moving continuously through the maze and no need to determine whether two polygons intersect.

For this kind of game, the grid already contains most of the information required by the game logic.

Smooth movement can still be just an animation

The early version simply made Pac-Man jump visually from one tile to the next.

That obviously works, but it does not look particularly elegant.

I also found versions with smoother movement animations, but I still didn't get them to work that properly.

Conceptually, it was designed like this:

Logical state:

[17,17] -> [17,18]



Visual transition:

350 -> 354 -> 358 -> 362 -> 366 -> 370

This does not necessarily require changing the logical model.

The game can still reason about tiles, while the user interface interpolates between their pixel positions.

In other words, smooth movement can be a presentation concern rather than a game-logic concern.

The tiles contain game state as well

...which might not be the best thing. But hey. We all started once.

A pill is not necessarily an independent object with its own coordinates.

Instead, the board itself can say:

board[row][column] = "o"

When Pac-Man enters that tile, the game detects the pill, increases the score and changes the tile to free space:

o -> 0

The maze therefore acts as both a description of the level geometry and a container for parts of the current game state.

This makes interactions rather straightforward.

Entering a tile can trigger events depending on what that tile contains:

wall       -> movement rejected
pill       -> increase score, clear tile
power pill -> special behaviour
warp point -> change target position
free space -> nothing special

Collisions become very simple

The same model simplifies collisions with ghosts.

Pac-Man and a ghost collide if they occupy the same logical tile:

pacman.row == ghost.row
and
pacman.column == ghost.column

Again, no pixel-perfect collision detection used.

Warp tunnels are just special tile transitions

The warp tunnel fits naturally into the same concept.

A warp point is simply another special tile type:

When Pac-Man enters such a tile, the normal target position is replaced by a configured position on the other side of the board.

One detail turned out to be useful here: the exit position does not have to be the other warp tile itself.

Instead, Pac-Man can be placed on the first normal tile immediately inside the maze.

For example:

[W] [ ] [ ] ... [ ] [W]
     ^               ^
     |               |
   exit            entrance

Entering the warp on the right while moving to the right places Pac-Man just inside the left side of the maze.

His movement direction remains unchanged.

So logically:

move right
    |
    v
enter right warp
    |
    v
appear on left side
    |
    v
continue moving right

The same principle works for vertical warp tunnels.

A warp changes the position. It does not have to change the movement direction.

The maze can also be viewed as a graph

There is another way of looking at this data structure which I find interesting today.

Although the board is stored as a two-dimensional grid, the accessible part of the maze can effectively be interpreted as a graph.

Every accessible tile is a node.

Possible movements to neighbouring tiles are edges.

A corridor therefore looks roughly like this:

[o] -- [o] -- [o] -- [o]

while an intersection might look like this:

        [ ]
         |
[ ] -- [ ] -- [ ]
         |
        [ ]

The old implementation already models ghosts using row and column coordinates just like Pac-Man, although the ghost movement itself was still largely unfinished in the version I rediscovered.

Model first, visualization second

Looking at the code today, AI would describe its central idea as:

GAME MODEL

It is obviously not a formal Model-View architecture, and I certainly did not sit down in 2013 thinking, "I am going to create an elegant architectural separation here."

But the basic separation is there.

The authoritative state of the game is not the Canvas.

It is the data behind it.

pperl 0.6.12+ - "Shall we play a game?"

2026-08-11T03:41:21Z

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.

]]> The epigraph, answered

Perl release announcements traditionally open with an epigraph, a short quotation the release manager chooses. For 5.44.0, Leon Timmermans chose Frank Herbert's Dune:

Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.

It is a nice touch with all these thinking machines around these days. Given pperl currently tracks 5.44, we think our epigraph should remain within the same universe:

"We have just folded space from Ix... Many machines on Ix... new machines. Better than those on Richesse."

Velocity, in perldelta units

Every perl release closes its perldelta with the same paragraph of statistics. For 5.44.0 it reads:

Perl 5.44.0 represents approximately 12 months of development since Perl 5.42.0 and contains approximately 270,000 lines of changes across 1,300 files from 71 authors.

Excluding auto-generated files, documentation and release tools, there were approximately 110,000 lines of changes to 860 .pm, .t, .c and .h files.

The same yardstick, applied to pperl per release sprint. Counting is the tree diff between the two release commits, over half-open ranges, so consecutive sprints neither overlap nor leave a gap. The code columns apply the same exclusions as perl's second sentence - no auto-generated files, no documentation, no assets, no vendored modules, no tooling; .rs, .pl, .pm and .t files only:

sprint	days	commits	lines	files	code lines	code files
0.5.0 .. 0.6.0	106	403	8,756,000	43,000	254,000	770
0.6.0 .. 0.6.8	16	153	1,389,000	20,000	270,000	595
0.6.8 .. 0.6.xx	13	294	1,889,000	27,000	105,000	475

Held against the quote above: the 16 days between 0.6.0 and 0.6.8 contain about as many lines of code change - 270,000 - as perl 5.44.0 reports for twelve months of changes of every kind, and the 13 days since 0.6.8 roughly match perl's full-year code figure. That is what "high-velocity development" means here: currently, about one perl-year of code change every two weeks. Greenfield churn is not mature-project maintenance, and we are not 71 authors - of course.

Two footnotes: the gross figures are mostly documentation, since the manual ships in English and 41 translated locales; and all of it lands under a harness - some 1,800 test files comparing pperl's output against perl 5.44 byte for byte, over a runtime of roughly 800,000 lines of Rust.

The Benchmarks Game

The Computer Language Benchmarks Game is the longest-running cross-language benchmark in public view: fixed problems, published source, any language, strict rules about keeping the same algorithm. Perl's standing there is not a secret. On nbody, the site lists C at about 2.1 s, node.js at about 8.6 s, and the fastest Perl entry at about seven minutes - 215x behind C.

The film our title borrows from concluded that the only winning move is not to play, and that has largely been Perl's relationship with the Game: the entries are old, the rankings are what they are, and the results get cited mainly by people arguing against Perl. With a JIT in the runtime, not playing stopped being the rational move. So we play - under house rules that keep the game from turning into solitaire:

Any entry we measure is Perl that implements the same algorithm as the published one, runs on perl5 too, and produces byte-identical output on both runtimes, at every input size.
The JIT is not shaped around the Game's programs, nor the programs around the JIT: every gap a program exposes is fixed as a general construct, or not at all.

The threads obstacle. The Game allows hand-threaded entries, and the strong Perl entries use ithreads - mandelbrot, the program this post reports, included. pperl is deliberately non-threaded; its parallelism is Rayon inside the runtime, not a thread API in the language, so the published entry cannot run on it at all. The rules permit different code as long as the algorithm is the same, and they do not require a parallel program either - some published entries are serial. We stay inside those lines: our rewrite keeps the kernel byte-identical and replaces the thread pool with a plain loop over scanlines, output pixel-identical. The eventual pperl entry will be more idiomatic, plainer Perl than today's highly optimized one - that is the point of a runtime that does the optimizing. On perl5 both versions run, which keeps the bracket visible - four threads for the published entry, one for the rewrite may be enough, more are an option.

The result, in ballpark. Identical algorithm, single-threaded, the JIT runs mandelbrot around 36x faster than perl5 - with --no-jit at perl5 parity as the control, so the win is the compiler, not baseline games. One pperl core beats the published entry's four threads in wall clock, and by an order of magnitude in CPU time - and the parallelizer contributes nothing here yet, so that is one core with more still on the table. The reading that matters most: the nearest runtime still ahead of us on this kernel is node.js, within a factor of 1.5 - the competition has moved from perl5 to V8.

And that is the promised explanation for the missing release. Playing the Game reset the goal: the reference for a JIT-equipped pperl is no longer perl5, it is the fastest scripted language of the day - which, more often than not, means node.js and its V8. Competing there takes more than closing gaps one by one, so we have started the pperl JIT architecture from scratch - again. Releases resume when the rebuild lands.

One more design decision belongs in that explanation. Benchmarks may or may not translate to real-world programs, so the new JIT is designed around real-world programs - the desired Game performance has to arrive as a side effect of accelerating those.

And that is the promise: the next pperl release will smash every interpreted language in the Game, and compete in every single benchmark with the best scripted language there. It will do so not with a specialized JIT tailored to this benchmark code, but with a general-purpose JIT that also happens to smash this game.

As always: no dates. On the other hand you can now quantify the velocity.

Richard C. Jelinek, PetaMem s.r.o.