Jens Rieks <[EMAIL PROTECTED]> wrote:
> Currently, Parrot_find_global throws and internal_exception, which is IMO not
> good.
Where? The Parrot_find_global() function returns NULL in failure case.
Parrot_get_global() throws a real execption.
> I have a patch ready that adds a "void *next" paramet
At 3:05 PM +0100 2/13/02, Angel Faus wrote:
>Dan wrote:
>>Yep, I've seen their plans. It's less an issue for us, at least as
>>far as globals are concerned, since we'll be doing that with
>>lexicals. (Python not having lexicals, after all) Globals are a bit
>>more interesting, since bytecode-loade
Dan wrote:
>Yep, I've seen their plans. It's less an issue for us, at least as
>far as globals are concerned, since we'll be doing that with
>lexicals. (Python not having lexicals, after all) Globals are a bit
>more interesting, since bytecode-loaded modules can't guarantee
>global positions, sin
At 12:54 AM -0500 2/10/02, Melvin Smith wrote:
>I know globals are still on the todo, but what is the plan for the
>operands of these opcodes? I see PMC examples, but will
>we also have versions of these for the native int, string and number
>Parrot types?
Nope, I'm not planning on that. We can a