• TriD::GL now more resilient and exceptions don't leave GL broken
• Bugfixes including to NiceSlice
• demo 3d now shows off a 3D Earth (with accurate shading), and also a 3D molecule-like graph evolving over time
• The pdl struct now has room for a single value (or if not complex long double, several values of smaller datatypes), avoiding extra memory-management for small ndarrays – but you don’t need to recompile installed modules

The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and ask questions, or just watch the GitHub messages flow by.

Please give the new PDL a try and report problems.

• Much broader testing of the wrapper functions e.g. msolve, with many fixes
• A number of memory-management and other bugs are fixed, helped by the above
• Those wrapper functions now work in a natural way with “native complex” numbers, so long as you don’t load PDL::Complex at all – they still work with PDL::Complex if you do load it

I’m strongly considering actually removing PDL::Complex support from PDL::LinearAlgebra, because it does add a fair bit of quite awkward code. Please express an opinion if you have one! It won’t be immediate because I’d want to lift out some of Greg’s nice patching of PDL::Complex into main-PDL’s PDL::Complex, and I haven’t done that yet.

Future ideas:

• Use Devel::CheckLib to ensure LAPACK is installed
• Be more available on Windows by using a still-to-be-created Alien::LAPACK
• Use ExtUtils::F77 to better detect trailing “_” on routine names, and use the technique from PDL::Slatec/Minuit to wrap that
• Make a somewhat-visual demo of this linear algebra stuff using the new plugin-based demo system – ideas welcome!

As usual, please give the new release a try and report problems.

Dear fellow Perl developers,

zlib, the compression library (also known as libz, deflate, compress on various systems) has a major flaw. While the bug is 17 years old, it only got attention in the last few days and weeks.

It even has a backdated CVE, because the bug was discovered years ago, but not fixed: CVE-2018-25032

See also: https://zlib.net/

It is known that this can cause at least denial-of-service attacks, but RCE (remote code execution) is not entirely out of the cards to my knowledge.

I have done a casual grep through my local CPAN mirror (yay for local mirrors!), which has given me a list of potentially vulnerable modules. There are over 90 of them. Yes, there are probably a few false negatives and a few false positive, as i didn't have time to go over each distribution in detail.

Please check your CPAN distributions for any use of zlib.c, libz.c, deflate.c, compress.c and similar variants and update as necessary. If at all possible, i would also recommend to switch to either the zlib provided by the operating system or at least coordinate with other CPAN authors to reduce the number of static copies of the zlib libraries spread all over CPAN modules.

The basic problem with distributing your own copy of a library like that is simple: Instead of it getting automatically updated with security fixes by the operating system or distribution vendor, it is up to YOU to track the library and provide security updates for your CPAN distributions. And you have to get the users to somehow not only update the operating system, you also have to get them to update their installed perl modules. While providing your own copies of C libraries is convenient, provides safety against incompatibilities with locally installed libraries and so on, in case of a security problem this can place a lot of extra burdens on the end user of your code. They suddenly have to go through every installed perl module, plus all the other non-perl programs to make their system secure again.

Perl isn't the only software environment that has this problem. Many other things also maintain local copies of these kinds of "simple but essential" libraries in their source code control. The list of potentially vulnerable programs is quite impressive. So far, i've seen mention (but have not confirmed it myself) of Chromium, Firefox, ImageMagick, Gimp, VLC, the Linux kernel among quite a few other programs. This stems from the fact the zlib/the deflate algorithm is used in, for example, the HTTP protocol and PNG image files.

Because the number of modules NOT using the zlib library installed with the operating system but instead using a static/local copy of the C-Files, a security problem like this (or worse) can take a long time to fix. It is up to all of us to work together and reduce the number of copies of potentially vulnerable code.

Thanks in advance for your help in solving this security problem.

Sincerely,

Rene "cavac" Schickbauer

For several years, I spent much time writing code for the Raspberry Pi, including hardware level register C code so that we can use various Integrated Circuit chips and sensors with Perl.

A couple of years ago, I acquired much larger and much more expensive toy, an all-wheel drive, full auto-pilot Tesla Model-X SUV, so of course, I want to write Perl code to access and manipulate it.

In the ensuing two years, I developed several microcontroller-based devices for the car, including one that knows where the car is, and its battery charge and state, and dispslays this information via an LED light strip and an OLED screen inside of my garage, along with an audible alarm that sounds for 1/8th of a second every three seconds if the battery is below a certain threshold so I don't forget to plug the charger in.

The microcontroller speaks to a Raspberry Pi who's job it is to fetch data from the Tesla API for my car, and to present that data to the microconroller, over Wifi. The software on the Pi is of course written in Perl, but because I couldn't figure out how to write the Tesla API authentication mechanism in Perl, I used Tim Dorssers TeslaPy Python library, and wrapped it for those calls.

Not anymore! We can now talk to the Tesla API via Perl!

I've officially released Tesla::Vehicle, which inherits from my other new related distribution, Tesla::API.

Upon first attempt to fetch data from Tesla, we will generate a URL that you must browse through to in a browser, authenticate into your Tesla account, and then paste back the ensuing URL you are redirected to into the console. After that, all access tokens are automatically used and updated when needed. My software never has any access or knowledge of your Tesla account credentials, which is the way I wanted this designed.

Thereafter, it's clear sailing!

The documentation is pretty elaborate about what the software can do so please check it out. For Tesla::Vehicle, there are methods to access aggregate data, sections of the aggregate data, and for several specific attributes that I use myself, I've added methods for them directly. More will be added as time goes on.

Features:

• Built-in initial access token generation code with prompts of instructions
• Automatic access token renewal
• Single method (api()) to access data from endpoints that don't yet have a direct method
• Built in modifiable data cache (set to 2 second timeout by default) to reduce calls to Tesla for data already retrieved (cache can be disabled)
• Consistent data return values... for data aggregate methods, all data is returned as a hash reference
• Near feature complete; most data has at least an aggregate fetch method, many individual attributes have accessor methods
• Ability to wake the car from sleep (wake()). For calls that require the car to be awake, you can set auto_wake and we'll wake the car ourselves (disabled by default)
• Many Tesla API calls require a vehicle ID sent in. We do our best to get this ourselves, otherwise it can be sent into new() or id()

Todo: The main one is adding methods that allow control of the functionality of the car. The only one implemented thus far is wake(). I'll also be adding more direct attribute retrieval methods. For now, use the aggregate methods and pull the data out of the return values yourself. There are also a few minor issues, primarily related to the handling of Tesla API timeouts.

How 'bout some code and output:

use warnings;
use strict;

use Tesla::Vehicle;

my $car = Tesla::Vehicle->new(auto_wake => 1);

printf(
    "My Tesla account has my car registered with the name '%s'.\n",
    $car->name
);

printf(
    "My car is in gear %s and is currently going %d MPH and my odomete
+r is %d\n",
    $car->gear,
    $car->speed,
    $car->odometer
);

printf(
    "My latitude is %f, longitide is %f, my heading is %d degrees and 
+its using %.2f kWh/mile\n",
    $car->latitude,
    $car->longitude,
    $car->heading,
    $car->power
);

printf(
    "My dashcam is %s, sentry mode is %s and I %s currently near my ve
+hicle\n",
    $car->dashcam,
    $car->sentry_mode ? 'enabled' : 'disabled',
    $car->user_present ? 'am' : 'am not'
);

printf(
    "My battery is at %d%%, and is %s charging at %.2f volts pulling %
+.2f Amps\n",
    $car->battery_level,
    $car->charging_state ? 'currently' : 'not',
    $car->charger_voltage,
    $car->charge_actual_current
);

if ($car->battery_level >= $car->charge_limit_soc) {
    print "The charger is connected but disabled due to set maximum ch
+arge level reached\n";
}

printf(
    "My steering wheel warmer is %s, passenger seat warmer is %s, and 
+Bio Weapon mode is %s\n",
    $car->heater_steering_wheel ? 'on' : 'off',
    $car->heater_seat_passenger ? 'on' : 'off',
    $car->bioweapon_mode ? 'on' : 'off'
);

printf(
    "The temperature inside the car is %dC and outside it's %dC, and c
+limate control is %s\n",
    $car->temperature_inside,
    $car->temperature_outside,
    $car->is_climate_on ? 'on' : 'off'
);
[download]

Output:

My Tesla account has my car registered with the name 'Dream machine'.
My car is in gear P and is currently going 0 MPH and my odometer is 49
+066
My latitude is XX.XXXXXX, longitide is -XXX.XXXXXX, my heading is 229 
+degrees and its using 0.00 kWh/mile
My dashcam is Unavailable, sentry mode is disabled and I am not curren
+tly near my vehicle
My battery is at 94%, and is currently charging at 0.00 volts pulling 
+0.00 Amps
The charger is connected but disabled due to set maximum charge level 
+reached
My steering wheel warmer is off, passenger seat warmer is off, and Bio
+ Weapon mode is off
The temperature inside the car is 17C and outside it's 13C, and climat
+e control is off
[download]

• Performance improvements for Primitive::matmult
• Performance fix under Perl ithreading (thanks marioroy)
• Many bugfixes
• PDL::Demos now a plugin system, so pdl> demo will only list available ones and anyone can make one
• perldl now handles Ctrl-C properly and doesn’t lose history with OpenGL
• TriD demos now work correctly and look better - try them with demo 3d

As usual, please give the new PDL a try and report any problems.

It now lives on GitHub under the Perl-GPU organisation. This is intended to be a home for all Perl libraries that help you use your GPU.

Come join #pogl on irc.perl.org and be part of the conversation!

• pthreads should now be available on BSD systems
• Support for signed and unsigned versions of all integers up to 64-bit, and real and complex long double
• qsortvec* now work with badvalues as documented
• wfits now handles RICE compression
• NiceSlice now works correctly with comments and strings
• rmpeg added, rpic and wpic work with multi-image PNM files
• xvals etc return at least a double, avoiding problems with e.g. byte ndarrays
• Improvements to $MACRONAME() handling including that arguments can now contain (balanced) brackets
• The PROJ.4 interface has been updated to use the PROJ v6+ interface, finally
• A zeroes() regression from 2.057_01 where it ignored the type of an input PDL has been fixed

The last dev-release showed FreeBSD 13 (the latest) failing to find “csinl” (complex long double sin). That is mandated by C99, so we won’t be doing configure probes for it. Please update your libm if this causes a problem, and your compiler (including clang <12.0.5) if it crashes on pdlcore.c.

Future plans, in something like intended order:

• “loop fusion” techniques to maximise locality of computation, minimising data’s trips through the “straw” between CPU and main RAM
• finish the independent C interface for making PDL usable from e.g. Python
• use OpenCL or other means to also utilise GPUs if available

The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and ask questions, or just watch the GitHub messages flow by.

As usual, please give the new PDL a try and report problems.

TL;DR - your CPAN client may be vulnerable to modified tarballs from untrusted mirrors (and will have been that way forever). Upgrade, force https, force signature verification and ensure it uses a trusted mirror by default.

See the hackeriet.no post listing the vulnerabilities and this in-depth explanation of what is vulnerable and what to do about it.

Very sad to learn today of the recent passing of the lovely David H Adler Esq.

Though I never met dha in person, I remember his delightful sense of humour from the London.pm mailing list years ago. I thought it strange that DHA was in New York, while I was in Sydney, yet we both relished the quirky sense of humour of the super-active London.pm mailing list back then.

DHA's love of the fun side of Perl culture is also revealed in his only CPAN module: Semi::Semicolons

The RFC process is continuing at the Corinna github repo.

Damian Conway has made a proposal for simplifying the syntax and the Corinna team is generally receptive, so we've adopted it (minus some side discussions about class data).

I call this KIM. KIM stands for "Keyword, Identifier, Modifier" and we're standardizing the syntax around that (there are open questions about method modifiers). As a result, Corinna is now reduced to four keywords, class, role, slot, and method. Modifying the behavior is done via attributes. This greatly simplifies the overall idea. Thus, instead of this:

class Foo isa Bar does This {
    ...
}
[download]

class Foo :isa(Bar) :does(This) {
    ...
}
[download]

Other major changes can be read about in our Major Changes document.

As an aside, you can now clone and install the Corinna code. It uses Object::Pad under the hood, of course. There are tests and you can get a rough idea of what new code will look like with Corinna.

I know this it taking a while and I'm sorry for that, but we're being careful to try to get it right. Plus, I'm slaughtered with work currently. Seems all Perl devs who want work have it, so we're having trouble finding senior Perl devs who want remote work (oh, and we're looking for Typescript and Vue.js, if you know anyone).

Note: the RFC documents are not final. We pretty much have the minimum viable product (MVP) semantics nailed, but there are tricky issues regarding the grammar. Reading the issues in github will help if you're interested in helping.

The Perl Foundation (TPF) is looking for volunteers to run a Perl dev room (basically a talk track) at FOSDEM (online on 5-6 February 2022).

From my own experience, I know that it is hard to run a set of presentations and at the same time give a talk yourself. So having a set of volunteers to shepherd the speakers is very welcome!

See their news post for further information.

• pthreading can be over non-divisible number of threads
• With an opt-in, .pd files generate one C file per function, allowing parallel build
• PP only updates files that have changed, for faster rebuilds during development especially with the above
• allow any pointer including “pdl *” as OtherPars
• OtherPars are now stored in a separate struct, so no restriction on names
• all PDL operations now have a C function interface called pdl_(name)_run
• far fewer “SV *” OtherPars, instead they just take e.g. “PDL_Index name[]” and PP and XS make things happen (a “name_count” variable is magically added)

It is a known problem that older versions of clang/LLVM (at least 10.0.1 and 12.0.0, though not 12.0.5) crash when compiling the latest PDL. If this happens for you, please upgrade your clang/LLVM.

Future plans, in no particular order:

• enabling pthreading by default rather than opting-in with an environment variable, detecting how many cores you have automatically
• finish the independent C interface for making PDL usable from e.g. Python
• more pervasive use of e.g. BLAS/LAPACK routines if available
• use OpenCL to also utilise GPUs if available

The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and ask questions, or just watch the GitHub messages flow by.

Please give the new PDL a try and report problems.

I've released version 1.36 of berrybrew, the Perlbrew for Windows. I've also reached out to see how I can become part of the Strawberry Perl team to get back on track with the release of new Strawberry Perls.

If you have any information on the release procedure for Strawberry, or know anyone on that team I might be able to contact to get things moving forward again, please let me know.

This release contains one significant new feature, the ability to use Powershell as the shell when opening or using a Perl. In the UI, when you "Open" your current Perl, or "use" any Perl you have installed, if the "Use Powershell" option is checked, instead of a cmd.exe shell, you'll be presented with a Powershell one (same applies for the command line berrybrew use $version). See image.

The other changes in this release enhance the unit testing infrastructure, and the tests themselves.

Other notable changes since my last blog post:

• The berrybrew associate command now has an alias of assoc for fewer keystrokes
• Better exception handling in several cases
• Documentation clarifications
• Removed the upgrade command. It's now recommended to use the Installer to manage upgrades
• Fix issue when using berrybrew to manage file associations where arguments passed to perl were being handled incorrectly
• Unit test infrastructure enhancements

As always, feedback, feature requests and especially bug notices are very welcome, whether here on Perlmonks or at my issue tracker.