A while ago I've registered perlpolls.com and perlsurveys.com but in the end I have not done anything with them. They are about to expire and I don't intend to renew them. If any of you is interested in these domains, please let me know and I can pass the ownership.
When you release your module to CPAN, you should make sure that the distribution has the right name. Doing so makes it more likely that all the different tools and systems in the CPAN ecosystem can process your distribution. I'll outline what I mean by that, and how you can get it right. If one or more of your distributions doesn't follow the conventions, maybe you could release a fix on CPAN day?
Quite a while I got interested in the idea of short, clear examples showing Perl as glue for CPAN. I recently refound these, and they caught my imagination:
Welcome to Planet Moose, a brief write up on what's been happening in the world of Moose in the past month, for the benefit of those of you who don't have their eyes permanently glued to the #moose IRC channel, or the MetaCPAN recent uploads page.
If you'd like to contribute some news for next month's issue, you can do so on the wiki.
Moose
Moose 2.1210 has been released containing some updates to the test suite, and documentation improvements.
Here are some details on our keynote speakers, who will close off each day of the conference in the main auditorium. Rather than technical talks on a specific part of Perl technology, these keynotes deal with major themes in Perl and the art of programming. We're delighted to present three of the major figures of Perl in Europe at YAPC::EU::2014.
This isn't a talk about Perl; it's a talk about how we're changing the world and how the world is sitting up and noticing.
Ovid will cover the gamut of human civilisation from hunter/gatherer tribes to Valve software in a fascinating call to arms about hierarchies and innovation.
CPANTS bills itself as a "testing service for CPAN distributions". It calculates a kwalitee score for all distributions. It doesn't test the quality of your code, but instead evaluates whether your distribution follows various conventions.
Being 'CPANTS clean' means that your distribution is more likely to behave well with the CPAN toolchain, the ecosystem of CPAN-related services, and ad-hoc tools that various people write.
If you haven't thought of something to release on CPAN Day (Sat August 16th), have a look at your CPANTS author's page.
I don't like that mop user tend to look down the user of current perl Object system.
Moose is great! Current Perl object system is not good!
No, No, No.
Current Perl object system is good. There are no lack to do Object Oriented program. Any program can be created by single inheritance and delegation.
At first, I hope improvement of current Perl OO system. Why from now we should write the following code? At first, I hope simple syntax of the following code before mop release.
This is a slightly expanded version of a comment I posted a couple of days ago on NEILB's blog.
Neil was mostly talking about private functions, while I'll be talking mostly about private methods (i.e. object-oriented programming), but I think there's probably a good deal of overlap between the two concepts.
The traditional way of indicating a method is private is to name it with a leading underscore:
The assumption is even baked into the Perl development and testing toolchain in a few places. For example Pod::Coverage won't complain about missing documentation for a sub if that sub happens to be named with a leading underscore.
I used to think the underscore convention was good enough. But partly because of this upcoming project and partly because of problems I've encountered working on various codebases, I've been forced to re-evaluate my thinking, and have come to the conclusion that the underscore convention is insufficient.
Well this is a bit embarrassing. My script to tell me the date of the first CPAN/PAUSE upload told me the 16th August, but somehow when writing the first post about it, I changed the date to the 14th. Doh.
The good news is that 16th August is a Saturday this year, which gives us all a better chance at uploading a release or two. And two more days to prepare.
I've updated the previous posts, and regenerated the charts.
Recently I encountered an issue with
Expect.pm
on OSX. I think it is caused by a bug in
IO::Pty
(Expect.pm is a subclass of IO::Pty) and thus filed a
bug report there
. I even created a test-case and released an
unofficial version of Expect.pm
with a
test
exposing the problem.
Today, thanks to the countless CPAN smokers of BinGOs (aka Chris Williams) I got the first test reports that indicate the same problem exists on OpenBSD and NetBSD as well. (Surprisingly, there are no reports at all on FreeBSD and OSX!)
As I don't have any knowledge of BSDs and this IO::Pty stuff, I wonder if there is anyone out there with such expertise? Could you look into this issue?
YAPC::EU is a great place to meet face to face with others in the community that share your interests, even non-Perl ones. To make it easier for you organise these informal gatherings - known as BoFs - we have created a page on the wiki.
Fancy getting together to watch the premier of the new season of Dr Who, going for a run, or discussing the future of Act (A Conference Toolkit? Then sign-up now!
If none of the current BoFs interest you then please feel free to make your own suggestions for a meet-up on the wiki and help us make the conference even better.
Race conditions are a fact of life. What can we do when one knocks upon our door?
Often we mark race conditions that are not immediately solvable with a comment:
if (!-l $config && -f _ && -r _) {
# RACE! config file could go away, change type, or become unreadable between file test and file read
open my $fh, '<', $config …
…
That is good so that future us can be easily reminded of the issue. It is really hard/impossible to debug or test the various possible race conditions though.
Race::Condition gives us a way to still mark the race condition but also adds in the ability to hook into it for debugging or testing purposes.
The SEE ALSO section in your module's pod is where you direct the reader to other things of interest. In this post I'll briefly outline what constitutes a good SEE ALSO, and why it benefits you to create one.
My thoughts on this topic have evolved over time, and in writing this I've realised that a lot of my modules could do with a brush up. I'll be releasing those on CPAN Day, of course :-)
Once in a while, I search the web for Perl/Tk. I'm always happy to find some old jewels. This time, it was keen little rabbit ears, which is a simple ear training program for Linux and Windows. It has a Perl/Tk GUI and comes with good installation instructions.
I downloaded the script, got the dependencies (it relies on timidity to play MIDI files) and tried it out. Then I did some changes, like use FindBin to locate files relatively to the script in the file system, use File::Spec to build paths, and use File::Temp to create the temporary MIDI file for timidity in a proper place.
But, then I wanted to share the code with Matthias Nutt, the original author. He has a web site: matthias-nutt.no-limit.de. But the feedback form is dead (have a look at the anti-spam picture).
So, does anybody know Matthias Nutt? Or: does anybody know how to handle this kind of code? Can I set up a git repo with the new code without risking expensive lawsuits?
Most Perl programmers using named captures in regex probably pick the (?<NAME>...) syntax, as that's what's displayed more prominently in the Perl documentation and tutorials.
However, Python does not support this syntax and uses (?P<NAME>...) instead (notice the extra P character). Incidentally, visual regex tool like kiki is built with Python and only support this syntax.
(?P<NAME>...) is also supported by Perl. So if you work with Python or use kiki, you might, like me, want to accustom yourself to using the P syntax.
PCRE (and thus PHP and other PCRE-using languages) supports both syntax. Komodo IDE's Rx toolkit support both. However, Ruby and .NET only support the non-P syntax. Well, that's how the real world works.
Without even speculating by what kind of dedication/witchcraft this number is even possible, it made me curious about stats in general for GitHub, and some googling turned up this page:
This is a report of the “Most Active” 256 GitHub users. Well, not quite… The current number 1 on the list has HALF the contribs (kevinsawicki at “11,430”).
kentfredric doesn’t show up because of this second caveat: "Only first 1000 GitHub users according to the count of followers are taken. This is because of limitations of GitHub search.
If the abstract for your module is up to snuff, then have a look at the SYNOPSIS to see whether you could improve that in a CPAN Day release. The SYNOPSIS should briefly show typical usage of the headline features of your module.
I have app which do some stuff via HTTP/HTTPS. Here it is, already posted about it on blogs.perl.org
There is simple logic:
1) Use http. If user wants https, use https but check that LWP version >= 6 AND LWP::UserAgent->is_protocol_supported("https")
2) Retry HTTP 500 server errors. There can be a lot (coming from server, it's normal)
3) Retry HTTP 500 errors with Client-Warning=Internal response (LWP could raise this in case of conenction problem and socket timeout) with warning "connection problem"
So now I got two reports at once that everything completely broken and HTTPS does not work.
After some investigation I found that:
LWP 6.00 and 6.01:
1) ship LWP::Protocol::https as part of LWP::UserAgent distr, not a separate dist.
2) Do not ship and depend on Mozilla::CA. Instead there is note in docs: