# New Ticket Created by Will Coleda
# Please include the string: [perl #56468]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56468 >
Now that we can subclass PMCs with Objects, we need to go through all
the code in src/pmc
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: multipart/mixed;
boundary="09080402060404020800"
X-Posted-By: 122.110.103.226
--09080402060404020800
Content-Type: text/plain; charset=UTF-8; form
On Thursday 11 September 2008 04:03:27 Vasily Chekalkin wrote:
> Will Coleda wrote:
> > Now that we can subclass PMCs with Objects, we need to go through all
> > the code in src/pmc/*.pmc that directly fiddles with PMC guts (e.g.
> > PMC_int_val(...) and PMC_num_val(...) and replace them with VTA
chromatic wrote:
Just for clarification, it attached patch is actually what this ticket
about?
Yes, that's correct.
Ok, so I go ahead and try to fix more pmcs. There is single line patch
for float.
--
Bacek
diff --git a/src/pmc/float.pmc b/src/pmc/float.pmc
index d315627..fa03356 100644
--
chromatic wrote:
Yes, that's correct.
There is 2 patches:
1. complex.pmc single replacement of PMC_str_val.
2. string.pmc.
Replaces PMC_str_val;
Replace VTABLE_get_string(INTERP, SELF) with SELF.get_string();
In set_*_keyed change logick to invoke VTABLE_set_string_native
instead of rep
Hello.
Another question: there is a lot of PMC_\S+_val accesses to Key pmc.
Should they be replaced with VTABLE analogues as well? Or Key isn't
supposed to be inherited by some other class and it will only sacrifice
performance?
--
Bacek.
On Saturday 13 September 2008 04:51:04 Vasily Chekalkin wrote:
> Another question: there is a lot of PMC_\S+_val accesses to Key pmc.
> Should they be replaced with VTABLE analogues as well? Or Key isn't
> supposed to be inherited by some other class and it will only sacrifice
> performance?
The
chromatic wrote:
On Saturday 13 September 2008 04:51:04 Vasily Chekalkin wrote:
Another question: there is a lot of PMC_\S+_val accesses to Key pmc.
Should they be replaced with VTABLE analogues as well? Or Key isn't
supposed to be inherited by some other class and it will only sacrifice
perfor
Vasily Chekalkin wrote:
And another question. Should all lvalue occurences of PMC_*_val(SELF) be
replaced with VTABLE_set_*_native? (Except for VTABLE method
implementation of cause)
In general, yes. You'll have to check each PMC to see if they have the
appropriate VTABLE_set_*(_native) vta
Patches to bigint, complex, float and string applied in r31370, thanks.
--
Salu2
NotFound wrote:
Patches to bigint, complex, float and string applied in r31370, thanks.
Thanks. There is little bit more patches.
Just replacing most obvious calls.
--
Bacek
diff --git a/src/pmc/bigint.pmc b/src/pmc/bigint.pmc
index 0c00f18..b94d513 100644
--- a/src/pmc/bigint.pmc
+++ b/src/
> Thanks. There is little bit more patches.
Applied in r31381, with some changes in the env.pmc part to avoid
repeated calls.
--
Salu2
12 matches
Mail list logo