When we publish our Perl module repository on GitHub, we might notice something peculiar in the "About"
section of our repository: GitHub doesn't recognize the Perl 5 license. This can be a bit
confusing, especially when we've explicitly stated the licensing in our LICENSE file.
Without properly defined license, GitHub ranks the quality of a repository lower. This is also unfortunate because it limits the "searchability" of our repository. GitHub cannot index it according to the license and users cannot search by license. This is today more important than ever before as many enterprises rule out open source projects purely on the grounds that their license is poorly managed.
The Problem: Two Licenses in One File
The standard Perl 5 license, as used by many modules, is a dual license: Artistic License (2.0) and GNU
General Public License (GPL) version 1 or later. Often, this is included in a single LICENSE file
in the repository root.
The stars aligned and all three of us managed to get together.
We mostly talked about PPCs, both in the general shape of the process, and specifically the latest proposal, PPC0034.
Given how the PPC process has worked out in practice, we discussed how much sense it makes and whether it solves a problem we actually have. We agreed that the steering council - and Perl overall - would still benefit from having some sort of declared process by which people can suggest and discuss new features, as separate from implementing them.
The process at the moment doesn’t align very well with existing practice; at the same time, existing practice is not particularly structured. Rather than trying to define a new process, we think it better to clarify the documented process to more obviously match what we actually do, and try to iterate that way.
PPC0034 is concerned with refalias parameters in signatures. Both the refalias and declared_refs features are still currently marked as experimental, though it is not immediately clear in their overview tickets why. We should clarify the status of these before we fully commit to PPC0034.
That aside, the overall document of PPC0034 seems good and we’re happy to merge it as a basis for ongoing experiment and a trial implementation.
The refalias draft PPC on the mailing list is looking good. We encourage Gianni to turn it into a full PPC doc PR
We still would like more automation around making real CPAN distributions out of dist/ dirs. Paul will write an email requesting assistance on that subject specifically
Briefly discussed the subject of the meta module handling signatures with named parameters. Further discussion will continue on the email thread.
wir laden Euch herzlich ein
zum Deutschen Perl/Raku Workshop 2026.
Der Workshop findet nächstes Jahr vom Montag 16. März bis
Mittwoch 18. März in der Heilandskirche in Berlin. statt.
Die Webseite und der Call for Papers sind bereits online. 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 orga2026@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 everybody,
we cordially invite you
to the German Perl/Raku Workshop 2026.
The workshop will take place next year from Monday 16th May to
Wednesday 18th March in the Heilandskirche in Berlin..
The website and the call for papers are already online.
We are looking forward to many interesting
presentations!
I thought it might be fun to write a "polymorphic virus", but that would involve learning executable file formats and machine code, which sounds like a lot of effort. So instead I went for the next best thing: Perl instead of machine code, and self-replicating code in the form of a quine rather than "infecting" other executables.
When you run this code, it will output a new version of itself, which you can run again to get another version, etc. Unlike a regular quine, which will produce an exact copy of its source code, this program is polymorphic: Its output is functionally identical to the original, but the code might look completely different. This is just a proof-of-concept, but it does try to introduce variations in all parts that a simple static scanner might use for detection (such as signatures in an antivirus). There are still fixed parts, but they're small and generic (such as ; or =) and can be found in most any perl script.
The newly-added signature_named_parameters experiment needs adding to perlexperiment.pod, and experimental.pm. Hopefully before 5.43.5 release on Thursday
The experimental dist would be easier to manage if it lived in dist/, but it would also be nice if we had more automated tooling to create real CPAN distribution tarballs out of those directories. Would help for making Module-Corelist updates every month as well.
We await a full write-up of a PPC document following on from the “refalias in signatures” Pre-PPC discussion
Get them from the usual place.
And no, I have still not had time to update CPAN::MetaCustodian so that it properly parses these wikis. But that time is approaching...
On my last post I asked Gemini to create a product requirement document to outline a plan to improve the overall state of the ev-calc-pricing application. In this blog entry I will discuss my interaction with Gemini and how it increased code coverage of the ev-calc-pricing application. Below is an example of the prompts:
----
> review PRD.md for @ev-calc-pricing
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ ReadFile PRD.md │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ The PRD.md outlines a plan to refactor the ev-calc-pricing application to improve maintainability, data accuracy, and
robustness.
Key issues identified:
* Manual, hardcoded electricity rate data in StateRates.pm.
* Minimal test coverage.
* Unused scripts and lack of input validation.
The plan focuses on four epics:
1. Automated Data Pipeline: To fetch, process, and load electricity rate data automatically.
2. Comprehensive Test Suite: To ensure accuracy and stability of calculations and data loading.
3. Code Refactoring and Cleanup: To remove hardcoded data, unused scripts, and consolidate data files.
4. Enhanced User Experience: To add input validation and better user feedback.
We discussed the unlimited statement modifier chaining proposal. Both of us thought that unlimited chaining is a bad idea, though we agreed that being able to combine one loop and one conditional would on rare occasions make things slightly nicer. However we also agreed that in terms of conceptual complexity, only either allowing arbitrary chaining or disallowing chaining entirely is justifiable, as opposed to specifying and implementing rules to permit it but only in certain specific cases, especially considering the marginal benefit. So we settled on agreeing with Larry’s original design decision to disallow them.
Get at the usual place...
Elsewhere, I've moved house, into a retirement village.
Yes, folks. I'm 75, much to my horror and astonishment.
It was an exhausting process, but I'll settled in now. And still programming!
And not just the wikis. I have various other projects I can get back to now I've moved.
Why move?
Because I downsized. The price difference gives me a little bit of money in the bank.
In my previous blogpost I briefly discussed the use of Gemini Cli on a Perl dancer application to analyze its codebase. The next step is to generate a product requirement document. Why is this important ? well I had a bad experience with Gemini on another application where I allowed it to roam free "YOLO" mode and it basically started fixing all the problem areas one after another for about an hour or so until my free trial of Google Gemini expired for the day. This resulted into a completely rewritten application that was not able to run due to so many different errors. The cool thing is that I had version control so a good old "git reset --hard Head" cleared up my project and I could start over again.
We had a small amount of helpful feedback on the named signature parameters PR. Paul wants to merge by the end of the week for the purposes of inviting more feedback, assuming no issues are raised in the meantime.
Every year we “welcome” a new bunch of trainees into our department. Young,
intelligent and enthusiastic, their psyche and physique have yet to be shaped to
accommodate cynical scepticism, efficient laziness, and an integument
thickened by years of abuse into something that offers natural protection
from radiation emanating from the monitors they will stare at all day playing
Solitaire.
One such fellow, let’s call him Nik the Greek, came up to me
with that sickening joie de vivre characteristic of youth, and proceeded
to reveal how eager he was to demonstrate his enormous intellectual
assets. I would have raised an eyebrow, had I the energy to do so. But
been there, done that. I was once his age I suspect, though either I
can’t remember or have developed a block to my memories as an act of
self-preservation.
