Re: PMC flags in Pmc2c

2007-05-17 Thread Leopold Toetsch
Am Mittwoch, 16. Mai 2007 11:50 schrieb tewk: > A couple of questions: > > 1: Only two pmcs have the const_too flag SArray and ParrotLibrary. > This seems redundant given that all pmcs except abstract, singleton, and > const_too pmcs get a read only variant of the vtable. Is there any > reason, w

PMC flags in Pmc2c

2007-05-16 Thread tewk
A couple of questions: 1: Only two pmcs have the const_too flag SArray and ParrotLibrary. This seems redundant given that all pmcs except abstract, singleton, and const_too pmcs get a read only variant of the vtable. Is there any reason, why we can't get rid of the const_too flag and just u

Re: PMC flags

2005-05-04 Thread Aaron Sherman
On Wed, 2005-05-04 at 01:51, Leopold Toetsch wrote: > Aaron Sherman wrote: > > On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: > > Here is some example P5 source from pp_pow in pp.c: > > I presume that Ponie eventually will run Parrot opcodes. pp_pow() is > like all these functions par

Re: PMC flags

2005-05-04 Thread Leopold Toetsch
Dave Mitchell wrote: So pseduo-code like if (pmc->vtable->is_IOK()) ... else if (pmc->vtable->is_NOK()) ... becomes status = pmc->vtable->status(); if (status & IOK) ... else if (status & NOK) That would still need to rewrite all but 1% of perl5 code and

Re: PMC flags

2005-05-04 Thread Leopold Toetsch
Nicholas Clark wrote: [ CCs cleared by some ] ... However there's a lot of source outside pp*.c and the SV/AV/HV/CV/GV manipulation code. A lot of that are helper functions for pp code, but anyway yes, the code exists and is an API. Which is the stuff we're trying to keep working unchanged. If it

Re: PMC flags

2005-05-04 Thread Nicholas Clark
On Mon, May 02, 2005 at 12:24:04AM +0100, Dave Mitchell wrote: > On Sun, May 01, 2005 at 11:36:02PM +0100, Nicholas Clark wrote: > > in the common cases be able to access the PObj structure members directly. > > I may be speaking here like someone at the back who hasn't been paying > attention, bu

Re: PMC flags

2005-05-04 Thread Dave Mitchell
On Wed, May 04, 2005 at 05:26:25PM +0100, Nicholas Clark wrote: > On Mon, May 02, 2005 at 08:58:43AM +0200, Leopold Toetsch wrote: > > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > > Parrot gives each PMC class 8 private flag bits. I was wondering how to > > > use > > > these most efficiently for

Re: PMC flags

2005-05-04 Thread Nicholas Clark
On Mon, May 02, 2005 at 08:58:43AM +0200, Leopold Toetsch wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > Parrot gives each PMC class 8 private flag bits. I was wondering how to use > > these most efficiently for ponie. My thoughts so far are > > > 1 bit for SVf_IOK > > 1 bit for SVf_NOK >

Re: PMC flags

2005-05-03 Thread Leopold Toetsch
Aaron Sherman wrote: On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: The vtable functions C and C, which take now a string, are a bit heavy-weighted and might get an extension in the log run that take an integer flag. Unless this happens, this would be a HUGE performance hit. After all,

Re: PMC flags

2005-05-03 Thread Aaron Sherman
On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > 1 bit for SVf_IOK > > 1 bit for SVf_NOK > > 1 bit for SVf_POK > > 1 bit for SVf_ROK > > I'd not mess around with (or introduce) flag bits. The more that this > would only cover perl5 PMCs. Pr

Re: PMC flags

2005-05-02 Thread Leopold Toetsch
Nicholas Clark <[EMAIL PROTECTED]> wrote: > Parrot gives each PMC class 8 private flag bits. I was wondering how to use > these most efficiently for ponie. My thoughts so far are > 1 bit for SVf_IOK > 1 bit for SVf_NOK > 1 bit for SVf_POK > 1 bit for SVf_ROK I'd not mess around with (or introduce

Re[2]: Extending interface: PMC flags and marking

2004-08-22 Thread Dan Sugalski
At 4:00 PM +0200 8/22/04, Mattia Barbon wrote: On Sat, 21 Aug 2004 19:36:43 -0400 Dan Sugalski <[EMAIL PROTECTED]> wrote: At 6:44 PM +0200 8/21/04, Mattia Barbon wrote: > Hello, >I think extenders should have access to at least some of the >flags in PObj_enum. Should we have a different funct

Re[2]: Extending interface: PMC flags and marking

2004-08-22 Thread Mattia Barbon
On Sat, 21 Aug 2004 19:36:43 -0400 Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:44 PM +0200 8/21/04, Mattia Barbon wrote: > > Hello, > >I think extenders should have access to at least some of the > >flags in PObj_enum. Should we have a different function for > >each flag (say: Parrot_PObj_set

Re: Extending interface: PMC flags and marking

2004-08-21 Thread Dan Sugalski
At 6:44 PM +0200 8/21/04, Mattia Barbon wrote: Hello, I think extenders should have access to at least some of the flags in PObj_enum. Should we have a different function for each flag (say: Parrot_PObj_set_custom_mark(INTERP, PMC, value), Parrot_PObj_set_is_class(INTERP, PMC, value) or a single

Extending interface: PMC flags and marking

2004-08-21 Thread Mattia Barbon
Hello, I think extenders should have access to at least some of the flags in PObj_enum. Should we have a different function for each flag (say: Parrot_PObj_set_custom_mark(INTERP, PMC, value), Parrot_PObj_set_is_class(INTERP, PMC, value) or a single Parrot_PObj_set_flag(INTERP, PMC, flag, value)