blogs.perl.org

We have a web developer position open in Helsinki, Finland. As I'm personally involved with this recruitment, and Perl can be the main tool in this job, I think it's ok to be posted on this forum. Read the full advertisement at our site, or below.

It's been a while since I've posted anything about Perl.

It's been a while since I've written much Perl as well, looking at my CPAN page shows a long gap since I moved over to America (and the Microsoft stack) to work at Kaggle.

The break has caused quite a few problems in terms of maintainership of various things. Padre's progress towards 1.00 has suffered quite a bit, and I've handed off a few modules where people showed interest in taking them over.

The time away from Perl has also given me a chance to reassess my work and the CPAN ecosystem and to think about which parts of it are actually important and which are in desperate need of a shake up.

The first project that badly needs some love is CPANDB, which is a single relatively small SQLite database (and ORM) layer that aggregates all the most important data about CPAN authors, distributions and modules together in one place.

This review is the conclusion of 2 rewrites. Today I'm still uncertain
about a final opinion about this course.

Definitely, the video series is a course. And it does hook up onto the
"Mastering Git" video series from the same authors. Content is rich,
very rich. Most of day to day Git users will probably learn a lot on
this marvelous tool that is Git.

But, Git is a tool. Basically a developer (or whatever user of text
files which can make use of a revision control system) knows one or
more languages, and tries to extend that knowledge as far can be. The
Git tool serves him in solving bugs (by i.e. finding diffs which
introduced them), keeping track of released versions, etc. There's a
lot Git can do beyond this, and the course covers lots of these. But
is that knowledge required?

Hello again Perl world!

After a wonderful vacation, I came back to discover that I had far more work to do than I had realized. I have only just started to claw out of the heap and arrive at a place where I have had some time for Perl-ing.

First of all I need to apologize. I missed my Grant Report this month. While this is no excuse, there also was nothing to report. I do hope to keep honing in on the few remaining problems that Alien::Base has developed, but I am increasingly believing that a few of my initial assumptions may have been too flawed, possibly requiring a little bit of rewrite. That said, what I really need is someone who has a longer beard than I (metaphorically) to help me understand some Makefile/linking stuff to help me over the hump.

In a comment of an article here at blogs.perl.org, Going to Perl School, I mentioned that Perl has 9 uses for braces. Here they are:

Perl modules are not like dynamically loaded libraries in other programming languages. Thanks to the import function, sub prototypes, symbol table hacking, parser hooks, magic like Devel-Declare, ties and other voodoo, Perl modules can shape and craft the flavour of Perl that is available to their caller. A practical example: Perl's exception handling via eval and $@ is weird, clunky and error-prone. But by loading TryCatch or Try::Tiny you get a clean syntax for catching exceptions that Just Works. You're not just loading a library and using it at arm's length; you're changing the very syntax of Perl - locally, within your module.

(Aside: there are of course plenty of modules that don't do any of this - say those that are designed to be used in an object-oriented fashion. Those are great too of course - different approaches are appropriate for solving different problems.)

This week's post by vti

• Venue
• Guests
• CIS

In order to override the C compiler with ExtUtils::MakeMaker, one can do something like:

perl Makefile.PL CC=/usr/bin/clang

Which will make the "CC" variable in the generated makefile be set to /usr/bin/clang instead of the default. Apparently, setting the CC environment variable does not work like it does with CMake.

Thanks to Sisyphus for the tip.

Cross posted from my blog

Welcome to Perl 5 Porters Weekly, a summary of the email traffic on the perl5-porters email list. The smartmatch discussion continues to be very popular, so its summary will go at the end of this post. There was also a very long, very tedious thread about how Perl ought to handle UTF-8 output which almost demonstrated [Godwin's Law] [1] (the longer a thread continues, the higher the liklihood someone will call someone else a Nazi.)

If you're reading this on my blog or somewhere else on the web, you can now find the summaries in Markdown format in [this github repository] [2].

Also, since there seems to be influx of new readers, ohai! I started writing these summaries after YAPC::NA 2012 after having a breakfast conversation with Gabor Szabo. If you don't already read his Perl Weekly email newsletter, you really ought to sign up for it.

Topics this week include:

• Term::ReadLine::Perl not moving forward
• DTrace probes for loading-file, loaded-file, op-entry
• My Perl Foundation Grant for Improving the Perl Debugger Was Accepted
• utf8 problems (still, )
• fixing smartmatch (again (still))

OK, so another MTMH 2012 blog post. I'm trailing far behind everyone else, but better late than never.

MTMH 2012 was a joint hackathon between the people working on p5-mop (a project to get a Moose-lite metaobject system into the Perl 5 core) and the Perl RDF toolkit, with a few Rakudo people thrown in too, ostensibly for convergence between the p5-mop and Perl 6 metaobject systems when possible. As somebody in the RDF camp, though with a toe in the Moose water, I decided to get a better feel for Moose by playing around with a few MooseX projects. (The results include MooseX-DeclareX and MooseX-Interface.) There's really a lot of cool stuff behind $self->meta. If you've never gone behind has, extends and with when using Moose, you really should.

Don't you love static web sites? So easy to deploy, so intrinsically safe... On the other hand, writing all your HTML by hand, like in 1994 (before server-side includes, for example) is rather painful.

Of course there are tools like Jekyll, but they kind of force you to adopt their conventions when you write your site.

What I'd really love to do, is to write my web site using one of those nice web frameworks we have now, update the data in there using all the nice tools they provide, and then generate the static version of the site to deploy. Most the fancy "dynamic" stuff can be handled with JavaScript on the browser.

This is what wallflower does. Given a list of URL and a Plack application, it will save all those URL into a set of files, ready to be uploaded.

Some advantages to this approach:

This post is written mainly as a personal note to remind a future me.

I just tried to install Server::Control on a linux box.
It depends on Proc::ProcessTable which blew up during testing:

t/process.t .. Can't load '/home/gabor/.cpan/build/
Proc-ProcessTable-0.45-rKuJSH/blib/arch/auto/
Proc/ProcessTable/ProcessTable.so' for module
Proc::ProcessTable:  /home/gabor/.cpan/build/
Proc-ProcessTable-0.45-rKuJSH/blib/arch/auto/
Proc/ProcessTable/ProcessTable.so: undefined 
symbol: pthread_once at 
/opt/dwimperl-5.16.0.1/perl/lib/5.16.0/x86_64-linux/
DynaLoader.pm line 190. at t/process.t line 9.

(I had to break the lines of the error as putting it in <pre> tags caused the lines to be cut off. Sorry for that.)

After returning from the Moose/RDF hackathon in Norway and moving to another city this weekend, I finally have the time to tackle two tasks on my TODO list at once, viz finally starting this blog and writing up on the hackathon.

The Moving to Moose Hackathon 2012, organized by the Oslo Perlmongers was a five-day event that catered both to the Metaobject Protocol enthusiasts (who use Moose now and may soon use the new p5-mop to be moved to Perl5 Core) and developers interested in using Semantic Technologies and RDF with Perl. I was one of the RDF guys.

If you think "white knight" is a crap term, a convenient argument-by-dismissal tactic, then you probably already know all this, but there may be some useful ideas for the next time someone attempts to spring this on you.

On the other hand, if you're one of those who think it's the scored-the-touchdown-high-five-we're-done-here way out of any situation where you've said or done something crappy and then been called on it, you're probably not going to read this anyway, but I shall go ahead and write it so you will have to waste energy making up increasingly vituperative denials which I will pointedly ignore.

I dream a lot. There was a period of 30-40 consecutive days in my high school year when I remember, because I made a note of it after realizing the fact going into the second week of that period, that I dreamed every single night. The frequency has gone much down nowadays, into only about once or twice every week or even less. I still make a note of some of these dreams, especially if the story is peculiar, and I try to find the possible triggers that made my mind decided to weave that story. Sometimes the connection is obvious, and sometimes it is less so.

Last night the dream was related to Perl, somewhat.

Our paper version of the proceedings was a success. We've given away all printed versions. If you missed it or your colleagues prefer an electronic version, we have the PDF version of the proceedings now online at

http://act.yapc.eu/ye2012/stuff/proceedings_ye2012.pdf

Due to some (legitimate) criticism I received for complaining about MySQL in another forum without bothering to say why, here is my list of my top MySQL complaints:

• CHECK constraints are parsed and then ignored
• No custom data types!!! (This really hurts me)
• No partial index support
• No subqueries on views
• Default values are severely crippled
• Cascading updates and deletes will not fire triggers
• No multiple triggers of the same type
• No triggers on views

Yes, triggers should be avoided, but if you can't avoid them, don't cripple 'em.

Many of these issues force devs to push logic into the application layer where they're far more likely to be buggy.

Actually, if I could just have three of those fixed, I'd want custom data types (with operators, please), sane default values and check constraints.

I'm happy to announce that version 0.46.1 of the Perl MongoDB driver has been released to CPAN! It should make its way to your local mirror soon. This release has mostly minor bugfixes and some housekeeping, but more and better stuff is coming down the line. I've written a detailed post about the release and future plans on my blog here: MongoDB 0.46.1 Released . Enjoy!