On Tue, Oct 19, 2004 at 11:23:13AM +0200, Leopold Toetsch wrote:
> * the import statement is simulated too by storing the lexicals into the
> caller's frame. This would very likely be another Python opcode.
I should point out that this is much more like Python's semantics for
"import *" than Da
On Sun, Sep 28, 2003 at 12:59:52PM -0700, Steve Fink wrote:
> I don't know whether Perl6 or any other language we want to be nice to
> has *non-constant* defaults. If so, and if we want direct support for
> them, then it means we need to evaluate them in the context of the
> callee.
Depends on wha
> "Peter" == Peter Seibel <[EMAIL PROTECTED]> writes:
> Hi, I'm new to this list and haven't had a chance to grovel
> through the old archives yet so please forgive me for jumping in
> in the middle of things.
> Anyway, what about languages that don't attach methods to
>
> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
> I don't see why Parrot couldn't do much of this. It can
> certainly audit allocations made through its own
> memory-allocation system, and with only a little help from the
> system it should be able to audit its processor u
> "Matthew" == Matthew Byng-Maddick <[EMAIL PROTECTED]> writes:
>> I guess what I'm saying is, sure, you can't stop a native
>> function (which was called from parrot code) from doing
>> whatever it wants, but you can still prevent the parrot code
>> from using that function in
The ops described in PDD 6 and docs/parrot_assembly.pod for
scratchpads appear to be subtly different from the ones actually in
core.ops. In particular, i was led astray by the docs referring to the
"newpad" op and core.ops implementing "new_pad". which is it supposed
to be? =)
I started investiga
