[CVS ci] Pie-thon 1 - recursion limit

[Leopold Toetsch]

b1.py calls recursively functions, the depth is limited by the
interpreter, which throws a RuntimeException at recursion depth 1000. So
does Parrot now.

The limit can be change by:

$P0 = getinterp
.local int new_limit
.local int old_limit
new_limit = 4711
old_limit = $P0."recursion_limit"(new_limit)

leo

[Dan Sugalski]

That's fine. We should add this (and anything else we do this way) to the
interpinfo op so the values can be fetched back out, both by bytecode and
via the interpinfo call for C code.. I'm tempted to have a special op for
setting interpreter values rather than rely on methods, since this is all
very low level, and likely to be set via C code. (Where method calls into
parrot are a bit of a pain)

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

Dan Sugalski <d...@sidhe.org> wrote:
> On Tue, 22 Jun 2004, Leopold Toetsch wrote:

>> old_limit = $P0."recursion_limit"(new_limit)

> That's fine. We should add this (and anything else we do this way) to the
> interpinfo op so the values can be fetched back out, both by bytecode and
> via the interpinfo call for C code.. I'm tempted to have a special op for
> setting interpreter values rather than rely on methods, since this is all
> very low level, and likely to be set via C code. (Where method calls into
> parrot are a bit of a pain)

I think that this won't get used heavily. Anyway for this case, we can
integrate it into C<interpinfo> or some such.

OTOH we probably need to support a method interface for a lot more
things. b3.py has stuff like: TT.__cmp = Integer.__cmp, where TT is a
ParrotClass and Integer isa PMC.

> Dan

leo

[Dan Sugalski]

On Tue, 22 Jun 2004, Leopold Toetsch wrote:

> Dan Sugalski <d...@sidhe.org> wrote:
> > On Tue, 22 Jun 2004, Leopold Toetsch wrote:
>
> >> old_limit = $P0."recursion_limit"(new_limit)
>
> > That's fine. We should add this (and anything else we do this way) to the
> > interpinfo op so the values can be fetched back out, both by bytecode and
> > via the interpinfo call for C code.. I'm tempted to have a special op for
> > setting interpreter values rather than rely on methods, since this is all
> > very low level, and likely to be set via C code. (Where method calls into
> > parrot are a bit of a pain)
>
> I think that this won't get used heavily. Anyway for this case, we can
> integrate it into C<interpinfo> or some such.

It won't be heavily used, certainly, but it will get used by folks doing
embedded work. (They're the most likely users of this stuff, really)

> OTOH we probably need to support a method interface for a lot more
> things. b3.py has stuff like: TT.__cmp = Integer.__cmp, where TT is a
> ParrotClass and Integer isa PMC.

The current method interface for this sort of thing's fine. We may want to
jump through some hoops with default MMD dispatch for some of these things
(which is what the above code does -- __cmp gets mapped to one of the cmp
slots) as it'll get... fun, but shouldn't be too big a deal.

The underlying python bytecode doesn't make method calls by default for
__cmp and friends unless they're overridden. (Which they are there, of
course, but...) A standard left-side-wins scheme with operator
overloading's in place for 'em.