chr() returns something that is not a string of characters, and say/print outputs it as bytes in Rakudo

[p6rt]

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

Searchable as RT77888$

[p6rt]

From @masak

<masak> perl6​: say chr(194), chr(177)
<p6eval> rakudo 358d72​: OUTPUT«±␤»
<p6eval> ..pugs​: OUTPUT«Â±␤»
<masak> I'm with pugs on this one.
<TimToady> I'm with masak on this one.
* masak submits rakudobug on this one
<masak> perl6​: print .chr for <233 186 166 233 171 152>
<p6eval> rakudo 358d72​: OUTPUT«麦高»
<p6eval> ..pugs​: OUTPUT«éº¦é«�»
<masak> clearly rakudo is thinking in bytes, not characters.
<TimToady> indeed

[p6rt]

From @pmichaud

This appears to be caused by a Parrot FileHandle bug -- filed as TT #​1793.

Pm

[p6rt]

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

[p6rt]

From @pmichaud

Now fixed in 760c734​:

  pmichaud@​plum​:~/rakudo$ ./perl6
  > print .chr for <233 186 166 233 171 152>;
  麦é«>

The TT #​1793 ticket turned out to be a non-bug; the problem was in
Rakudo's setup of $*IN, $*OUT, and $*ERR.

I'm not sure how the current test suite would be able to test this
particular bug (since it's in the standard output filehandle), so I'm
going to go ahead and mark the ticket as resolved. (If someone has a
good way of testing this, it would be welcome.)

Thanks!

Pm

[p6rt]

From @pmichaud

Now fixed in 760c734​:

  pmichaud@​plum​:~/rakudo$ ./perl6
  > print .chr for <233 186 166 233 171 152>;
  麦é«>

The TT #​1793 ticket turned out to be a non-bug; the problem was in
Rakudo's setup of $*IN, $*OUT, and $*ERR.

I'm not sure how the current test suite would be able to test this
particular bug (since it's in the standard output filehandle), so I'm
going to go ahead and mark the ticket as resolved. (If someone has a
good way of testing this, it would be welcome.)

Thanks!

Pm

[p6rt]

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