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
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
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
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
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
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
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
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
>
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,
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
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
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
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
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
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)
15 matches
Mail list logo