blogs.perl.org

This is a moderately edited (primarily rearranged) version of a comment on the Perl 5 issue tracker written by Yves Orton (demerphq). I thought it would be useful to a wider audience so I am reposting here with permission.

Note: this was written off the cuff and is not comprehensive. In correspondence, Yves noted that such an article could/should cover more formats, e.g. MsgPack.

I [feel strongly] that Data::Dumper is generally unsuitable as a serialization tool. The reasons are as follows:

I sometimes need to write shell-script test scripts and not perl, to be able to test perl scripts, without interfering with perl, and also for performance and easier IO reasons.

In order to find out with which perl this distro was built, we need to parse the generated Makefile.

Recent EUMM 7.0x introduced a new feature which broke all my scripts. They started double-quoting PERL and FULLPERL in the generated Makefile. Damage is already done. They only thing you can do is to remove the quote.

PERL=`grep "^PERL =" Makefile|cut -c8-`
PERL=${PERL:-perl}
PERL=`echo $PERL|sed -e's,^",,; s,"$,,'`

In my last report, I had received an ok from the module's author to proceed with a pull request. The first thing I did, as I had with the modules referenced by Devel::StackTrace::WithLexicals, is to write an example for myself so I could see how it worked. Working from the synopsis, I had a difficult time writing a working piece of code. It occurred to me that this was the very place I could start with a Pull Request.

More

As you may know MetaCPAN as a project has no budget. We rarely solicit funds because we rarely need to pay for anything. This has allowed us to focus on the project itself rather than the administrative issues that arise whenever money changes hands. Because these relationships allow us the freedom to do what we need to do, we think it's important to thank our sponsors publicly.

And with that introduction I'd like to thank Panopta, the latest sponsor in the MetaCPAN world.

A while back I put out a call on Twitter to see about getting someone to sponsor a monitoring solution. Less than 30 minutes later, I got a response directly from Panopta. I started an email conversation and we had a sponsored account in no time.

An interesting list of awesome-perl.

I just had to endure MJD’s horrible pseudohash explanation at the Pittsburgh Workshop. “A new, never-before-seen talk on Perl’s catastrophic experiment with “pseudohashes”, which wasted everyone’s time for nine years between 1998 and 2007”

https://www.youtube.com/watch?v=-HlGQtAuZuY

Watch it, you can fast forward through it. I honestly had higher opinions on Marc-Jason.

So let’s see what’s wrong with the popular and uninformed pseudohash critic:

Their main points are that storing a hash in the array slot 0 for run-time lookup is too complicated, the exists and delete ops need to check for arrays / pseudohashes now also, and all the pseudohash checks slowed down general hash usage by 15%. Which basically levelled the advantage of faster compile-time accelerated array lookup on those pseudo hashes, which was ~15%.

Whats breaking? Much less than you might expect, but more than I had hoped.
Should I be scared? If you do not test your things now, and file reports for me to fix bugs, then yes, you should be VERY scared.

That about sums it up! (Just kidding.) But in all seriousness, PLEASE TEST YOUR CODE!. Please install the trial releases of Test-Simple, try building your dependency chains against it! Please also try your non-cpan code against it. There has been plenty of warning, and you still have almost 3 months to file bug reports.

What breaks?
Code that does any of the following is no longer supported:

• Replacing the $Test::Builder::Test singleton
• Monkey-patching Test::Builder (Note: Exceptions for some commonly monkey-patched subs)
• Directly modifying values in the Test::Builder instance hash

There are a few monkey-patching exceptions, if your code wrapped 'ok', 'diag', 'done_testing' or a couple other common ones, some fancy hackery has been done to allow them to keep working.

I'm collecting notes on Perl modules, including articles, which impinge on this huge issue.

I'd be delighted if someone has beaten me to it, but if not, please comment freely...

On my quest for downloading more podcasts, I decided to tackle another podcast I started listening to, Criminal.

This posed a set of new problems, and I'm going to go over the code for solving it, since I'm actually somewhat proud of it.

As a minor contribution to the challenge, I've started to collect the links
about the CPAN PRC If something is missing, please send a pull request. (No, that pull request won't count as being part of the challenge :)

After talking with the toolchain, and Ricardo Signes, a new Test-Simple release plan has been made. The Test-Simple release will sync up with blead and the 5.22.0 release (well, kind of).

• 2015-01-20 5.21.8 Contentious changes freeze
• 2015-02-20 5.21.9 User-visible changes freeze
• 2015-03-20 5.21.10 Full code freeze
• 2015-05-20 5.22.0 Stable release!

We settled on 2015-03-19 as the Test-Simple release date. The idea is to release Test-Simple AFTER the user-visible change freeze, providing a few weeks of much more rigorous adoption/testing. However We also want to release with a good amount of time before the perl-stable release so that if anything critical is found by a release it can be put into blead before 5.22.0 is out.

So on 2015-03-19 a patch will go to blead changing the version number of Test-Simple such that it will no longer be a trial. The same day a cpan release will be made marking the new internals of Test-Simple as stable.

I've written an article detailing the major advantages of Text::Balanced::Marpa. V 1.03 has just been uploaded to CPAN.

I was a bit taken aback by Gabor's Perlweekly mention of my Bedrock blog. I guess there really are a few people that read these blogs! ;-)

Then of course, I was a little disheartened by the something from the last century reference. Having been born in the last century like many programmers today, I don't necessarily think everything that comes from the 20th century is bad, obsolete or not worthy of our attention. But, in the end, he's actually spot on.

I spent another day of prosaic adjustments to my CPAN distributions. For quite awhile the chaos of the Changes and README files have bothered me, so I wanted to think about those. And, many of the files I scheduled for deletion disappeared from PAUSE today.

I'd like Changes to have structured information that a program can turn into a data structure (and query, such as "What version fixed GitHub issue #137?". We don't quite have that, but there is the start of a specification in CPAN::Changes::Spec and a test module, Test::CPAN::Changes to check it. There's even a Changes Kwalitee at CPAN HQ. I'm not doing so well at the moment. Dave Rolsky has some thoughts on Changes files too. Of course, Neil has already written about it in A convention for Changes files, and Jonas covers many of the same things.

So, yeah, to make me more active in the Perl community I decided to join the Pull Request Challenge. I have a quite big number of modules to maintain, but sometimes it is good to look to some other people code to learn something.

My attribution for January was Data::ObjectDriver. I am not sure, yet, what this module is about, but I learned some stuff already, dealing with Module::Install. That was enough for a simple Pull Request [see here]. Hopefully it will be useful for other people as well. Also, hope it gets accepted.

Although this is enough for the Challenge, I expect, in the next days, to prepare at least one more Pull Request. So, stay tuned.

EDIT: The second pull request [here] did not take that much time. Fixed a test that was failing given new error message on DBD::SQLite.

Unless something comes up, I plan to release the new Test-Simple, with refactored and new internals, on Saturday January 10'th.

Test-Simple-1.301001_096

This trial version has been on cpan since December 28'th. No issues have been reported against this trial version. Assuming that does not change I will re-release it as stable. Now is absolutely the time to check your code against this new version.

The goal from the start has been to maintain compatibility as much as possible. That said I was not able to maintain compatibility for things that munged the internals of Test::Builder too much. However I was able to maintain support for the most common cases of monkey-patching. I also maintained the existing APIs.

If you find something that is broken by the new internals please file a bug on github. All issues will be evaluated, if the issue can reasonably be resolved by patching Test-Simple, then that will happen. However if the issue is that you replace the Test::Builder singleton, or make significant modifications to subs in Test::Builder, then you may be asked to patch your module instead.

Note: This version is also in perl-blead, and was in perl-5.21.7.

I started getting into podcasts recently and one that I heard mentioned a few times was Welcome to Night Vale. I didn't get to listen to it yet, but decided I'll try it out.

When I start with a podcast, I want to download the episodes. I don't listen on my computer, I listen on my mp3 player. (Yes, I still havhttp://commonplacebooks.com/welcome-to-night-vale/e one, and no, it's not an iPod.)

At the same time, I'm sick of going over lists of pages, opening each, and then looking for the download button, so I wrote a Perl script that downloads all episodes for this podcast.

Dave Mitchel finally got fed up by the lack of stable perl benchmarks, and the impossibility do catch performance regressions.

This was his announcement, with the sample:

Now that I've put Djet into production, I recon it's time I at least told about it.

Djet is a Node Based Content Management System. It's a rather advanced one, using features from modern Perl and PostgreSQL. It's meant to be used behind some kind of frontend server, e.g. Nginx, or at least a Web Cache like Varnish.

My second day of CPAN Cleaning was just the sort of work that I like: organizing a chaotic mess into something I can work with. My CPAN distributions are a mix of almost everything I've done in my history as a CPAN author. There was a CVS repository in the mix, several things left over from Sourceforge, and various ways of using Git. Even in the Git repos, many files still had CVS tags. A surprising number of files don't end in a newline, making for apparently pointless file changes.

Fixing all that up is easy; it's just work.

But then I want to ensure that all the .gitignore files have everything they need. In some repos, some .DS_Store entries snuck in, for instance. For MANIFEST.SKIP, we have a default set of includes. I went looking for the same thing for Git, and, of course, Github has a repo of sample .gitignore for many languages.