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 ).
End result
Why
For my video conference displays, I'd like to have a (subtly) animated
background. Not too animated as to be distracting, but if you look close
enough, you should be able to see that the background changes over time.
SVG animations
Instead of getting into Blender or ShaderToy,
I decided to go with simple animated SVG. SVG has <animate> elements
that allow me to specify how a single DOM node should animate over time.
In the end the background is just some Bezier curves morphing into another,
and some CPU-gobbling filter effects for blur.
My goal is to create the illusion of waves travelling across the image by
animating each path into the next one and having all these animations play
in a loop. Here, only the second line is animated to animate into the third:
Workflow
I do the basic SVG editing in Inkscape, and
luckily it keeps existing <animate> elements alive even if it does not
know about them. Working in Inkscape makes it easy to get the layout of lines
and trace existing images without having to guess the coordinates.
Inkscape does not display the animations, but that's fine, I add these later
in a post-processing step.
<animate> tag
If all lines slowly animate into their next neighbour, this will create the
intended illusion of lines flowing across the screen.
The <animate> element is a good fit for my animation goal, with a small snag.
There seems to be no easy way to tell SVG "animate from shape with id foo
to id bar in 5 seconds". I can only describe "animate the shape
of the element from this (explicit) path into another (explicit) path":
<path
d="M 9.0454762,0 C -7.6337807,60.410349 -84.36489,310.51971 137.97241,386.67508..."
id="line_009"
><animate
attributeName="d"
dur="20s"
repeatCount="indefinite"
keyTimes="0; 1"
values="M 9.0454762,0 C -7.6337807,60.410349 -84.36489,310.51971 137.97241,386.67508...
M parameters-of-next-line />
</path>
This animation between two paths is still workable, but I have to copy the path
parameters into the animation parameters of each line and its preceding
animation element whenever I change the shape of a line.
Perl
To update the paths in the animation elements, I wrote me a short Perl script
that reads the XML, finds all lines that I want to animate, sorts
them by X offset and adds an animation to them that animates the line into
the next line:
my $dom = XML::LibXML->load_xml( location => 'lines.svg' );
my @lines = $dom->findnodes('//svg:*[@id="layer1"]//svg:path[@d]');
# Sort the lines
my %line_offset = map {
0+$_ => $_->getAttribute( 'd' ) =~ /^\s*M\s*(-?[\d.]+),/i
} @lines;
@lines = sort {
$line_offset{ 0+$a }
<=>
$line_offset{ 0+$b }
} @lines;
# Add animations
for my $i (0..$#lines-1) {
my $line = $lines[ $i ];
my $next = $lines[ $i+1 ];
# Now, remove all animation nodes and other children:
$line->removeChildNodes();
my $ani = $dom->createElement('animate');
$ani->setAttribute( 'attributeName' => 'd' );
$ani->setAttribute( 'dur' => '20s' );
$ani->setAttribute( 'repeatCount' => 'indefinite' );
$ani->setAttribute( 'keyTimes' => '0; 1' );
$ani->setAttribute( 'values' =>
sprintf "%s; %s", $line->getAttribute('d'), $next->getAttribute('d') );
$line->appendChild($ani);
}
open my $output, '>:raw', 'lines-animated.svg';
print $output $dom->toString;
Live reloading
I really prefer interactive tools when doing graphics, so to get away from
manually reloading the SVG animation in the browser, I wanted live reloading
of the browser tab whenever the file changed. Adding SVG support was a fairly
simple
addition to App::Mojo::AssetReloader,
but work on that is not finished, as the animation resets on each reload.
I need to think about how to preserve the current animation time. Likely
this is "easily" done by saving the time from .getCurrentTime() and restoring
it after reload via .setCurrentTime(). But then I also need to figure out
how/when I want to reset the animation time to the start instead of keeping it.
Further ideas: WebMIDI integration / knob integration
Integrating the whole thing with WebMIDI would be fun for an all-in-one thing.
Twisting a knob is so much more fun for adjusting animation parameters than
manually editing a number via the keypad.
I have MIDI and non-MIDI hardware though, so
going a custom route is also interesting.
My upgrade of my home server from Debian 11 ("bullseye") to
Debian 12 ("bookworm") went
almost without a hitch. Yesterday I realized that the Postgres data hadn't
been migrated from the old DB to the Debian package of Postgres 15. But
luckily, the good Pg people provide a Debian
package of 9.6 (the version which held my data) for Debian 12.
I could install that one, fire it up, dump all data into SQL, fire up Pg 15
from Debian and import it there. Now I run such an SQL dump daily, just to have
the data available as SQL files.
I wonder if it would be worthwhile for Perl to provide prebuilt
binaries/packages of old Perl versions for current OSes, but then, there are so
many build options that it's not worth the effort in general.
The only use case I see would be to provide an emergency Perl when your
dist-upgrade nuked the system Perl [^1] , but some custom XS modules
or XS modules installed via cpan instead of the package manager
relied on that version. This would reduce the number of build options,
but I'm still not sure if that actually helps anybody.
Maybe simply taking the (Debian) build files for old packages/distributions and
running them for new distributions, with a prefix of /opt/perl5-xx could
already help. People would still need to edit the path of their scripts to
bring things back up.
This only makes sense when also rebuilding all the old CPAN modules
for the new OS version, except under /opt. That's a lot of effort for
little to no gain, except when people really need it.
[^1] : well, not nuked, but replaced with a newer major version that is
not binary compatible