(Assuming the PM is sooner alive than dead & I can still read/write here), I noticed some cpan modules have a label (the _: to be specific, mostly in modules by SPROUT, but also perl itself if example is needed) at the end of a sub; it's deparsed into () i.e. empty list. Why? Is this behaviour documented anywhere?

I've got an observation/question to make that isn't about the Perl language but instead is about our Perl infrastructure. Hope it's ok to put it at SoPW anyhow.

I went to look at what's been released recently, at metacpan.org, and found Image::ExifTool v13.35, released a day ago. On my CygwinPerl installation I have cpanplus set up to install CPAN modules. In the cpanp shell I typed i Image::ExifTool and cpanplus found v13.30, not v13.35! Is this a known thing? How would metacpan have a newer release than cpan.org? Aren't packages uploaded to cpan.org first, then somehow appear on metacpan.org?

What I did about it was this. I first ran x --update_source, which did not cause the newer Image-ExifTool to show up. Then, I uninstalled v13.30 (probably an unnecessary step). Then I downloaded the ExifTool .tar.gz package from metacpan and unrolled the archive, typed i <path to archive dir> and hit enter. Pleasingly, that worked (cpanplus does have some good features).

    — Soren

Sep 07, 2025 at 22:09 UTC

Not a Perl question per-se: This code creates an Excel file containing a column chart with one series of 36 points. The color of each column in this series is the same color.

My question is: how can one use Perl to assign the fill color '#ED7D31' to the first 12 columns, '#4472C4' to the following 12 columns, and '#00B050' to the final 12 columns?

In case it matters: perl 5.24 running on Windows 7.

#!  perl -w

use strict;
use warnings;

use Excel::Writer::XLSX;

my $workbook     = Excel::Writer::XLSX->new( 'test.xlsx' );
my $worksheet    = $workbook->add_worksheet( 'C' );

my $a_fill_color = $workbook->add_format( bg_color => '#ED7D31' );
my $b_fill_color = $workbook->add_format( bg_color => '#4472C4' );
my $c_fill_color = $workbook->add_format( bg_color => '#00B050' );

my $headings = [ 'FY 2024 Big-3', 'Total' ];
my $data     = [
   [ 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'Jan', 'Feb', 'Mar', 'A
+pr', 'May', 'Jun',
     'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'Jan', 'Feb', 'Mar', 'A
+pr', 'May', 'Jun',
     'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'Jan', 'Feb', 'Mar', 'A
+pr', 'May', 'Jun',
   ],
   [ 15, 18, 17, 16, 13, 12, 20, 16, 35, 10, 22, 21,
     10, 22, 20, 28, 24, 28, 23, 34, 39, 27, 56, 35,
      5,  7,  7,  2,  7,  5,  7,  3,  6, 12,  3,  2,
   ],
];
$worksheet->write( 'A1', $headings );
$worksheet->write( 'A2', $data );

my $chart = $workbook->add_chart(
  type     => 'column',
  subtype  => 'clustered',
  embedded => 1,
  name     => 'CHART03' );
$chart->add_series(
  name        => '=C!$B$1',
  categories  => '=C!$A$2:$A$37',
  values      => '=C!$B$2:$B$37',
  data_labels => { value => 1 },
  gap         =>  40,
);

$chart->set_title ( name     => 'FY 2024 Big-3' );
$chart->set_legend( position => 'none' );
$chart->set_style( 10 );
$chart->set_x_axis( name => '', minor_unit => 1, major_unit => 1 );
$chart->set_y_axis( name => '' );
$chart->set_size(width => 1200, height => 600);
$worksheet->insert_chart( '=C!$D$1', $chart, 10, 10 );
$workbook->close() or die "XLSX: Error closing file: $!";
exit(0);
[download]

I hope I can get connectivity to Perlmonks long enough to post this write-up. It's been just terrible. Ok. We'll hope for better days ahead.

I used Module::Starter to create the accessory files and build infrastructure for a module I've been working on for some time now. I tried installing from CPAN on a Linux box using cpan (the script) and strangely enough, although I had cpan set up to prefer EU::MM (Makefile.PL) over M::B, it used M::B. This was a fortunate error because there was mistaken encoding on the Build.PL file (my name with an umlaut over the "o" gave perl indigestion). And it was also fortunate because the template-created Build.PL had an entry for release_status that terminated the creation of ./Build with extreme prejudice:

$ perl Build.PL --installdirs=site
Illegal value 'experimental' for release_status

I have now probably explained enough of the circumstances to ask my question: is this a problem other people have noticed? I just deleted the entire line and then Build.PL ran to completion. Was there a change of heart on the part of M::B authors, regarding a release_status of "experimental"? or was the inclusion of this by Module::Starter a mistake? Guesses, ideas, knowledge? TIA. Oh, and do download / install Env::AsYaml from CPAN.

    — Sören :-)

Sep 02, 2025 at 18:24 UTC

I've spent months trying to install Image::Magick for my Strawberry on Windows-10: cpan install |Image::magick fails with "Magick.xs:56:10: fatal error: MagickCore/MagickCore.h: No such file or directory"

WhatI've tried: From the official Magick site, I downloaded and ran every .exe "installer". All succeeded until Finish, but they seem to only unpack some files and not to interact with the Perl installation. Perl still fails to use Image::Magick; I also noted that some of the "installers" unpack a .ppd file in their installation directory. But   ppm install Image-Magick.ppd in that directory fails with "but it is not intended for this build of Perl (MSWin32-x64-multi-thread-5.40)".

$spinner->count('benchLoop', __FILE__, __LINE__);

While I have this on line 93 of the physical file, Perl __LINE__ is reporting line 95. THere is nothing else on that line, there is no modification of the value in the sub handling it. __FILE__ is reported correctly.

Any idea why __LINE__ would be consistently off by 2?

The Perl Regexp Engine of course. I have been working hard on working out how to formulate a regular expression with a negative lookbehind and I cannot get it right. What I have right now is this: /^(?<!XDG_) [_A-Z0-9]+ _PATH$/x

I'll explain in english what I need. There will be desired matches with strings like PKG_CONFIG_PATH but I must not match XDG_SEAT_PATH or XDG_SESSION_PATH. Naturally, it is not as simple as avoiding any match with a string beginning with XDG_ because I want to match XDG_DATA_DIRS, for example. (Yes, these are well-recognized environment variables).

This works for getting only PATH: /^(?<!XDG_)PATH$/, so I can see that the Engine does understand the lookbehind. Any suggestions will be appreciated!

Given the recent licensing hokey-cokey by Redis I'm inclined to use Valkey in preference. However, there isn't any explicit mention of Valkey on CPAN that I could find. This isn't a huge surprise given how relatively new it is but nor does it give me confidence about support for it now or in the future.

So, does anyone have experience with using any of the various Redis modules with Valkey as the server? Is it as much of a drop-in replacement as I would hope?

I have XML that I manipulate and save.

Among other tags, I may have a <body> tag with simple text in it. XML::Smart insists on encoding that in this way:

<body dt:dt="binary.base64">

which causes an error since dt is not defined and I am not interested in defining it.

Is there a way to tell XML::Smart to NOT encode that tag.

XML::Smart proves to be to smart in this case

Thank you

ZA

While researching for a encoding problem, I wanted to retrieve the value of the current windows ANSI code page.
This can be done e.g. with Powershell like this:

Get-WinSystemLocale | Select-Object -ExpandProperty TextInfo | Select-Object -Property ANSICodePage
which gives the following output:

ANSICodePage
------------
        1252
[download]

Instead of calling PowerShell and parsing its output, I tried to use Perl's own facilities.

perl -MWin32 -we "print Win32::GetACP()"
which however gave the following output:

65001
indicating an UTF8 ANSI code page instead of Western-Europe one (cp1252) from above.

I am using Strawberry Perl 5.38.0 64-bit with its own W32 module running on Windows 11.

Is this behavior understood and known? Did I miss something or could it be a bug?
Thanks very much for your attention!