From @bbkr

Rakudo version 2017.09 built on MoarVM version 2017.09.1
MacOS 10.10.5, tested both in iTerm2 and built-in Terminal app.

Following code does not wait for user input but exits immediately.

perl6 -e 'say $*IN.getc'
Nil

BTW​: This affects modules such as Terminal​::Print that are unable to react to user input on macOS.

My default TTY settings are​:
$ stty
speed 38400 baud;
lflags​: echoe echok echoke echoctl pendin
iflags​: iutf8
oflags​: -oxtabs
cflags​: cs8 -paren

But even setting it to raw mode​:
$ stty raw
$ stty
speed 38400 baud;
lflags​: -icanon -isig -iexten -echo echoke echoctl
iflags​: -icrnl -ixon -imaxbel iutf8 ignbrk -brkint
oflags​: -opost -oxtabs
cflags​: cs8 -parenb

does not wait for user input.

From @bbkr

I've tested previous Rakudo builds and moar-2017.05 works fine, moar-2017.07 is broken. So regression happened somewhere between those two versions.

From @timo

can you get us strace output for this?

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

From @bbkr

There is no strace on macOS, I used dtruss (dtrace)​:

$ dtruss -p 1827
SYSCALL(args) = return
fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
lseek(0x0, 0x0, 0x1) = 54132 0
write(0x1, "Nil\n\0", 0x4) = 4 0
thread_selfid(0x0, 0x7F8252ED2090, 0x4) = 24710 0

From @AlexDaniel

[Coke]++ bisected it to rakudo/rakudo@80bbfcd

On 2017-10-22 12​:25​:07, bbkr@​post.pl wrote​:

There is no strace on macOS, I used dtruss (dtrace)​:

$ dtruss -p 1827
SYSCALL(args) = return
fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
lseek(0x0, 0x0, 0x1) = 54132 0
write(0x1, "Nil\n\0", 0x4) = 4 0
thread_selfid(0x0, 0x7F8252ED2090, 0x4) = 24710 0

From @coke

On Sun, 22 Oct 2017 12​:25​:07 -0700, bbkr@​post.pl wrote​:

There is no strace on macOS, I used dtruss (dtrace)​:

$ dtruss -p 1827
SYSCALL(args) = return
fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
lseek(0x0, 0x0, 0x1) = 54132 0
write(0x1, "Nil\n\0", 0x4) = 4 0
thread_selfid(0x0, 0x7F8252ED2090, 0x4) = 24710 0

This behavior changed on rakudo/rakudo@80bbfcd

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author​: Jonathan Worthington <jnthn@​jnthn.net>
Date​: Fri Jul 14 14​:24​:13 2017 +0200

  Use same slow-path for getc and readchars.

  This will allow fixing the common problem they have near the end of
  the file in one place, as well as giving less code to maintain.

IRC chat noted the behavior of

perl6 -e '$*IN.eof.say'

Is different on OS X and other platforms (True on mac, False elsewhere)

--
Will "Coke" Coleda

From @zoffixznet

On Mon, 23 Oct 2017 07​:15​:56 -0700, coke wrote​:

On Sun, 22 Oct 2017 12​:25​:07 -0700, bbkr@​post.pl wrote​:

There is no strace on macOS, I used dtruss (dtrace)​:

$ dtruss -p 1827
SYSCALL(args) = return
fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
lseek(0x0, 0x0, 0x1) = 54132 0
write(0x1, "Nil\n\0", 0x4) = 4 0
thread_selfid(0x0, 0x7F8252ED2090, 0x4) = 24710 0

This behavior changed on
rakudo/rakudo@80bbfcd

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author​: Jonathan Worthington <jnthn@​jnthn.net>
Date​: Fri Jul 14 14​:24​:13 2017 +0200

Use same slow-path for getc and readchars.

This will allow fixing the common problem they have near the end of
the file in one place, as well as giving less code to maintain.

IRC chat noted the behavior of

perl6 -e '$*IN.eof.say'

Is different on OS X and other platforms (True on mac, False
elsewhere)

More IRC discussion​: https://irclog.perlgeek.de/perl6-dev/2017-10-23#i_15341428

Kinda boils down to this snippet saying "STDIN IS​: seekable" on Macos, while NOT seekable everywhere else​:

  #include <stdio.h>
  #include <sys/types.h>
  #include <unistd.h>
 
  int main(void) {
  int r = lseek(STDIN_FILENO, 0, SEEK_CUR);
  printf("STDIN IS​: %s\n", (r && r != -1) ? "seekable" : "NOT seekable");
  return 0;
  }

And some C++ stackoverflow post claimed this was a bug in standard library on macos that was fixed in some version already.

From @bbkr

And some C++ stackoverflow post claimed this was a bug in standard
library on macos that was fixed in some version already.

I'll try to get you Sierra (10.12) and High Sierra (10.13) results tomorrow.

From @zoffixznet

On Mon, 23 Oct 2017 09​:28​:47 -0700, bbkr@​post.pl wrote​:

And some C++ stackoverflow post claimed this was a bug in standard
library on macos that was fixed in some version already.

I'll try to get you Sierra (10.12) and High Sierra (10.13) results tomorrow.

Added a test (in a branch) that covers the bug​: Raku/roast@27833272b4
I also made a MoarVM PR that fixes the bug​: MoarVM/MoarVM#731

However, I've no idea if that fix is sane and whether it has significant performance impact
on MacOS (I was using someone's VM for the fix and couldn't get reliable spectest or perf measure done).

From @zoffixznet

On Mon, 23 Oct 2017 20​:05​:33 -0700, cpan@​zoffix.com wrote​:

On Mon, 23 Oct 2017 09​:28​:47 -0700, bbkr@​post.pl wrote​:

And some C++ stackoverflow post claimed this was a bug in standard
library on macos that was fixed in some version already.

I'll try to get you Sierra (10.12) and High Sierra (10.13) results
tomorrow.

Added a test (in a branch) that covers the bug​:
Raku/roast@27833272b4
I also made a MoarVM PR that fixes the bug​:
MoarVM/MoarVM#731

However, I've no idea if that fix is sane and whether it has
significant performance impact
on MacOS (I was using someone's VM for the fix and couldn't get
reliable spectest or perf measure done).

Thank you for the report. This is now fixed.

Fix​: rakudo/rakudo@eb1febd5658377a
  Raku/nqp@8fa082b269
  MoarVM/MoarVM@27f91344cc
Test​: Raku/roast@cb7ec603ccebdb55c

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