From @masak

<masak> this is the first bug in quite some time that I can't describe
with a one-liner. perhaps someone can help minimize or explore it?
<masak> first off,
https://gist.github.com/908829/e9bad177e78265cde76772ad0799d7d4ac3400a6
(which I posted a few days ago) works nicely, and outputs 36 lines of
the desired output.
<masak> but I wasn't happy with the sub at lines 11..15.
<masak> so I rewrote it as
https://gist.github.com/908829/3af6c425a2768753e63d82efd420d487009bfdaf
-- much nicer
<masak> and it should be identical in function... but...
<masak> the correct 36 solutions are still output, but now they're on
the same line with spaces between them.
<masak> it looks like things do when a list or array has been
stringified with prefix​:<~>
<masak> so maybe I'm getting a double layer of lists somewhere.
<masak> I'd be happy if someone could shed some light on this.
<masak> oh -- https://gist.github.com/908829/648dd197e56195f1cc83cdc8a6bde8b647a2cc84
fixes my issue above. I don't understand why a .list call is necessary
there, and I suspect it's a bug that it is.
<masak> further clues/insights are still very much welcome.
<moritz> .list is usually necessary if the iterators somehow get mixed
up otherwise [17​:26]
<colomon> I have to admit to never being able to figure out ahead of
time when [ ]s and .lists will be needed.
<TimToady> rakudo still doesn't quite believe in lol, so occasionally
over-lols a parcel on your behalf, I suspect
* masak submits the over-lol explanation as a rakudobug

From @coke

On Sat Apr 09 09​:29​:21 2011, masak wrote​:

<masak> this is the first bug in quite some time that I can't describe
with a one-liner. perhaps someone can help minimize or explore it?
<masak> first off,
https://gist.github.com/908829/e9bad177e78265cde76772ad0799d7d4ac3400a6
(which I posted a few days ago) works nicely, and outputs 36 lines of
the desired output.
<masak> but I wasn't happy with the sub at lines 11..15.
<masak> so I rewrote it as
https://gist.github.com/908829/3af6c425a2768753e63d82efd420d487009bfdaf
-- much nicer
<masak> and it should be identical in function... but...
<masak> the correct 36 solutions are still output, but now they're on
the same line with spaces between them.
<masak> it looks like things do when a list or array has been
stringified with prefix​:<~>
<masak> so maybe I'm getting a double layer of lists somewhere.
<masak> I'd be happy if someone could shed some light on this.
<masak> oh --
https://gist.github.com/908829/648dd197e56195f1cc83cdc8a6bde8b647a2cc84
fixes my issue above. I don't understand why a .list call is necessary
there, and I suspect it's a bug that it is.
<masak> further clues/insights are still very much welcome.
<moritz> .list is usually necessary if the iterators somehow get mixed
up otherwise [17​:26]
<colomon> I have to admit to never being able to figure out ahead of
time when [ ]s and .lists will be needed.
<TimToady> rakudo still doesn't quite believe in lol, so occasionally
over-lols a parcel on your behalf, I suspect
* masak submits the over-lol explanation as a rakudobug

These gists aren't runnable standalone. Can you provide some self contained examples that
exhibit the issue?

--
Will "Coke" Coleda

The RT System itself - Status changed from 'new' to 'open'

From @coke

On Fri May 10 21​:37​:25 2013, coke wrote​:

On Sat Apr 09 09​:29​:21 2011, masak wrote​:

<masak> this is the first bug in quite some time that I can't
describe
with a one-liner. perhaps someone can help minimize or explore it?
<masak> first off,
https://gist.github.com/908829/e9bad177e78265cde76772ad0799d7d4ac3400a6
(which I posted a few days ago) works nicely, and outputs 36 lines of
the desired output.
<masak> but I wasn't happy with the sub at lines 11..15.
<masak> so I rewrote it as
https://gist.github.com/908829/3af6c425a2768753e63d82efd420d487009bfdaf
-- much nicer
<masak> and it should be identical in function... but...
<masak> the correct 36 solutions are still output, but now they're on
the same line with spaces between them.
<masak> it looks like things do when a list or array has been
stringified with prefix​:<~>
<masak> so maybe I'm getting a double layer of lists somewhere.
<masak> I'd be happy if someone could shed some light on this.
<masak> oh --
https://gist.github.com/908829/648dd197e56195f1cc83cdc8a6bde8b647a2cc84
fixes my issue above. I don't understand why a .list call is
necessary
there, and I suspect it's a bug that it is.
<masak> further clues/insights are still very much welcome.
<moritz> .list is usually necessary if the iterators somehow get
mixed
up otherwise [17​:26]
<colomon> I have to admit to never being able to figure out ahead of
time when [ ]s and .lists will be needed.
<TimToady> rakudo still doesn't quite believe in lol, so occasionally
over-lols a parcel on your behalf, I suspect
* masak submits the over-lol explanation as a rakudobug

These gists aren't runnable standalone. Can you provide some self
contained examples that
exhibit the issue?

16​:13 < masak> [Coke]​: I'm thinking we might just want to close
  https://rt-archive.perl.org/perl6/Ticket/Display.html?id=88144
16​:13 < masak> [Coke]​: I've never had that issue since, and it's likely
  semantics have shifted since I posted that.
--
Will "Coke" Coleda

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