use Perl

Am I the only one whose OCD goes on overdrive everytime he sees a fixed-function tree traversal sub?

I immediately want to refactor &show into a general traversal sub:

sub traverse(%tree, Traversal $order, &function) { ... &function(%tree<VALUE>); ... }

and a trivial driver:

sub show(%tree, Traversal $order) { traverse(%tree, $order, &take) }

I guess that gets away from keeping the same overall form as the E02 code. Of course, I had the same reaction the first time I read the original code in E02 ....

It's been over a month since my last entry. Life pretty much had me swamped for the last five weeks, but nevertheless I did get some Plumage work done.

When last we left off, Plumage had just managed to install its first project, thus moving from the "infant" to "toddler" phase of development.

After posting for Day 6, Tene and I realized that the instructions section of the metadata spec needed to change -- the original "design" didn't survive actual implementation. While I made the necessary spec changes, Tene++ worked on several iterations of an HTTP fetcher i

"Day" 6 turned out to actually be hours here and there from most of the week. After Tene's initial Makefile patch initiated Day 5, Tene and darbelo began to pester me for details on the design and current capabilities. Once he realized it wasn't as far along as he needed, Tene switched his p

Shortly after Day 4 day job deadlines loomed, and I expected Day 5 to be delayed at least a week. Thanks to some late nights this morning's status meeting at the day job went well, so Tene++'s ping on #parrot caught me with a few spare tuits and the strong desire to take a break from the tasks of the last few days.

Day 1 and Day 2/3 got me (mostly) prepared to begin the actual coding for the Parrot Plumage prototype. There were just two things left to figure out: how to access command-line arguments, and how to initialize complex data structures.

After spending Day 1 mostly exploring the boundaries of NQP, I was hoping to put the pedal to the metal and start the Parrot Plumage implementation in earnest. I ended up with more bald yaks instead.

The time has clearly come to start work on Parrot's module ecosystem -- the module installer, search tool, dependency checker, and so on. We've been discussing various pieces on #parrot, #perl6, and parrot-dev for a few weeks, and a couple weeks ago we reached rough consensus. At that point, I collected all the comments and emails and wrote up a draft design document. I guess you could call that 'Day 0'.

Modern Perl ...

* uses no deprecated or "evil" features
* freely uses features of recent Perls and recent module versions
* discards contortions used for compatibility with ancient Perls and ancient module versions
* uses newer, cleaner, more powerful modules, rather than decade-old modules generally agreed to be showing their age
* generally follows current best coding and interface practices (but may decide to ignore specific recommendations when appropriate)
* follows best security practices
* shares with others: performs decently without hogging system or network resources

Other than the ability to barf on local changes, this is a subset of the already existing languages/perl6/tools/rebase_rakudo.pl . Would you mind merging your idea into that script, for example by adding a new option?

To frame the discussion, it might help to know what our current constraints are. For example, if we decide to replace rt.perl.org, are we limited in our choice by available hosting hardware, or admin expertise (of other tracking products), or admin tuits? Are any of those constraints so tight that we will need to seek donations or grants to allow us to make the best choice for Rakudo and Perl 6?