blogs.perl.org

Here are the most popular ebooks from Jul 16 2012 to Jul 22 2012:

Release

1. Dancer
2. DBI
3. AnyEvent-RFXCOM
4. Prima
5. libnet
6. perl
7. Net-Server
8. Mojolicious
9. CGI.pm
10. What

"One of the secrets to mathematical problem solving is that one needs to place a high value on partial progress, as being a crucial stepping stone to fully solving the problem." -- Terence Tao

Once an error is found, a traditional parser is pretty much lost. This is true for even state of the art compilers and interpreters. One small typo results in many screens of useless diagnostics. If you're an old hand, you scroll back over these, knowing that, for the better quality compilers, the first few lines often have something to do with the real problem. With Marpa, we can do better than this.

The YAPC::EU blog says "Our final voting round ends on Friday." So, Friday has gone by, does that mean that all talks that have not been accepted now have been rejected?

And if so, are we really not going to have a single talk on Perl 6? I know that some good speakers (and I don't mean me :-) have submitted talks on Perl 6, and I'd be rather disappointed if they all got rejected.

Can anybody tell me what's going on?

I am following lots of Perl related blogs, including most of those posted on blogs.perl.org, and share many of those posts on the various social channels of Perl Weekly.

Both Facebook and the Google Page fetch the images embedded in the post and offer them as thumbnails. If you look at the pages, I think the ones with images stand out more and are probably read by more people.

We will have a lot of books at the venue: Liz and Wendy will bring their incredible Perl library to the venue. If you want to know which Perl books exist, you should have a look at the library. As far as we know they have all Perl books ever written.

And there will be a booth where you can buy books. That booth is run by "Gutenberg-Buchhandlung".

I would like to announce two new CPAN distributions of mine: App-Notifier-Service and App-Notifier-Client. These are derived from a few simplistic scripts I've written in shell and Perl, to allow me to notify when a task has finished (e.g: make ; finish-client) or a certain time has elapsed (e.g: sleep 240 ; finish-client), and I decided to create something more serious as CPAN modules.

App-Notifier-Service implements an HTTP service (using Dancer), which listens for requests, and once one arrives, implements a callback, which notifies the user on the localhost that the event occured. App-Notifier-Client complements it by implementing a client that connects to the service and sends the event.

Currently documentation may be lacking, and there are almost no automated tests in the distributions, but it appears to work nicely. To get started, read the documentation and you may wish to peruse some of these files from my home directory. First of all, the .app_notifier.yml file:

I've published a review of CPAN modules for making HTTP requests. This covers 20 different modules from 19 distributions. I focussed on making GET and POST requests, whether the module supports https and redirects, and some other features.

As ever, I've no doubt missed a couple — let me know if you're aware of one not on the list. Also happy to hear if there are other aspects you think should be included in the comparison.

Did you know that 22/7 is actually a better approximation of pi than 3.14 is?

use DateTime;
use Math::Trig qw(pi);
use Test::More tests => 1;

my $today = DateTime::->now;
my $dm    = sprintf '%d/%d' => ($today->day, $today->month);

cmp_ok(
	abs( eval($dm) - pi ),
	'<',
	0.0015,
)
or diag("this test only passes on 22/7")

BinGOs will give a talk at YAPC::Europe 2012 described as

Perl. Windows. The two are often seen as incompatible.

But they aren't.

I will distill and present 13 years or so of experience of
running Perl on the Windows operating system.

Topics covered will include:

- Strawberry Perl
- ActivePerl
- Cygwin Perl
- Building Perl from source
- Active Directory manipulation with Perl

and much more.

I've previously written about Any::Moose and suggested using it instead of Mouse in order to provide interoperability in code. You get Mouse unless Moose is needed and in that case you get Moose.

However, there are a few problems, mainly having some incompatibilities between Moose and Mouse (which has been drastically reduced to have as little side-effects as possible) and the load order being tricky. My original post relates to that specifically.

We now have Moo! Moo is very small, yet maintains much compatibility by simply not getting into the whole "metaclass protocol" thing, and giving you Moose-like attributes. Moo can also inflate properly into Moose objects, giving you what Any::Moose does, but correctly.

mst has written a very compelling post explaining how Mouse was started and how Any::Moose was designed in contrast to Moo, and why you should use Moo instead of Mouse or Any::Moose.

Moo is so awesome, I've started moving many of my modules to Moo. Dancer 2 is also based on Moo.

So, "can we have a smaller faster implementation of the basic parts of Moose?" - Yes, we can, it's called Moo.

In tandem with the creation of perl4science.github.com, gizmo_mathboy created a new google group called The Quantified Onion. Both of these web properties are meant to give greater visibility to Perl's role in science, and to spread the word to newcomers that Perl is a great language for scientific computing and data analysis.

It doesn't take long to realize that The Quantified Onion could easily slip into becoming just another room in the Perl echo chamber, a forum-based extension to blogs.perl.org with a scientific bent. If our goal had been to create a space for Perl scientists to hang out, this might be acceptable. However, I am convinced that Perl needs to get itself out of the lonesome offices and into the halls of academia. We have to grab the interest of undergraduates and graduate students doing science. Heck, I'll even take a postdoc or professor if I can get their attention. How do we achieve this?

We put on workshops for scientists and engineers.

One of the purpose of blogging for me is to record ideas and thoughts. So, here's another series: features I'd like to see on various Perl-related websites (like search.cpan.org, MetaCPAN, cpanratings, blogs.perl.org, etc). There will be future posts.

• cpanratings: comment on a review. Sometimes a review is so $adjective that you just want to say something about it :)
• MetaCPAN: view details of a ++ score. For starters, list of users who ++'ed the distribution. Posted to github issue comment.
• MetaCPAN: list a user's favorite distributions. For starters, list all *my* favorite distributions. Posted to github issue comment.
• MetaCPAN: show ++ score (and number of reviews) on author's page. For starters, list all *my* favorite distributions. Posted to github issue comment.
• MetaCPAN: count number of downloads. It is a good indicator of popularity. Compare: Debian's popcon, download counters on rubygems, download counters on PEAR.

Uwe Voelker will give a talk at YAPC::Europe 2012 described as

Segfaults are nasty, sometimes they are hard to detect or hard to narrow down.

This beginner level talk (in regard to segfaults) will show two ways to narrow them down: Devel::Trace and core dumps plus gdb.

Having played with Dancer and Rose::DB earlier and blogged about it here, I thought why not play with Catalyst and DBIx::Class now. If you are interested in my earlier blog series then here is [ Part 1 ] and [ Part 2 ].
Source code for this blog are here .
Lets get our hand dirty now. Before we begin lets get the environment sorted first. The sample code has been tested on Windows Vista Home Premium Edition (32 bit) machine with the following modules:

• perl 5, version 16, subversion 0 (v5.16.0)
• Catalyst v5.90015
• Catalyst::Devel v1.37
• DBIx::Class v0.08198
• Catalyst::Model::DBIC::Schema v0.6
• HTML::FormFu v0.09007
• DBD::SQLite v1.37
• Template Toolkit v2.24
• SQLite v3

[STEP 1]: We will create the skeleton of our catalyst application like below:

I rarely rant on this board, and I try not to rant whenever I can stop myself. With that in mind I am going to try to phrase this rant as a question and see if people agree with me or not. Note that for the remainder of this post I am going to be speaking in broad generalities and I know that there will be notable exceptions. Ok here goes.

This started while responding to a post from awncorp, but it really isn’t the same topic. I want to know, is the focus on “user-friendly” or “ease of use” or “one-click” hurting users in the end? Not even from a teaching standpoint, but actually in their day-to-day computing? My assertion is that some things in computing are inherently difficult, and that they should be, and people might to well to embrace that.

At $work, our flagship application was recently audited for potential security issues. One of the items which raised a red flag was the fact that we weren't dealing with the threat of CSRF (Cross Site Request Forgery). The solution which we decided to implement was to add a CSRF token to all POST requests. This token should only be known to the app and the end user. Passing it along with a POST request gives some measure of assurance that a POST by the user is intentional and so can help to reduce the risk of CSRF.

Reini Urban will give a talk at YAPC::Europe 2012 described as

address-sanitizer (aka ASan) is a memory error detector for C/C++, superior to valgrind. It comes with clang.

It finds:
* Use after free
* Out-of-bounds accesses to
** heap
** stack
** globals
* Use after return

It is very fast. The average slowdown of the instrumented program is ~2x, it's ~10-20x faster than valgrind. DEBUGGING builds should just use it.
The tool works on x86 Linux and Mac.
How it works, what errors it finds, some tools.

Today is a very sad day for perl: https://twitter.com/Reini_Urban/status/225999360058617856

I had to remove the perl frontend for mosh, being replaced by a C++ script. perl IO::Pty on cygwin and various platforms did not work good enough. mosh was one of the most prominent users of perl.

• mosh on cygwin: http://cygwin.com/ml/cygwin-apps/2012-07/msg00060.html
• problems only solvable by getting rid of perl: http://mailman.mit.edu/pipermail/mosh-devel/2012-July/000257.html
• new package

Accidently some tweet from today says: ": But for some things, ‪#Perl‬ just isn't the optimal choice. (yet) :-) -Larry Wall in 199702221943.LAA20388@wall.org ‪#iFollowBack‬"

A note to folks reading reddit:

This is not a fork, it's a sanctioned pre-release of 1.3 with a bad version number. It was decided for the next major mosh release 1.3 to use the C++ wrapper by Peter. The new c++ wrapper is also used in the android mosh opkg version. mosh is awsome, 1.3 will be even more awsome.

PS: If you don't know that: I am the cygwin maintainer of perl, and toddr the IO::Pty maintainer sits next to me. It's not my personal decision to remove perl, but I just had to do that also for my port.

Naturally, you'll need to season this to taste, but here's how I've now integrated perlcritic and vim, making it easy to jump to specific errors.

I've previously written about using the Vi::QuickFix module. It takes advantage of vim's quickfix commands.

First, drop this into your .vimrc:

" quickfix for Perl error formats
set errorformat+=%m\ at\ %f\ line\ %l\.
set errorformat+=%m\ at\ %f\ line\ %l

I also have the following mapping:

noremap ,c :!time perlc --critic %<cr>

It's the perlc hack which makes all of this work.

Just noticed from my CPAN feed that Moo 1.000000 is released. Yay. Also wishing mst to reach 1.000000 in recovery soon.

(I remember about a year ago when only my dists were the ones mainly using Moo. It's nice to see the list has grown. Not far behind Mouse and Moose, really.