Re: RFC: Actions without barriers

Bob Rogers wrote: Almost two weeks ago, I had what I thought was a clever idea for eliminating the continuation barrier from action invocation: Simply call the action using the original continuation instead of creating a new RetContinuation. The original continuation, I reasoned, should be r

Re: Anyone relying on objects stringifying to class names?

Patrick R. Michaud wrote: I propose this is removed in a week, please respond if you'd have an issue with that or think that's too short. I think it's too long. :-) Does anything fail if you eliminate it (e.g., via "make tests")? If no, then I think it's okay to eliminate, and we'll see

RFC: Actions without barriers

Almost two weeks ago, I had what I thought was a clever idea for eliminating the continuation barrier from action invocation: Simply call the action using the original continuation instead of creating a new RetContinuation. The original continuation, I reasoned, should be re-entrant after havi

[perl #40608] key_append segfault

On Sat Oct 28 15:30:49 2006, rgrjr wrote: > I don't see a segfault in r15040 on x86 GNU/Linux, but it seems to be > using push_string(). Same error on r15009. What are you running? > Windows. And sorry, I stuffed up the example. It shoulda been: .sub main $P0 = new .Key $P1 = new .Strin

[perl #40608] key_append segfault

From: Jonathan Worthington (via RT) <[EMAIL PROTECTED]> Date: Sat, 28 Oct 2006 13:32:25 -0700 The following program segfaults Parrot: .sub main $P0 = new .Key push $P0, "test" push $P0, "test" print "not reached" .end Which sucks. :-( I

Re: [perl #40443] Separate vtable functions from methods (using :vtable)

Jonathan Worthington wrote: Tests and some extra error checking code to come. Also now done. If you write one of: .sub not_a_vtable_method :method :vtable .sub badger :method :vtable("not_a_vtable_method") It's a compiler error. I'll leave this ticket open a few more days for comments, then i

[perl #40608] key_append segfault

# New Ticket Created by Jonathan Worthington # Please include the string: [perl #40608] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40608 > The following program segfaults Parrot: .sub main $P0 = new .Key

Re: [perl #40443] Separate vtable functions from methods (using :vtable)

Hi, As of r15039, :vtable and :vtable("...") are now both implemented. See example code at the end of this email. As of now, please use this new syntax. I have left in support for the old "__"-prefix lookup as plenty of old code is using it; please note that if you have a :vtable("xxx") and

Re: Anyone relying on objects stringifying to class names?

On Sat, Oct 28, 2006 at 06:50:05PM +0100, Jonathan Worthington wrote: > So, I want to get rid of this and allow this v-table method to just > dispatch to a user implementation or a fallback. But before I do that, I > wanted to check if anyone is relying on the behavior? I'd really rather > not b

Anyone relying on objects stringifying to class names?

Hi, At the moment, if you have some ParrotObject instance, say foo, and do something like: $S0 = foo Then $S0 will contain the name of the class. This is BAD because it means you can't overload what a class stringifies too! In fact, there is a comment in the code saying that: /* =item C

[svn:parrot-pdd] r15037 - trunk/docs/pdds/clip

Author: jonathan Date: Sat Oct 28 09:59:25 2006 New Revision: 15037 Modified: trunk/docs/pdds/clip/pdd17_basic_types.pod Log: Add two new reference PMCs to the Basic Types PDD. Modified: trunk/docs/pdds/clip/pdd17_basic_types.pod ===