http://www.perlmonks.org?node_id=757207


in reply to Error ... at (eval 75) line 7974.

You might try explicitly setting a more meaningful line number and name via the #line directive (similar to what many incarnations of cpp grok): 

my $line = 99;
for my $n ( qw/foo bar baz/ ) {
  my $code = <<"EOT";
#line $line "$n"
die "aieee!"
EOT

  eval $code;
  if( $@ ) {
    print "Died: $@\n";
  }
}
__END__
Died: aieee! at foo line 99.

Died: aieee! at bar line 99.

Died: aieee! at baz line 99.

[download]

See Plain Old Comments (Not!) in perlsyn for more details.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^2: Error ... at (eval 75) line 7974.
by syphilis (Archbishop) on Apr 14, 2009 at 08:09 UTC
    You might try explicitly setting a more meaningful line number

    Well ... yes, I might have to try and do something like that, though at this stage I've no idea where that line number needs to be set. But then, I haven't even yet made a serious attempt to find the string eval responsible. I do know that the error occurs after (in Inline/C.pm) $parser->code($o->{ILSM}{code}) gets called and before it returns. ($parser is a Parse::RecDescent object, and code() is a Parse::RecDescent method.)

    The problem occurs only with Inline::CPP and Parse::RecDescent versions later than 1.94 (no problem with Inline::C), and has already been reported for Parse-RecDescent-1.95 at http://rt.cpan.org/Public/Bug/Display.html?id=33366. Obviously, the issue has not been addressed in 1.96, though it could be an Inline::CPP bug faik.

    For the time being I can live with the fact that Parse-RecDescent-1.94 (or perhaps earlier) is specifically needed. No doubt I'll continue to investigate as time and energy permit.

    Many thanks for the replies.

    Cheers,
    Rob
[reply]
[d/l]
[select]

      Have you tried enabling trace? our $::RD_TRACE = 1;

      If that output doesn't help you track back to the C/C++ code that's being mis-parsed, then you could try my old standby: 

      perl -d:Trace yourICscript.pl 2>trace

      [download]

      You'll want to ensure you have plenty of free diskspace and something else to do for a few hours--sleeping's good. Cos a program that would run for a few seconds normally, can take hours. But generally, especially if you can make the error fatal (maybe Fatal?), then when it stops the last couple of hundred lines of the trace tell you everything you need to know.

      If you want to get sophisticated, you can turn the tracing off at the top of your program and then turn it on just before whatever line of your code instigated the code that issues the warning. It can get you there more quickly. Good luck.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        Have you tried enabling trace?

        I just tried the -d:Trace and that did give me the line number in P::RD where the eval is called. It was indeed line 7974 (which comes from Inline/CPP/grammar.pm) of that string that was causing the problem: 
        $return .= join '',' ',@{$item{$Inline::CPP::grammar::star}} if @{$ite
+m{$Inline::CPP::grammar::star}};

        [download]
        So I made the excution of that line of code conditional upon $item{$Inline::CPP::grammar::star} being defined, and the problem went away.

        Unfortunately, that's not the whole solution, as the grammar is still broken. From the first inline::CPP test script (during 'make test') I now get: 
        _01basic_t_5cd2.c: In function `void XS_main__Soldier_new(PerlInterpre
+ter*, CV*)
':
_01basic_t_5cd2.c:79: error: no matching function for call to `Soldier
+::Soldier(
)'
_01basic_t_5cd2.xs:16: note: candidates are: Soldier::Soldier(const So
+ldier&)
_01basic_t_5cd2.xs:30: note:                 Soldier::Soldier(char*, c
+har*, int)

dmake:  Error code 129, while making '_01basic_t_5cd2.o'

        [download]
        Given that Inline::CPP is no longer maintained, I see little point in digging further ... though, of course, pointlessness does not necessarily deter me :-)

        I'm just glad that Inline::C hasn't similarly been destroyed by the latest versions of P::RD.

        Cheers,
        Rob
[reply]
[d/l]
[select]

      For others who may have run into this and subsequently destroyed their brain like the rest of us, I believe the exact change in RecDescent that is causing issues is this:

      (from the Changes file) 

      1.90    Tue Mar 25 01:17:38 2003


        - BACKWARDS INCOMPATIBLE CHANGE: The key of an %item entry for
          a repeated subrule now includes the repetition specifier.
          For example, in:

                sentence: subject verb word(s)

          the various matched items will be stored in $item{'subject'}
+,
          $item{'verb'}, and $item{'word(s)'} (i.e. *not* in $item{'wo
+rd'},
          as it would have been in previous versions of the module).
          (thanks Anthony)

      [download]

      In my case, I had something like this: 

              Item(s) EOF
        {
                $return = [ @{$item{Item}} ];
        }

      [download]
      and it *should be*: 
              Item(s) EOF
        {
                $return = [ @{$item{qq(Item(s))}} ];
        }

      [download]

      Check other sub-rules for similar kind of behavior and hash referencing.

      It's also actually already documented within the grammer included by Inline::CPP:

      http://cpansearch.perl.org/src/SHASSAN/Inline-CPP-0.27/grammar/grammar.pm

      Unfortunately to figure it out myself, I had to take the long road on an entirely different piece of older code. Just the type of thing to make one tear their hair out unless they know the exact place to look.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom