If you have a Perl-related news item you'd like to share, you may post it in the Perl Newssection.
Please try to avoid duplicating news; but pointers (with summaries) to important stories on other sites are acceptable here.
Update for thost of you suggesting tech skills aren't needed. I have never written a line of C. I have no idea what a makefile does. Spreadsheets running VBA or 123 macros are my comfort zone. And yes, I'm still comfortable with the /X versions of 123 macros.
Not sure that anyone here is particularly interested in this, but I'll mention it anyway that, as of the release (on 20.01.2021) of perl-5.33.6, it's possible to build perl on MS Windows with an NV type of __float128.
And it has become a little easier in 5.33.7 with a change to GNUmakefile that removed the need for a somewhat cumbersome configuration argument.
With the release of perl-5.22.0, the NV type of long double was enabled on Windows, and now we finally get the additional option of having the __float128 NV type.
All of this does, of course, rely on using mingw-w64 ports of gcc to build your Windows perl.
I think that many of us, accustomed to simply using Strawberry Perl, don't realize just how easy it is to build perl from source on Windows.
Strawberry Perl, itself, does provide us with the toolchain that's capable of building any recent version of perl (including blead releases) from source.
The latest blead source can be obtained with:
And that's it - in C:\bleadstraw I now have a Windows perl that has __float128 as its NV.
You may want to alter INST_TOP, and you probably need to alter CCHOME which should specify the full path to gcc's bin directory.
NOTE that CCHOME does not include "\bin". (Failure to get CCHOME right will cause some test failures, but will not affect the perl that has been built.)
If you want to do a 'long double' build instead, you would just remove the 2 gmake arguments that include the string "QUADMATH", and insert the USE_LONG_DOUBLE=define argument.
If you don't request either a 'long double' or a 'quadmath' build, then the nvtype will be 'double'.
If you're using a 32-bit compiler, you'll also need to insert the argument WIN64=undef, and you might also want to add the argument USE_64_BIT_INT=define if you want 64-bit integers and pointers.
With 64-bit compilers, perl's integer and pointer will inevitably be 64-bit.
I think that covers the most commonly exercised options ... but you'll find additional options laid out in the GNUmakefile.
I don't know if it's a general issue, but (on 64-bit builds only) there's usually a couple of test scripts in cpan/IO-Compress/t that hang for me .
Update: This issue is a long-standing one for me, and is not limited to just the "quadmath" builds.
It's generally (but not always) the same test scripts that hang, and it has been happening for a few years. In perl-5.33.7, I'm finding that the problem has moved to a different couple of files.
The Strawberry project have never, to my knowledge, complained about such an issue - so I'm hoping that it's just something in my particular environment.
It would be nice to find out if it is "just me".
It's quite annoying - I have to kill these hangs using process explorer in order to get the test suite to run to completion. (Killing them with Ctrl-C kills the entire 'gmake test' process.)
These test scripts have always passed when run outside of the testing harness, and they've also passed even when I've run make test in the cpan/IO-Compress folder.
There's also the same thing happening in the cpan/IPC-Cmd tests with t/01_IPC-Cmd.t.
If I can find any evidence that it's also an issue for others then I'll try to get it fixed.
As we're all aware, news of RT's imminent shutdown left many rattled. Luckily, the code is now available on GitHub. Some discussion is happening on perl.perl5.porters and can be followed here. The disclaimer is that the code is 7 years old and may be hard to run.
Personally I applaud this move, and I think it should be tractable to run it in a container or somesuch.
"Excuse me for butting in, but I'm interrupt-driven..."
Further to discussions yesterday in the chatterbox regarding issues connecting to perl.com the answer is that the domain has apparently been hijacked. This will probably take some time to resolve so be careful of links to perl.com in the meantime.
"But think about this. If we switched Perl off today, there would be a problem. A huge problem! We know that Perl is the glue that holds a lot of the IT world together. The Perl Foundation wants to support the community to make sure that the IT world doesnít fall apart and supporting people learning Perl is a big element of that.
We have developed a survey that needs just a few minutes of your time, to tell us what you would like, or need, to support your move into, or progress within, the Perl language."