in reply to Unexpected 'panic: top_env' in regex match

there was a typo in there that had taken a (?<=) positive look-behind assertion and turned into (?<), a meaningless abomination.
If we could see the regex (and perhaps the data that was being matched) it would go a very long way to helping us solve this conundrum1.
HTH

_________
broquaint

1 although I think it's something to do with re-entrancy (or some such) in the regex engine as I've come across similar problems before and it's likely to be fixed in 5.8.0 and beyond

  • Comment on Re: Unexpected 'panic: top_env' in regex match

Replies are listed 'Best First'.
Re: Re: Unexpected 'panic: top_env' in regex match
by mowgli (Friar) on Jan 21, 2003 at 15:09 UTC

    Thank you - I'm still using 5.6.1, so this may indeed have caused the error. The regex thas was triggering this itself was m/(?(?{!$i})(?{s{[\w\s]*(?<=u\ )\w+.*}{just };print)|(?{print}))/, part of my (as of yet unfinished) attempts to write my first obfuscated bit of perl.

    --
    mowgli

[reply]

      The expression engine is not re-entrant. You attempted to do a substitution during an eval during a conditional in a match. Also, it looks like you forgot the include the closing curly brace for your eval block right after the {just };print). I've had similar success with re-entrant regexes. Some work, some fail miserably. It's just sheer luck (or astounding insight) that keeps two simultaneously executing regexes from killing each other.

      Seeking Green geeks in Minnesota

[reply]
[d/l]

        Thank you a lot! The missing curly brace is probably just a typo in the node's text; the script itself, with the corrected assertion, works. With regard to nested regexes, are there plans to remove this limitation in Perl 6? Granted, it might not be a feature that would often be used, but then, the same holds probably true for match-time code evaluation, anyway.

        --
        mowgli

[reply]

In Section Seekers of Perl Wisdom