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
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
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).
Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on my
machine:
$ perl6 -e 'my $proc = run($*EXECUTABLE, "-e"
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 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.
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
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
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
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
17 matches
Mail list logo
