On Sun Dec 08 17:40:36 2013, zef...@fysh.org wrote: > Will Coleda via RT wrote: > >It's dealing with a specific behavior needed of the VM by rakudo which > >isn't appropriate to push into nqp > ... > >At which point the limit on each backend will no doubt need to be > >different, > > Interesting: your view here implies a rather different intent to the > recursion_limit code than any of the options I considered. I'd supposed > that the intent was to provide a settable recursion limit where possible, > looking essentially similar to HLL code across VMs, with only the > implementation differing. But if essentially different behaviour is > wanted per VM, that sounds more like you're intending to cope with > different kinds of limit imposed by each VM, hiding it entirely from > HLL code. > > If the intent is to cope with, and hide, the fact that Parrot imposes a > (low) recursion limit by default, the value you should set the limit to > is -1. That is, -1 as it appears in the interpreter recursion_limit > method that takes a Parrot int (signed word) for its parameter. > Internally the recursion limit is interpreted as an *un*signed word, > so the -1 becomes the highest possible value. In fact, since the > comparison (in src/pmc/sub.pmc) is of the form depth>limit, with the > limit at all-bits-one the exception can never be triggered even if the > depth count somehow becomes decoupled from actual stack frame records > and grows enough to wrap around. > > -zefram >
Rakudo no longer targets the parrot backend of NQP - I've removed the code in rakudo that set the recursion limit since it's a noop on the backends we do target, closing this ticket. The code to attempt to set the recursion limit still exists in NQP - If someone feels strongly about cleaning up NQP, a PR can be opened at https://github.com/perl6/nqp - be sure to include a reference back to this ticket. -- Will "Coke" Coleda
