This post about y.2k38 got me wondering about how Perl will handle the date. From what I can tell localtime() and gmtime() appear to support dates past 2038. What else should we check?
My Date::Parse::Modern module supports parsing dates past 2038. I specifically wrote unit tests for WAY in the past and future.
[link] [comments]
I have the following program with JSON:
use strict;
use warnings;
use Data::Dumper qw( );
use JSON qw( );
my $json_text = '[
{
"sent": "2026-01-16T17:00:00Z",
"data": [
{
"headline": "text1",
"displayText": "text2"
},
{
"displayText": "text3"
},
{
"displayText": "text4"
}
]
},
{
"sent": "2026-01-16T17:00:00Z",
"data": [
{
"headline": "text5",
"displayText": "text6"
},
{
"displayText": "text7"
},
{
"displayText": "text8"
},
{
"headline": "text9",
"displayText": "text10"
}
]
}
]';
my $json = JSON->new;
my $data = $json->decode($json_text);
print Data::Dumper->Dump($data);
# This is pseudocode:
foreach ( $data->[] ) {
print "\$_ is $_";
}
I would like to walk through elements in JSON and find all sent and all displayText values. But, I do not know how to dereference first element. First element is array without any name in this case.
Thunderhorse framework was just released as beta. Read more about it on my blog: https://bbrtj.eu/blog/article/thunderhorse-beta-released

(I make no apologies for the ChatGPT images in my recent blog posts, by the way. No artists are missing out on being paid: I wasn’t going to hire an artist to illustrate these blog posts which will be read by like three people.)
A while back, I wrote MooseX::XSAccessor which you can add to Moose classes to inspect your attributes and try to replace the accessors with faster XS-based ones. Now I’ve done the same for constructors (new) and destructors (DESTROY) with MooseX::XSConstructor.
There are probably still bugs, but initial benchmarks look promising:
Rate Standard XS Standard 6392/s -- -43% XS 11228/s 76% --
They’re mostly just a matter of importing the modules and forgetting about them. If the modules detect that your class is too complex for the XS modules to handle, they’ll sit back and let the regular Moose code work its magic. Give them a try. Let me know if they break things. They usually won’t.
Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with a local development…
We are happy to announce that Geizhals Preisvergleich supports the German Perl Workshop 2026.
Geizhals Preisvergleich zählt zu den größten Produkt- und
Preisvergleichsplattformen im deutschsprachigen Raum.
Geizhals Preisvergleich zählt zu den größten Produkt- und
Preisvergleichsplattformen im deutschsprachigen Raum.
Unser Unternehmen bewährt sich seit mittlerweile 25 Jahren in einer hoch
kompetitiven, dynamischen Branche.
Unseren Erfolg führen wir auf eine kompromisslose Umsetzung unserer
Unternehmensphilosophie zurück: Transparenz, objektive und
User-orientierte Information sowie Qualität unseres Contents.
Geizhals Preisvergleich ist ein mit der Heise Medien Gruppe verbundenes
Unternehmen.
(I make no apologies for the ChatGPT images in my recent blog posts, by the way. No artists are missing out on being paid: I wasn’t going to hire an artist to illustrate these blog posts which will be read by like three people.)
A while back, I wrote MooseX::XSAccessor which you can add to Moose classes to inspect your attributes and try to replace the accessors with faster XS-based ones. Now I’ve done the same for constructors (new) and destructors (DESTROY) with MooseX::XSConstructor.
There are probably still bugs, but initial benchmarks look promising:
Rate Standard XS
Standard 6392/s -- -43%
XS 11228/s 76% --
They’re mostly just a matter of importing the modules and forgetting about them. If the modules detect that your class is too complex for the XS modules to handle, they’ll sit back and let the regular Moose code work its magic. Give them a try. Let me know if they break things. They usually won’t.
Rebuild embed.h last, in case other regen steps wanted to add more things to it Otherwise, it's possible that later steps add new macros that `embed.pl` would have wanted to add to its list of things to `#undef`, requiring a second run of `make regen`. By running embed.pl last, we ensure this happens in the right order the first time.
Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with Google Cloud Run.
Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with Google Cloud Run.
Why not just use Python?
Python has traditionally been the main coding language for ML and AI tools. One of the strengths of the MCP protocol is that the actual implementation details are independent of the development language. The reality is that not every project is coded in Python- and MCP allows you to use the latest AI approaches with other coding languages.
Perl? Is that even a language anymore?
The goal of this article is to provide a minimal viable basic working MCP server in Perl that can be run without any unneeded extra code or extensions.
The Perl MCP module is here:
What Is Perl?
Perl is a general-purpose, high-level programming and scripting language, primarily known for its powerful text manipulation capabilities. Originally created by Larry Wall in 1987 for easier report processing, it has evolved to be used for a wide range of tasks, including system administration, web development, and network programming.
The main site for Perl is :
The Perl Programming Language - www.perl.org
Installing Perl
The step by step instructions vary by platform- for a basic Debian system here are the steps:
sudo apt-get install perl cpanminus
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl$ perl --version
This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux-gnu-thread-multi
(with 60 registered patches, see perl -V for more detail)
Gemini CLI
If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:
npm install -g @google/gemini-cli
Testing the Gemini CLI Environment
Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:
gemini
Node Version Management
Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:
Perl MCP Documentation
The official MCP CPAN page provides samples and documentation for getting started:
Where do I start?
The strategy for starting MCP development is a incremental step by step approach.
First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.
Then, a minimal Hello World Style Perl MCP Server is built with HTTP transport. This server is validated with Gemini CLI in the local environment.
This setup validates the connection from Gemini CLI to the local process via MCP. The MCP client (Gemini CLI) and the MCP server both run in the same local environment.
Next- the basic MCP server is extended with Gemini CLI to add several new tools in standard code.
Setup the Basic Environment
At this point you should have a working Perl environment and a working Gemini CLI installation. The next step is to clone the GitHub samples repository with support scripts:
cd ~
git clone https://github.com/xbill9/gemini-cli-codeassist
Then run init.sh from the cloned directory.
The script will attempt to determine your shell environment and set the correct variables:
cd gemini-cli-codeassist
source init.sh
If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:
cd gemini-cli-codeassist
source set_env.sh
Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.
Hello World with HTTP Transport
One of the key features that the standard MCP libraries provide is abstracting various transport methods.
The high level MCP tool implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.
The simplest transport that the SDK supports is the stdio (stdio/stdout) transport — which connects a locally running process. Both the MCP client and MCP Server must be running in the same environment.
The connection over HTTP will look similar to this:
# Use HTTP transport
any '/mcp' => $server->to_action;
Perl Package Information
The Perl code depends on several standard libraries for MCP and logging:
requires 'Mojolicious::Lite';
requires 'MCP::Server';
requires 'JSON::MaybeXS';
requires 'WWW::Google::Cloud::Auth::ServiceAccount';
requires 'URI::Encode';
requires 'LWP::Protocol::https';
Installing and Running the Perl Code
Run the install make release target on the local system:
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl$ make
Installing dependencies...
--> Working on .
Configuring /home/xbill/gemini-cli-codeassist/mcp-https-perl ... OK
<== Installed dependencies for .. Finishing.
Running tests...
t/00_compile.t .. ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.00 usr 0.00 sys + 0.21 cusr 0.03 csys = 0.24 CPU)
Result: PASS
To test the code:
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl$ make test
Running tests...
t/00_compile.t .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.18 cusr 0.05 csys = 0.25 CPU)
Result: PASS
Gemini CLI settings.json
In this example — the Perl source code uses a Perl interpreter that can be called directly from Gemini CLI.
The default Gemini CLI settings.json has an entry for the source:
{
"mcpServers": {
"hello-https-perl": {
"url": "http://127.0.0.1:8080/mcp"
}
}
}
Validation with Gemini CLI
Finally- Gemini CLI is restarted and the MCP connection over HTTP to the Perl Code is validated, The full Gemini CLI Session will start:
> /mcp list
Configured MCP servers:
🟢 hello-https-perl - Ready (1 tool)
Tools:
- greet
> greet Camel!
✦ I will call the greet tool with the parameter "Camel!".
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? greet (hello-https-perl MCP Server) {"param":"Camel!"} ← │
│ │
│ MCP Server: hello-https-perl │
│ Tool: greet │
│ │
│ Allow execution of MCP tool "greet" from server "hello-https-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I will call the greet tool with the parameter "Camel!".
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ greet (hello-https-perl MCP Server) {"param":"Camel!"} │
│ │
│ Camel! │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Deploying to Cloud Run
After the HTTP version of the MCP server has been tested locally — it can be deployed remotely to Google Cloud Run.
First- switch to the directory with the HTTP MCP sample code:
cd ~/gemini-cli-codeassist/mcp-https-perl
Deploy the project to Google Cloud Run with the pre-built cloudbuild.yaml and Dockerfile:
cd ~/gemini-cli-codeassist/mcp-https-perl
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl$ make deploy
The Cloud Build will start:
> make deploy
✦ I will read the Makefile to understand the deploy target and any other relevant files like cloudbuild.yaml or Dockerfile.
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ ReadFile Makefile │
│ │
│ │
│ ✓ ReadFile cloudbuild.yaml │
│ │
│ │
│ ✓ ReadFile Dockerfile │
│ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I will execute make deploy to submit the build to Google Cloud Build and deploy it to Cloud Run.
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ⊶ Shell make deploy [current working directory /home/xbill/gemini-cli-codeassist/mcp-https-perl] (Submitti… (ctrl+f to focus) │
│ │
│ Step #0: d4d869c8f88d: Pulling fs layer │
│ Step #0: 8b22c905be5d: Pulling fs layer │
│ Step #0: 8b22c905be5d: Waiting │
│ Step #0: 7703c2863431: Verifying Checksum │
│ Step #0: 7703c2863431: Download complete │
│ Step #0: 8b22c905be5d: Verifying Checksum │
│ Step #0: 8b22c905be5d: Download complete │
│ Step #0: 7bbf972c6c2f: Verifying Checksum │
│ Step #0: 7bbf972c6c2f: Download complete │
│ Step #0: d4d869c8f88d: Verifying Checksum │
│ Step #0: d4d869c8f88d: Download complete │
│ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
It can take 15–30 minutes to complete the build.
The cloud build needs to pull in all Perl libraries in the build environment and generate the entire package from scratch.
When the build is complete- an endpoint will be returned:
│ Starting Step #2 │
│ Step #2: Already have image (with digest): gcr.io/cloud-builders/gcloud │
│ Step #2: Deploying container to Cloud Run service [mcp-https-perl] in project [comglitn] region [us-central1] │
│ Step #2: Deploying... │
│ Step #2: Setting IAM Policy............done │
│ Step #2: Creating │
│ Revision...................................................................................................................... │
│ ..............................................................................................done │
│ Step #2: Routing traffic.....done │
│ Step #2: Done. │
│ Step #2: Service [mcp-https-perl] revision [mcp-https-perl-00002-pw8] has been deployed and is serving 100 percent of traffic. │
│ Step #2: Service URL: https://mcp-https-perl-1056842563084.us-central1.run.app │
│ Finished Step #2 │
│ PUSH │
The service endpoint in this example is :
https://mcp-https-perl-1056842563084.us-central1.run.app
The actual endpoint will vary based on your project settings.
Review Service in Cloud Run
Navigate to the Google Cloud console and search for Cloud Run -
and then you can detailed information on the Cloud Run Service:
Cloud Logging
The remote server writes logs to stderr in standard JSON format. These logs are available from the deployed Cloud Run Service:
Validate HTTP connection
Once you have the Endpoint — you can attempt a connection- navigate to in your browser:
https://mcp-https-perl-1056842563084.us-central1.run.app
You will need to adjust the exact URL to match the URL returned from Cloud Build.
You will get an error- this connection is expecting a message in the MCP format:
Page Not Found
Gemini CLI settings.json.cloudrun
Replace the default Gemini CLI configuration file — settings.json with a pre-configured sample- settings.json.cloudrun to use the Cloud Run version of the connection:
{
"mcpServers": {
"hello-cloudrun-perl": {
"httpUrl": "https://mcp-https-perl-$PROJECT_NUMBER.us-central1.run.app/mcp"
}
}
}
Copy the Cloud Run version of the Gemini CLI configuration file:
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl$ cd .gemini
cp settings.json.cloudrun settings.json
xbill@penguin:~/gemini-cli-codeassist/mcp-https-perl/.gemini$
Validation with Gemini CLI
The final connection test uses Gemini CLI as a MCP client with the deployed Cloud Run Service in Perl providing the MCP server. Startup Gemini CLI with the updated settings :
gemini
> /mcp list
Configured MCP servers:
🟢 hello-cloudrun-perl - Ready (1 tool)
Tools:
- greet
> greet Swifties!
✦ I will call the greet tool to get a greeting for "Swifties!".
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? greet (hello-cloudrun-perl MCP Server) {"param":"Swifties!"} ← │
│ │
│ MCP Server: hello-cloudrun-perl │
│ Tool: greet │
│ │
│ Allow execution of MCP tool "greet" from server "hello-cloudrun-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ greet (hello-cloudrun-perl MCP Server) {"param":"Swifties!"} │
│ │
│ Swifties! │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ OK. I've greeted the Swifties
Summary
MCP development with Perl using Gemini CLI was validated with an incremental step by step approach.
A minimal streaming HTTP transport MCP Server was built from source code and validated with Gemini CLI running as a MCP client in the same local environment.
Then — the MCP server was wrapped in a container and submitted to Google Cloud Build for deployment to Google Cloud Run. The remote MCP server was validated with a standard browser, and Gemini CLI.
Finally- remote MCP operations were performed from the local Gemini CLI installation to the Perl MCP server hosted in Google Cloud Run.
This approach can be extended to more complex deployments and Cloud based options.
Just Paul and Aristotle this week.
We mostly discussed the experimental refaliasing and declared_refs features to see if we can find a path towards declaring at least the latter non-experimental. This would be useful in its own right, as well as an enabler for PPC0034 “Ref-aliased parameters in subroutine signatures”.
regexec.c: Change return 0 to NULL It is better practice to return a pointer when that's what the function is declared to return
Document (and export) [IU]_(BITS|DIG) Fixes #24083. Fixes #24084. In d957e95daa0143d60933d96d6cbfb69eee6d6269 I changed the definitions of IV_DIG and UV_DIG to depend on IV_BITS and UV_BITS respectively, creating the latter in perl.h. These had only visibility to the perl core. But I forgot that the _DIG forms were visible everywhere, so the _BITS forms needed to be as well. This commit merely documents all of them as public API (which should have been the case all along anyway), which automatically causes their visibility to be made everywhere.
I have long used Module::Runtime::use_module rather than Module::Load::load because the former has workarounds for various bugs in now-ancient versions of Perl which I needed to support.
I now no longer target Perl versions older than ~5.26, and would prefer switching to Module::Load, as it is part of core Perl.
Does Module::Runtime provide any benefit over Module::Load for recent versions of Perl?
(Module::Runtime::use_module rather handily returns the package name, but I can manage without that behavior.)
[link] [comments]
scan_num: Macroize common code This avoids repeating code snippets. It also changes things so adjacent underscores are all absorbed at once (and warned about). That means we no longer have to keep track of if the previous character was an underscore, so the variable that did that is removed. Only two checks need be done for running off either end of the buffer. The buffer is NUL-terminated, so if we see an underscore in the current position, the next position exists (there is a NUL there if nothing else); and the macro that looks behind one position is called in only one place where we haven't always parsed beyond the first character.
scan_num: Replace code by equivalent function call The previous commit has made this function, long in numeric.c, available to the rest of core. The code removed here duplicated what it does. Two variables are now unused, and are removed.

Dave writes:
During December, I fixed assorted bugs, and started work on another tranche of ExtUtils::ParseXS fixups, this time focussing on:
adding and rewording warning and error messages, and adding new tests for them;
improving test coverage: all XS keywords have tests now;
reorganising the test infrastructure: deleting obsolete test files, renaming the t/*.t files to a more consistent format; splitting a large test file; modernising tests;
refactoring and improving the length(str) pseudo-parameter implementation.
By the end of this report period, that work was about half finished; it is currently finished and being reviewed.
Summary:
* 10:25 GH #16197 re eval stack unwinding
* 1:39 GH #23903 BBC: bleadperl breaks ETHER/Package-Stash-XS-0.30.tar.gz
* 0:09 GH #23986 Perl_rpp_popfree_to(SV sp**) questionable design
* 3:02 fix Pod::Html stderr noise
* 27:47 improve Extutils::ParseXS
* 1:47 modernise perlxs.pod
Total: * 44:49 (HH::MM)

Tony writes:
``` [Hours] [Activity] 2025/12/01 Monday 0.23 memEQ cast discussion with khw 0.42 #23965 testing, review and comment 2.03 #23885 review, testing, comments 0.08 #23970 review and approve 0.13 #23971 review and approve
0.08 #23965 follow-up
2.97
2025/12/02 Tuesday 0.73 #23969 research and comment 0.30 #23974 review and approve 0.87 #23975 review and comment 0.38 #23975 review reply and approve 0.25 #23976 review, research and approve 0.43 #23977 review, research and approve
1.20 #23918 try to produce expected bug and succeed
4.16
2025/12/03 Wednesday 0.35 #23883 check updates and approve with comment 0.72 #23979 review, try to trigger the messages and approve 0.33 #23968 review, research and approve 0.25 #23961 review and comment 2.42 #23918 fix handling of context, testing, push to update,
comment on overload handling plans, start on it
4.07
2025/12/04 Thursday 2.05 #23980 review, comment and approve, fix group_end() decorator and make PR 23983 0.25 #23982 review, research and approve 1.30 #23918 test for skipping numeric overload, and fix, start
on force overload
3.60
2025/12/05 Friday
0.63 #23980 comment
0.63
2025/12/08 Monday 0.90 #23984 review and comment 0.13 #23988 review and comment 2.03 #23918 work on force overload implmentation
1.45 #23918 testing, docs
4.51
2025/12/09 Tuesday 0.32 github notifications 1.23 #23918 add more tests 0.30 #23992 review 0.47 #23993 research, testing and comment
0.58 #23993 review and comment
2.90
2025/12/10 Wednesday 0.72 #23992 review updates, testing and comment 1.22 #23782 review (and some #23885 discussion in irc) 1.35 look into Jim’s freebsd core dump, reproduce and find cause, email him and briefly comment in irc, more 23885
discussion and approve 23885
3.29
2025/12/11 Thursday 0.33 #23997 comment 1.08 #23995 research and comment 0.47 #23998 review and approve
1.15 #23918 cleanup
3.03
2025/11/15 Saturday 0.20 #23998 review updates and approve 0.53 #23975 review comment, research and follow-up 1.25 #24002 review discussion, debugging and comment 0.28 #23993 comment 0.67 #23918 commit cleanup 0.20 #24002 follow-up
0.65 #23975 research and follow-up
3.78
2025/12/16 Tuesday 0.40 #23997 review, comment, approve 0.37 #23988 review and comment 0.95 #24001 debugging and comment 0.27 #24006 review and comment 0.23 #24004 review and nothing to say
1.27 #23918 more cleanup, documentation
3.49
2025/12/17 Wednesday 0.32 #24008 testing, debugging and comment 0.08 #24006 review update and approve 0.60 #23795 quick re-check and approve 1.02 #23918 more fixes, address each PR comment and push for CI 0.75 #23956 work on a test and a fix, push for CI 0.93 #24001 write a test, and a fix, testing 0.67 #24001 write an inverted test too, commit message and push for CI 0.17 #23956 perldelta 0.08 #23956 check CI results, make PR 24010
0.15 #24001 perldelta and make PR 24011
4.77
2025/12/18 Thursday 0.27 #24001 rebase, local testing, push for CI 1.15 #24012 research 0.50 #23995 testing and comment
0.08 #24001 check CI results and apply to blead
2.00
Which I calculate is 43.2 hours.
Approximately 32 tickets were reviewed or worked on, and 1 patches were applied. ```

Paul writes:
A mix of focus this month. I was hoping to get attributes-v2 towards
something that could be reviewed and merged, but then I bumped into a
bunch of refalias-related issues. Also spent about 5 hours reviewing
Dave's giant xspod rewrite.
- 1 = Rename
THINGtoken in grammar to something more meaningful- https://github.com/Perl/perl5/pull/23982
- 4 = Continue work on
attributes-v2 - 1 = BBC Ticket on Feature-Compat-Class
- https://github.com/Perl/perl5/issues/23991
- 2 = Experiment with
refaliasparameters with defaults in XS-Parse-Sublike - 1 = Managing the PPC documents and overall process
- 2 = Investigations into the
refaliasanddeclared_refsfeatures, to see if we can un-experiment them - 2 = Add a warning to
refaliasthat breaks closures- https://github.com/Perl/perl5/pull/24026 (work-in-progress)
- 3 = Restore refaliased variables after foreach loop
- https://github.com/Perl/perl5/issues/24028
- https://github.com/Perl/perl5/pull/24029
- 3 = Clear pad after multivariable foreach
- https://github.com/Perl/perl5/pull/24034 (not yet merged)
- 6 = Github code reviews (mostly on Dave's xspod)
- https://github.com/Perl/perl5/pull/23795
Total: 25 hours
An Analysis of The Perl and Raku Foundation's 2024 Finances
In October 2024, I published an article analyzing the financial situation of The Perl and Raku Foundation (TPRF). Since then, I have left the board, and my life is now largely unrelated to Perl. I no longer have insight into TPRF's internal decision-making but I got a few suggestions to continue, so this article again analyzes TPRF's finances using publicly available data for the 2024 calendar year. There is an unavoidable delay between when nonprofit tax returns are filed and when they become public.
Executive Summary
- Assets at end of 2023: $200,215
- Revenue in 2024: $86,845
- Expenses in 2024: $188,037
- Assets at end of 2024: $101,525
Revenue: A Positive Turn

Total revenue in 2024 was $86,845, more than double the $41,442 recorded in 2023.
The increase came almost entirely from contributions (donations), which rose from $24,395 in 2023 to $69,911 in 2024. This suggests that fundraising efforts were effective. Of that amount, I sourced $10,000.
Program services revenue, which is primarily revenue from conference ticket sales, remained stable. It was $16,581 in 2024, compared to $15,903 in 2023.

Expenses: Still high

Total expenses in 2024 were $188,037, roughly the same as in 2023 ($181,655) and the highest level of spending since 2019.
The two largest categories continue to be Grants ($89,944, 47.8%) and Conferences ($62,365, 33.2%). Together, these two categories accounted for over 80% of total spending.
The foundation spent nearly $190,000 in a year where it earned only $87,000.

Assets: Cut in Half
At the end of 2023, TPRF held $200,215 in assets. By the end of 2024, that figure had dropped to $101,525.
In a single year, the foundation lost $98,690. TPRF would run out of money if this trend continued.


Cost Cutting: What Changed
TPRF does not publish a detailed expense breakdown, which makes external analysis difficult. That said, based on public information, several cost-saving changes appear to have occurred in 2024:
- The foundation stopped hiring an intern to support diversity in open-source software, saving $8,000 per year. This is unfortunate, but financially meaningful.
- Previous grant programs for work outside of core language development seem to have ended. I have not seen any calls for such grants since January 2024.
- I was also told that the 2025 conference was organized at a significantly lower cost than in prior years, which should help going forward.
Transparency
Beyond high-level numbers, it is virtually impossible to understand how the foundation spends its money.
There was a proposal by @Tib to leverage Open Collective, which would publicly show where funds come from and how they are spent. This would also make earmarked donations automatic and transparent, including clear allocation between Perl and Raku, which was requested at the previous conferences.
Increased transparency is critical for several reasons:
- Donor trust: When donors can see exactly how their contributions are used, they are more confident that their money is making an impact.
- Accountability: Publicly visible spending ensures that the foundation's leadership is held responsible for financial decisions and priorities.
- Long-term sustainability: Transparent reporting makes it easier to plan budgets, attract new donors, and justify continued support.
- Clear communication between communities: Transparency allows both Perl and Raku communities to understand how resources are allocated, preventing misunderstandings or perceived favoritism.
A Call to the Community
My employer donates to TPRF through a gift-matching program every year and I deeply appreciate that support.
Many tech companies in the 2000s relied heavily on Perl, often at no cost. Supporting its ongoing development is a way of saying thank you. It is never too late.
There has been much to say about Perl improving in TIOBE during 2025 and ending in the top 10 which is roughly where things were around 2016.
Many things are working well in the Perl community and we should expect to be seeing them paying off.
For example:
- The Perl Steering Committee is now several years in and is working effectively
- New releases continue their consistent, predictable, and reliable cadence
- Backward compatibility is still a priority, and breaks happen with care and ample warning.
- MetaCPAN and CPAN are being well run and attracting regular donations
- The Perl and Raku foundation continues in its mission. Continuing to run events and engage with the community
- Perl-centric events continue regularly in America, Europe, and Asia. New events have also sprung up with both in person and online attendance options
- Several grants are adding considerable value to the maintenance of Perl
- Perl continues to be maintained as an official package in every Linux distro, BSD, and is available for Windows. Perl continues to be very viable on a range of systems outside those, some commercial others proprietary
- The Perl langauge has excellent support in major editors/IDE such as Vscode (it is by far the most popular), Vim, Nevim, Emacs, IntelliJ and others.
- The various community channels are more helpful and friendly than ever.
- All major AI platforms can help you with Perl, which excellent results. Never has it been easier to decipher Perl code, to have something patiently explained, or to have detailed reviews of your code
- Perl critic and Perltidy are more relevant than ever in the age of AI. You can define a policy to automatically avoid many of Perls pitfalls and to ensure your code is formatted in a consistent way to suit your needs
Be skeptical of TIOBE by all means, but let's not grasp defeat from the jaws of victory.
Let's take the Win!
Edit: Mentioned events. Which deserve a mention.
TL;DR
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc).
The Twelve-Factor App
Storing the often changing parts of configuration in environment variables is
one of the principles of The Twelve-Factor App.
From this principle follows the need to:
ensure that all the required environment variables are set with
appropriate values, andstore those environment variables and their values in easily accessible ways suitable both for development and for running in production.
Both are typical DevOps problems. To help solve them, use Env::Assert and Env::Dot, two programs which, while doing two very different things, are designed to work in unison.
Env::Assert
Env::Assert was born from frustration. One too many times:
$ PLAEC='Stockholm'
$ if [[ "$PLACE" == '' ]]; then echo "Normal OK"; fi
OK
... And the program fails with no errors!
Not quite what we want!
Another example, from a real life Docker execution script:
perl -Ilib bin/repos-gh-yaml.pl --verbose \
| perl -Ilib bin/repos-yaml-csv.pl --verbose \
| az storage blob upload --data @- \
--content-type 'text/csv' \
--content-encoding 'UTF-8' \
--content-language 'en_US' \
--name "$blob_name" \
--container "$CONTAINER_NAME" \
--account-name "$AZURE_STORAGE_ACCOUNT" \
--sas-token "$AZURE_STORAGE_SAS_TOKEN"
If the environment variables are wrongly set, or not set at all, it won't become evident until after the run has started. It could take hours before the run reaches the point when they are used.
Describe The Environment
Env::Assert, or rather the executable envassert, that comes with it provide an easy way to find out if the environment variables are what we require them to be.
envassert is a CLI command to assert that your environment variables match your Environment Description.
Envdesc or Environment Description is a way to describe which environment variables are required by your program.
Environment Description is written in a file. Default file name is .envdesc.
.envdesc actually looks a lot like a .env file, except instead of
defining variables and their content, it defines regular expressions
which control the variables' content. These regexps are Perl's
extended regular expressions (m/<regexp>/msx).
Example .envdesc:
CONTAINER_NAME=^[a-z0-9-]{1,}$
AZURE_STORAGE_ACCOUNT=^[a-z0-9]{1,}$
AZURE_STORAGE_SAS_TOKEN=^[?].*$
GITHUB_TOKEN=^[[:word:]]{1,}$
In normal circumstances, envassert only verifies the variables that you specifically describe. If you want more control over your environment, there is the meta command envassert (opts: exact=1)
which will make envassert also assert that the environment doesn't contain any unknown variables.
## envassert (opts: exact=1)
USER=^username$
HOME=^/home/username$
PATH=^/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin$
Running Env::Assert
You can create an airtight environment description to verify environment variables in both test and production. Just run envassert as the first command during container execution or any script run:
envassert --env-description /home/me/.envdesc \
|| ( echo 'Break execution ...' 1>&2 && exit 1 )
If it detects problems, envassert will report errors and exit with an error, e.g.:
$ envassert
Environment Assert: ERRORS:
variables:
FIRST_VAR: Variable FIRST_VAR is missing from environment
FOURTH_VAR: Variable FOURTH_VAR has invalid content
Running Self-Contained
A .envdesc file is really convenient for a bigger app which may have many disconnected parts and execution scripts. But if you have only a single script which nevertheless is dependent on having certain predefined environment variables, you can also include the .envdesc file in the script. An example:
#!/usr/bin/env sh
envassert --stdin <<'EOF' # Ensure the required environment.
NUMERIC_VAR=^[[:digit:]]+$
TIME_VAR=^\d{2}:\d{2}:\d{2}$
EOF
echo "${NUMERIC_VAR}: ${TIME_VAR}"
Using Env::Assert in a Program
Env::Assert is a Perl language module. If your application is a Perl script or package, you can also call Env::Assert directly in the code.
If you know you will always have a .envdesc file in the working directory, call:
use Env::Assert 'assert';
But it would probably be better to specify the Environment Description file. Other parameters are also available. break_at_first_error will make Env::Assert to only report the first error it detects:
use Env::Assert assert => {
envdesc_file => 'another-envdesc',
break_at_first_error => 1,
};
Inlining the description file is also possible:
use Env::Assert assert => {
exact => 1,
envdesc => <<'EOF'
NUMERIC_VAR=^[[:digit:]]+$
TIME_VAR=^\d{2}:\d{2}:\d{2}$
EOF
};
Env::Dot
Env::Dot is the other piece of the puzzle, the one which will provide the environment repeatably and reliably.
There is plenty of existing DotEnv solutions. Env::Dot, however, can offer a few unique features. The .env files are treated more like source files, not as ready shell (Unix standard sh or Bash) files. With meta commands user can specify if the .env file is compatible with shell or is written in the more limited format that Docker is using:
For standard shell:
# envdot (file:type=shell)
VAR="value"
For Docker:
# envdot (file:type=plain)
VAR=My var value
You can chain .env files. When seeing meta command read::from_parent**Env::Dot** will search for another.env` file in any parent directory. It will load the first .env file it finds from the current directory upwards to root. If you have several applications in different subdirectory which share some environment variables but also have some unique ones, you can place the common ones in the parent directory and refer to it:
# envdot (read:from_parent)
DIR_VAR="dir"
COMMON_VAR="dir"
Env::Dot uses environment variable ENVDOT_FILEPATHS to read dotenv files located somewhere else than in the current work dir. You can specify several file paths; just separate them by ":". Env::Dot will load the files in the reverse order, starting from the last. This is the same ordering as used in PATH variable: the first overrules the following ones, that is, when reading from the last path to the first path, if same variable is present in more than one file, the later one replaces the one already read.
If you are using Windows, separate the paths by ";"!
For example, if you have the following directory structure:
project-root
| .env
+ - sub-project
| .env
and you specify ENVDOT_FILEPATHS=project-root/sub-project/.env:project-root/.env, then the variables in file project-root/.env will get replaced by the more specific variables in project-root/sub-project/.env.
In Windows, this would be ENVDOT_FILEPATHS=project-root\sub-project\.env;project-root\.env
Env::Dot Executable
Use executable envdot to bring the variables into your shell.
The executable is distributed together with Env::Dot package.
envdot supports the following Unix shells: sh and its derivatives, including bash and ksh, csh and its derivative tcsh', and fish`.
Normally the variables are created in a way that also exports them into any subsequent programs which are run in the same shell, i.e. they become environment variables. However, envdot can also create them as simple variables only for the current process.
Examples of usage:
eval `envdot --no-export --shell csh`
eval `envdot --dotenv subdir/.env`
ENVDOT_FILEPATHS='../.env:subdir/.env:.env' eval `envdot`
Using Env::Dot in a Program
Env::Dot is a Perl language module. If used in code, having the .env file is not mandatory. By default, Env::Dot will do nothing if there is no .env file. You can also configure *Env::Dot * to break execution if there is no .env file.
# If your dotenv file is `.env` or there is no `.env` file:
use Env::Dot;
# If you have a dotenv file in a different filepath:
use Env::Dot read => {
dotenv_file => '/other/path/my_environment.env',
};
# When you absolutely require a `.env` file:
use Env::Dot read => {
required => 1,
};
Existing environment variables always take precedence to dotenv variables. A dotenv variable (variable from a file) does not overwrite an existing environment variable. This is by design because
a dotenv file is to augment the environment, not to replace it. This means that you can override a variable in .env file by creating its counterpart in the environment.
An example of how that works in a normal shell:
#!/usr/bin/env sh
unset VAR
echo "VAR='Good value'" >> .env
perl -e 'use Env::Dot; print "VAR:$ENV{VAR}\n";'
# VAR:Good value
VAR='Better value'; export VAR
perl -e 'use Env::Dot; print "VAR:$ENV{VAR}\n";'
# VAR:Better value
If your .env file(s) contain variables which need interpolating,
for example, to combine their value from other variables or execute a command to produce their value, you have to use the envdot program. Env::Dot does not do any interpolating. It cannot because that would involve running the variable in the shell context within the calling program.
Env::Assert And Env::Dot
If you are in the habit of using .env files, .envdesc complements it. Commit your .envdesc file into your repository and it will act as a template for user or developer to create his/her .env file which should not be committed into Git anyway.
Version Control SVN
Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with a local development…
Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with a local development environment.
Why not just use Python?
Python has traditionally been the main coding language for ML and AI tools. One of the strengths of the MCP protocol is that the actual implementation details are independent of the development language. The reality is that not every project is coded in Python- and MCP allows you to use the latest AI approaches with other coding languages.
Perl? Is that even a language anymore?
The goal of this article is to provide a minimal viable basic working MCP stdio server in Perl that can be run locally without any unneeded extra code or extensions.
The Perl MCP module is here:
What Is Perl?
Perl is a general-purpose, high-level programming and scripting language, primarily known for its powerful text manipulation capabilities. Originally created by Larry Wall in 1987 for easier report processing, it has evolved to be used for a wide range of tasks, including system administration, web development, and network programming.
The main site for Perl is :
The Perl Programming Language - www.perl.org
Installing Perl
The step by step instructions vary by platform- for a basic Debian system here are the steps:
sudo apt-get install perl cpanminus
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ perl --version
This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux-gnu-thread-multi
(with 60 registered patches, see perl -V for more detail)
Gemini CLI
If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:
npm install -g @google/gemini-cli
Testing the Gemini CLI Environment
Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:
gemini
Node Version Management
Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:
Perl MCP Documentation
The official MCP CPAN page provides samples and documentation for getting started:
Where do I start?
The strategy for starting MCP development is a incremental step by step approach.
First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.
Then, a minimal Hello World Style Perl MCP Server is built with stdio transport. This server is validated with Gemini CLI in the local environment.
This setup validates the connection from Gemini CLI to the local process via MCP. The MCP client (Gemini CLI) and the MCP server both run in the same local environment.
Next- the basic MCP server is extended with Gemini CLI to add several new tools in standard code.
Setup the Basic Environment
At this point you should have a working Perl environment and a working Gemini CLI installation. The next step is to clone the GitHub samples repository with support scripts:
cd ~
git clone https://github.com/xbill9/gemini-cli-codeassist
Then run init.sh from the cloned directory.
The script will attempt to determine your shell environment and set the correct variables:
cd gemini-cli-codeassist
source init.sh
If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:
cd gemini-cli-codeassist
source set_env.sh
Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.
Hello World with STDIO Transport
One of the key features that the standard MCP libraries provide is abstracting various transport methods.
The high level MCP tool implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.
The simplest transport that the SDK supports is the stdio (stdio/stdout) transport — which connects a locally running process. Both the MCP client and MCP Server must be running in the same environment.
The connection over stdio will look similar to this:
# Explicitly use stdio transport
$server->to_stdio;
Perl Package Information
The code depends on several standard Perl libraries for MCP and logging:
requires 'Mojolicious::Lite';
requires 'MCP::Server';
requires 'JSON::MaybeXS';
requires 'WWW::Google::Cloud::Auth::ServiceAccount';
requires 'URI::Encode';
requires 'LWP::Protocol::https';
on 'develop' => sub {
requires 'Perl', '5.010';
requires 'Perl::Critic';
requires 'Perl::Tidy';
};
Installing and Running the Perl Code
Run the install make release target on the local system:
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make
Installing dependencies...
--> Working on .
Configuring /home/xbill/gemini-cli-codeassist/mcp-stdio-perl ... OK
<== Installed dependencies for .. Finishing.
Running tests...
t/00_compile.t .. ok
To test the code:
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make test
Running tests...
t/00_compile.t .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.17 cusr 0.05 csys = 0.23 CPU)
Result: PASS
Gemini CLI settings.json
In this example — the Perl source code uses a Perl interpretor that can be called directly from Gemini CLI.
The default Gemini CLI settings.json has an entry for the source:
{
"mcpServers": {
"hello-stdio-perl": {
"command": "perl",
"args": [
"-I$HOME/gemini-cli-codeassist/mcp-stdio-perl/local/lib/perl5",
"$HOME/gemini-cli-codeassist/mcp-stdio-perl/server.pl"
]
}
}
}
Validation with Gemini CLI
Finally- Gemini CLI is restarted and the MCP connection over stdio to the Perl Code is validated, The full Gemini CLI Session will start:
> /mcp list
🟢 hello-stdio-perl - Ready (1 tool)
Tools:
- greet
> greet Camel
✦ I will call the greet tool with the parameter Camel.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? greet (hello-stdio-perl MCP Server) {"param":"Camel"} ← │
│ │
│ MCP Server: hello-stdio-perl │
│ Tool: greet │
│ │
│ Allow execution of MCP tool "greet" from server "hello-stdio-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ greet (hello-stdio-perl MCP Server) {"param":"Camel"} │
│ │
│ Camel │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ Hello Camel! How can I help you today?
Extending the MCP Server with Gemini CLI
Now that the basic MCP functionality has been tested and verified with Gemini CLI- the Perl server code can be extended with new MCP tools:
> with the perl project add new MCP tools -
one that gets detailled Perl system information,
one that gets server information
and one that gets the current time
Gemini CLI will get right to work:
│ 53 │
│ 54 + $server->tool( │
│ 55 + name => 'get_perl_system_info', │
│ 56 + description => 'Get detailed Perl system information (Config::myconfig).', │
│ 57 + input_schema => { │
│ 58 + type => 'object', │
│ 59 + properties => {}, │
│ 60 + }, │
│ 61 + code => sub ( $tool, $args ) { │
│ 62 + $log->info("Executed get_perl_system_info tool"); │
│ 63 + return Config::myconfig(); │
│ 64 + } │
│ 65 + ); │
│ 66 + │ │
Once completed — the changes will be summarized:
✦ I have added the three requested MCP tools to server.pl and verified them with a new test suite.
Summary of changes:
1. Modified `server.pl`:
* Imported Config module.
* Added get_perl_system_info: Returns detailed Perl configuration using Config::myconfig().
* Added get_server_info: Returns server name, version, status, and transport type.
* Added get_current_time: Returns the current system time.
* Refactored the script to be testable (returns $server and only runs to_stdio if run as a script).
2. Created `t/01_tools.t`:
* A new test file that loads server.pl, inspects the registered tools, and executes their callbacks to verify correctness.
Verification:
* t/00_compile.t passed.
* t/01_tools.t passed, confirming all 3 tools are registered and return expected data.
Restart Gemini CLI and check for the new MCP tools:
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make
Installing dependencies...
--> Working on .
Configuring /home/xbill/gemini-cli-codeassist/mcp-stdio-perl ... OK
<== Installed dependencies for .. Finishing.
Running tests...
t/00_compile.t .. ok
t/01_tools.t .... 1/? {"asctime":"2026-01-12T01:08:56.49922Z","levelname":"INFO","message":"Executed get_server_info tool","name":"root"}
{"asctime":"2026-01-12T01:08:56.49954Z","levelname":"INFO","message":"Executed get_current_time tool","name":"root"}
{"asctime":"2026-01-12T01:08:56.49965Z","levelname":"INFO","message":"Executed get_perl_system_info tool","name":"root"}
t/01_tools.t .... ok
All tests successful.
Files=2, Tests=13, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.35 cusr 0.05 csys = 0.42 CPU)
Result: PASS
And list the new MCP Tools:
🟢 hello-stdio-perl - Ready (4 tools)
Tools:
- get_current_time
- get_perl_system_info
- get_server_info
- greet
to run the tools:
> get_current_time
✦ I will get the current time for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? get_current_time (hello-stdio-perl MCP Server) {} ← │
│ │
│ MCP Server: hello-stdio-perl │
│ Tool: get_current_time │
│ │
│ Allow execution of MCP tool "get_current_time" from server "hello-stdio-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I will get the current time for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_current_time (hello-stdio-perl MCP Server) {} │
│ │
│ Sun Jan 11 20:12:02 2026 │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I've retrieved the current time. I am now ready for your first command.
and Perl information:
> get_perl_system_info
✦ I will retrieve the Perl system information for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_perl_system_info (hello-stdio-perl MCP Server) {} │
│ │
│ Summary of my perl5 (revision 5 version 36 subversion 0) configuration: │
│ │
│ Platform: │
│ osname=linux │
│ osvers=4.19.0 │
│ archname=x86_64-linux-gnu-thread-multi │
│ uname='linux localhost 4.19.0 #1 smp debian 4.19.0 x86_64 gnulinux ' │
and system information:
> get_server_info
✦ I will get the information about this MCP server.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_server_info (hello-stdio-perl MCP Server) {} │
│ │
│ {"name":"Perl MCP Stdio Server","perl_version":"v5.36.0","status":"running","transport":"stdio","version":"1.0.0"} │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ The server is running version 1.0.0 of the Perl MCP Stdio Server on Perl v5.36.0.
Summary
The strategy for using Perl with MCP development with Gemini CLI was validated with a incremental step by step approach.
A minimal stdio transport MCP Server was started from Perl source code and validated with Gemini CLI running as a MCP client in the same local environment.
Gemini CLI was then used to extend the sample Perl code with several MCP tools and use these tools inside the context for the underlying LLM.
-
App::Greple - extensible grep with lexical expression and region handling
- Version: 10.02 on 2026-01-09, with 56 votes
- Previous CPAN version: 10.01 was 9 days before
- Author: UTASHIRO
-
App::Netdisco - An open source web-based network management tool.
- Version: 2.097002 on 2026-01-09, with 818 votes
- Previous CPAN version: 2.097001
- Author: OLIVER
-
App::Sqitch - Sensible database change management
- Version: v1.6.1 on 2026-01-06, with 3087 votes
- Previous CPAN version: v1.6.0 was 3 months before
- Author: DWHEELER
-
CPANSA::DB - the CPAN Security Advisory data as a Perl data structure, mostly for CPAN::Audit
- Version: 20260104.001 on 2026-01-04, with 25 votes
- Previous CPAN version: 20251228.001 was 6 days before
- Author: BRIANDFOY
-
DateTime::Format::Natural - Parse informal natural language date/time strings
- Version: 1.23 on 2026-01-04, with 19 votes
- Previous CPAN version: 1.23 was 5 days before
- Author: SCHUBIGER
-
Firefox::Marionette - Automate the Firefox browser with the Marionette protocol
- Version: 1.69 on 2026-01-10, with 19 votes
- Previous CPAN version: 1.68 was 3 months, 26 days before
- Author: DDICK
-
GD - Perl interface to the libgd graphics library
- Version: 2.84 on 2026-01-04, with 32 votes
- Previous CPAN version: 2.83 was 1 year, 6 months, 11 days before
- Author: RURBAN
-
IO::Socket::SSL - Nearly transparent SSL encapsulation for IO::Socket::INET.
- Version: 2.098 on 2026-01-06, with 49 votes
- Previous CPAN version: 2.097
- Author: SULLR
-
JSON::Schema::Modern - Validate data against a schema using a JSON Schema
- Version: 0.632 on 2026-01-06, with 16 votes
- Previous CPAN version: 0.631 was 12 days before
- Author: ETHER
-
MetaCPAN::Client - A comprehensive, DWIM-featured client to the MetaCPAN API
- Version: 2.037000 on 2026-01-07, with 27 votes
- Previous CPAN version: 2.036000
- Author: MICKEY
-
MIME::Lite - low-calorie MIME generator
- Version: 3.035 on 2026-01-08, with 35 votes
- Previous CPAN version: 3.034 was 2 days before
- Author: RJBS
-
Module::Starter - a simple starter kit for any module
- Version: 1.81 on 2026-01-09, with 34 votes
- Previous CPAN version: 1.80
- Author: XSAWYERX
-
Perl::Tidy - indent and reformat perl scripts
- Version: 20260109 on 2026-01-08, with 147 votes
- Previous CPAN version: 20250912 was 3 months, 26 days before
- Author: SHANCOCK
-
perlsecret - Perl secret operators and constants
- Version: 1.018 on 2026-01-09, with 55 votes
- Previous CPAN version: 1.017 was 4 years, 2 months before
- Author: BOOK
-
Type::Tiny - tiny, yet Moo(se)-compatible type constraint
- Version: 2.010001 on 2026-01-06, with 148 votes
- Previous CPAN version: 2.010000 was 7 days before
- Author: TOBYINK
-
UV - Perl interface to libuv
- Version: 2.001 on 2026-01-06, with 14 votes
- Previous CPAN version: 2.000 was 4 years, 5 months, 8 days before
- Author: PEVANS
In a script I'm using constants (use constant ...) to allow re-use ion actual regular expressions, using the pattern from https://stackoverflow.com/a/69379743/6607497.
However when using a {...} repeat specifier following such constant expansion, Perl wants to tread the constant as a hash variable.
The question is how to avoid that.
Code example:
main::(-e:1): 1
DB<1> use constant CHARSET => '[[:graph:]]'
DB<2> x "foo" =~ qr/^[[:graph:]]{3,}$/
0 1
DB<3> x "foo" =~ qr/^${\CHARSET}{3,}$/
Not a HASH reference at (eval 8)[/usr/lib/perl5/5.26.1/perl5db.pl:738] line 2.
DB<4> x "foo" =~ qr/^${\CHARSET}\{3,}$/
empty array
DB<5> x $^V
0 v5.26.1
According to https://stackoverflow.com/a/79845011/6607497 a solution may be to add a space that's being ignored, like this: qr/^${\CHARSET} {3,}$/x; however I don't understand why this works, because outside of a regular expression the space before { is being ignored:
DB<6> x "foo" =~ qr/^${\CHARSET} {3,}$/x
0 1
DB<7> %h = (a => 3)
DB<8> x $h{a}
0 3
DB<9> x $h {a}
0 3
The manual page (perlop(1) on "Quote and Quote-like Operators") isn't very precise on that:
For constructs that do interpolate, variables beginning with "$" or "@" are interpolated. Subscripted variables such as $a[3] or "$href->{key}[0]" are also interpolated, as are array and hash slices. But method calls such as "$obj->meth" are not.
foobar is a Perl script that prints to both standard output and standard error. In a separate Perl script echo-stderr, I run foobar and capture its standard error using IPC::Open3's open3 function, and simply echo it back.
Here's the code for echo-stderr:
#!/usr/bin/perl -w
use IPC::Open3;
use Symbol 'gensym';
$fh = gensym;
$pid = open3('STDIN', 'STDOUT', $fh, './foobar') or die "$0: failed to run ./foobar\n";
while ( <$fh> ) {
print STDERR $_;
}
close $fh;
waitpid($pid, 0);
The result is that whatever foobar writes to standard error is printed, nothing that it writes to standard output is.
And there is an error at the end:
<message written to STDERR>
<message written to STDERR>
...
Unable to flush stdout: Bad file descriptor
What is the reason for this error?
Version Control SVN
Whenever I’m building a static website, I almost never start by reaching for Apache, nginx, Docker, or anything that feels like “proper infrastructure”. Nine times out of ten I just want a directory served over HTTP so I can click around, test routes, check assets, and see what happens in a real browser.
For that job, I’ve been using App::HTTPThis for years.
It’s a simple local web server you run from the command line. Point it at a directory, and it serves it. That’s it. No vhosts. No config bureaucracy. No “why is this module not enabled”. Just: run a command and you’ve got a website.
Why I’ve used it for years
Static sites are deceptively simple… right up until they aren’t.
-
You want to check that relative links behave the way you think they do.
-
You want to confirm your CSS and images are loading with the paths you expect.
-
You want to reproduce “real HTTP” behaviour (caching headers, MIME types, directory handling) rather than viewing files directly from disk.
Sure, you can open file:///.../index.html in a browser, but that’s not the same thing as serving it over HTTP. And setting up Apache (or friends) feels like bringing a cement mixer to butter some toast.
With http_this, the workflow is basically:
-
cdinto your site directory -
run a single command
-
open a URL
-
get on with your life
It’s the “tiny screwdriver” that’s always on my desk.
Why I took it over
A couple of years ago, the original maintainer had (entirely reasonably!) become too busy elsewhere and the distribution wasn’t getting attention. That happens. Open source is like that.
But I was using App::HTTPThis regularly, and I had one small-but-annoying itch: when you visited a directory URL, it would always show a directory listing – even if that directory contained an index.html. So instead of behaving like a typical web server (serve index.html by default), it treated index.html as just another file you had to click.
That’s exactly the sort of thing you notice when you’re using a tool every day, and it was irritating enough that I volunteered to take over maintenance.
(If you want to read more on this story, I wrote a couple of blog posts.)
What I’ve done since taking it over
Most of the changes are about making the “serve a directory” experience smoother, without turning it into a kitchen-sink web server.
1) Serve index pages by default (autoindex)
The first change was to make directory URLs behave like you’d expect: if index.html exists, serve it automatically. If it doesn’t, you still get a directory listing.
2) Prettier index pages
Once autoindex was in place, I then turned my attention to the fallback directory listing page. If there isn’t an index.html, you still need a useful listing — but it doesn’t have to look like it fell out of 1998. So I cleaned up the listing output and made it a bit nicer to read when you do end up browsing raw directories.
3) A config file
Once you’ve used a tool for a while, you start to realise you run it the same way most of the time.
A config file lets you keep your common preferences in one place instead of re-typing options. It keeps the “one command” feel, but gives you repeatability when you want it.
4) --host option
The ability to control the host binding sounds like an edge case until it isn’t.
Sometimes you want:
-
only
localhostaccess for safety; -
access from other devices on your network (phone/tablet testing);
-
behaviour that matches a particular environment.
A --host option gives you that control without adding complexity to the default case.
The Bonjour feature (and what it’s for)
This is the part I only really appreciated recently: App::HTTPThis can advertise itself on your local network using mDNS / DNS-SD – commonly called Bonjour on Apple platforms, Avahi on Linux, and various other names depending on who you’re talking to.
It’s switched on with the --name option.
When you do that, http_this publishes an _http._tcp service on your local network with the instance name you chose (MyService in this case). Any device on the same network that understands mDNS/DNS-SD can then discover it and resolve it to an address and port, without you having to tell anyone, “go to http://192.168.1.23:7007/”.
Confession time: I ignored this feature for ages because I’d mentally filed it under “Apple-only magic” (Bonjour! very shiny! probably proprietary!). It turns out it’s not Apple-only at all; it’s a set of standard networking technologies that are supported on pretty much everything, just under a frankly ridiculous number of different names. So: not Apple magic, just local-network service discovery with a branding problem.
Because I’d never really used it, I finally sat down and tested it properly after someone emailed me about it last week, and it worked nicely, nicely enough that I’ve now added a BONJOUR.md file to the repo with a practical explanation of what’s going on, how to enable it, and a few ways to browse/discover the advertised service.
(If you’re curious, look for _http._tcp and your chosen service name.)
It’s a neat quality-of-life feature if you’re doing cross-device testing or helping someone else on the same network reach what you’re running.
Related tools in the same family
App::HTTPThis is part of a little ecosystem of “run a thing here quickly” command-line apps. If you like the shape of http_this, you might also want to look at these siblings:
-
https_this : like
http_this, but served over HTTPS (useful when you need to test secure contexts, service workers, APIs that require HTTPS, etc.) -
cgi_this : for quick CGI-style testing without setting up a full web server stack
-
dav_this : serves content over WebDAV (handy for testing clients or workflows that expect DAV)
-
ftp_this : quick FTP server for those rare-but-real moments when you need one
They all share the same basic philosophy: remove the friction between “I have a directory” and “I want to interact with it like a service”.
Wrapping up
I like tools that do one job, do it well, and get out of the way. App::HTTPThis has been that tool for me for years and it’s been fun (and useful) to nudge it forward as a maintainer.
If you’re doing any kind of static site work — docs sites, little prototypes, generated output, local previews — it’s worth keeping in your toolbox.
And if you’ve got ideas, bug reports, or platform notes (especially around Bonjour/Avahi weirdness), I’m always happy to hear them.
The post App::HTTPThis: the tiny web server I keep reaching for first appeared on Perl Hacks.
A jq-compatible JSON processor written in pure Perl, designed for environments where jq cannot be installed.
-
App::cpm - a fast CPAN module installer
- Version: 0.998003 on 2025-12-29, with 177 votes
- Previous CPAN version: 0.998002 was 24 days before
- Author: SKAJI
-
App::Greple - extensible grep with lexical expression and region handling
- Version: 10.01 on 2025-12-31, with 56 votes
- Previous CPAN version: 10.00 was 19 days before
- Author: UTASHIRO
-
App::Music::ChordPro - A lyrics and chords formatting program
- Version: v6.090.1 on 2026-01-03, with 432 votes
- Previous CPAN version: v6.090.0 was 2 months, 3 days before
- Author: JV
-
CPANSA::DB - the CPAN Security Advisory data as a Perl data structure, mostly for CPAN::Audit
- Version: 20251228.001 on 2025-12-29, with 25 votes
- Previous CPAN version: 20251221.001 was 7 days before
- Author: BRIANDFOY
-
DBD::SQLite - Self Contained SQLite RDBMS in a DBI Driver
- Version: 1.78 on 2026-01-02, with 107 votes
- Previous CPAN version: 1.76 was 1 year, 2 months, 14 days before
- Author: ISHIGAKI
-
Module::Starter - a simple starter kit for any module
- Version: 1.79 on 2026-01-03, with 33 votes
- Previous CPAN version: 1.78 was 7 months, 30 days before
- Author: XSAWYERX
-
Type::Tiny - tiny, yet Moo(se)-compatible type constraint
- Version: 2.010000 on 2025-12-30, with 148 votes
- Previous CPAN version: 2.009_003 was 7 days before
- Author: TOBYINK
-
WebService::Dropbox - Perl interface to Dropbox API
- Version: 2.10 on 2025-12-29, with 12 votes
- Previous CPAN version: 2.09 was 4 years, 6 months, 14 days before
- Author: ASKADNA
In an attempt to avoid switch /x for a complex regular expression, I tried to replace qr/string/ with the following expression:
(map { qr/$_/ } ("a more" . "complex regex"))[0]
As the latter expression uses double quoted strings, I thought I would have to duplicate any backslash that should go into the qr operator. Because of that, I tried something like this:
(map { qr/$_/ } (
"^Load key \"\\Q$host_CA\\E\": "
. 'incorrect passphrase supplied '
. "to decrypt private key$CRLF"
))
However, Perl 5.26 complains with the following error message:
Unrecognized escape \Q passed through in regex; marked by <-- HERE in m/^Load key "\Q <-- HERE ...
It seems I don't have to duplicate the backslash, but I don't understand why. The following examples illustrate the behavior I am seeing:
DB<3> $x='f*o'
DB<4> x qr/\Q$x\E/
0 (?^u:f\\*o)
-> qr/(?^u:f\*o)/
DB<5> x map { qr/$_/ } ("\\Q$x\\E/")
0 (?^u:\\Qf*o\\E/)
-> qr/(?^u:\Qf*o\E\/)/
DB<6> x map { qr/$_/ } ("\Q$x\E/")
0 (?^u:f\\*o/)
-> qr/(?^u:f\*o\/)/
-
App::DBBrowser - Browse SQLite/MySQL/PostgreSQL databases and their tables interactively.
- Version: 2.438 on 2025-12-25, with 18 votes
- Previous CPAN version: 2.437_05 was 7 days before
- Author: KUERBIS
-
Convert::Pheno - A module to interconvert common data models for phenotypic data
- Version: 0.29 on 2025-12-23, with 15 votes
- Previous CPAN version: 0.28 was 8 months, 4 days before
- Author: MRUEDA
-
Devel::MAT - Perl Memory Analysis Tool
- Version: 0.54 on 2025-12-26, with 30 votes
- Previous CPAN version: 0.53 was 1 year, 9 months, 19 days before
- Author: PEVANS
-
Finance::Quote - Get stock and mutual fund quotes from various exchanges
- Version: 1.68 on 2025-12-21, with 145 votes
- Previous CPAN version: 1.68 was 3 days before
- Author: BPSCHUCK
-
HTTP::Tiny - A small, simple, correct HTTP/1.1 client
- Version: 0.092 on 2025-12-27, with 115 votes
- Previous CPAN version: 0.091 was 14 days before
- Author: HAARG
-
JSON::Schema::Modern - Validate data against a schema using a JSON Schema
- Version: 0.631 on 2025-12-25, with 16 votes
- Previous CPAN version: 0.630 was 10 days before
- Author: ETHER
I am developing a Virtualmin plugin. But the problem is to have a link appear under the "Manage Virtual Server" category in the Virtualmin sidebar whenever the feature is enabled for a virtual server (domain).
Despite following the standard plugin structure, the menu item refuses to appear in the Virtualmin UI, although the module is accessible if I manually type the URL or find it in the Webmin "Tools" section (when not hidden).
Environment
- OS: Ubuntu 22.04 / 24.04
- Virtualmin version: Latest
- Webmin version: Latest
File Structure
/usr/share/webmin/my-plugin-folder/
index.cgimodule.infovirtual_feature.pl- ...
Relevant Code
virtual_feature.pl
require 'my-plugin-lib.pl';
sub feature_name {
return "plugin_name";
}
sub feature_label {
return "Plugin Name";
}
sub feature_disables {
return 1;
}
sub feature_check {
return undef;
}
sub feature_setup {
my ($d) = @_;
return undef;
}
sub feature_links {
my ($d) = @_;
# This is intended to place the link under "Manage Virtual Server"
return ({ 'mod' => $module_name,
'desc' => "Plugin Name",
'page' => "index.cgi?dom=" . $d->{'id'},
'cat' => 'server' });
}
1;
module.info
desc=Plugin Name Tool
os_support=*-linux
version=1.6
category=server
depends=virtual-server
virtualmin=1
hidden=1
Expected Behavior
After enabling the feature globally in System Settings -> Features and Plugins, a link should appear in the left-hand sidebar under the "Manage Virtual Server" category.
Actual Behavior
The feature shows up in the "Enabled features" list and can be toggled/saved successfully. However, the link never appears in the sidebar. No errors are logged in /var/webmin/miniserv.error.
What I have tried
- Restarting Webmin (
/etc/webmin/restart). - Hardcoding the module folder name in the
'mod'field offeature_links. - Changing the
'cat'field to'services'or'logs'. - Refreshing the Webmin module cache.
- Verifying that the feature is indeed marked as enabled in the domain's configuration file in
/etc/webmin/virtual-server/domains/.
Is there a specific registration step or a required function in virtual_feature.pl that I am missing for the sidebar injection to work correctly in recent versions of the Virtualmin Authentic Theme?
At an online event through the Perl Maven group we tried to understand this module and even to contriute to it. For more details about the contributions check out the OSDC Perl page.
This example is based on the one in the documentation of the JSON::Schema::Validate and tweaked a bit. It will be useful again if we continue dealing with this module.
examples/json_schema_validate.pl
use JSON::Schema::Validate;
use JSON ();
use open qw( :std :encoding(UTF-8) );
my $schema = {
'$schema' => 'https://json-schema.org/draft/2020-12/schema',
'$id' => 'https://example.org/s/root.json',
type => 'object',
required => [ 'name' ],
properties => {
name => { type => 'string', minLength => 5 },
next => { '$dynamicRef' => '#Node' },
},
'$dynamicAnchor' => 'Node',
additionalProperties => JSON::false,
};
my $js = JSON::Schema::Validate->new( $schema )
->compile
->content_checks
->ignore_unknown_required_vocab
->prune_unknown
->register_builtin_formats
->trace
->trace_limit(200) # 0 means unlimited
->unique_keys; # enable uniqueKeys
#my $data = {
# name => 'head',
# next => {
# name => 'tail'
# }
#};
#my $data = {
# name => 23,
# next => {
# name => 'tail'
# }
#};
#my $data = {
# name => 'head',
#};
my $data = {
name => 'head big',
};
my $ok = $js->validate($data)
or die( $js->error );
print "ok\n";
-
App::Netdisco - An open source web-based network management tool.
- Version: 2.097000 on 2025-12-16, with 810 votes
- Previous CPAN version: 2.096001 was 2 days before
- Author: OLIVER
-
CPANSA::DB - the CPAN Security Advisory data as a Perl data structure, mostly for CPAN::Audit
- Version: 20251221.001 on 2025-12-21, with 25 votes
- Previous CPAN version: 20251214.001 was 7 days before
- Author: BRIANDFOY
-
Dist::Zilla::Plugin::Test::Compile - Common tests to check syntax of your modules, using only core modules
- Version: 2.059 on 2025-12-16, with 13 votes
- Previous CPAN version: 2.058 was 7 years, 11 months, 27 days before
- Author: ETHER
-
Image::ExifTool - Read and write meta information
- Version: 13.44 on 2025-12-15, with 44 votes
- Previous CPAN version: 13.36 was 3 months, 6 days before
- Author: EXIFTOOL
-
JSON::Schema::Modern - Validate data against a schema using a JSON Schema
- Version: 0.630 on 2025-12-14, with 16 votes
- Previous CPAN version: 0.629 was 2 days before
- Author: ETHER
-
List::Gen - provides functions for generating lists
- Version: 0.979 on 2025-12-21, with 24 votes
- Previous CPAN version: 0.978
- Author: SOMMREY
-
Minilla - CPAN module authoring tool
- Version: v3.1.29 on 2025-12-17, with 98 votes
- Previous CPAN version: v3.1.28 was 3 months, 2 days before
- Author: SYOHEX
-
Module::CoreList - what modules shipped with versions of perl
- Version: 5.20251220 on 2025-12-20, with 44 votes
- Previous CPAN version: 5.20251120 was 1 month before
- Author: BINGOS
-
Mouse - Moose minus the antlers
- Version: v2.6.1 on 2025-12-20, with 63 votes
- Previous CPAN version: v2.6.0 was 1 month, 20 days before
- Author: SKAJI
-
PGXN::API - Maintain and serve a REST API to search PGXN mirrors
- Version: v0.21.0 on 2025-12-15, with 18 votes
- Previous CPAN version: v0.20.2 was 1 year, 9 months before
- Author: DWHEELER
-
Sidef - The Sidef Programming Language
- Version: 25.12 on 2025-12-21, with 121 votes
- Previous CPAN version: 24.11 was 1 year, 22 days before
- Author: TRIZEN
-
Text::Markup - Parse text markup into HTML
- Version: 0.41 on 2025-12-18, with 12 votes
- Previous CPAN version: 0.40 was 3 days before
- Author: DWHEELER
-
Unicode::UTF8 - Encoding and decoding of UTF-8 encoding form
- Version: 0.63 on 2025-12-20, with 20 votes
- Previous CPAN version: 0.62 was 8 years, 8 months, 9 days before
- Author: CHANSEN
-
Zonemaster::Backend - A system for running Zonemaster tests asynchronously through an RPC-API
- Version: 12.0.0 on 2025-12-19, with 16 votes
- Previous CPAN version: 11.5.0 was 5 months, 22 days before
- Author: ZNMSTR
-
Zonemaster::Engine::Exception::NormalExit - run Zonemaster tests from the command line
- Version: 8.000001 on 2025-12-19, with 23 votes
- Previous CPAN version: 8.000000 was 5 months, 22 days before
- Author: ZNMSTR
-
Zonemaster::Engine - A tool to check the quality of a DNS zone
- Version: 8.001000 on 2025-12-19, with 35 votes
- Previous CPAN version: 8.000000 was 5 months, 22 days before
- Author: ZNMSTR
This is the weekly favourites list of CPAN distributions. Votes count: 43
Week's winner: MCP (+3)
Build date: 2025/12/21 13:03:54 GMT
Clicked for first time:
- App::BlurFill - Blurred background fill image processor
- Complete::Getopt::Long - Complete command-line argument using Getopt::Long specification
- Data::Turtle - Turtle Movement and State Operations
- Marlin - ð pretty fast class builder with most Moo/Moose features ð
- Mojo::Collection::XS - Fast XS subclass of Mojo::Collection with XS-based while
- SimpleFlow - easy, simple workflow manager (and logger); for keeping track of and debugging large and complex shell command workflows
Increasing its reputation:
- Affix (+1=4)
- App::shcompgen (+1=3)
- Complete::Bash (+1=5)
- Complete::Util (+1=2)
- Const::Fast (+1=37)
- DateTime::Format::Strptime (+1=26)
- File::HomeDir (+1=35)
- File::XDG (+1=10)
- Getopt::Long::Complete (+1=15)
- Getopt::Long::More (+1=2)
- IPC::Run3 (+1=25)
- JQ::Lite (+1=7)
- JSON::Schema::Modern (+1=9)
- JSON::XS (+1=121)
- MCP (+3=7)
- Melian (+2=3)
- MooX::Singleton (+1=6)
- OpenGL (+1=14)
- OpenGL::Modern (+1=3)
- PAGI (+2=2)
- Path::Iterator::Rule (+1=26)
- Perl::Types (+1=2)
- Prima (+1=46)
- SDL3 (+2=2)
- sealed (+1=2)
- Storage::Abstract (+2=2)
- Sub::Throttler (+1=2)
- Test2::Plugin::SubtestFilter (+1=3)
- Text::Markup (+1=12)
- Thread::Subs (+2=2)






