Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>>
>> As already stated:
>> - COWed buffers need distinct buffer headers pointing to the same
>> buffer memory
>> - unCOWing (regstack_copy_chunk) allocates new buffer memory and
>> resets the COW flag
> I headed in to fix this w
Leopold Toetsch writes:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > This patch make the problem case submitted by Jeff Clites work. All
> > tests pass, and his sample has been added to the tests.
>
> > struct RegisterChunkBuf* top = stack->top;
> > if (top->used > 1) {
> > +
Matt Fowles <[EMAIL PROTECTED]> wrote:
> This patch make the problem case submitted by Jeff Clites work. All
> tests pass, and his sample has been added to the tests.
> struct RegisterChunkBuf* top = stack->top;
> if (top->used > 1) {
> +top->used--;
Thanks for the patch *but*
# New Ticket Created by Matt Fowles
# Please include the string: [perl #25960]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=25960 >
All~
This patch make the problem case submitted by Jeff Clites work. All
tests pass
Sorry about the delay in responding.
My current sample program is 2760 lines of imcc in 23 files, plus a
small .tcl script.
I'll see if I can trim that down to a more reasonable test case.
On Monday, January 26, 2004, at 05:32 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Well, that was festive. "I can reproduce that bug in 22 lines!"
I expect the following code to print out a single colon (since
PerlUndef prints as the empty string) and a newline. Instead, I get:
:get_string() not implemented in class 'RetContinuation'
which shows that the PerlUndef I assigned
Will Coleda wrote:
Well, that was festive. "I can reproduce that bug in 22 lines!"
Great.
The bug (and other reported curruptions) are definitely coming from the
COW logic in register.c. This is what happens:
Setting up the exception handler (which is a continuation) triggers COW
setting of th
Will Coleda <[EMAIL PROTECTED]> wrote:
> I'm trying to track down a problem with a PerlArray that is getting
> modified on me.
> I have a snippet of code like:
Could you please provide a complete program, that imposes the bug?
leo
Nope. If I turn on -G and leave off explicit savetop/restoretop, the
perlArray is still stomped.
Regards.
On Sunday, January 25, 2004, at 09:29 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
If there's magic, it was an unintentional invocation. =-) If I was
managing my own
Will Coleda <[EMAIL PROTECTED]> wrote:
> If there's magic, it was an unintentional invocation. =-) If I was
> managing my own registers, I'd expect to have to save things - but
> since I'm always (I think) using .locals or the $I syntax, I'd
> expect IMCC to do the saving,
IMCC does provide the n
If there's magic, it was an unintentional invocation. =-) If I was
managing my own registers, I'd expect to have to save things - but
since I'm always (I think) using .locals or the $I syntax, I'd
expect IMCC to do the saving, since I have no way of knowing /which/
registers it's using for me.
Will Coleda writes:
> I'm trying to track down a problem with a PerlArray that is getting
> modified on me.
>
> I have a snippet of code like:
>
> typeof $S12, tcl_words
> $I12 = tcl_words
> print "TYPEOF: "
> print $S12
> print "\n"
> print "SIZEOF: "
> print $I12
> print "\n"
>
I'm trying to track down a problem with a PerlArray that is getting
modified on me.
I have a snippet of code like:
typeof $S12, tcl_words
$I12 = tcl_words
print "TYPEOF: "
print $S12
print "\n"
print "SIZEOF: "
print $I12
print "\n"
(var_start_at,var_length,var_replace_str) =
13 matches
Mail list logo
