Re: RT Ticket Summary

> I'd like to see: ... http://rt.perl.org/rt3/NoAuth/parrot/Overview.html

Re: Exceptions, sub cleanup, and scope exit

On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote: > On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote: > > > I'd like pushing exception handlers to remain simple -- the current > > system is almost OK. What I'd like it to change to is: > > > > push_eh label > > > > with poppin

Re: Exceptions, sub cleanup, and scope exit

On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote: > I'd like pushing exception handlers to remain simple -- the current > system is almost OK. What I'd like it to change to is: > > push_eh label > > with popping the top exception handler being: > > pop_eh > > I'm up for better

[PATCH] dynclasses/matchrange.pmc void with return

Sun's cc compiler complains about dynclasses/matchrange.pmc: "matchrange.pmc", line 305: void function cannot return value The following patch fixes it. --- parrot-current/dynclasses/matchrange.pmcFri Sep 17 00:55:02 2004 +++ parrot-andy/dynclasses/matchrange.pmc Mon Nov 15 11:04:04

Re: Perl 6 Summary for 2004-11-08 through 2004-11-15

At 11:06 AM -0800 11/18/04, Michel Pelletier wrote: > From: Jeff Horwitz <[EMAIL PROTECTED]> To: Matt Fowles <[EMAIL PROTECTED]> cc: Perl 6 Internals List <[EMAIL PROTECTED]> Subject: Re: Perl 6 Summary for 2004-11-08 through 2004-11-15 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Conte

Exceptions, sub cleanup, and scope exit

Now that invocation semantics are fixed and permanent, we need some cleanup of the code base to round out support. It's also time to get some things in place that are part of the fallout from it. The 'invoke the current return continuation' op apparently got lost in the blowup. That needs to go

Re: Perl 6 Summary for 2004-11-08 through 2004-11-15

> From: Jeff Horwitz <[EMAIL PROTECTED]> > To: Matt Fowles <[EMAIL PROTECTED]> > cc: Perl 6 Internals List <[EMAIL PROTECTED]> > Subject: Re: Perl 6 Summary for 2004-11-08 through 2004-11-15 > Message-ID: <[EMAIL PROTECTED]> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On M

Re: silent effects of opcodes

Dan Sugalski wrote: If the point is to direct the allocator to flush temps and start fresh, then we should just do it: .flushtemps The point basically is to insert a loop into the CFG. When we have foo() ... bar() which is a linear control flow through these basic blocks, we need: in

Re: silent effects of opcodes

At 8:26 AM +0100 11/18/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Exceptions and continuations should be the same problem -- the target is the start of a basic block. (Well, more than that, as they're places where calling conventions potentially kick in) This means the i

Re: RT Ticket Summary

Will Coleda wrote: Robert has provided me access to the RT command line tool, which I scripted around to generate this small report. I'd appreciate feedback on whether or not something like this would be useful (and suggestions for other things to report on are welcome.) If we can settle on a desir

Re: light-weight calling conventions (was: Second cut at a P6 grammar engine, in Parrot)

On Wed, Nov 17, 2004 at 10:35:47PM +, Nicholas Clark wrote: > On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote: > > > BTW, it may be very possible for me to write the p6ge generator so > > that it can be switched between the PIR and bsr/ret calling conventions, > > so we don

Re: light-weight calling conventions

On Wed, Nov 17, 2004 at 11:07:28PM +0100, Leopold Toetsch wrote: > $ parrot pmfactbsr.imc > 500500 > 3.459947 > > $ parrot -Oc pmfact.imc > 500500 > 1.237185 > > Now what ;) > Are you sure, that you can't do a tailcall sometimes? Sure, p6ge already makes heavy use of tailcalls. In a bsr/ret sc

deprecation warning P0, P1, P2

Here's again a summary of upcoming changes. I'll commit for now just the new "returncc" opcode. Other changes that start breaking things will follow in a few days. Summary: 1) PIR code using PIRs HLL call syntax doesn't need changes. foo() # call sub foo a = bar(x)# call bar wi

imcc update (was: silent effects of opcodes)

Bill Coffman <[EMAIL PROTECTED]> wrote: > Since I understand the item about allocating registers between sub > calls, I can probably implement that change, as I work through the > control flow/data flow analysis. I've no resynced pending changes with the old allocator and committed these changes.