What do you get when you cross a parrot with an elephant? Find out! PL/Parrot is a DSL construction kit for PostgreSQL, and much, much more. Stay tuned for more details. David Fetter will give us the ins and outs of PL/Parrot.
This meeting will take place on Tuesday, May 25th at 7pm at Six Apart World Headquarters.
Parrot home page: http://www.parrot.org/
PL/Parrot on GitHub: http://github.com/leto/plparrot
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.
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.
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.
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.
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
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.)
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?
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.
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.
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.
