This patch defines a RECURSION_LIMIT macro in include/parrot/sub.h,
which interp->recursion_limit is assigned to in src/inter_create.c.
It's currently hardcoded as 1000 in inter_create.c.
> Thanks! Applied in r17863.
It would be pretty simple to make this a settable/queryable interpreter
property. Would that be valuable?
It's already a gettable interpreter property
(interp->recursion_limit). I'm guessing it would be valuable to be
able to set the value at runtime. Coke mentioned this on #parrot.
Unfortunately, I don't know how to implement this. Any takers?
$P0 = getinterp
$P0["recursionlimit"] = 2000
$P0["recursionlimit"] = -1
Where the last one signifies an infinite recursion limit (unsafe, but
it should still be available to HLL implementors).
Come to think of it, why are we using a keyed interface at all? Why
can't we just use getprop and setprop, or getattribute and
setattribute? It's what they were designed for, after all.
On 3/30/07, Nicholas Clark <ni...@ccl4.org> wrote:
> On Fri, Mar 30, 2007 at 10:25:59PM +0000, Alek Storm wrote:
> > How about like this:
> > $P0 = getinterp
> > $P0["recursionlimit"] = 2000
> > $P0["recursionlimit"] = -1
> > Where the last one signifies an infinite recursion limit (unsafe, but
> > it should still be available to HLL implementors).
> Is the value "recursionlimit" signed or unsigned?
> Using 0 to flag the infinite recursion limit might feel more natural.
> Using -1 to mean ~0 makes me edgy. In particular, because in C you can end
> up with integer size promotion meaning that -1 isn't -1. Or at least what
> you thought was -1 isn't -1 any more, because it was converted to unsigned,
> and then converted to a larger unsigned type, and so is now an unremarkable
> positive integer, rather than all bits set.
> Nicholas Clark
Is the value "recursionlimit" signed or unsigned?
The interpreter already has it:
where $P0 isa ParrotInterpreter
recursion_limit(Parrot_Interp interp, PMC *self, int l)
int ret = interp->recursion_limit;
interp->recursion_limit = l;
Pass. It has methods, and access to the internal data of the interpreter
object should go through those methods.
Do you mean a PCCMETHOD? If we're just getting and setting attributes, I
really think we should be using getattribute and setattribute, or getprop
and setprop, instead of expanding the ParrotInterpreter namespace with a
bunch of simple getter and setter methods.
getattribute and setattribute are only implemented on ParrotObjects (and
other implementations of high-level objects). And really, even on
ParrotObjects getattribute and setattribute should only be called inside
the class itself. All external code using the object should access the
attributes through accessor methods (preserving encapsulation).
getprop and setprop are completely different, they access (extra) data
attached to a PMC as a hash at runtime.
Read docs/ops/object.pod and docs/ops/pmc.pod.