blogs.perl.org

Want per project perl defaults that save boilerplate? You want your perl - you want myperl.

Crypt::RSA is a module that's been around since 2001, when Vipul Ved Prakash put it on CPAN. It's had only very minor updates since then, and gets used by a few other modules. However, it's had one big problem: it uses Math::Pari for all its calculations, and two of its dependencies (Crypt::Primes and Crypt::Random) also use Pari. Debian in particular has been pining for a version that gets away from the Math::Pari dependency (see RT52689 for some reasons).

I decided to go ahead and do the Pari removal, and it's on CPAN as Alt::Crypt::RSA::BigInt. This uses Ingy's Alt framework -- install the Alt version and you get a new shiny Crypt::RSA. Install the old version and you're back again. There are no Pari dependencies, and if Math::BigInt::GMP is used, it's 5 to 11 times faster. I decided to use Math::BigInt directly, as that makes it very portable, though the speed without either the GMP or Pari backend leaves much to be desired.

Just a quick note to say that I’ve released a new version of Method::Signatures today.  There’s nothing major, just a few housekeeping duties.  Here’s the highlights:

DBIx::DataModel (DBIDM) is an Object Relational Mapper for Perl that is very elegant, simple and effective. It helps you to efficiently interact with your database.

• results are hashes - so it is very easy to manipulate and debug query results,
• schema generation is fast, clean and effective - so we very quickly get a useful map within Perl of just the most important aspects of our database, and
• the API allows inserts, updates and selects to be defined extremely efficiently - keeping the easy things easy

After reading some of the posts about renaming Perl to something else I noticed that a commonly used argument was about the language visibility. Personally I don't want to take party here and restart all the discussion about that issue, I think a lot of people more capable and committed to the language evolution already gave their opinion.

My point here is about that comment mentioned before, the language visibility and appearance. If the way how people see and remember Perl is the problem, I think that we can come up with some kind of solution without any dramatic changes in the language itself, and I'm going to tell you how, in my opinion, we could address this issue.

I wrote "pathed", a tool to munge the Bash "PATH" environment variable.

The Bash "PATH" environment variable contains a colon-separated list of paths. pathed - "path editor" - can split the path, append, prepend or remove elements, remove duplicates and reassemble it.

http://marcelgruenauer.com/blog/2013/02/22/pathed/

A fresh new version of perlbrew is out that incorporates some sweet new sugar via arc:

perlbrew install --switch stable

Which expands as:

• Install the "latest stable" Perl - don't make me think about version numbers ;)
• When you're done, switch to it

It is just sugar, but it makes a one-liner out of what used to be:

• Figure out what the latest stable version of Perl is.
  • Think about here: "those outside the echo chamber"
• perlbrew install perl-5.16.2
• perlbrew switch perl-5.16.2

More usefully for my (planned) purposes, I can write documentation targetted to outside the echo chamber that ensures both:

• those reading it will always get the latest stable version of Perl, and
• I won't have to bump the docs every time a new release is rolled.

Go lazy!

As you know, Selenium is a marvelous library for automating a browser. It can be combined with Test::More and PhantomJS to provide a headless test suite.

An example script looks like:

As developers, we sometimes have to help operations going smoothly by fiddling with the data "by hand" because there's no GUI to allow people doing some rare and obscure things. One common way of doing it is by connecting to the DB and writing some SQL. But often, accessing your database is not enough, because you need your application code to be run.

And for that, you need a shell.

I spent time to create the below message for Brian's post on crowfunding. For whatever reason, he felt the need to delete my post. So I've recreated the gist of what I said previously. I guess next time I'll take a screenshot for posterity.

Brian, Now that is a great contribution! Thank you!

Discoverability issues: On a crowdfunding platform that is generic in nature there is a discoverability problem if you are targeting a specific audience. Brian, does Catincan support creating a Perl channel/filter with permalinking? If so this could then be linked directly from Perl.org. If not, how do we address that issue?

So far the initial response to my three-value logic in Perl post has been great. Due to that response, on Reddit, Perlmonks, here and my RT queue has led to:

• Made sorting a bit more useful
• Contemplating removing stringification
• Plenty of strengthening of the documentation (including making it explicitly clear that the unknown logic is akin to SQL's NULL)

And then there's been some interesting rebuttals.

Last night I reached chapter 4 of Think Python, which is full of good old fashioned turtle graphics stuff.

It’s just - well - there’s a problem. I don’t think there is a port of the swampy library to Perl 6. I could write one, but that would probably require a Tk interface with Perl 6. Even just writing a Perl 5 Tk version of Swampy is beyond my spare time attention span.

I know what I’ll do. I’ll cheat and have perl6 call python.

I've proposed a "Perl" project on Catincan, a new crowd funding site targeted at open source software. They've said that the first 25 projects to be fully funded have their fees waived for life. That is, if a Perl project gets funded, we have a crowd sourcing platform where the developer gets all the money.

That fee waiver is interesting. I've looked at many crowd funding sites. Most at least charge the credit card fees. Fractured Atlas, where I'm a board member, charges 7% for their fiscal sponsorship program. If TPF wanted to set up their own program, not only would they have to charge some fees, even to just cover costs, but they'd have to manage it as well. If there's already someone doing all that work and doing it for us for free, so much the better.

On February 28th I will be presenting an “Introduction to Mojolicious” to the Chicago.pm meeting. If you are in the area I hope you will stop by; it won’t just be an introduction despite the name. If you are interested, here is the Meetup link.

I haven’t decided, but I might try to “self-host” the talk, writing it as a Mojolcious app! To do that I had to resurrect one of my earliest CPAN releases Mojolicious::Plugin::PPI. This module does just what the name should imply, providing syntax highlighting via PPI and PPI::HTML in a handy Mojolicious plugin.

Whether or not I decide to use this for my talk, it still is handy to have around. Here is a cute example, a simple “quine” which you can run:

After being dormant for longer than I can remember, the Thames Valley Perl Mongers mail list woke up recently when someone[1] offered to host a meeting.

I've put together a very short survey to work out how many might be interested. If you live in this corner of the UK and/or fancy coming along, please let us know:

http://www.surveymonkey.com/s/QNPF2V8

[1] the offer comes from Opsview, a company based at the University of Reading campus who use Perl in their main product (and might be scouting for employees).

Drop a note to oliver at cpan dot org if you have any questions. Many thanks!

Bad news. You've a brand-new CEO and he has a reputation for having a short temper. He knows about his reputation so he's decided to win over the employees by offering all "underpaid" employees a salary increase of $3,000 per year. You've been tasked to write the code. Fortunately, it's fairly straight-forward.

foreach my $employee (@employees) {
    if ( $employee->salary < $threshold ) {
        increase_salary( $employee, 3_000 );
    }
}

Congratulations. You just got fired and have to find a new job. Here's what went wrong and a new way to make sure it doesn't happen again.

The following is my view on the subject (and also first, hopefully not last, blog post here), a comment to About the Grants Committee.

Whenever someone is about to submit a grant proposal, that proposal goes through one's "internal review" first. And in that internal review one asks yourself: "Why should I ask to be paid for what countless of others just CONTRIBUTE to Perl community? The Perl itself and tens of thousands of modules are literally millions of hours, hundreds of years of work just contributed. Why should I ask for pay?". This is the perfectly right question to ask. And this makes the one's internal review quite picky, and the result is what we see - no proposals. And, though surprisingly it may sound, this is the right thing.

To be financed with grant there must really be a tangible, important benefit to community at large that cannot be achieved without grant. And this criteria leaves VERY FEW things appropriate to be financed with grant.

On to chapter 3 of Allen B. Downey's Think Python book, as interpreted through Perl 6.

I'm currently working on a big, and I mean /BIG/ codebase, like 200K LOC with about 10 years of history behind it.

In this post I'll briefly describe how I'm refactoring code using a little tool called Geest (github), which I completely stole from Ruby's kage.

tl;dr: With Geest you can check differences between new / old code transparently. It's really handy. Please let me know what you think, or file issues if you find any.