From jjmerelo@gmail.com

This statement

  my @​stuff = "\x0"... "\xfff"

hangs the REPL for a while. In fact, memory as reported by top goes up to 1
GB and increases slowly but firmly. This happens whatever the start of the
range and for a few characters.

Ob versions​:
This is Rakudo version 2016.09-68-g447d592 built on MoarVM version
2016.09-1-gdebb859

From @samcv

On Sun, 01 Jan 2017 10​:11​:57 -0800, jjmerelo@​gmail.com wrote​:

This statement

my @​stuff = "\\x0"\.\.\. "\\xfff"

hangs the REPL for a while. In fact, memory as reported by top goes up to 1
GB and increases slowly but firmly. This happens whatever the start of the
range and for a few characters.

Ob versions​:
This is Rakudo version 2016.09-68-g447d592 built on MoarVM version
2016.09-1-gdebb859

I don't think this is a bug. Assigning to an array makes the range not lazy, and so it has to compute all of them. If you use a $ sigil it is very quick.

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

From @samcv

Actually ignore what I just said. But seems using ... (yada operator) is what is making it computer all values. If you use .. even with an array it happens very quickly and produces a Range type value stored in @​stuff.

From @zoffixznet

On Sun, 01 Jan 2017 10​:11​:57 -0800, jjmerelo@​gmail.com wrote​:

This statement

my @​stuff = "\\x0"\.\.\. "\\xfff"

hangs the REPL for a while. In fact, memory as reported by top goes up to 1
GB and increases slowly but firmly. This happens whatever the start of the
range and for a few characters.

Ob versions​:
This is Rakudo version 2016.09-68-g447d592 built on MoarVM version
2016.09-1-gdebb859

Thank you for the report, however this is not a bug.

There are two things at play that cause the hang​:

1) As samcv mentions above, the way you're assigning to the array makes it reify all the elements. You can use either `my @​stuff := "\x0"..."\xfff"` or `my $stuff = ("\x0"..."\xfff")` or `my @​stuff = lazy "\x0" ..."\xfff"` to avoid this issue.

2) So even though it's reifying everything, the next obvious question is why is it doing it forever? That it due to sequences by default using `.succ` method here, and there exist ranges infinitely repeated ranges because the char of a `.succ` of one char becomes normalized and its .succ is actually prior to that first char.

If you run this code, you can see that after \x[33F], the next char is \x[300] and it loops in that range. That's the normalization biting you.

  my @​stuff = lazy "\x0" ... "\xfff"; .ord.base(16).say for @​stuff

If you need a list of chars between \x0 and \xfff; you can generate the numeric sequence and then use a map to convert to to chars​:

  my @​stuff = map *.chr, lazy 0 ... 0xfff; .say for @​stuff

Cheers,
ZZ

@zoffixznet - Status changed from 'open' to 'rejected'

From @AlexDaniel

While the ticket is rejected, there are ways we can improve the docs. I have created this ticket​: Raku/doc#1103

Perhaps there are other things we should change in the docs (besides documenting what … actually does), feel free to submit more tickets.

On 2017-01-01 10​:11​:57, jjmerelo@​gmail.com wrote​:

This statement

my @​stuff = "\x0"... "\xfff"

hangs the REPL for a while. In fact, memory as reported by top goes up to 1
GB and increases slowly but firmly. This happens whatever the start of the
range and for a few characters.

Ob versions​:
This is Rakudo version 2016.09-68-g447d592 built on MoarVM version
2016.09-1-gdebb859