Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd
Tests: https://github.com/perl6/roast/commit/927b026
On Thu, 13 Jul 2017 10:54:27 -0700, ug...@cpan.org wrote:
> Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd
>
> Tests: https://github.com/perl6/roast/commit/927b026
Closing issue. ugexe++
On Wed, 12 Jul 2017 15:30:33 -0700, ug...@cpan.org wrote:
> Resolved in https://github.com/rakudo/rakudo/commit/c86090e
>
> `perl6 -e 'run("ls", :merge).out.slurp.say'`
Worls on OSX as well. The fudged test was unfudged by ugexe++. Closing issue.
Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd
Tests: https://github.com/perl6/roast/commit/927b026
'dirname' represents a component of a path, not a path. I suspect the
internal field components should be renamed, though, as people do not
generally think in terms of the implementation of the shell's 'dirname',
but instead of its effective behavior. (The implementation splits a path
into its
'dirname' represents a component of a path, not a path. I suspect the
internal field components should be renamed, though, as people do not
generally think in terms of the implementation of the shell's 'dirname',
but instead of its effective behavior. (The implementation splits a path
into its
On 2017-07-13 08:18:20, alex.jakime...@gmail.com wrote:
> On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> > This only applies if you call .stdout or .stderr *and* never close
> > them.
>
> Hm, isn't it fixed now? Similarly to
> https://github.com/perl6/doc/issues/1304 ?
Ah, no, it's not. It's a
On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> This only applies if you call .stdout or .stderr *and* never close them.
Hm, isn't it fixed now? Similarly to https://github.com/perl6/doc/issues/1304 ?
On Wed, 22 Feb 2017 19:32:31 -0800, comdog wrote:
> Here's a curious change over in precision:
>
> > 4.999 ~~ 0..^5
> True
> > 4. ~~ 0..^5
> False
>
> I figure this is an implementation detail that ties to storage, but
> one of the selling points of
On Wed, 22 Feb 2017 19:32:31 -0800, comdog wrote:
> Here's a curious change over in precision:
>
> > 4.999 ~~ 0..^5
> True
> > 4. ~~ 0..^5
> False
>
> I figure this is an implementation detail that ties to storage, but
> one of the selling points of
# New Ticket Created by
# Please include the string: [perl #131739]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131739 >
Guys,
Here is a one liner to illustrate a possible bug trying to redefine the
operator '>' and I
# New Ticket Created by
# Please include the string: [perl #131742]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131742 >
Hi,
I have found some unexpected behaviour when attempting to redefine the
operator '>'.
First
# New Ticket Created by Evan Miller
# Please include the string: [perl #131740]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131740 >
I'm using the new scheduler behavior described here:
On Tue, 11 Jul 2017 07:08:43 -0700, elizabeth wrote:
>
> > On 11 Jul 2017, at 15:34, Jarkko Haapalainen (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Jarkko Haapalainen
> > # Please include the string: [perl #131737]
> > # in the subject line of all future correspondence
14 matches
Mail list logo
