From @masak

<colomon> rakudo​: say (1...10)[2...4]
<p6eval> rakudo cfbeb5​: OUTPUT«Null PMC access in getprop() [...]
* masak submits rakudobug
<colomon> ooooo, it's a closure bug, I'll bet.
<colomon> rakudo​: my @​a = 1...10; say @​a[0...4]
<p6eval> rakudo cfbeb5​: OUTPUT«12345␤»
<colomon> closure bug, nothing to see here.
<masak> the closure bug usually doesn't result in a Null PMC access.
<masak> rakudo​: my @​a = 1...10; say @​a[2...4]
<p6eval> rakudo cfbeb5​: OUTPUT«345␤»
<masak> but yes, seems like it's parallel gather blocks interfering
that's the underlying cause.
<colomon> I will be unspeakably happy when that bug is eliminated.

From @coke

On Tue Jun 15 04​:49​:35 2010, masak wrote​:

<colomon> rakudo​: say (1...10)[2...4]
<p6eval> rakudo cfbeb5​: OUTPUT«Null PMC access in getprop() [...]
* masak submits rakudobug
<colomon> ooooo, it's a closure bug, I'll bet.
<colomon> rakudo​: my @​a = 1...10; say @​a[0...4]
<p6eval> rakudo cfbeb5​: OUTPUT«12345␤»
<colomon> closure bug, nothing to see here.
<masak> the closure bug usually doesn't result in a Null PMC access.
<masak> rakudo​: my @​a = 1...10; say @​a[2...4]
<p6eval> rakudo cfbeb5​: OUTPUT«345␤»
<masak> but yes, seems like it's parallel gather blocks interfering
that's the underlying cause.
<colomon> I will be unspeakably happy when that bug is eliminated.

Today's your lucky day!

The first line above now outputs "345" - assigning to moritz for tests.

--
Will "Coke" Coleda

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

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