It's weird but currently I draw most of my programming satisfaction from using (and enhancing) App::sqldisplay. It is a simplistic app that allows me to write and display SQL queries against a spreadsheet. I mostly use it to do the accounting for the Perl club. But doing that made doing the books much more fun actually.

Here I edit a cell in the spreadsheet, and the SQL query in the browser automatically updates and highlights the changed rows:

Also, I've now started exploring HTMX for that, and it works surprisingly well for the use case I have, removing 20+ lines of code in favour of 1 line of configuration and small Perl-side code changes.

The one thing I don't like about HTMX is that for every component of your page that you want to update individually, you need to create an HTTP accessible endpoint. But for push notifications, you can just push the new HTML instead, which is good enough.

But "even" with this hobby project, I see feature creep, as just today I thought about exporting the collection of queries as an Excel sheet. And the UI now has tabs, just like an Excel sheet and I wonder if I should keep an Excel sheet/spreadsheet for data entry or just (also) write my own editing UI. But writing an editing UI is makework for little gain. I would want it to have mostly Excel-like UI, keyboard bindings and autofill.

Last week, the Perl community came together for the 28th German Perl Workshop. This year, it was held at the Heilandskirche in Berlin Moabit. Excitingly, we had the nave for the presentations.

While the name is still German Perl Workshop, we now draw attendees from all over the globe. Presenters came from India, the US and various European countries. Maybe it is time to announce it as a more international conference again.

Bringing the infrastructure to a Perl Workshop is a lot of additional hardware that we hopefully won't need, like looong HDMI cables, various adapters to HDMI, a bundle extension cords and duct tape of the non-Perl variant. Lee also brought the EPO recording set for recording the presentations. The set came back with me from Berlin, as its main use is nowadays recording the talks at a German Perl Workshop for later publication.

Organizing a conference usually means that my attention is divided between running the event, chatting with attendees and giving a presentation or two. Luckily other members of Frankfurt.pm and other long-time attendees are always there to lend a hand.

Over the years, we have organized the German Perl Workshop many times. Local organizers for 2027 already stepped up. Next year, we aim for the city of Hannover. We don't have the contract for a venue signed, so watch https://www.perl-workshop.de/news for announcements.

Such an event can't happen without the sponsors who support us financially. Let me quickly show their logos here:

... which are meaningless internet points, but Anthropic only recognize projects with 5k+ Github stars for their Open Source program. Of course, you can also apply and try for a manual review. But maybe we should push the stars of the Perl repository up a bit in this popularity contest...

Of course, a free 6-month Claude Max subscription isn't all that great, but if Github stars are a measure...

When I write a blog entry, I usually end in the following loop:

1. Write/update the .markdown file
2. Regenerate the HTML using statocles build; this regenerates the whole site
3. Refresh my browser to view the current page

Glueing together Mojo::File::ChangeNotify and App::Mojo::AssetReloader and a nice default rule using make for changed files makes updating the browser automatic and somewhat instant.

The Makefile

BLOGPOSTS=$(wildcard blog/*/*/*/*/*.markdown)
HTML=$(patsubst %.markdown,.statocles/build/%.html,$(BLOGPOSTS))

all: $(HTML)

%.html: $(patsubst $(patsubst .statocles/build/,,$<),.html,.markdown)
    statocles build

The main "problem" now is opening the loong URL in the browser manually. Having make also work with processes ( via /proc/(pid)/cmdline ) is something for a later day.

It would be great if statocles supported building a single page, but so far, I've resolved to rebuilding the whole site every time.

Last Monday I did the Perl Developer Release of Perl 5.43.7. As usual, I worked from the Release Managers Guide . Everything worked well, even if everything was cutting it a bit close. My video setup on the desktop was not suited for streaming anymore, so I had to do a stream consisting only of the console window and me talking over it, and no floating head of me available.

What worked well

The Twitch chat was the most active that I witnessed when streaming a Perl release. We chatted about organizing Perl conferences and also the Perl release process. One realization for me was that the RMG process is mostly there to exercise the Perl build machinery and testing that the generated tarball does not have deficiencies. This means that testing that Perl can build through Configure is important, but testing different Perl configurations like ithreads or userelocatableinc is not that important.

The dashboard for tracking my progress through the release worked well up to the release. I had modified it in the weeks leading up to the release to not only show the human step description but also to show the command line steps that should be undertaken, where applicable. I see this as a first step in automating these steps where possible and sensible.

What didn't work out

The dashboard can use some improvements:

• The script did not cope well with the events after the release when the repo version number was bumped from 5.43.7 to 5.43.8. This part needs to be investigated but is easy to replicate by simply launching the dashboard with a version number before the current version number.

• The script could highlight the current position in the sequence better. For console output this would likely mean inverting the line where the next applicable step is, but this means moving the output from Text::Table to a custom table generation or post-patching the string from Text::Table with the appropriate console commands.

• The script should generate HTML and terminal output at the same time. Having output visible in a browser feels less retro but makes things like publishing the progress elsewhere easier.

• The script should have a feature to simply output the next step. This could be integrated into the shell prompt to give a guided message in the console window. Maybe the console output and the HTML output should be done as files when in "interactive" mode?

Improvements to the Perl Release Process

• More parallelism - the current release manager guide uses make test in many places. This runs the test suite in serial mode, which takes on my machine about 10 minutes. Running the test suite in parallel takes about 4-5 minutes. This is implemented using the make test_harness command. Whether Perl should move the default of parallel testing to make testfrom make test_harness is debatable. Most likely everybody who cares about speed already runs the test suite in parallel.

• Remove sequences of shell commands - comparing the file names between the previous and current Perl version is done using a sequence of shell commands involving sort, diff`. I have a patch that adds a small tool to do that within Perl (mostly powered by Algorithm::Diff ).