use Perl

It's just that "inspiration", "influence" and "instigation" are something different than "precondition". That's at least my impression as a non-native English speaker.

By the same reasoning, how can you be so certain that Perl 6 was a precondition for modern Perl? There can't be any evidence that modern Perl wouldn't have happened in one form or another if Perl 6 didn't exist.

Maybe there is simply a misunderstanding of the meaning of "precondition" in this context.

I agree with zby. The file should be available. It *is* based on Loader, so it will load the table definitions etc. automatically as I understand. Your Madre::Sync::Model::padreDB has a schema_class of Madre::Sync::Schema. Catalyst::Model::DBIC::Schema coerces that to basically a ClassName type (the name of a loaded class) by attempting to load it via Class::MOP. The coercion is declared in Catalyst::Model::DBIC::Schema::Types.

The basic issue seems to be that it can't locate that file, as zby suggests.

It seems to me that this information is already available but not yet collected. If tester reports would include the versions of the checked prereqs they could be parsed.

To think it fully through: It would start with a module that would output prerequisite version information in the test output (if this is possible). A script could parse the reports, extract the version information, and keep track of it in a database.

Another script could then take this data and generate a snapshot distribution (I'd for example be thinking of M:I's bundle feature that bundles other dists with yours AFAIU) with the highest possible dep versions. Bonus points if old snapshots are remembered and new ones only generated if all dep versions in the new snapshot are at least as high as in the new ones.

A side-effect of this would be that you'd have, for example, Catalyst community snapshots that come with all batteries included.

I'm not sure if there'd be something blocking this. It was more of just a quick thought.

My favorites are »$module should do that for me« and »I shouldn't have to think about that.«

First a disclaimer: I haven't yet participated in either the development of Perl 6 directly or any of its marketing efforts.

A few things that would trouble me as someone who hasn't been in the loop with Perl 6 for a while (I followed a bit closer in the beginning, but lost interest):

• The colors are way too active. My eyes (or rather: my eye) have to switch focus all the time when I look around on that frontpage. Together with the multicolor butterfly it just seems noisy colored. I'd prefer a more consistent colorscheme, so that if I read the right block, my eyes are at the same time still able to scan the words on the next one. This gives context. There are the traditional schools of color palletes to use in print. Personally, I'd like to pick one ground color, one accentuation color (for design and layout purposes), and use them in two or three shades of brightness when needed. For text, I almost always prefer either (if on dark background) "almost white" or (if on light background) "almost black".
• There's too much stuff in bold. The information on that page is actually pretty dense, so I think it would benefit from cleaner typesetting. Personally, I prefer using sans-serif for the body of the page, and a font with serifs (like Georgia) for the headings to have a separation.
• I find the logo itself a bit debatable. I get the playfulness, but I always thought of the Perl 6 movement as "geeky playful" not "hello kitty playful." But that's actual a rather minor point. I think people are put off by it because the site has the logo rather big on its top. It's a bit of a slap in the face. If the top-block would be smaller (and didn't contain that much text), and the logo would shrink too, it would seem much more elegant. This might require the aforementioned consistency in the color schemes with an easier-to-read palette, because if the site is this colorful itself, the logo would figuratively drown if it were smaller.
• The intro text next to the butterfly should rather sum up the Perl 6 spirit, idea and mission, and not be a call to volunteers who at that point might not even know what Perl 6 is yet. Something like

  Perl 6 is a modern high-level language integrating both experiences from decades of Perl 5 development and recent developments in other languages and comp-sci research.

  Then have a content block concerned with getting in volunteers.

On the things-I-like list are definitely the layout and the dense information. It is frustrating to have to navigate through multiple levels to find examples and such, so this works out really good.

I also want to note that I don't find the design bad, Since the layout is clean, things like colorschemes and typesetting depend on the information you want to present. I can imagine many projects for which this design would be perfect, I'm just not sure something technical like a language specification and development effort falls into that category.

And of course, ++ for doing it in the first place.

The referer is rather unreliable and can be, and is often, changed by the browser or a proxy.

I'd just check $c->action (or $c->action->reverse) instead of the path, in case you reconfigure it one day to another path. The rest is very nice :)

Ah, now I see. That sounds like a very good idea to me. I don't know if anything like this already exists. But since I remember the confusing parts of (only) moving from Austria to Germany, I can imagine this would be much appreciated, especially by people targetting countries that are further from where they are, and where the cultural differences are bigger.

That was more meant as a "isn't this already doing what you want" :) What do you feel is missing there? More meta-information?

Have you seen tripwolf?

The slot is still accessible via the MOP, which means other accessor-like methods can access it. For example, with MooseX-AttributeHelpers you could have an ArrayRef container providing push and pop methods without providing an API to directly set the array reference value.

I would see no problem with that if it was dependent on the user to declare their intended version. For example, couldn't 'use 5.010;' imply strict and warnings? Like it now implies all features in the 5.10.0 bundle?

What does core here mean? perl itself, or the bundled modules? If bundled, then there'd still be the need for the modules itself. If in perl itself, then we'd be stuck with it for a while. The fact that the common basics of Perl OO are very flexible is why we even got as far as having something as powerful as Moose. We're basically everything Scheme wanted to be. A small core (by which I mean the interpreter, not the distribution) with extensions living in libraries.