Encode is a well known core module in Perl with support for encoding and decoding text from almost any character encoding you can think of. But it's also an old module with a large amount of historical cruft.
With inspiration from #perl on freenode IRC, Encode::Simple is an attempt to at least improve on its interface and usability issues. Rather than an awkward and unintuitive bitmask and the option of clobbering the input data, Encode::Simple exports straightforward encode and decode functions that simply return the encoded or decoded result or throw an exception. For the cases where you want to allow invalid characters or byte sequences, encode_lax and decode_lax are provided.
Encode itself supports many more operations such as partial, mixed, and in-place encoding or decoding, where its options may make more sense, but these uncommon use cases are not supported by Encode::Simple.
As a final note, if you are working strictly with UTF-8, I suggest avoiding Encode entirely and using the excellent Unicode::UTF8, or the related filehandle layer :utf8_strict, for fast and correct encoding and decoding.
Today in the Dist-Pen I am going to have another crack at a different Versioning technique.
In my last post I had a look at using Dist::Zilla::Plugin::PkgVersion and I found it very useful but in the end I ran into a problem with putting all my Database::Accessor classes into my Accessor.pm file.
I wanted to see if I could have differing versions within the same file and the short answer was 'No' but the long answer was 'Yes'. I did play about with 'Dist::Zilla::Role::PPI' to see if I could adjust it to what I wanted it to do.
Well after a little while of poking about I did manage to get it to work the way I wanted but it was a hard-coded Kludge which I think could evolve into a patch. Now before I started to go down that rabbit hole I noticed there was an IRC for Dist::Zilla so I asked a quick question there before I created the patch.
2nd Round talk submissions are open until Sunday! We hope you're planning to submit.
Somebody once said, that the power of a programming language is not what it lets you do, but what it lets you do easily. Might be Larry himself who said it, not sure, but I heard it at the London Perl Workshop. I started learning Perl from an old second hand book I found in a charity shop a few years ago. I can't say I am any good at it. While previously I could find lots of resources available, these are increasingly harder to find, more outdated, and less able to address modern use cases. Some folk even suggest it is terminal decline. It would be a pity. It is a powerful language, and using it for me has given me a daily discovery for some feature that I didn't know, and exposed me to a large number of clever folk who can bring a different angle to a problem you have struggling with. To my mind it reflects the versatility of a language that has more than one way to to anything.
Read this article on Rakudo.Party
Recently, I came across a somewhat-frantic comment on StackOverflow that describes a 2017.01 change to the type of return value of
"you just can't be sure what
~~ returns" Ouch. […]
.list the result of a
sort is presumably an appropriate work around. But, still, ouch. I don't know
of a blog post or whatever that explains how P6 approaches changes to the
language; and to roast; and to Rakudo. Perhaps someone will write one that also
explains how this aspect of 2017.01 was conceived, considered and applied;
what was right about the change; what was wrong; etc.
Today, I decided to answer that call to write a blog post and reply to all of the
questions posed in the comment, as well as explain how it's possible that such an "ouch"
change made it in.
In the Dist-Pen today I am looking at another plugin to help with my many versioning woes.
In my last post I had a look at a Dist::Zilla plugin that helped me out with versioning my distributions. Today I am going to see if there is a plugin that will help me out with my Module versions as well. So a quick look about and I see we have a few options so I will start with the most likely candidate 'Dist::Zilla::Plugin::PkgVersion'
Like all the Dist::Zilla plugins I have used so for this one is quite simple; Just add
in my '.ini' Now there are a number of attributes I can play with but before I do that lets see what I have I my Database::Accessor classes;
$Database::Accessor::VERSION = "0.01";
Today in the Dist-Pen I am going to try and get all my version numbers in a row.
Doing some more investigation on how Dist::Zilla will solve another of my distro pains and that is Versioning of my package. I did learn a lesson on version some years again when I though I was doing someone a favor I did a quickie release of DBD::Oracle where the release tar ball didn't match up with the release name.
Go a whole bunch of heat over that breaking a few things that other people where doing. I guess going from 1.23 to 1.24a can really spoil some peoples day, who new? So since that time I have always been very weary about visioning my code.
There is a nice little plugin for Dist::Zilla called '
' which is suppose to fix this sort of thing for you. Up till now I just had
version = 0.01
Following is the p5p (Perl 5 Porters) mailing list summary for the past week.
Just a quickie post here at the Dist-Pen today!
One thing that has been pointed out to me in the past it that I neglected to includ a license file on some of my CPAN distros. I have even forgotten to include a copyright notice, not a mistake one should really be making.
Dist::Zilla already has a rule that compels me to add in a license, as we saw that in this post and I think with only a few quick changes to my '.ini' file I will be able to get the license file in there as well.
In my '.ini' I just enure I have the correct license set up, right now I have
license = Perl_5
I think I will change that over to the one on the more modern GPL licenses so all I need to go is search to see which ones are available from the CPAN page
I see that
So today in the Dist-pen I am going to add in a few more plugins into my Dist::Zilla just to see how bad my Kwalitee is.
One of the things that has always caused me problems when creating a perl module distribution are the 'required' modules that sometimes may be unknowingly buried in the code or just forgotten when the distro was created. My Database::Accessor package has a large number of required mods so I will have to be careful when creating my Dirstro
Just of the top of my head I have some ten or eleven in the Data::Accessor class and then there are my test cases where there are some more. Now with Dist::Zilla I can add a simple plugin and get most of them automajickaly so I added in
Now this will not really work and not to bore you too much with miles of Dist::Zill poop coming onto your screen. So lets add these in as well
encoding = bytes
Well today in the Dist-Pen I am going to get a little deeper into the basic plugins of Dist::Zilla.
I left off in my last post with Dist::Zilla I needed to add in an 'Abstract' to my dist.ini file and this I did ad first a pod entry
=Abstract: CRUD Interface for any DB
Unfortunately Dist::Zilla didn't like that so I should just did what it said first and add this into my Accessor.pm
# ABSTRACT: CRUD Interface for any DB
[DZ] beginning to build Database-Accessor
[DZ] writing Database-Accessor in Database-Accessor-0.01
[DZ] building archive with Archive::Tar::Wrapper
[DZ] writing archive to Database-Accessor-0.01.tar.gz
[DZ] built in Database-Accessor-0.01
so what did I get? Looking at results in my working dir I did get
which is the tar-ball I would sent to PAUSE if it was ready to go. I also see I have a
Every year we bring together the lead developers of the Perl and CPAN toolchain! This event was previously known as the QA Hackathon, but in 2016 it became the Perl Toolchain Summit (PTS) to more accurately reflect the scope and purpose.
This is an event where pressing issues around Perl’s toolchain, CPAN, testing infrastructure and much more are hacked on, fixed and improved, and where important issues are discussed and decided on. The focus is the continued support and development of the tools used every day by individuals, organisations, and companies that rely on Perl in Production.
Many improvements in the CPAN ecosystem can trace their roots to this event, including Test2 improvements, the “River of CPAN” analogy, numerous MetaCPAN additions, improvements to the Perl Authors Upload Server (PAUSE), policies on how to handle CPAN distribution adoption and takeover, work on the CPAN Testers service, several consensus documents and much, much, much, more!
So the dilemma today is to decide what to call my next series I guess Dist-Pen would be an apt name and now to come up with some catchy titles and imags.
I spent a good little while looking at the fancy new (at least to me) distribution helpers out there and I have made a decision on which one I am going to use with accessor.
Well I have already abused 'ExtUtils::MakeMaker ' over the years so I will not lear much from playing with that one.
As for Module::Build I did play with that for a bit because it is Pure Perl and I have a Windows box but it did not play out the way I wanted. It will not get ne around the fact that I need an 'nmake' installed on my windows box. So I left this one in the dust.
Lab::Measurement 3.620 was released yesterday.
The most important addition as a new high-level sweep framework written with Moose. Check out the new tutorial Lab::Moose::Sweep::Tutorial!
Comparing with the older Lab::XPRESS framework, the main new feature is support for block data. This is needed when working with instruments like spectrum analyzers which return an array of data in each measurement.
Well there comes a time in every playpen where it is time for bed so this will be the last moose-pen for a little while as I am all out of Moose to do on my Accessor project and I have to start getting it ready for CPAN.
So my love affair with Moose is ending, for the time being, and now I start working on the part of creating packages I dread the most 'Distribution'.
Up to this point in my career I have been lucky the only complex CPAN dist I ever worked with, DBD::Oracle, came with an extensive MakeFile.PL that I really only need to tweak every once an a while. At some 2800+ lines of code I was glad for that.
So in honour YAPCE 2018 it's shiftin bobbins day here in the Moose-pen.
Carrying on from where I left off in yesterday's
I decided it was time I cleaned up a little more of my code. Seems I do this
or code similar to it a almost a dozen times in the Accessor.pm file. Now there is nothing wrong with this but I think I can clean it up a bit by a just a little re-factoring or shifting things about (hence the link at the top).
One might say why re-factor not that you almost got it all working aren't you taking a change of breaking all stuff. Well yes but, I do have an extensive test suite all written up and if I do it on a test case by test case bases I should be ok.
And here we go!
Perl is a programming language created by Larry Wall in 1987. It gained popularity in the 1990’ and was also referred to as the “duct tape that holds the Internet together”. For esthetic and practical purposes I will be referring to Perl 5 in this article as Perl.
Last December it turned 30, an important milestone for every language, 30 years of Perl, 30 years of people and companies from all over the world using Perl.
And I do mean, all over the world, Perl developers are everywhere, from California to Japan, from the Netherlands to Romania. Actually, the most popular countries are United States, the United Kingdom, Germany, Spain, The Netherlands, Japan. Romania is also on the list, but that’s not the point here, the point is that the Perl bug is in Romania and has been for some time now.
Before diving into the local Perl scene there are a few things that should be pointed out about software development in Romania.
IT in Romania
The organisers of the London Perl Workshop 2017 are very happy to announce that
the videos of the talks are now on YouTube.
In the rest of this post we'll give a summary of the videos, with links to each talk.
Last Friday, kichijojipm was held at Shinjuku, Tokyo, Japan.
It is a japanese local Perl Monger group organized by magnoliak.
The talks were about not only Perl but also a wide variety of subjects.
I talked about App::RemoteCommand there,
which is a simple remote command launcher via SSH, built on top of an excellent module Net::OpenSSH.
Here is the slide. I hope you try it!
Yep. You guessed it. Yet Another Moose Post. Today in the Moose-Pen just a quick bit of code cleanup
I stumbled upon some of my early notes for this project today and it seems I forgot to include a MooseX I was keen on using from the beginning, I guess I forgot about it, so a little back programming today.
The MooseX is called '
' and it does what it says, forces all of your attributes to have
coerce => 1,
unless you set them to
coerce => 0,
It is quite funny really because if I used the above since the start I think I would of never run into some of the bugs I know I memtioned in other posts. Reading the POD for this MooseX the author says much the same.
Anyway on with the code. I really only added in this
++ use MooseX::AlwaysCoerce;