On Mon, Sep 11, 2017 at 09:48:01AM -0700, Dan Zwell wrote:
>
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
>
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil
Isn't the whole point of :ratchet to turn
On Mon, Sep 11, 2017 at 09:48:01AM -0700, Dan Zwell wrote:
>
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
>
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil
Isn't the whole point of :ratchet to turn
On Mon, 11 Sep 2017 16:53:15 -0700, b...@abrij.org wrote:
> On Mon, 11 Sep 2017 13:35:54 -0700, zef...@fysh.org wrote:
> > Brian S. Julin via RT wrote:
> > >Fixed in 2017.6 or thereabouts.
> >
> > Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
> > 2017-06-15.
> >
> > -zefram
On Mon, 11 Sep 2017 13:35:54 -0700, zef...@fysh.org wrote:
> Brian S. Julin via RT wrote:
> >Fixed in 2017.6 or thereabouts.
>
> Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
> 2017-06-15.
>
> -zefram
Tests added in roast 9a09b4ee, resolving this ticket.
# New Ticket Created by Dan Zwell
# Please include the string: [perl #132066]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132066 >
`|` matches the longest input:
> 'ab' ~~ / ^:ratchet [ . | .. ] $ /
｢ab｣
If the regex conta
Actually...
Rakudo *does* generally follow interpretation (b):
➜ 'x' ~~ / .* { say '*' } | .? { say '?' } /; # *
➜ 'x' ~~ / .? { say '?' } | .* { say '*' } /; # ?
The observed bug is specifically with character classes:
➜ '1' ~~ / { say 'digit' } | <[0..9]> { say '0..9' }
Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.
Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.
-zefram
Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.
Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.
-zefram
On Sun, 14 Aug 2016 08:01:48 -0700, zef...@fysh.org wrote:
> The description of coercion in S02 says:
>
> # The type outside the parens indicates the desired end result, and
> # subsequent code may depend on it being that type.
>
> Rakudo does not actually ensure that the result of a coercion is
On Sun, 10 Sep 2017 11:44:09 -0700, b...@abrij.org wrote:
> On Fri, 08 Sep 2017 21:13:59 -0700, b...@abrij.org wrote:
> > On Wed, 23 Aug 2017 06:20:49 -0700, b...@abrij.org wrote:
> > > On Mon, 24 Jul 2017 10:04:54 -0700, c...@zoffix.com wrote:
> > > > The coercion works fine here:
> > > >
> > > >
On Fri, 27 Jan 2017 16:11:28 -0800, c...@zoffix.com wrote:
> Another related one (the first colonpair has empty key):
>
> m: sub infix:bar {}
> rakudo-moar cfae23: OUTPUT«===SORRY!===Cannot find method
> 'has_compile_time_value' on object of type NQPMu»
Current behavior:
$ perl6 -e 'sub inf
On Fri, 19 Aug 2016 19:00:53 -0700, zef...@fysh.org wrote:
> Pair.perl produces incorrect output for some type objects:
>
> > ((Int) => 2).perl
> Int => 2
> > ((Int) => 2).perl.EVAL.perl
> :Int(2)
>
> Following the fix for [perl #126890] it's correct for most type
> objects:
>
> > ((Pair) => 2).
This bug is still present in
Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.
---
However, there's also a design question to be answered here:
On Sat, 21 Jan 2017 10:32:39 -0800, ronaldxs wrote:
> https://design.perl6.org/S
PS: This *really* needs to be properly documented on http://docs.perl6.org
though - I've submitted a ticket for that here:
https://github.com/perl6/doc/issues/1550
On Mon, 11 Sep 2017 09:48:01 -0700, dzw...@gmail.com wrote:
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
>
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil
Not a bug.
As the S05 design document expla
On Sun, 20 Sep 2015 09:17:21 -0700, zef...@fysh.org wrote:
> Presumably using a defined value (anything other than a type object)
> as a type constraint should be a semantic error.
It does throw a compile-time error for the `my` declaration now, however the
error message is not appropriate:
On Sun, 20 Sep 2015 14:00:53 -0700, zef...@fysh.org wrote:
> Presumably the "malformed my" error is correct, but the preceding "type
> 'Any' is not declared" is bogus.
It now no longer prints the bogus "type 'Any' is not declared" error, only the
correct "malformed my" error:
➜ my Any⏏ :D $
On Mon, 05 Oct 2015 09:10:42 -0700, grond...@yahoo.fr wrote:
> The following two expressions should give the same result:
>
> $ perl6 -e 'say ([o] (1 + 1/*), (2 + 1/*))(Inf);'
> 1.5
>
> $ perl6 -e 'say ([o] (++$ + 1/*) xx 2)(Inf);'
> 3
What's happening is that the `++$` operation isn't evaluated
Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later commits),
tests needed.
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
>
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
>> perl6-bugs-follo
Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later commits),
tests needed.
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
>
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
>> perl6-bugs-follo
On Sat, 09 Sep 2017 19:53:53 -0700, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
> {}
> > %h
> {b => 3}
>
> The array/hash variable's default is an empty array/hash literal. If
On Sat, 09 Sep 2017 19:53:53 -0700, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
> {}
> > %h
> {b => 3}
>
> The array/hash variable's default is an empty array/hash literal. If
22 matches
Mail list logo
