blogs.perl.org

(For those people who don't know about it yet - ubic is a flexible, powerful, extensible perl-based service manager. Something like upstart or daemontools, but better.)

So.
Lots of cool stuff happened in last few months.

First, ubic is now cross-platform and runs on *bsd, Mac OS X and pretty much any posix-compatible OS out there (no Windows yet, sorry).

Second, installation is now as easy as possible. Just do "cpanm Ubic && ubic-admin setup", and you are done. (Pass "--batch-mode" to setup command if questions annoy you). It's even possible to install ubic in home folder without root access and use it with perlbrew or whatever you like. Even on shared hosting, if you have the ability to edit crontab there.

Third, 1.30 release finally got some new manuals. They are far from perfect, but I believe they are much better than old PODs with which it was pretty obscure for new user to figure out where to start.

I proposed to port pmtools (Perl module tools) to Perl 6.

Unfortunately, I will be porting pmtools while unsupported.

C'est la logiciel.

There has recently recently been an increase people asking, seriously or in jest, for Perl 5 and/or Perl 6 to be renamed and others offering rebuffals of various types. You could say a heated debate seems to be going on.

However, one thing stands out here: It does not seem to be clear to either party exactly why the party is saying what it is saying. And when the realization arrives, some realize that it should be fairly obvious and stop arguing, but do not make their realization public, leaving others to make the same mistake.

As such, i'll try to put it into the most simple words i can here:

The existence of Perl 6 means that for the decision makers in IT, the managers and CEOs who are not even programmers, Perl 5 appears to be obsolete.

For those of you who get the reference, great. For those of you who don’t, I recommend reading the development section over on Wikipedia.

I write this with some hesitation, because I know it’s a touchy subject that has been going the rounds recently and that people have some very strong opinions about it. Mostly I’ve been lurking: nodding here, shaking my head in disdain there. There are good points all around, but I can’t help wanting to say something, and so, I’ve decided to try to gather my thoughts and lay them out.

UPDATE: This perl bug has been fixed

I was writing some very simple unit tests last night and was baffled when one didn't work. The code was very simple, something I thought I had done hundreds of times:

return do { local $/; $fh->getline }

But I stumbled upon some weird voodoo... It's extra baffling to me considering this recent post/bug discovery by Brian D Foy.

It's not the same thing, but it seems similar to me. Unfortunately the commit that fixed Brian's bug 93548 does not fix this one.

I refactored the problem down to a pretty small sub, and am further baffled by the minor variations that cause the problem to go away.

Here is the script and the output from various perls... Interestingly this test appears to include another bug that was fixed somewhere between 5.10 and 5.12...

Chromatic makes fun of Alberto. I understand the sarcasm: much of it, I share. (Falling into editorial we seems common in Alberto’s posts.) And yet, Perl From The Outside.

Calling it Perl 6 was sensible at the time of its inception, for all the reasons chromatic outlined there in caricature. But the premise and direction of The Language has evolved dramatically since the time its name was chosen. In premise it’s a similar idea now, and at the same time one with naught in common with the original. And still, the name persists.

As programmers we (yes, us, us all, not editorial we) should know of the importance of naming: any good programmer spends a lot of time in agony over variable names and function names.

What we (the editorial, this time) have done here is refactor the entire codebase rug from underneath the variable, yet insistently kept its now-misleading name the same. Become, became: we left the frame.

On the other hand – of course! –, names create. There are no things until there are words to name them. And also: names identify. You don’t rename your son or daughter because they’ve grown and changed.

And Perl 6 is Larry’s baby.

I get that. And yet: Perl From The Outside. Perl From The Outside.

I don’t know what to say.

I reached Paris yesterday morning and went to see Alexis Sukrieh (sukria) - founder of Dancer - at his office at Weborama. I was invited to give the Moose talk there as well, and happily agreed. While I was imagining 2-4 people, the room was full and it was very nice. I got to see Damien Krotkine (dams), who is also a core Dancer developer, and one hell of a guy.

Paris is really beautiful, and it's most beautiful when you don't take the regular route, and instead spend time in the smaller streets, and seeing life through the eyes of a Parisian and not a tourist. I still carry my camera with me everywhere (and I only finally put the suitcase at home in the evening) so that kind of spoils it a bit. :)

The installation of Movable Type on this site was a couple[1] of versions behind so last night I decided to update the site to version 4.37.

Unfortunately, while carrying out the update, I skipped a vital step. I forgot to copy over the many site specific plugins which are installed here. This meant that for approximately ten hours overnight (UK time) the site was broken and it was impossible to create new blog entries or to post comments.

I think the problem has been fixed and the site should now be back to normal.

Apologies for the problems. I'll be more careful next time.

If you see any problems with the site, please report them over on github.

[1] For embarrassingly large values of "couple".

Hi Folks

Yep, both Marpa-style grammars and Set::FA::Element-style state transition tables can now be graphed.

As always, the demo page is the place to start.

After that, hit CPAN.

[This is now [perl #93548]]

Perl 5.14 added a return value to given if you put it inside a do. However, it looks like that return value can't be a value in a lexical variable the you define inside the given:

Some CPAN modules I inherited used the old Test.pm for some of their t/*.t scripts instead of the more modern Test::More. This annoys me to no end because Test.pm is very limited. When I worked on Config-IniFiles, I did the conversion manually, which was a lot of work. More recently, I started working on XML-LibXML which has over 40 of those pesky Test.pm scripts, and I did not have the nerve to do all the manual and menial work.

As a result, I ended up spending a few hours studying PPI (the Perl Parsing Interface), and writing a script to automatically convert Test.pm-based scripts to Test::More. The main issue at hand was that in Test.pm, a single argument ok() tests for the scalar's truth, while a double argument ok() tests for simple equivalence (similarly to Test::More's is()). Eventually, I got the script working, with some limitations (see the page).

The Astro-satpass distribution contains classes to compute satellite position and visibility. If you are using it, please read on. If you think I should continue to deliver change notifications via this blog, please let me know, otherwise I will stop doing so, and merely give notice via electronic mail.

On June 11 2011 I wrote about the changes to the Astro::Coord::ECI::TLE pass() method which were in release 0.039_04. The blog entry detailed those changes and expressed the intent to make another release in about two weeks.

A respondent questioned the performance of the pass() method when the interval attribute was positive. This attribute causes the pass() method to return periodic positions during the pass, as well as the significant events of the pass. Investigation revealed a serious inefficiency in this functionality, and turned up some more “edge case” pass prediction problems.

First, please, you are free to comment, but I do not want to open a flame war or anything. Also, I do not think this is the place for this to be discussed. This post is just my humble opinion.

I think Perl 6 is a bad name for the new language Larry (and Damian and others) are defining. First, before the language, although based on Perl 5, is a new language. Second, because the name is around for too many time, making it bad advertising for the language itself, and for the community. Third, because it makes hard to Perl 5 to advance.

In fact, I think that keeping the name of the new language as Perl 6 is bad for everybody, from the people that do not like Perl 6, for the people who love Perl 6, and for all the community members.

hi there,
Am new to perl. been very determined make some lines of code fromRandal l. Swartz work.
It reads:
write a subroutine named greet, that welcomes the person you name by telling them the name of the last person it greets.

like; greet('fred');
greet('Barney');

This sequence of statement should print:
Hi Fred! you are the first one here!
Hi Barney i've seen Fred
Hi Wilma i;ve seen Fred Barney
HI Betty ive seen Fred Barney Wilma.

I have folloed the tips and even implemented defined operator and state but nothing seem to work. Anyone with extensive knowledge of this should please help me with the answer.

A few days ago we began moving things together to form the conference schedule. It was ready a couple of days ago, and after talking to the speakers and making a number of changes, we are proud to present the schedule to a wider audience.

YAPC::Europe 2011 "Modern Perl" Schedule is publicly available: Monday 15th, Tuesday 16th and Wednesday 17th of August are full of Perl talks.

This year we easily filled four talk tracks for the whole three days of YAPC. The first day even contains five. All the talks start at 10 a.m., and together with the fact that Riga Old Town is small enough, it would be quite convenient for many of us to show up at the conference a bit before 10 in the morning.

The first two days will be opened with the keynotes given by Larry Wall and Damian Conway. The names say everything.

Here's one for the "stupid shell tricks" category:

I made myself a shell alias today to simplify the times when i want a quick view of how something works in perl:

alias perl1='perl -MData::Dumper -MYAML::Any -MClass::Autouse=:superloader -E "sub D(\$){ say Dumper(shift) } sub Y(\$){ say Dump(shift) }"'

I'm not quite sure about the name, and I may add more helper functions, but a handy alias like this one allows me to type this at the shell:

perl1 -E 'D [File::Spec->path]'

Instead of

perl -MData::Dumper -MFile::Spec -E 'say Dumper( [File::Spec->path] )'

I don't have to type out -MData::Dumper and I can use D instead of say Dumper()

Plus, thanks to Class::Autouse and it's :superloader import tag I don't have to type out Module::Name ("File::Spec" for example) multiple times just to get a quick glance at it's output.

I haven't decided yet if I want to just append " -E" to the alias. That might get in the way if I want the "-n" or "-p" flags or multiple -E's or something...

Anyway... thought that was handy; Thought I'd share.

I got tired of seeing my SQL in big, ugly grey walls of text in my Perl code, so I wanted to syntax highlight them. Of course, since I'm working with a large code base which has evolved over many years, it's simply not possible (or desirable) for me to rip these out and replace them with SQL::Abstract or something else (as has already been suggested) lest I spend a few weeks not developing features and hoping I didn't introduce bugs.

Fortunately, vim allows you to be rather flexible about this.

Probably you do not agree with my point of view, but I think that adding version numbers to sub-modules is, most of the times, counter-productive.

Explaining what I mean by adding version numbers to sub-modules. If I have a module, named Foo::Bar that ships with Foo::Bar::Helper, probably I don't want to add a version to Helper module.

Or if you do, be sure to keep or increment it on every release you do.

Why this matters? Well, it matters to the people who use cpan and the r command to check for outdated modules:

CHI::Driver::Role::HasSubcaches     undef      0.45  JSWARTZ/CHI-0.45.tar.gz
CHI::Serializer::JSON         undef      0.43  JSWARTZ/CHI-0.43.tar.gz
CHI::Test::Class              undef      0.39  JSWARTZ/CHI-0.39.tar.gz
Mason::DynamicFilter           undef      2.06  JSWARTZ/Mason-2.06.tar.gz
Mason::Plugin::Defer::Filters     undef      2.01  JSWARTZ/Mason-2.01.tar.gz

Very basic introduction with example about how to use Devel::Cover to improve your tests.

Read the article.

Programs, modules, and distributions are different things, but we are often loose with the language. In CPANizing Behavior and Democratizing Publishing, chromatic conflates two issues that are really only loosely connected: making modules and releasing code as a Perl distribution.

Distributions are merely the unit of things we give away. A Perl distribution has a conventional structure, and usually contains modules. However, there's no requirement that it contain any modules. It doesn't even have to contain Perl code. It's quite easy to distribute a non-module Perl program in a Perl distribution. The major installers handle it just fine. You can even extend the installers right from the distribution, doing almost anything you wanted.