Untraceable warning: "Warning: Use of "require" without parenthesesis ambiguous at (eval 23) line 1.

Discussion in 'Perl Misc' started by Julian Mehnle, May 17, 2006.

  1. Hi all,

    I'm having problems tracing a

    > Warning: Use of "require" without parentheses is ambiguous at (eval 23)line 1.


    warning. It occurs in a larger program that has multiple "require"s and
    "eval"s, and the line numbers aren't helpful at all.

    I have tried inserting "use diagnostics qw(-traceonly -warntrace);" into
    the program, but I still don't get a stack trace, just the exact same
    warning message.

    What can I do to get a stack trace?

    TIA,
    Julian Mehnle.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEaoBMwL7PKlBZWjsRAmkJAKD7eikG+W1QkcT8Z/cX093PU5OSiwCgp5nH
    dJm4Sq9rdzd/k0Or+g5xdV4=
    =ltX1
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #1
    1. Advertising

  2. Julian Mehnle wrote:
    > I have tried inserting "use diagnostics qw(-traceonly -warntrace);" into
    > the program, but I still don't get a stack trace, just the exact same
    > warning message.


    Sorry for replying to myself, but a minor correction is in order: it's
    "-trace", not "-traceonly" (the latter is described in `perldoc
    diagnostics`, but only the former actually works).

    Julian.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEaoElwL7PKlBZWjsRAugBAKCzGnmVcsz38UmZEBYD3uyRPiKDwACfdfP0
    BkK+Hl8a66ar5b877CmziII=
    =HTp7
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #2
    1. Advertising

  3. Julian Mehnle wrote:
    > Julian Mehnle wrote:
    >> I have tried inserting "use diagnostics qw(-traceonly -warntrace);"
    >> into the program, but I still don't get a stack trace, just the exact
    >> same warning message.

    >
    > Sorry for replying to myself, but a minor correction is in order: it's
    > "-trace", not "-traceonly" (the latter is described in `perldoc
    > diagnostics`, but only the former actually works).


    Now I guess I've almost used up my good karma for this year, having to
    make yet another amendment to my posting. I did NOT mean to say that
    "use diagnostics qw(-trace -warntrace);" "actually works" to give me a
    stack trace (sorry for the ambiguous wording). It doesn't -- it just
    doesn't blow in my face as "qw(-traceonly)" (as documented in the
    diagnostics module) does.

    So how can I get a stack trace to debug this 'Use of "require" without
    parentheses is ambiguous' warning?

    Julian.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEaoKUwL7PKlBZWjsRAoR0AKCBz9AnF05xjEcPhVl97xbl8v+a1wCgj3wH
    fdrD3dRePldJ0JmIV9A5Sz8=
    =w3we
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #3
  4. Julian Mehnle

    Ben Morrow Guest

    Quoth Julian Mehnle <>:
    > Julian Mehnle wrote:
    > > Julian Mehnle wrote:
    > >> I have tried inserting "use diagnostics qw(-traceonly -warntrace);"
    > >> into the program, but I still don't get a stack trace, just the exact
    > >> same warning message.

    >
    > Now I guess I've almost used up my good karma for this year, having to
    > make yet another amendment to my posting. I did NOT mean to say that
    > "use diagnostics qw(-trace -warntrace);" "actually works" to give me a
    > stack trace (sorry for the ambiguous wording). It doesn't -- it just
    > doesn't blow in my face as "qw(-traceonly)" (as documented in the
    > diagnostics module) does.
    >
    > So how can I get a stack trace to debug this 'Use of "require" without
    > parentheses is ambiguous' warning?


    I get

    ~% perl -v

    This is perl, v5.8.7 built for i686-linux
    ....

    ~% perl -Mdiagnostics=-trace,-warntrace -le'sub foo{warn "foo"; die} foo'
    foo at -e line 1.
    at -e line 1
    main::foo() called at -e line 1

    Uncaught exception from user code:
    Died at -e line 1.
    at -e line 1
    main::foo() called at -e line 1

    However, I also get

    ~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
    Warning: Use of "require" without parentheses is ambiguous at -e line 1.
    at -e line 1

    : the warning is issued at compile time, so there is no call to &foo in
    the stack trace, indeed no stack at all yet. The file/line no should be
    right, though.

    Ben

    --
    Razors pain you / Rivers are damp
    Acids stain you / And drugs cause cramp. [Dorothy Parker]
    Guns aren't lawful / Nooses give
    Gas smells awful / You might as well live.
    Ben Morrow, May 17, 2006
    #4
  5. Julian Mehnle

    Guest

    Re: Untraceable warning: "Warning: Use of "require" without parentheses is ambiguous at (eval 23) line 1."

    Julian Mehnle <> wrote:
    >
    > Hi all,
    >
    > I'm having problems tracing a


    > Warning: Use of "require" without parentheses is ambiguous at
    > (eval)
    > line 1.
    >
    > warning. It occurs in a larger program that has multiple "require"s and
    > "eval"s, and the line numbers aren't helpful at all.
    >
    > I have tried inserting "use diagnostics qw(-traceonly -warntrace);"


    Those appear to only trace run-time warnings, not compiler warnings.
    (Even if the thing being compiled is in an eval.)


    >
    > What can I do to get a stack trace?


    Maybe:

    use Carp qw(cluck);
    $SIG{__WARN__}=sub {cluck
    $_[0]};


    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , May 17, 2006
    #5
  6. Ben Morrow wrote:
    > ~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
    > Warning: Use of "require" without parentheses is ambiguous at -e line 1.
    > at -e line 1
    >
    > : the warning is issued at compile time, so there is no call to &foo in
    > the stack trace, indeed no stack at all yet.


    Makes sense. Too bad.

    > The file/line no should be right, though.


    Well, "at (eval) line 1" isn't very helpful because there are lots of
    one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    "eval" encountered, but which one is that?

    I'm at a total loss as of how to crack this nut, save from running it
    through `perl -d`, which isn't really viable given that the project's size
    is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
    and it's a CGI application.)

    Julian.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEaxe5wL7PKlBZWjsRAgCEAKC8EtHIw/aXVXw1QDymtEm9rWOKIACdE5MR
    ePYuXN+ptgHKIeYX73TdAsc=
    =2Lfe
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #6
  7. wrote:
    >> What can I do to get a stack trace?

    >
    > Maybe:
    >
    > use Carp qw(cluck);
    > $SIG{__WARN__}=sub {cluck $_[0]};


    I tried

    use Carp qw(verbose);
    BEGIN { $SIG{__WARN__} = sub { Carp::cluck(@_) } }

    ...but it didn't help. The WARN handler wasn't invoked by the compiler
    warning.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEaxhnwL7PKlBZWjsRAnM6AKCCd+NdEOABt6jYXQPI4iHn5irH6ACgqAET
    pn2XLpugJY8zx7M/A3SHC1M=
    =SPaW
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #7
  8. Julian Mehnle

    David Squire Guest

    Julian Mehnle wrote:
    > Ben Morrow wrote:
    >> ~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
    >> Warning: Use of "require" without parentheses is ambiguous at -e line 1.
    >> at -e line 1
    >>
    >> : the warning is issued at compile time, so there is no call to &foo in
    >> the stack trace, indeed no stack at all yet.

    >
    > Makes sense. Too bad.
    >
    >> The file/line no should be right, though.

    >
    > Well, "at (eval) line 1" isn't very helpful because there are lots of
    > one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    > "eval" encountered, but which one is that?
    >
    > I'm at a total loss as of how to crack this nut, save from running it
    > through `perl -d`, which isn't really viable given that the project's size
    > is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
    > and it's a CGI application.)


    Perhaps just at the command line, grep for require, with a view lines of
    context either side so that you can see if it's in an eval, and look for
    ones that look potentially ambiguous?

    DS
    David Squire, May 17, 2006
    #8
  9. Julian Mehnle

    Ben Morrow Guest

    Quoth Julian Mehnle <>:
    > -=-=-=-=-=-
    >
    > Ben Morrow wrote:
    > > ~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
    > > Warning: Use of "require" without parentheses is ambiguous at -e line 1.
    > > at -e line 1
    > >
    > > : the warning is issued at compile time, so there is no call to &foo in
    > > the stack trace, indeed no stack at all yet.

    >
    > Makes sense. Too bad.
    >
    > > The file/line no should be right, though.

    >
    > Well, "at (eval) line 1" isn't very helpful because there are lots of
    > one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    > "eval" encountered, but which one is that?


    An eval is different; here, there *is* a runtime stack and Perl should
    show it you. I get

    ~% perl -Mdiagnostics=-w,-t -e'1;' -e'sub foo {eval "require +5;"} foo'
    Warning: Use of "require" without parentheses is ambiguous at (eval 2) line 1.
    at (eval 2) line 1
    eval 'require+5;' called at -e line 2
    main::foo() called at -e line 2

    which seems to me to contain all required information; do you get
    something different?

    > I'm at a total loss as of how to crack this nut, save from running it
    > through `perl -d`, which isn't really viable given that the project's size
    > is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
    > and it's a CGI application.)


    I have to say, I can't see how you could get that warning without doing
    something pretty weird. The warning is issued for require followed
    immediately by a binary operator; you could try grepping for
    'require[[:space:]]*\+' and so on...

    Ben

    --
    And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
    * *
    Ben Morrow, May 17, 2006
    #9
  10. [A complimentary Cc of this posting was sent to
    Julian Mehnle
    <>], who wrote in article <e4f53q$i6i$-online.net>:
    > Well, "at (eval) line 1" isn't very helpful because there are lots of
    > one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd=
    >
    > "eval" encountered, but which one is that?
    >
    > I'm at a total loss as of how to crack this nut, save from running it
    > through `perl -d`, which isn't really viable given that the project's siz=
    > e
    > is non-trivial and I haven't found out yet how to reproduce the bug. (Oh=
    > ,
    > and it's a CGI application.)


    What has perl -d to do with the project size? You should get all the
    info from debugger.

    Hope this helps,
    Ilya
    Ilya Zakharevich, May 17, 2006
    #10
  11. Ilya Zakharevich wrote:
    > Julian Mehnle <> wrote:
    >> I'm at a total loss as of how to crack this nut, save from running it
    >> through `perl -d`, which isn't really viable given that the project's size
    >> is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
    >> and it's a CGI application.)

    >
    > What has perl -d to do with the project size? You should get all the
    > info from debugger.


    If I don't know how to reproduce the bug, then the number of situations I
    have to test with the debugger grows roughly exponentially with code size.

    A few minutes ago I luckily found the bug by accident (I was embedding
    RFC3066-style language tags, e.g. "en", in class names that would then be
    require'd, which would obviously fail if the lang tag had a hyphen in it,
    e.g. "en-us"). But the question remains how that bug could have been
    traced back from the warning message given by Perl.

    Perhaps Perl should be giving the _real_ line number in the _real_ source
    file in such cases, as the debugger does?

    I guess I'm going to file wish to the Perl developers on this one.

    Thanks for everyone's ideas!

    Julian.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEa0zAwL7PKlBZWjsRAhM+AJ0fG5rI5R19LZZ/UXb7Lf1mSgNVlQCg+8E1
    TuEDbwwhS6d5/U5LQ1BP5+s=
    =58TJ
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #11
  12. Ben Morrow wrote:
    > Quoth Julian Mehnle <>:
    >> Well, "at (eval) line 1" isn't very helpful because there are lots of
    >> one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    >> "eval" encountered, but which one is that?

    >
    > An eval is different; here, there *is* a runtime stack and Perl should
    > show it you. I get
    >
    > ~% perl -Mdiagnostics=-w,-t -e'1;' -e'sub foo {eval "require +5;"} foo'
    > Warning: Use of "require" without parentheses is ambiguous at (eval 2) line 1.
    > at (eval 2) line 1
    > eval 'require+5;' called at -e line 2
    > main::foo() called at -e line 2
    >
    > which seems to me to contain all required information; do you get
    > something different?


    No, that's what I get, too, if I enter in bash what you wrote above.
    However I could not call the application that way because it is a CGI. As
    I wrote, I tried saying "use diagnostics qw(-t -w)" in the main CGI
    script, but it still didn't give me a stack trace. I still don't
    understand why not, but that's what happened anyway.

    > I have to say, I can't see how you could get that warning without doing
    > something pretty weird. The warning is issued for require followed
    > immediately by a binary operator; you could try grepping for
    > 'require[[:space:]]*\+' and so on...


    As I wrote in another posting a minute ago, I did something pretty weird
    alright. In effect I was doing eval("require AppName::L10N::$lang"), with
    $lang eq 'en-us'. Hard to spot, but pretty obvious now that I found it.
    /me slaps forehead.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEa06/wL7PKlBZWjsRAhWWAJ0eXhcEukmXHk3AUQAFTWDZw09BcACZAWmD
    jONzxt/CgZccgAs6McpzM0M=
    =RGhI
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 17, 2006
    #12
  13. Julian Mehnle

    Guest

    Re: Untraceable warning: "Warning: Use of "require" without parentheses is ambiguous at (eval 23) line 1."

    Julian Mehnle <> wrote:

    >
    > wrote:
    > >> What can I do to get a stack trace?

    > >=20
    > > Maybe:
    > >=20
    > > use Carp qw(cluck);
    > > $SIG{__WARN__}=3Dsub {cluck $_[0]};

    >
    > I tried
    >
    > use Carp qw(verbose);
    > BEGIN { $SIG{__WARN__} =3D sub { Carp::cluck(@_) } }
    >
    > =2E..but it didn't help. The WARN handler wasn't invoked by the
    > compiler=
    >
    > warning.


    For me it is.

    use Carp qw(cluck);
    use Data::Dumper;

    $SIG{__WARN__}=sub {cluck $_[0]};

    foreach ( 1..10) {
    #eval "print rand + 5" ;
    eval "require +5" ;
    };
    __END__
    Warning: Use of "require" without parentheses is ambiguous at (eval 1) line
    1.
    at foo.pl line 4
    main::__ANON__('Warning: Use of "require" without parentheses is
    ambiguous at...') called at (eval 1) line 1 eval 'require^@+5
    ;' called at foo.pl line 8
    Warning: Use of "require" without parentheses is ambiguous at (eval 2) line
    1.
    at foo.pl line 4
    main::__ANON__('Warning: Use of "require" without parentheses is
    ambiguous at...') called at (eval 2) line 1 eval 'require^@+5
    ;' called at foo.pl line 8


    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , May 17, 2006
    #13
  14. Julian Mehnle

    Guest

    Re: Untraceable warning: "Warning: Use of "require" without parentheses is ambiguous at (eval 23) line 1."

    Julian Mehnle <> wrote:
    >
    > Ben Morrow wrote:
    > > ~% perl -Mdiagnostics=3D-w,-t -le'sub foo{require +5} foo'
    > > Warning: Use of "require" without parentheses is ambiguous at -e line
    > > 1=

    > =2E
    > > at -e line 1
    > >=20
    > > : the warning is issued at compile time, so there is no call to &foo
    > > : in=

    >
    > > the stack trace, indeed no stack at all yet.

    >
    > Makes sense. Too bad.
    >
    > > The file/line no should be right, though.

    >
    > Well, "at (eval) line 1" isn't very helpful because there are lots of
    > one-line "eval"s in my project, and "(eval 23)" presumably means the
    > 23rd=
    >
    > "eval" encountered, but which one is that?


    If nothing better comes along, add some:

    eval 'warn "eval warning number 1"';

    to your code. They will report both the embedded string, and the (eval
    23), so you can use them as landmarks to navigate.


    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , May 17, 2006
    #14
  15. Re: Untraceable warning: "Warning: Use of "require" without parentheses is ambiguous at (eval 23) line 1."

    Julian Mehnle wrote:
    > Ben Morrow wrote:
    > > ~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
    > > Warning: Use of "require" without parentheses is ambiguous at -e line 1.
    > > at -e line 1
    > >
    > > : the warning is issued at compile time, so there is no call to &foo in
    > > the stack trace, indeed no stack at all yet.

    >
    > Makes sense. Too bad.
    >
    > > The file/line no should be right, though.

    >
    > Well, "at (eval) line 1" isn't very helpful because there are lots of
    > one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    > "eval" encountered, but which one is that?


    You can change the default "(eval n)" to something more meaning full by
    changing...

    eval $cmd;

    ....to...

    eval qq(#line 1 "(eval something meaningful)"\n$cmd);

    Obviously if the eval is visited many times in your code you would what
    to make "something meaningful" contain something that gives you
    context.
    Brian McCauley, May 17, 2006
    #15
  16. [A complimentary Cc of this posting was sent to
    Julian Mehnle
    <>], who wrote in article <e4fic0$n05$-online.net>:
    > > What has perl -d to do with the project size? You should get all the
    > > info from debugger.


    > If I don't know how to reproduce the bug, then the number of situations I=
    >
    > have to test with the debugger grows roughly exponentially with code size=


    Apparently, you knew how to reproduce the bug when you posted.

    > Perhaps Perl should be giving the _real_ line number in the _real_ source=
    > file in such cases, as the debugger does?


    Perhaps you should have *asked* Perl to do this, as, e.g., the
    debugger does? Perhaps, look for debugging flags variable?

    Hope this helps,
    Ilya
    Ilya Zakharevich, May 18, 2006
    #16
  17. Brian McCauley wrote:
    > Julian Mehnle wrote:
    >> Well, "at (eval) line 1" isn't very helpful because there are lots of
    >> one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
    >> "eval" encountered, but which one is that?

    >
    > You can change the default "(eval n)" to something more meaning full by
    > changing...
    >
    > eval $cmd;
    >
    > ...to...
    >
    > eval qq(#line 1 "(eval something meaningful)"\n$cmd);
    >
    > Obviously if the eval is visited many times in your code you would what
    > to make "something meaningful" contain something that gives you
    > context.


    Wow, that sure is a helpful technique!

    $ perl -Mdiagnostics=-w,-t -e'sub foo {eval "require +5;"} foo'
    Warning: Use of "require" without parentheses is ambiguous at (eval 2)
    line 1.
    at (eval 2) line 1
    eval 'require+5;' called at -e line 1
    main::foo() called at -e line 1

    $ perl -Mdiagnostics=-w,-t -e'sub foo {eval qq(#line 1 "my little
    eval"\n require +5;)} foo'
    Warning: Use of "" without parentheses is ambiguous at my little eval
    line 1.
    at my little eval line 1
    eval 'line 1 "my little eval"
    require +5;' called at -e line 1
    main::foo() called at -e line 1

    I didn't know that feature, but now I found it is documented at the very
    bottom of `perldoc perlsyn`. Thanks for the hint!

    ----

    But:

    $ perl -Mdiagnostics=-w,-t -e'sub foo {eval qq(#line 1 "(my little
    eval)"\n require +5;)} foo'
    $

    Huh? It seems one cannot use parentheses in line directive filenames, or
    Perl suppresses the warnings.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEbFMowL7PKlBZWjsRAgORAKDBcmvrKw8c5v2b4rqZR6addTdHZgCePCnN
    AS+kYLgG7UyTZ4V6b1oSqUQ=
    =JJEK
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 18, 2006
    #17
  18. wrote:
    > Julian Mehnle <> wrote:
    >> I tried
    >>
    >> use Carp qw(verbose);
    >> BEGIN { $SIG{__WARN__} = sub { Carp::cluck(@_) } }
    >>
    >> ...but it didn't help. The WARN handler wasn't invoked by the
    >> compiler warning.

    >
    > For me it is.


    I believe you. I said that I could reproduce it outside my CGI
    application, but not inside. I guess it has something to do with the app
    loading CGI::Carp, which probably installs its own WARN handler and throws
    the other one away. I'm not sure, though.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEbFPawL7PKlBZWjsRAlk4AJ90XD+VN3lunOz2s8phwUOpvskJ4gCggLLA
    w8ZfUe/OLj3jB5NGBOZs1nU=
    =BbA4
    -----END PGP SIGNATURE-----
    Julian Mehnle, May 18, 2006
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric Newton
    Replies:
    3
    Views:
    9,379
    Brock Allen
    Apr 4, 2005
  2. DataBinder.Eval and Eval.

    , Jun 16, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    542
    Karl Seguin [MVP]
    Jun 16, 2006
  3. TheFlyingDutchman
    Replies:
    5
    Views:
    1,815
    Johannes Schaub
    May 13, 2011
  4. John Carter
    Replies:
    1
    Views:
    306
    Yukihiro Matsumoto
    Sep 2, 2004
  5. Replies:
    0
    Views:
    108
Loading...

Share This Page