FAQ
After upgrading to 5.7, I occasionally got the following error when
starting my server:

$ CATALYST_DEBUG=1 perl script/blog_server.pl -r
Warning: Use of "require" without parentheses is ambiguous at (eval 94)
line 1.
syntax error at (eval 94) line 2, at EOF
Compilation failed in require at script/blog_server.pl line 52.

This was very annoying, and since it would randomly come and go, I
couldn't debug the cause. I finally decided to run the program under
the Perl debugger, and immediately the cause of the problem became clear:

Warning: Use of "require" without parentheses is ambiguous at (eval
108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252] line 1.
at (eval 108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252] line 1
eval 'require Blog::Controller::.#Feeds;' called at
/usr/local/share/perl/5.8.8/Catalyst/Utils.pm line 252

Catalyst::Utils::ensure_class_loaded('Blog::Controller::.#Feeds',
'HASH(0x9f8d004)') called at /usr/local/share/perl/5.8.8/Catalyst.pm
line 1798
Catalyst::setup_components('Blog') called at
/usr/local/share/perl/5.8.8/Catalyst.pm line 836
-- >8 cut 8< --

As you can see, Catalyst was trying (and failing) to load emacs'
autosave files as a Controller! I don't know if emacs is widespread
enough to warrant ignoring all files that are like ".#[^/]+", but if
you're having this problem, there's the fix. Delete all non-Controller
files in your Controller folder, and you'll be very happy :)

Regards,
Jonathan Rockway

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 370 bytes
Desc: OpenPGP digital signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060728/c3cf5608/attachment.pgp

Search Discussions

  • Ashley Pond V at Jul 28, 2006 at 8:24 am
    I complained about this quite some time ago and was told to use the
    "restartregex" option to filter that out (and "scratch_file~" of
    course). Instead of suggesting that, I'll join in in complaining
    again. :)


    ?Ashley
    --

    On Jul 28, 2006, at 1:05 AM, Jonathan Rockway wrote:
    After upgrading to 5.7, I occasionally got the following error when
    starting my server:

    $ CATALYST_DEBUG=1 perl script/blog_server.pl -r
    Warning: Use of "require" without parentheses is ambiguous at (eval
    94)
    line 1.
    syntax error at (eval 94) line 2, at EOF
    Compilation failed in require at script/blog_server.pl line 52.

    This was very annoying, and since it would randomly come and go, I
    couldn't debug the cause. I finally decided to run the program under
    the Perl debugger, and immediately the cause of the problem became
    clear:

    Warning: Use of "require" without parentheses is ambiguous at (eval
    108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252] line 1.
    at (eval 108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252]
    line 1
    eval 'require Blog::Controller::.#Feeds;' called at
    /usr/local/share/perl/5.8.8/Catalyst/Utils.pm line 252

    Catalyst::Utils::ensure_class_loaded('Blog::Controller::.#Feeds',
    'HASH(0x9f8d004)') called at /usr/local/share/perl/5.8.8/Catalyst.pm
    line 1798
    Catalyst::setup_components('Blog') called at
    /usr/local/share/perl/5.8.8/Catalyst.pm line 836
    -- >8 cut 8< --

    As you can see, Catalyst was trying (and failing) to load emacs'
    autosave files as a Controller! I don't know if emacs is widespread
    enough to warrant ignoring all files that are like ".#[^/]+", but if
    you're having this problem, there's the fix. Delete all non-
    Controller
    files in your Controller folder, and you'll be very happy :)

    Regards,
    Jonathan Rockway

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Kieren Diment at Jul 28, 2006 at 8:43 am
    Right,

    Catalyst used to use Module::Plugable::Fast for component autodiscovery

    Now it uses Module::Pluggable::Object.

    This behaviour was fixed for M::P::F a while back but evidently hasn't been
    for M::P::O (and MPO produces a more cryptic error message too :( ). So if
    you're up to it, rtfs for both, make a patch for MPO and send it to the
    author or to RT noting that the behaviour was fixed in MPF a while back.

    On 28/07/06, apv wrote:

    I complained about this quite some time ago and was told to use the
    "restartregex" option to filter that out (and "scratch_file~" of
    course). Instead of suggesting that, I'll join in in complaining
    again. :)


    ?Ashley
    --

    On Jul 28, 2006, at 1:05 AM, Jonathan Rockway wrote:
    After upgrading to 5.7, I occasionally got the following error when
    starting my server:

    $ CATALYST_DEBUG=1 perl script/blog_server.pl -r
    Warning: Use of "require" without parentheses is ambiguous at (eval
    94)
    line 1.
    syntax error at (eval 94) line 2, at EOF
    Compilation failed in require at script/blog_server.pl line 52.

    This was very annoying, and since it would randomly come and go, I
    couldn't debug the cause. I finally decided to run the program under
    the Perl debugger, and immediately the cause of the problem became
    clear:

    Warning: Use of "require" without parentheses is ambiguous at (eval
    108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252] line 1.
    at (eval 108)[/usr/local/share/perl/5.8.8/Catalyst/Utils.pm:252]
    line 1
    eval 'require Blog::Controller::.#Feeds;' called at
    /usr/local/share/perl/5.8.8/Catalyst/Utils.pm line 252

    Catalyst::Utils::ensure_class_loaded('Blog::Controller::.#Feeds',
    'HASH(0x9f8d004)') called at /usr/local/share/perl/5.8.8/Catalyst.pm
    line 1798
    Catalyst::setup_components('Blog') called at
    /usr/local/share/perl/5.8.8/Catalyst.pm line 836
    -- >8 cut 8< --

    As you can see, Catalyst was trying (and failing) to load emacs'
    autosave files as a Controller! I don't know if emacs is widespread
    enough to warrant ignoring all files that are like ".#[^/]+", but if
    you're having this problem, there's the fix. Delete all non-
    Controller
    files in your Controller folder, and you'll be very happy :)

    Regards,
    Jonathan Rockway

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060728/0f9a0d01/attachment.htm
  • Jonathan Rockway at Jul 28, 2006 at 6:47 pm
    OK, I'll write a patch when I get home :)

    However, what should the filtering behavior be? I think the best
    solution would be to ignore everything that can't contain a valid perl
    package (C<package .#foo> is a compile error, as is C<package foo~>)
    That way vi (or kate / gedit / whatever) users get the bugfix too :)

    Also (in response to apv), changing the restart regex won't fix things.
    If your emacs crashed (or rather, you killed the X session without
    closing emacs first, in my case), your catalyst server won't be able to
    start until you cleanup the tempfiles with M-x recover-session or
    careful use of C<rm>. :)

    Regards,
    Jonathan Rockway

    Kieren Diment wrote:
    Right,

    Catalyst used to use Module::Plugable::Fast for component autodiscovery

    Now it uses Module::Pluggable::Object.

    This behaviour was fixed for M::P::F a while back but evidently hasn't
    been for M::P::O (and MPO produces a more cryptic error message too :(
    ). So if you're up to it, rtfs for both, make a patch for MPO and
    send it to the author or to RT noting that the behaviour was fixed in
    MPF a while back.


    On 28/07/06, *apv* <apv at sedition.com wrote:

    I complained about this quite some time ago and was told to use the
    "restartregex" option to filter that out (and "scratch_file~" of
    course). Instead of suggesting that, I'll join in in complaining
    again. :)
  • Nathan Kurz at Jul 28, 2006 at 8:08 pm

    On Fri, Jul 28, 2006 at 01:47:47PM -0500, Jonathan Rockway wrote:
    Kieren Diment wrote:
    Right,

    Catalyst used to use Module::Plugable::Fast for component autodiscovery

    Now it uses Module::Pluggable::Object.

    This behaviour was fixed for M::P::F a while back but evidently hasn't
    been for M::P::O (and MPO produces a more cryptic error message too :(
    ). So if you're up to it, rtfs for both, make a patch for MPO and
    send it to the author or to RT noting that the behaviour was fixed in
    MPF a while back.
    I've been bothered by this problem as well, and appreciate your
    efforts in tracking it down. I've just been looking at how to write
    the patch, and I found that there are some undocumented parts of
    Module::Plugable::Object that make it possible to do this in Catalyst.

    Attached is a patch that seems to work for me. The 'only' option to
    MPO tells it to use only modules that match the regular expression
    given. The regex I've chosen seems right to me, but perhaps it is too
    restrictive---I'm not sure what's actually legal for a package name.

    Nathan Kurz
    nate at verse.com

    ps. I've also found that MPO isn't the prettiest code, and it
    scares me a bit that Catalyst is built on top of it.

    ---------------------------------------------------------------------
    --- Catalyst.pm~ 2006-07-19 15:48:15.000000000 -0600
    +++ Catalyst.pm 2006-07-28 13:54:32.000000000 -0600
    @@ -1790,6 +1790,7 @@

    my $locator = Module::Pluggable::Object->new(
    search_path => [ map { s/^(?=::)/$class/; $_; } @paths ],
    + only => qr/(^|::)\w+$/,
    %$config
    );
  • Matt S Trout at Jul 31, 2006 at 1:53 pm

    Nathan Kurz wrote:
    ps. I've also found that MPO isn't the prettiest code, and it
    scares me a bit that Catalyst is built on top of it.
    No, it isn't. But it's code that has been used in production a lot of places
    for a long time, and M::P::Fast is just as ugly (due to being mostly a
    fast-hack fork of an old M::P version).

    Module::Pluggable also has a test suite and a responsive maintainer; neither
    can be said of M::P::F.
    ---------------------------------------------------------------------
    --- Catalyst.pm~ 2006-07-19 15:48:15.000000000 -0600
    +++ Catalyst.pm 2006-07-28 13:54:32.000000000 -0600
    @@ -1790,6 +1790,7 @@

    my $locator = Module::Pluggable::Object->new(
    search_path => [ map { s/^(?=::)/$class/; $_; } @paths ],
    + only => qr/(^|::)\w+$/,
    %$config
    );
    Note the '%$config' there. In MyApp,

    http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7001/lib/Catalyst.pm#%24c-%3Esetup_components

    __PACKAGE__->config({
    setup_components => { only => qr/(^|::)\w+$/ }
    });

    will fix this without requiring a patch to anything.
  • Brian Cassidy at Jul 31, 2006 at 2:59 pm

    Matt S Trout wrote:
    Note the '%$config' there. In MyApp,

    http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7001/lib/Catalyst.pm#%24c-%3Esetup_components

    __PACKAGE__->config({
    setup_components => { only => qr/(^|::)\w+$/ }
    });

    will fix this without requiring a patch to anything.
    It's probably better to do that as an "except":

    __PACKAGE__->config({
    setup_components => { except => qr/#/ }
    });


    Also, if you're using a YAML config:

    setup_components:
    except: !!perl/regexp:
    REGEXP: #

    (ugly, i know, but it works [at least for YAML 0.62])

    -Brian
  • Nathan Kurz at Jul 31, 2006 at 3:04 pm

    On Mon, Jul 31, 2006 at 02:53:01PM +0100, Matt S Trout wrote:
    Module::Pluggable also has a test suite and a responsive maintainer;
    neither can be said of M::P::F.
    Thanks, those are fine reasons to be using it. I never saw M::P::F,
    and if this is a step up then it's probably the right choice.
    ---------------------------------------------------------------------
    --- Catalyst.pm~ 2006-07-19 15:48:15.000000000 -0600
    +++ Catalyst.pm 2006-07-28 13:54:32.000000000 -0600
    @@ -1790,6 +1790,7 @@

    my $locator = Module::Pluggable::Object->new(
    search_path => [ map { s/^(?=::)/$class/; $_; } @paths ],
    + only => qr/(^|::)\w+$/,
    %$config
    );
    Note the '%$config' there. In MyApp,

    http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7001/lib/Catalyst.pm#%24c-%3Esetup_components

    __PACKAGE__->config({
    setup_components => { only => qr/(^|::)\w+$/ }
    });

    will fix this without requiring a patch to anything.
    That's true, but I think it would be better to have a more sensible
    default behaviour. In the absence of the 'only' parameter, the
    Catalyst application fails with a non-specific error message if a
    non-compilable file ending with .pm exists anywhere in the search
    path. Since this happens only sporadically (when a temporary autosave
    file exists), and since the error message makes no reference to the
    specific file, it's quite hard to figure out what is happening.

    And since the documentation for M::P::O doesn't mention 'only', it's a
    lot to expect each individual to figure out how to fix the problem. I
    think this would make better sense as a patch to Catalyst. It might
    help to understand this bug if you were to create a '.junk.pm' file
    filled with some junk, and see whether the steps to fixing the problem
    would readily be apparent. Then pretend the problem is intermittent.

    Until M::P::O is patched to have this default, I think patching
    Catalyst to supply it would be a good choice. That said, now that I
    know the source of the error message and the incantation to prevent
    it, I personally could deal just fine with setting the option myself.

    --nate
  • Matt S Trout at Jul 31, 2006 at 4:06 pm

    Nathan Kurz wrote:
    That's true, but I think it would be better to have a more sensible
    default behaviour. In the absence of the 'only' parameter, the
    Catalyst application fails with a non-specific error message if a
    non-compilable file ending with .pm exists anywhere in the search
    path. Since this happens only sporadically (when a temporary autosave
    file exists), and since the error message makes no reference to the
    specific file, it's quite hard to figure out what is happening.

    And since the documentation for M::P::O doesn't mention 'only', it's a
    lot to expect each individual to figure out how to fix the problem. I
    think this would make better sense as a patch to Catalyst. It might
    help to understand this bug if you were to create a '.junk.pm' file
    filled with some junk, and see whether the steps to fixing the problem
    would readily be apparent. Then pretend the problem is intermittent.
    How about submitting a doc patch and test back to the M::P author, perhaps
    including a better error message? :)
    Until M::P::O is patched to have this default, I think patching
    Catalyst to supply it would be a good choice. That said, now that I
    know the source of the error message and the incantation to prevent
    it, I personally could deal just fine with setting the option myself.
    Sure, but if we're going to supply defaults they should be more comprehensive
    than this; I asked on catalyst-dev@ for people to test some time before 5.70
    was released and to suggest strings that should be included, but nobody
    bothered to reply so we didn't ship one.

    Since that's two of you so far who've suddenly started to care, why don't you
    start a thread on catalyst-dev@ and we'll discuss a sensible default there?
  • Rodney Broom at Jul 28, 2006 at 8:39 pm
    From: "Jonathan Rockway" <jon at jrock.us>

    However, what should the filtering behavior be?
  • Jonathan Rockway at Jul 31, 2006 at 5:42 pm
    I tracked down the problem, sort of.

    Basically, M::P::O's default "this file is a module to load" regex is:

    qr/[.]pm$/

    Which allows lots of junk like
    ".#.#\3847*#$#!!foo!!!bar##../../../...pm" which of course cannot
    contain a valid module (only \w+ is allowed in module names; AFAIK). So
    therefore, I've changed the default regex to:

    qr{[\/:]\w+[.]pm$};

    Not quite as elegant (!), but it works. Halfway.

    This allows:

    /foo/bar/../baz/test.pm (foo::baz::test)
    /foo/bar.pm
    bar.pm
    foo/bar.pm
    foo:bar.pm (on weird filesystems)

    But disallows:

    /foo/bar/../baz/.#test.pm
    .#test.pm

    etc.

    To test this yourself, look for:

    my $file_regex = $self->{'file_regex'} || qr/\.pm$/;

    near line188 in Module::Pluggable::Object.pm, and replace the qr// part
    with that big regex above. All unit tests pass, and Catalyst works
    great. It loads valid modules, and ignores emacs' tempfiles. Exciting!

    Unfortunately, this isn't the best solution because we don't know how
    far up the directory tree to check for perl semantics. For example,

    "/cygdrive/c/Documents and Settings/jrockway/Foo/Bar.pm" (yes, Windows
    at work, unfortunately) is valid if the module we're tyring to load is
    "Foo::Bar", but not valid if we're trying to load "Documents and
    Settings::jrockway::Foo::Bar". What really needs to happen is M::P::O
    needs to open the file, check for a valid package declaration, and
    compare that to the filename. This is pretty simple and I'm working on
    it right now, but I'd like to hear other ideas. Opening each file will
    be a slight performance hit, but since it only happens once I'm OK with
    that.

    I'm on the dev list now, so please feel free to discuss there.

    Regards,
    Jonathan Rockway

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJul 28, '06 at 8:05a
activeJul 31, '06 at 5:42p
posts11
users7
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase