[EMAIL PROTECTED]:
# On Mon, Jul 22, 2002 at 02:47:01PM -0400, Tanton Gibbs wrote:
# >
# > The RECALL command automates that so that set_string now looks like:
# >
# > void set_string( PMC* value ) {
# > CHANGE_TYPE( pmc, PerlString );
# > RECALL;
# > }
# >
# > will be turned into the corre
Sure, that's pretty trivial to fix. What is the general concensus.
REINVOKE is fine with me, does that sound good?
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tanton Gibbs" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 200
On Mon, Jul 22, 2002 at 02:47:01PM -0400, Tanton Gibbs wrote:
>
> The RECALL command automates that so that set_string now looks like:
>
> void set_string( PMC* value ) {
> CHANGE_TYPE( pmc, PerlString );
> RECALL;
> }
>
> will be turned into the correct code shown above. By
> using the RE
Sure,
the basic problem is that in perlint.pmc we have something like:
void set_string( PMC* value ) {
CHANGE_TYPE( SELF, PerlString );
SELF->data = value->data
}
In other words implement a COW strategy after being changed into a
PerlString. However, in perlstring.pmc
the following is perf
Tanton Gibbs sent the following bits through the ether:
> I implemented a RECALL preprocessor directive for the pmc classes.
> ...
> Thus ensuring that the correct semantics always occur.
I'm afraid I don't quite understand what RECALL is supposed to do.
Can you explain it in a little more detai
On Sat, Jul 20, 2002 at 10:23:45PM -0400, Tanton Gibbs wrote:
> without the recall it performs in: 16.055 seconds
> with the recall it performs in: 16.722 seconds
>
> So, it slowed it down 6.5 tenths of a second after 10,000,000 times. That
> is not too bad for ensuring correct semantics.
>
>
