Infinite pretzel recursion when replacing a hash value with an array containing the old value in Rakudo #819

p6rt · 2009-03-22T09:29:28Z

Migrated from rt.perl.org#64080 (status was 'resolved')

Searchable as RT64080$

p6rt · 2009-03-22T09:29:28Z

From @masak

<masak> rakudo: my %p; %p<a> = [%p<a>, 4]; say %p.perl
<masak> infinite recursion.
<masak> on my box, it eventually says: 'maximum recursion depth exceeded'
<p6eval> rakudo de786f: OUTPUT«maximum recursion depth exceeded [...]
<masak> there we go.
<masak> AFAIKS, there's nothing wrong with the statement as such; it
shouldn't create a pretzel.
* masak submits rakudobug

p6rt · 2009-03-22T14:41:15Z

From @masak

<jnthn> masak: We already had a ticket on .perl on recursive data
structures...
<masak> jnthn: thing is, I don't see why this should be recursive in the
first place.
<masak> it's not like I'm doing binding.
<masak> just regular assignment.
<jnthn> You're still creating a circular reference.
<jnthn> So far as I can tell.
<masak> jnthn: if that creates a circular reference, how does one spell
what I meant to write?
<jnthn> masak: What is it you want exactly?
<masak> i.e. take the hash _value_ of that particular key, insert it
into an array, and make the new hash value that array. without circular
references.
<jnthn> Oh, hmm.
<jnthn> rakudo: my %h; %h<a> = 42; my $p = [%h<a>]; say %h<a>;
<p6eval> rakudo de786f: OUTPUT«42␤»
<masak> well, fwiw, I didn't init %h<a> before I introduced the array...
<jnthn> rakudo: my %h; %h<a> = [%h<a>]; say %h<a>.perl;
<masak> that's it :)
<masak> and that's what I consider a bug.
<masak> the semantics shouldn't differ just because %h<a> wasn't init'ed.
<masak> this will take a while.
<masak> it did when I tried that this morning.
<jnthn> What, it takes this long to blow up on infinite recursion?
<masak> aye.
<masak> it's faster on my box.
<jnthn> Still...
<jnthn> Rakudo will need quite some optimization at some point...
<p6eval> rakudo de786f: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> (not that that's news.)

p6rt · 2009-03-22T14:41:16Z

@masak - Status changed from 'new' to 'open'

p6rt · 2009-07-29T01:20:38Z

From @kyleha

This is an automatically generated mail to inform you that tests are now available in t/spec/S02-names_and_variables/perl.t

commit 31c7bee223f2343bb87ca5e8d28476a3787e71d5
Author: kyle <kyle@c213334d-75ef-0310-aa23-eaa082d1ae64>
Date: Wed Jul 29 01:19:01 2009 +0000

[t/spec] Test for RT #64080 (may be misplaced)

git-svn-id: http://svn.pugscode.org/pugs@27789 c213334d-75ef-0310-aa23-eaa082d1ae64

Inline Patch

diff --git a/t/spec/S02-names_and_variables/perl.t b/t/spec/S02-names_and_variables/perl.t
index 667c4e1..85f9c92 100644
--- a/t/spec/S02-names_and_variables/perl.t
+++ b/t/spec/S02-names_and_variables/perl.t
@@ -55,7 +55,7 @@ my @tests = (
     [ { :a(1) }, { :b(2), :c(3) } ],
 );
 
-plan 14 + 2*@tests;
+plan 17 + 2*@tests;
 #?pugs emit force_todo 8, 45..50, 94, 96;
 
 #?pugs emit unless $?PUGS_BACKEND eq "BACKEND_PUGS" {
@@ -185,3 +185,14 @@ plan 14 + 2*@tests;
     is @reconstituted, @original,
        "eval of .perl returns original for '$dehydrated'";
 }
+
+# RT #64080
+{
+    my %h;
+    lives_ok { %h<a> = [%h<a>] },
+             'can assign list with new hash element to itself';
+    #?rakudo skip 'RT #64080'
+    lives_ok { %h<a>.perl }, 'can take .perl from hash element';
+    #?rakudo todo 'RT #64080'
+    ok %h<a> !=== %h<a>[0], 'hoa does not refer to hash element';
+}

p6rt · 2009-07-29T01:33:26Z

From @petdance

Are these automatic mails valuable? I suspect they're jamming up RT.

Unless I'm missing something.

xoxo,
Andy
.

Begin forwarded message:

From: kyleha@gmail.com
Date: July 28, 2009 8:20:07 PM CDT
To: perl6-bugs-followup@perl.org
Subject: [perl #64080] tests available

This is an automatically generated mail to inform you that tests are
now available in t/spec/S02-names_and_variables/perl.t

commit 31c7bee223f2343bb87ca5e8d28476a3787e71d5
Author: kyle <kyle@c213334d-75ef-0310-aa23-eaa082d1ae64>
Date: Wed Jul 29 01:19:01 2009 +0000

[t/spec] Test for RT #64080 (may be misplaced)

git-svn-id: http://svn.pugscode.org/pugs@27789 c213334d-75ef-0310-
aa23-eaa082d1ae64

diff --git a/t/spec/S02-names_and_variables/perl.t b/t/spec/S02-
names_and_variables/perl.t
index 667c4e1..85f9c92 100644
--- a/t/spec/S02-names_and_variables/perl.t
+++ b/t/spec/S02-names_and_variables/perl.t
@@ -55,7 +55,7 @@ my @tests = (
[ { :a(1) }, { :b(2), :c(3) } ],
);

-plan 14 + 2*@tests;
+plan 17 + 2*@tests;
#?pugs emit force_todo 8, 45..50, 94, 96;

#?pugs emit unless $?PUGS_BACKEND eq "BACKEND_PUGS" {
@@ -185,3 +185,14 @@ plan 14 + 2*@tests;
is @reconstituted, @original,
"eval of .perl returns original for '$dehydrated'";
}
+
+# RT #64080
+{
+ my %h;
+ lives_ok { %h<a> = [%h<a>] },
+ 'can assign list with new hash element to itself';
+ #?rakudo skip 'RT #64080'
+ lives_ok { %h<a>.perl }, 'can take .perl from hash element';
+ #?rakudo todo 'RT #64080'
+ ok %h<a> !=== %h<a>[0], 'hoa does not refer to hash element';
+}

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

p6rt · 2009-07-29T03:17:37Z

From @pmichaud

For each ticket that is open, it's very useful to know that
a spectest has been written for the ticket and where that
spectest is located. So, having the notification added to
RT is valuable to me at least, as it means that once the
issue is fixed I know (1) where the relevant tests are
located and (2) that the ticket can be closed because
spectests exist.

If messages simply updating the status of tickets in RT
are causing it to "jam up", that indicates (to me) a
problem somewhere. (I've often noticed that RT can
be very slow about notifications, well before the
automatic messages were being generated.)

Pm

On Tue, Jul 28, 2009 at 08:32:56PM -0500, Andy Lester wrote:

Are these automatic mails valuable? I suspect they're jamming up RT.

Unless I'm missing something.

xoxo,
Andy
.

Begin forwarded message:

From: kyleha@gmail.com
Date: July 28, 2009 8:20:07 PM CDT
To: perl6-bugs-followup@perl.org
Subject: [perl #64080] tests available

This is an automatically generated mail to inform you that tests are
now available in t/spec/S02-names_and_variables/perl.t

commit 31c7bee223f2343bb87ca5e8d28476a3787e71d5
Author: kyle <kyle@c213334d-75ef-0310-aa23-eaa082d1ae64>
Date: Wed Jul 29 01:19:01 2009 +0000

[t/spec] Test for RT #64080 (may be misplaced)

git-svn-id: http://svn.pugscode.org/pugs@27789 c213334d-75ef-0310-
aa23-eaa082d1ae64

diff --git a/t/spec/S02-names_and_variables/perl.t b/t/spec/S02-
names_and_variables/perl.t
index 667c4e1..85f9c92 100644
--- a/t/spec/S02-names_and_variables/perl.t
+++ b/t/spec/S02-names_and_variables/perl.t
@@ -55,7 +55,7 @@ my @tests = (
[ { :a(1) }, { :b(2), :c(3) } ],
);

-plan 14 + 2*@tests;
+plan 17 + 2*@tests;
#?pugs emit force_todo 8, 45..50, 94, 96;

#?pugs emit unless $?PUGS_BACKEND eq "BACKEND_PUGS" {
@@ -185,3 +185,14 @@ plan 14 + 2*@tests;
is @reconstituted, @original,
"eval of .perl returns original for '$dehydrated'";
}
+
+# RT #64080
+{
+ my %h;
+ lives_ok { %h<a> = [%h<a>] },
+ 'can assign list with new hash element to itself';
+ #?rakudo skip 'RT #64080'
+ lives_ok { %h<a>.perl }, 'can take .perl from hash element';
+ #?rakudo todo 'RT #64080'
+ ok %h<a> !=== %h<a>[0], 'hoa does not refer to hash element';
+}

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

p6rt · 2009-07-29T03:25:47Z

From @kyleha

On Tue, Jul 28, 2009 at 8:32 PM, Andy Lester<andy@petdance.com> wrote:

Are these automatic mails valuable? I suspect they're jamming up RT.

If they're causing a problem, I'll (1) be very surprised, and (2)
discontinue them.

I find them valuable so that I don't embark on the task of testing a
bug that's already tested. From conversations on IRC, I gather others
find other values in them.

Kyle.

p6rt · 2009-07-29T03:36:55Z

From @petdance

On Jul 28, 2009, at 10:25 PM, Kyle Hasselbacher wrote:

If they're causing a problem, I'll (1) be very surprised, and (2)
discontinue them.

That's fine. I just have never heard discussions of them. Thanks for
generating them.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

p6rt · 2009-07-29T09:26:35Z

From @jnthn

Just to weigh in with another developer opinion...

Patrick R. Michaud wrote:

For each ticket that is open, it's very useful to know that
a spectest has been written for the ticket and where that
spectest is located. So, having the notification added to
RT is valuable to me at least, as it means that once the
issue is fixed I know (1) where the relevant tests are
located and (2) that the ticket can be closed because
spectests exist.

Agree - I find them useful too. Tickets shouldn't be closed without
making sure there are tests covering the issue, and knowing that there
is a test and where to find it in order to enable it certainly helps cut
down the time it takes to resolve tickets. I agree it's some noise on
the mailing list, but to me the value certainly out-weighs that.

Thanks,

Jonathan

p6rt · 2010-03-06T22:46:06Z

From @moritz

On Tue Jul 28 18:20:38 2009, KyleHa wrote:

This is an automatically generated mail to inform you that tests are
now available in t/spec/S02-names_and_variables/perl.t

commit 31c7bee223f2343bb87ca5e8d28476a3787e71d5
Author: kyle <kyle@c213334d-75ef-0310-aa23-eaa082d1ae64>
Date: Wed Jul 29 01:19:01 2009 +0000
\[t/spec\] Test for RT #&#8203;64080 $may be misplaced$

git\-svn\-id&#8203;: http://svn.pugscode.org/pugs@&#8203;27789 c213334d\-75ef\-0310\-
aa23-eaa082d1ae64

diff --git a/t/spec/S02-names_and_variables/perl.t b/t/spec/S02-
names_and_variables/perl.t
index 667c4e1..85f9c92 100644
--- a/t/spec/S02-names_and_variables/perl.t
+++ b/t/spec/S02-names_and_variables/perl.t
@@ -55,7 +55,7 @@ my @tests = (
[ { :a(1) }, { :b(2), :c(3) } ],
);

-plan 14 + 2*@tests;
+plan 17 + 2*@tests;
#?pugs emit force_todo 8, 45..50, 94, 96;

#?pugs emit unless $?PUGS_BACKEND eq "BACKEND_PUGS" {
@@ -185,3 +185,14 @@ plan 14 + 2*@tests;
is @reconstituted, @original,
"eval of .perl returns original for '$dehydrated'";
}
+
+# RT #64080
+{
+ my %h;
+ lives_ok { %h<a> = [%h<a>] },
+ 'can assign list with new hash element to itself';
+ #?rakudo skip 'RT #64080'
+ lives_ok { %h<a>.perl }, 'can take .perl from hash element';
+ #?rakudo todo 'RT #64080'
+ ok %h<a> !=== %h<a>[0], 'hoa does not refer to hash element';
+}

The tests now pass, although with a bit of cheating:

23:41 < moritz_> rakudo: my %p; %p<a> = [%p<a>, 4]; say %p.perl
23:41 <+p6eval> rakudo 14a83e: OUTPUT«{"a" => [Proxy.new(), 4]}␤»

What should we do with this bug?

p6rt · 2011-01-22T04:04:53Z

From @felliott

This works now. I've unfudged the final test and I'm marking it 'resolved'.

Cheers,
Fitz

p6rt · 2011-01-22T04:04:53Z

@felliott - Status changed from 'open' to 'resolved'

p6rt closed this as completed Jan 22, 2011

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Infinite pretzel recursion when replacing a hash value with an array containing the old value in Rakudo #819

Infinite pretzel recursion when replacing a hash value with an array containing the old value in Rakudo #819

p6rt commented Mar 22, 2009

p6rt commented Mar 22, 2009

p6rt commented Mar 22, 2009

p6rt commented Mar 22, 2009

p6rt commented Jul 29, 2009

p6rt commented Jul 29, 2009

p6rt commented Jul 29, 2009

p6rt commented Jul 29, 2009

p6rt commented Jul 29, 2009

p6rt commented Jul 29, 2009

p6rt commented Mar 6, 2010

p6rt commented Jan 22, 2011

p6rt commented Jan 22, 2011

Infinite pretzel recursion when replacing a hash value with an array containing the old value in Rakudo #819

Infinite pretzel recursion when replacing a hash value with an array containing the old value in Rakudo #819

Comments

p6rt commented Mar 22, 2009

p6rt commented Mar 22, 2009

From @masak

p6rt commented Mar 22, 2009

From @masak

p6rt commented Mar 22, 2009

p6rt commented Jul 29, 2009

From @kyleha

p6rt commented Jul 29, 2009

From @petdance

p6rt commented Jul 29, 2009

From @pmichaud

p6rt commented Jul 29, 2009

From @kyleha

p6rt commented Jul 29, 2009

From @petdance

p6rt commented Jul 29, 2009

From @jnthn

p6rt commented Mar 6, 2010

From @moritz

p6rt commented Jan 22, 2011

From @felliott

p6rt commented Jan 22, 2011