From @masak

<diakopter> masak​:
<diakopter> rakudo​:
????????????????????????????????????????????????????????????????????????????????
<diakopter> parse timeout
<moritz_> (even the timeout feels quicker today :-)
<masak> diakopter​: was that directed specifically at me? :)
<diakopter> oh oops, 'scuse me
<diakopter> masakbot​: see above
<masak> diakopter​: yes, but why?
<masak> all I see is you tormenting the implementation...
<diakopter> seems to me that's worthy of a bugreport
<masak> sure, as soon as I figure out what's wrong with it.
<diakopter> (*I'd* want to know about a parse timeout)
<masak> it's not so much a bug in Rakudo, is it?
<diakopter> yesbut
<masak> more of a bug in p6eval.
<diakopter> LOL
<diakopter> I think I see your point
<diakopter> unfortunately
<diakopter> .
<masak> I agree that it'd be nice to have the information in question
from p6eval.
<masak> timeouts are historically difficult to get right in the evalbot.
<diakopter> o wait
<diakopter> what
<diakopter> how could that be a bug in p6eval
<masak> p6eval waits X seconds to get a result back from Rakudo.
<masak> when it gets nothing, it reports 'no output'.
<diakopter> I'm confused
<diakopter> rakudo​: ???????????
<p6eval> rakudo 65e2d3​: OUTPUT«Confused at line 11, near "??????????"␤ [...]
<diakopter> rakudo​: ????????????????????????
<p6eval> rakudo 65e2d3​: OUTPUT«Confused at line 11, near "??????????"␤ [...]
<diakopter> rakudo​: ?????????????????????????????????
<p6eval> rakudo 65e2d3​: OUTPUT«Confused at line 11, near "??????????"␤ [...]
<masak> I run your 'program' locally, and it gives me 'Confused'. yes,
like that.
<diakopter> rakudo​: ????????????????????????????????????????????????????????
<masak> but throw enough confusion at it, and it won't have time to
report its confusion :)
<p6eval> rakudo 65e2d3​: ( no output )
<diakopter> how long does it take your local one to report Confused on
the long one above
* masak times it
* diakopter falls into the clockface
<masak> this feels quadratic to me :)
* diakopter sniffs
<moritz_> so it's still in P :-)
<masak> add it to the FAQ​: consider not writing 80 question marks one
after the other in your program.
<masak> moritz_​: I might be wrong. maybe it's exponential, even.
<diakopter> std​:
????????????????????????????????????????????????????????????????????????????????
<p6eval> std 29742​: OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Found ?? but
no !!; possible precedence problem [...]
<masak> STD++ # fast, honest
<diakopter> std​:
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
<p6eval> std 29742​: OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Found ?? but
no !!; possible precedence problem [...]
* diakopter claps
<diakopter> let me rephrase.
<diakopter> if I were the parser-generator's/interpreter's
author/maintainer, *I'd* want to know about seemingly exponential
behavior when parsing 80 question marks.
<masak> diakopter​: waiting for Rakudo to finish parsing 80 question
marks, I tend to agree :)
* masak submits rakudobug

Note​: I had to abort my local Rakudo 80-question-mark run after about
18 minutes, because my usually very trusty laptop was growing
dangerously sluggish and unresponsive, gobbling up ~1.5 Gb of memory.

@coke - Status changed from 'new' to 'open'

From @moritz

This seems to have been fixed, closing without regression tests.

@moritz - Status changed from 'open' to 'resolved'