lib/Scrappy.pm | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 spelling errors

lib/Scrappy/Plugin.pm | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 plugins: call initializers in correct order

According to Class::MOP::Attribute manual:

Note that there is no guarantee that attributes are initialized in any
particular order, so you cannot rely on the value of some other attribute when
generating the default.

This is exactly what was being done, causing test failures ever since hash key
order was randomized (RT#82142):

Can't use an undefined value as an ARRAY reference at lib/Scrappy/Plugin.pm line 21.

Let's just initialize plugins() lazily -- it will still be initialized upon the
instance creation, since registry() will trigger it, just in the correct order
now.

lib/Scrappy/Scraper/Control.pm | 14 7 + 7 - 0 !
t/00_test_function_control.t | 2 1 + 1 - 0 !
2 files changed, 8 insertions(+), 8 deletions(-)

 fix scrapy::scraper::control and its test

It's rather broken, possibly due to some careless copy & pasting:

* in restrict() and allow(), "next" outside loops is used in place
  of function returns
* in is_allowed(), argument is assumed to be an URI instance despite the
  function takes a string. Also, a chunk of code (apparently copied from
  lines above), mistakes allowed() for restricted() and apart from that
  leaves the logic reversed.
* Moreover, the test does not pass a valid URI to a subroutine that
  expects one

The silly condition is left as entertainment for future generations:

     if (keys %{$self->restricted}) {
         if (keys %{$self->restricted}) {

lib/Scrappy/Action/Generate.pm | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)

 scrappy creates files with interesting permissions like --w