Please be aware that you may have received Daily Summaries from the CPAN Testers, that list the archname/platform as i686-linux, but the report in question is from a MSWin32 OS. We are aware of the issue.
Unfortunately, due to an untraditional smoker setup, the tests are run on a Win32 machine, but saved to disk as text files, then parsed on another machine, a i686-linux box, before being submitted to the CPAN Testers servers. As such the metadata sent with the report is misleading, even though the original text report is valid.
As a result, I will be running some validation checks over the weekend on all recent reports (those submitted in 2010) to ensure we have platforms and osnames that correspond with each other. Those that differ will be reparsed and the metadata will be updated accordingly. Further validation checks on incoming reports will also be added to ensure we catch any similar inconsistencies as soon as possible.
The Perl Survey 2010 is now closed. A quick preliminary look at the data set indicates that of the 4847 responses, 3256 were complete responses (by looking at who answered the final question). I'm on my way to German Perl Workshop tomorrow, and as I'm coming from Australia, it's going to take me over 24 hours to get there I'll have plenty of time to prepare the data and get a preliminary analysis going during that time.
Most importantly I'll be able to release the (lightly processed) raw data for you by that time as well.
I've just updated a syntax highlighter bookmarklet I wrote a while back so that it now supports Chrome and Safari, besides Firefox.
I find it useful to syntax highlight when I peek at a module's source code in the CPAN website. You may find it useful too.
To install it, create a new bookmark and paste the following code into the location field (sorry, I couldn't find a way to post this as a javascript: link in this blog):
It will be even handier if you stick it in your bookmark toolbar.
I've even thrown in some regex to allow linking from one module to the next. It works 90% of the time, moreless.
The code is actually kept here. There you'll also find a lushier, Alex Gorbatchev's syntax highlighter version available, but I couldn't get it to work in Chrome nor Safari, only in Firefox.
It should be easy to tailor these bookmarklets to fancy your taste buds.
I have an RFC patch series to Git to add gettext localization support to it. So that eventually you'll be able to configure Git to e.g. shout error messages at you in German. Won't that be a nice variant of the current abuse? I think so.
Here's the latest version of the patch series I posted to the Git mailing list.
For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.
Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.
Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.
While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.
I could be mistaken, but I believe CamelCase was largely a holdover from Smalltalk which only allowed a leading letter and then optional letters and digits. TheReadabilityOfPerlIsBadEnoughWithoutCamelCase.
Actually, shared hosting - in terms of quality - usually sucks big time.
However, some of us are (hopefully only) forced to use it. If you're one (or simply want to show off to someone else who is), this is where Patrick Donelan comes in.
Further beta testng has been ongoing over the last week and all seems to be working well. The metabase search problem, although not resolved completely, now has a mechanism in place to avoid blockages. The feed started up again last week and after 3 days had caught up with a month's worth of reports submitted to the metabase. Although this is still in the beta phase, it does give us more confidence that the eco-system can cope with the submission levels we have been seeing in the last year, and has the capacity to cope with much more. Further tests are being carried out, but the days of CT1.0 are definitely numbered now.
Thanks to all for the wonderful response rate. At this point we're a little over the 3,000 mark. I'm going to close the survey down at 7:00 am UTC on Thursday the 3rd of June, so if there are people you think still need to answer the survey, please point them at http://survey.perlfoundation.org.
I'll process the data file to make it useful over the weekend, and have a preliminary report ready early next week.
I've only recently taken on the tremendous task of learning Perl (with the aide of O'Reilly's Learning Perl). I have a little background in programming as I am a Computer Engineering & Computer Science student at the Florida Institute of Technology. Actually, I was a student there. I can't quite afford it at this point, and I'm going to attempt to transfer elsewhere (UCF, USF, UF? Something with a U and an F, I'd suppose).
Well, on to something a bit more on-topic. I'm midway through Chapter 5 in Learning Perl and I felt the need to create something that the book didn't explicitly tell me to. I eventually want to build my own forums software, but this small 'Journal' or 'Diary' script will have to do for now.
#! /usr/bin/perl
print "Press CTRL-D to end journal entry.\n";
my $success = open LOG, ">>logfile";
if ( ! $success) {
die "Cannot create logfile: $!";
}
Seems like Padre (the Perl IDE, ya know...) got some heat for using a Trac bug tracking system instead of the default CPAN RT system.
Dancer, as mentioned in Gabor's post, prefers to use the Github Issues ticket system to keep track of bugs, wishes, expected features, etc.
I agree there's a certain barrier to provide bugs for Padre and Dancer or any other project that uses a non-CPAN-RT ticket system. I personally hate registering for websites and have decided not to file a bug more than once because I had to register. (case in point: notifying Yahoo! someone is abusing their mailing list system for SPAM.)
Some days are just big buckets of fail. So far I've not been able to get any code to successfully publish anything to blogger.com. I've failed with both Net::Blogger and Atompub and am seriously tempted to just create a bunch of damned HEREDOCs and push them straight to the Google Blogger API.
Didn't we use to own the Web? Or maybe I'm just having a really off day. I've successfully written a custom CMS in just a few hours and I'm stuck on one last, little stumbling block.
Anyone have working code they care to share? I mean real, live working code, not examples. I've seen more failed examples than I care to admit :)
CGI? That's even older than ASP, you cannot write my webapp in it!
Does Perl support session?
I can let you try to code at most 20% of my webapp(you can't code the whole site with Perl, apparently), but make sure it can share session with ASP.NET.
What's needed to run your Perl?
Is there anything Perl can do better than Java?
Does Perl have business value?
Like Damian said in this interview: "Selling Perl to your manager is about explaining Perl in terms that your manager cares about: stable, reliable, powerful, efficient, cheap, maintainable, well-supported, and future-proof."
Now I've tested out Method::Signatures::Simple. It's powered by Devel::Declare and doesn't seem to incur a any runtime penalty. However, since it needs to do some work when the subroutines are compiled, there's a 3-4% compilation hit for my tests:
But on runtime there's no hit at all:
Here's what I needed to do to convert Hailo to it. Unfortunately using it breaks interaction with Devel::NYTProf. When I generate profiling output with nytprofhtml what were previously links to my subroutines aren't links at all.
That's a big price to pay for just turning this:
Into this:
So unless I can figure out a workaround for that I won't be merging that branch.
I've been noticing more and more attention being given to environment testing. That is, part of your testing would be to check the environment you're on. Many Perl developers would probably hear this and say "yeah, well, that makes sense" - that is because many Perl developers already do it. Apparently the other developers are starting to catch on. :)
Test::SFTP was written to make sure my environment is okay. By "okay", I mean "consistent." Also, I really wanted to write a test module.
Originally I wrote Test::SFTP when Net::SFTP::Foreign either didn't exist or was in its very very early days. Point is, I didn't know it. I used Net::SFTP which uses in turn Net::SSH::Perl which - for those that do not know it - is a pure-Perl implementation of the SSH protocol. It's actually a pretty cool thing, except that the dependency is a complete nightmare (including GMP and half of Crypt::* namespace) and it's rather slow.
I'm getting married on June 20th. Leïla and I chose this date because it's my birthday. It's my birthday because I was born on Dies Martis xx Junius MCMLXVII, as calculated by:
I think I started to reinvent XPath. I hate when that happens.
It started simply enough. I had a directory with 12,000 YAML files in it. I wanted to grep them, but I can't do that from the command line:
-bash: /usr/bin/grep: Argument list too long
Although slightly annoying this isn't a big deal. I can write a Perl script to do the job and get the files through opendir. I hardcoded the bits that I wanted to get out, and when I needed something else, I just changed the source.
I made a couple of these quick scripts before I realized I was going to be doing this a lot. I refactored it so I could specify on the command line the path to the YAML thingy I wanted, and called it, well, it was called extract, but I renamed it ypath to put it on Github.
For some time now I have been promising to publish the list of CPAN Authors who for one reason or another, appear to be uncontactable. These are authors, who when using their PAUSEID @ cpan.org address, generates a rejection of some form. Typically this appears to be for addresses which are set up to be used in redirection, which have since been made obsolete (perhaps from changing jobs or personal domain), but there are a few that are just not setup to receive emails.
I have now created a Missing In Action page, which I will keep updated as I receive bounce backs from the CPAN Testers daily summaries. In some cases bounce backs require verification from a real person, and I do eventually get round to those, but the ones listed are specifically for emails that are outright rejected. If you have not been receiving any CPAN Testers summaries or reports and have been expecting some, please first check this list to ensure that you haven't had your preferences disabled.
If you are on the list, please read the instruction on the page, to learn how to enable your PAUSE email, and to get your CPAN Tester preferences re-enabled.
If there is one thing that is more abundant than Hello World programs, it is password generators. Yet, one of the things I could never get right when working on my system administration job (all of them) was comfortable password generation.
There were various methods I've learned from people:
I really haven't done a huge amount of work on Test::Harness since it was released as core, so I decided to take a look at how it is now. I was reading a blog post where someone commented that Perl's Test::Class doesn't offer a progress bar and I thought, that should be easy to hack into prove.
First, a very very big thank you to people who have filled in the survey and spread the word. After a little less than a week, we have 2500 responses. For this kind of survey, that kind of response is incredible, and many researchers will be envious of obtaining a sample that large, that easily.
The rate of responses is about double that of the 2007 survey which stayed open for about two months to obtain 4000 completed questionnaires. In all likelihood I'll close this survey down at the end of the first week of June (after 2.5 weeks), so to get more interesting data I'd like your help.
Please can you pass on details about the survey to less committed Perl programmers that you know - we don't just want to know about the core of the community, but also more casual users. This group are clearly more difficult to reach, so it's important to spread the word. Just point them to the link http://survey.perlfoundation.org and let them know that the work is sponsored by The Perl Foundation.
