On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
> First, we need to beef up ret, but that's a problem of definition. It
> should walk the control stack until it hits something it can return,
> so we can undo exception handler pushes, scope change, and suchlike
> things. (My proble
On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
> So, in total, we need:
>
> *) Original routine entry point
> *) Current routine entry point
> *) Native/bytecode flag
> *) Opcode table
> *) Global namespace chain
> *) "default" lexical scope
> *) All the register sets
> *) All the
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
>Alternatively, I think you can just replace the definition of yield
>by:
>
> inline op yield (in INT) {
> struct Parrot_Sub * sub =
> (struct Parrot_Sub*)interpreter->pmc_reg.registers[0]->data;
> sub->init = OFFSET($1);
>
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
> > First, we need to beef up ret, but that's a problem of definition. It
>
>Why does ret need to be so smart? We can have an opcode that pop
>exception handlers (we need it anyway) a
On Fri, 7 Jun 2002, Peschko, Edward wrote:
: Let me get this straight. the grammar of Perl is reprogrammable,
: and expressed in perl6. And a script is parsed using this grammar,
: on the fly, hence portions of scripts could have different grammars
: than other parts.
Where have you been for the
On Fri, Jun 07, 2002 at 11:23:56PM -0400, Dan Sugalski wrote:
> 2) A revamped stack system so we can support exceptions
What is the intent for stacks ?
--
Jason
At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
>
>Although I should mention that it's not verifying the presence of these
>headers- it just assumes they are available. It does that because the
>intent is to use this has_header.h for miniparrot, where we won't be doing
>any probing. The assumption
On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
> Right now all it [ret] does is pop the return address from the global
> interpreter control stack, but continuations, etc. will have their own
> control stack, so they must restore the caller's before returning.
Continuations never r
On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
> At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
> >Alternatively, I think you can just replace the definition of yield
> >by:
> >
> >inline op yield (in INT) {
> > struct Parrot_Sub * sub =
> >(struct Parrot_Sub*)i
On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> The support isn't complete, for example, co-routines, etc. need to
> swap in their own context, which right now they don't do.
Instead of using some space on the stack, co-routines can store all
their local variables into their closu
At 10:40 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
>> So, in total, we need:
>>
>> *) Original routine entry point
>> *) Current routine entry point
>> *) Native/bytecode flag
>> *) Opcode table
>> *) Global namespace chain
>> *)
At 9:50 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
>> First, we need to beef up ret, but that's a problem of definition. It
>> should walk the control stack until it hits something it can return,
>> so we can undo exception handler pus
At 1:43 PM -0400 6/8/02, Jason Gloudon wrote:
>On Fri, Jun 07, 2002 at 11:23:56PM -0400, Dan Sugalski wrote:
>
>> 2) A revamped stack system so we can support exceptions
>
>What is the intent for stacks ?
They need to be more formally turned to frames (though each sub may
have multiple frames),
At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
>> Right now all it [ret] does is pop the return address from the global
>> interpreter control stack, but continuations, etc. will have their own
>> control stack, so they must restor
At 8:30 PM +0200 6/8/02, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
>> The support isn't complete, for example, co-routines, etc. need to
>> swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-routin
At 08:15 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>I think this is a design mistake of the Java VM. It would have been
>more efficient to keep the local variables on the stack.
Define efficient. I assume they made their choices for more than one
reason, and I'd hesitate to call it a design mist
At 08:27 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
> > What would that accomplish?
> >
> > If yield is to suspend the current coroutine and return back to the
> > controlling context, you don't need an argument to yield, unless you
> >
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> > The support isn't complete, for example, co-routines, etc. need to
> > swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-rou
At 3:35 PM -0400 6/8/02, Melvin Smith wrote:
>At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
>>> The support isn't complete, for example, co-routines, etc. need to
>>> swap in their own context, which right now they don't do.
>>
At 03:48 PM 6/8/2002 -0400, Dan Sugalski wrote:
>At 3:35 PM -0400 6/8/02, Melvin Smith wrote:
>At more risk of admitting more of my ignorance...
>>
>>We have to store the closure's variables somewhere, if not on a stack, where?
>
>In scratchpads. The way perl 5 does it is that every subroutine has
At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote:
>At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
>>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
>>> The Java VM does this by popping values off of the local stack, and
>>> onto the callee's stack upon return.
>>
>>I think this is a
> --- start of forwarded message ---
> Date: 7 Jun 2002 21:36:26 -
> From: Joe Yates (via RT) <[EMAIL PROTECTED]>
> Cc: recipient list not shown: ;
> Subject: Re: [netlabs #590] Ticket Resolved
> Message-Id:
>
> Dear Daniel,
>
> I hope I'm not being a pain. The response to my report
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> > The support isn't complete, for example, co-routines, etc. need to
> > swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-rou
On Sat, Jun 08, 2002 at 01:39:56PM -0400, Dan Sugalski wrote:
> At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
> >
> >Although I should mention that it's not verifying the presence of these
> >headers- it just assumes they are available. It does that because the
> >intent is to use this has_header.
Nicholas Clark:
# On Sat, Jun 08, 2002 at 01:39:56PM -0400, Dan Sugalski wrote:
# > At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
# > >
# > >Although I should mention that it's not verifying the presence of
# > >these
# > >headers- it just assumes they are available. It does that
# because the
#
Standard MSVC++ 6.0 setup, last known to work: Thursday. Updated with
completely clean tree, built with defaults (as I always do) and here's how
it went:
C:\projects\parrot\parrot>perl Configure.pl
Parrot Version 0.0.6 Configure 2.0
Copyright (C) 2001-2002 Yet Another Society
Hello, I'm Confi
Dave Storrs yiked:
> Yikes. Ok, I obviously badly misunderstood that. I'll go back
> and reread it. So, can you provide an example of a "pattern nested
> within a closure", since I obviously didn't understand?
Sure:
m/ if { /? ::: / and print $0.{comment} } /
The C? ::: />
Trey Harris wrote:
> I guess this is as good an opportunity as any to be sure I've got what's
> going on. So, here's a first, simple, addmitedly broken hack at a simple
> parser for xml-ish start tags and empty entities:
>
> rule lt { \< }
> rule gt { \> }
> rule identifier {
> # I don't kn
28 matches
Mail list logo
