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
process
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
process
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)»
Tha
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)»
Tha
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 act
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 act
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, a
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, a
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.
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.
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
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
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, "-e"
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 survive string round-trip
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 = run($*EX
A Windows-specific skip-fudge now went in[^1] but the problem remains
[1]
https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd
A Windows-specific skip-fudge now went in[^1] but the problem remains
[1]
https://github.com/perl6/roast/commit/86abb5376bd331d9766212ce4d0c11c11dd5c5dd
17 matches
Mail list logo