From cygx@cpan.org

Cf

  say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars #=> 2

vs

  say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars #=> 1

From @samcv

On Fri, 14 Oct 2016 11​:06​:54 -0700, cygx@​cpan.org wrote​:

Cf

say \("\\c\[REGIONAL INDICATOR SYMBOL LETTER G\]" x 2\)\.chars \#=> 2

vs

say \(\[~\] "\\c\[REGIONAL INDICATOR SYMBOL LETTER G\]" xx 2\)\.chars \#=> 1

What is going on here is not a bug in string repetition, but a bug in
converting from List to a Str object.

say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).elems #> 2
say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2)[0].ords #> 127468
say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2)[0].chars #> 1

say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).Str.ords #> (127468 32
127468)

It is adding in a space between the characters when turning it from a List
into a Str.

Will hopefully get more time to look into this bug later.

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

From @samcv

Actually this is not a bug at all, and it is not limited to those characters.

If you do ('a' xx 2).chars you will get 3 as well. If you want to join the list after you create it​:

say ('a' xx 2).join.chars #> 3

Rejecting.

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

From @samcv

17​:54Z <cygx> samcv​: I believe you misread RT #​129878 - the issue is not stringifying a list generated by xx (did you miss the [~]), but the string generated by x

Looks like I made a mistake, re-opening this. Will have to look more into it. Thanks for pointing it out.

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

From @coke

On Fri, 14 Oct 2016 11​:06​:54 -0700, cygx@​cpan.org wrote​:

Cf

say \("\\c\[REGIONAL INDICATOR SYMBOL LETTER G\]" x 2\)\.chars \#=> 2

vs

say \(\[~\] "\\c\[REGIONAL INDICATOR SYMBOL LETTER G\]" xx 2\)\.chars \#=> 1

With a recent rakudo, these now both output 1

say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars
1
say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars
1

--
Will "Coke" Coleda

From @smls

On Wed, 06 Sep 2017 15​:20​:17 -0700, coke wrote​:

With a recent rakudo, these now both output 1

Bisectable shows that it was fixed during recent MoarVM changes​:

  https://gist.github.com/Whateverable/01a82d07e8009c7beffe5893432dddf2
  rakudo/rakudo@593fa5f

Among the listed MoarVM commits, this one seems to be the most likely candidate based on its commit message​:

  MoarVM/MoarVM@62f66cbf

Marking this ticket TESTNEEDED.

From @samcv

On Thu, 07 Sep 2017 09​:52​:07 -0700, smls75@​gmail.com wrote​:

On Wed, 06 Sep 2017 15​:20​:17 -0700, coke wrote​:

With a recent rakudo, these now both output 1

Bisectable shows that it was fixed during recent MoarVM changes​:

https://gist.github.com/Whateverable/01a82d07e8009c7beffe5893432dddf2
rakudo/rakudo@593fa5f

Among the listed MoarVM commits, this one seems to be the most likely
candidate based on its commit message​:

MoarVM/MoarVM@62f66cbf

Marking this ticket TESTNEEDED.

Yes you are correct that that is the MoarVM commit where I fixed it :-)

I added tests here​: Raku/roast@1e4fd21486

Closing this now :-)

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