The style of returning different things in list vs scalar context has been debated for a long time (for a particular example, this thread in Perlmonks).
A few months ago I made a decision that all API functions in one of my projects should return this:
That is, we can skip error checking when we don't want to do it.
Now, in the spirit of Fatal and autodie, I am changing the above to:
return wantarray ? ($status, $errmsg, $result) :
do { die "$status - $errmsg" unless $status == SUCCESS; $result };
But somehow I can still see myself and others tripping over this in the future, as I have, several times so far. It's bad enough that for each API function one already has to remember the arguments and their types, and one kind of return and its type.
Maybe I should just bite the bullet and admit the misadventure into wantarray(), and that context-sensitive return should be left to @foo, localtime(), and a few other classical Perl 5 builtins that have been ingrained in every Perl programmer's mind.
While this is often a Subversion versus mercurial/git argument, I want to look beyond that. Can anyone offer me any compelling reasons to choose centralized over decentralized version control? I'm not even talking about weighing pros and cons (because if you did, centralized source control would lose badly). I'm just curious about any good, solid reasons to choose a non-decentralized source control system.
Is this the obligatory "hello blogs.perl.org" post? I guess so. I will no longer be updating my old use.perl.org journal. Not that I updated it very much to begin with.
Which leads to my point. For a long time, I engaged the Perl community under my screen name "revdiablo", but I've been slowly migrating away from that in favor of simply using my real name. I haven't really thought about a way to smoothly transition, so I'm leaving my screen name on old accounts and using my real name for new accounts. Hopefully, at some point, my screen name will fade into obscurity.
Unfortunately, there are probably still some people who recognize me only by the screen name. Maybe they will see this and take notice. Are any of you one of them?
[I actually wrote this a long time ago and it's been stuck in the draft status. I don't have answers for these yet.]
I've been swamped with work lately, and despite perl5-porters giving me and everyone else plenty of time to update all of our modules for the next major release, I basically ignored Perl 5.11. Life sucks sometimes, then they release anyway. This isn't really a big deal because all the CPAN Testers FAILs go to a folder that I look at all at once. It's a big deal for other people when they try to install a borken dependency and cpan(1) blows up.
However, my negligence in updating my CPAN modules reminded me of a possible best practice that has been on my mind for a long time, and which I've casually brought up at a couple Perl QA workshops since I've written several Test modules. Don't rush to say Test::Class just yet.
It's the first Software::License::* not in the core Software::License distribution (RJBS refused my patch to integrate it). It might not be for long, FLORA has threatened to release WTFPL support.
Whenever I start on a new team, there's one thing I want and never get. I'm not a betting man, but I've even bet that this thing I want won't happen. I've never lost that bet.
When I started writing the new Test::Harness, I had a .perltidyrc file which, while not perfect, allowed me to easily format my code with the following vim mappings:
nnoremap ,pt :%!perltidy -q<cr> " only work in 'normal' mode
vnoremap ,pt :!perltidy -q<cr> " only work in 'visual' mode
Do you find Perl 6 interesting, but maybe not very accessible? Would you like to contribute half an hour of your time, if it doesn't involve learning a few new languages and weird parrot assembler langauges?
Then participate in the Perl 6 contribution challenge. No sign-up required, and there will be one task per week with which you can actually help the Perl 6 users and developers without needing to dive too deep into compiler guts.
I've just released Marpa,
a general BNF parser generator, to CPAN.
(A general BNF parser generator is a parser generator which works for any grammar you can express in BNF.)
Previously, CPAN did not have a general BNF parser generator suitable
for practical use.
Then again, neither did much of anybody else.
What was the issue?
General BNF parsers have been around since the 60's.
But the first ones were slow, and the reputation stuck.
It's time to take a new look.
As
Wikipedia says,
Earley's takes
"linear time for almost all LR(k) grammars.
It performs particularly well when the rules are written left-recursively."
LR(k) grammars
include all those parseable by Bison, YACC, recursive descent,
or regular expressions.
Chances are that
Marpa runs in linear time on your grammar, or can
easily be made to do so.
If Marpa doesn't run your grammar in linear time,
chances are that the alternatives you are considering
do not run your grammar at all.
Forum software is frequently awful. In trying to write a minimal version on my own, I've discovered that mine is just as awful, so I'd rather use someone else's awful forum software. I'm sure it will be less awful than mine. Naturally, I'd prefer it to be Perl as I can hack on it if need be.
Unfortunately, this is to be integrated into an existing Catalyst application. Integrating multiple Catalyst applications into a single application isn't an easy task. There's CatalystX::Features, but I've not yet looked at it terribly closely. I think a better solution would be to find an existing, solid forum application and use Apache URL rewriting to make the two apps appear to be integrated.
Regardless of what approach I take, I really don't want to keep trying to write my own forum software. That's a waste of my time. What would you recommend?
I arrived a bit late but hadn't missed much. Gabor was in the middle of explaining the benefits of getting Perl on Android. He went over a lot of API examples, showing code and explaining and doing a damn goo job at it!
After that, I tried to explain how to install the Android emulator on a Linux machine, configure it and run it. My slides weren't displaying properly on the projector so it was annoying to explain and probably harder to understand.
Then Shmuel went over perl512delta and explained to us the bigger differences and their implications. He said "... because someone had to do it" - and I'm happy someone did.
Lately I've been tempted to use croak() instead of die(). Somehow it seems more considerate to users. But finally in the end I'm sticking with die(). In fact, I think the Carp module should be, well, croaked.
The reasons:
1. Even though Carp has been included in Perl 5 since forever (Module::CoreList tells me: "5"), carp(), croak(), cluck(), and confess() are still not builtins, which means I still need an extra "use Carp".
2. Too many keywords! Most other languages only have "throw" or "raise".
3. Names are too weird! I understand the difficulty of coming up with a concise set of names that are similar but slightly different. But requiring these weird names might also indicate that there is something fishy about the concept itself.
4. The choice of showing a stack trace or not should not be in the individual functions. That burdens the programmer with too much thinking.
5. Even with Carp qw(verbose), what's to be done with codes that still die() and warn()? (But luckily there's Carp::Always.)
Often times I find myself wondering how Open Source is even possible. How does something so amazing as CPAN get built and maintained and perfected?
I think I figured it out, at least one part of it.
It is possible because there are a lot of smart people out there being employed by employers who have no real idea of what is required in any given project. Therefore, programmers who have
tremendous flexibility to get "whatever they want" done to accomplish a given project
employers/managers who don't know the first thing about what is required to create an application
can contribute amazing feats of collective heroism day in and day out, without having to worry about how they are going to pay for new shoes.
And then of course there is boredom. And the sheer enjoyment of coding. And altruism.
When you're thinking of packaging every piece of code as a CPAN module.
A couple of days ago I need a subroutine that takes a nested data structure (e.g. {vol1 => {a=>{b=>{c=>10}}}, vol2 => {a2=>{b2=>{c2=>20}}}}), a Unix-like path string (e.g. "vol1:/a/b/c") and return the branch/leaf node of the data structure according to the specified path (in this example, 10).
After browsing CPAN and a few minutes of reading the POD of some modules and not finding exactly what I wanted [*], that subroutine idea quickly transformed into an idea of a full-fledged CPAN module. The next day I uploaded Data::Filesystem to CPAN, which is actually yet another Data::Walker- / Data::Path- / Data::DPath-like module.
A few days ago Shmuel Fomberg (who organizes Haifa.pm) wrote in the Israel.pm mailing list: "Sawyer is doing so many interesting things currently, that it is ridicules. Sawyer, please take a long vacation to let us all catch up!".
While this truly flatters me, I reckon that's how I think of a lot of other developers (and I'll refrain from the usual name-dropping I'm accustomed to). Whatever I play with is always minimal in comparison to the stuff I see in the Perl community. This includes both Devel::Declare and the amazing Perl Onion Pillow.
Its a magazine most of you here would not read, bacause it explaines most of the time basic perl stuff. But many of you, I guess, care that there is a beginnerfriendly Perl publication. So do I. Thatswhy i wrote 2 articles for this isssue. About Perl 5 references and one about Perl 6. Also Perl beginner have a right to have a broad overview what is perl 6 about and how it is going. I think I never summarized it in such simple terms before. Maybe that spark your interest? :) But its written in German, as the name suggest.
I'm only a year late with this post; I wrote it in the airport in Moscow on the way home, then it never made it onto the blog. I need to published it before the next YAPC Russia, which is June 12-14 in Kiev this year.
This might be the only YAPC::Russia 2009 report you read, if only because I was the only presenter in english and maybe the only one writing about it in english. While everyone else's english got better over the conference, I think my Russian got worse.
The best reason to go to a conference is to meet new people, to see new places, and, oh, sometimes to see new code. The more interactions that we can get between the different parts of the physical world the better. If you always go to the same conference, you might be limiting the people you can meet.
Many people have been seeing the cryptic error message "Text Entered Was Wrong" when trying to use this site. It was caused by MT expecting to see the response from a CAPTCHA which wasn't being displayed.
It's taken us a while to get to the bottom of this problem, but we think that we have fixed it now. We think that the CAPTCHA will now be displayed in all of the circumstances when MT thinks it has been displayed.
Sorry for the inconvenience this has caused. Hopefully this will allow a larger selection of people to use the site successfully.
As always, please let us know if you are having any problems with the site.
