Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

When I filed this ticket I kinda expected that somehow rakudo or libuv would handle this for me under the hood. But what Timo and Brandon say makes sense. The process is still running when you slurp-rest. slurp-rest neds EOF before it stops blocking. It will never get it because the writing

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

When I filed this ticket I kinda expected that somehow rakudo or libuv would handle this for me under the hood. But what Timo and Brandon say makes sense. The process is still running when you slurp-rest. slurp-rest neds EOF before it stops blocking. It will never get it because the writing

[perl #130688] [BUG] .subst/.subst-mutate with :g do not set $/ to all the matches

On Wed, 22 Mar 2017 13:58:22 -0700, c...@zoffix.com wrote: > Also affects :x and :nth modifiers > > m: 'mmm'.subst: :x(1..3), /m/, 'g'; say WHAT $/ > rakudo-moar 6a77cd: OUTPUT: «(Match)␤» > m: 'mmm'.subst: :nth(1..3), /m/, 'g'; say WHAT $/ > rakudo-moar 6a77cd: OUTPUT: «(Match)␤»

[perl #130688] [BUG] .subst/.subst-mutate with :g do not set $/ to all the matches

On Wed, 22 Mar 2017 13:58:22 -0700, c...@zoffix.com wrote: > Also affects :x and :nth modifiers > > m: 'mmm'.subst: :x(1..3), /m/, 'g'; say WHAT $/ > rakudo-moar 6a77cd: OUTPUT: «(Match)␤» > m: 'mmm'.subst: :nth(1..3), /m/, 'g'; say WHAT $/ > rakudo-moar 6a77cd: OUTPUT: «(Match)␤»

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

And in the cases where it "works", the buffer is larger. Which runs the risk of consuming all available memory in the worst case, if someone tries to "make it work" with an expanding buffer. The fundamental deadlock between processes blocked on I/O is not solved by buffering. Something needs to

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

And in the cases where it "works", the buffer is larger. Which runs the risk of consuming all available memory in the worst case, if someone tries to "make it work" with an expanding buffer. The fundamental deadlock between processes blocked on I/O is not solved by buffering. Something needs to

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

This is a well-known problem in IPC. If you don't do it async, you risk the buffer you're not currently reading from filling up completely. Now your client program is trying to write to stderr, but can't because it's full. Your parent program is hoping to read from stdin, but nothing is arriving,

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

This is a well-known problem in IPC. If you don't do it async, you risk the buffer you're not currently reading from filling up completely. Now your client program is trying to write to stderr, but can't because it's full. Your parent program is hoping to read from stdin, but nothing is arriving,

[perl #126897] [BUG] Slip objects deparse as List

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote: > so no > further tests needed > > > Liz And in addition it's covered by tests for another slip bug: https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff Closing.

[perl #126897] [BUG] Slip objects deparse as List

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote: > so no > further tests needed > > > Liz And in addition it's covered by tests for another slip bug: https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff Closing.

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote: > Seems an optimizer bug. Running with --optimize=off does not have the > issue present. Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote: > Seems an optimizer bug. Running with --optimize=off does not have the > issue present. Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote: > FWIW that hangs on FreeBSD as well (maybe not too much a surprise, > given the relationship of the OSes). Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on my machine: $ perl6 -e 'my $proc = run($*EXECUTABLE,

Re: (default) Real->Rat precision should match what compiler uses for literals

On Sun, Mar 4, 2018 at 8:49 AM, yary wrote: > In that spirit, I'd expect numeric comparison in general, and epsilon > specifically, to be set so these return True: > > > pi == pi.Rat # Does Num to Rat conversion keep its precision? > False > > pi.Str.Num == pi # Does Num

[perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote: > FWIW that hangs on FreeBSD as well (maybe not too much a surprise, > given the relationship of the OSes). This still hangs on MoarVM, but works on JVM (I didn't check the behaviour on JVM last year): $ ./perl6-j -e 'my $proc =

[perl #130892] t\spec\S32-io\IO-Socket-INET.t hangs

A Windows-specific skip-fudge now went in[^1] but the problem remains [1] https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd

[perl #130892] t\spec\S32-io\IO-Socket-INET.t hangs

A Windows-specific skip-fudge now went in[^1] but the problem remains [1] https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd