Fixed in 754664ed54aea24f9c9162002b6e68aadd311412.
On Wed, 08 Oct 2014 05:20:07 -0700, timo wrote:
> compare:
>
> > perl6-m -e 'enum Bug ("foo" => -1, "A", "B"); say +A; say +B;'
> > 1
> > 2
>
> and:
>
> > perl6-m -e 'enum Bug (foo => -1, "A", "B"); say +A; say +B;'
> > 0
> > 1
>
> an
Fixed in 754664ed54aea24f9c9162002b6e68aadd311412.
On Thu, 28 Apr 2016 07:06:42 -0700, gfldex wrote:
> enum Bits ( (('Bit-' X~ 1..8) Z=> (1, 2, 4 ... 256)) ); dd Bits.enums;
> # OUTPUT«{"Bit-1\t1" => 0, "Bit-2\t2" => 1, "Bit-3\t4" => 2, "Bit-
> 4\t8" => 3, "Bit-5\t16" => 4, "Bit-6\t32" => 5, "Bit-
Fixed in 754664ed54aea24f9c9162002b6e68aadd311412.
Note however, that there's a braino above, since the 'my' is initialized after
the value is needed. So the fix is to warn about an empty variable, not to
make it work. (It does work if you make it a constant, or put the my inside a
BEGIN.)
On
Actually, the Z=> misbehavior is already called out in #128017.
On Tue, 28 Nov 2017 00:04:05 -0800, larry wrote:
> This also showed up when doing things like:
> enum Foo ( Z=> 1,2,3);
>
> Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed.
>
>
> On Mon, 07 Nov 2016 11:37:06
Actually, the Z=> misbehavior is already called out in #128017.
On Tue, 28 Nov 2017 00:04:05 -0800, larry wrote:
> This also showed up when doing things like:
> enum Foo ( Z=> 1,2,3);
>
> Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed.
>
>
> On Mon, 07 Nov 2016 11:37:06
This also showed up when doing things like:
enum Foo ( Z=> 1,2,3);
Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed.
On Mon, 07 Nov 2016 11:37:06 -0800, FROGGS.de wrote:
> m: enum Foo ( A => 42, 'B', 'C', 'D' ); say +B
> rakudo-moar e10f76: OUTPUT«43»
>
> m: enum Foo ( 'A
Yes, as noted above, this is a dup of rejected ('better docs needed', really)
ticket #130562.
Yes, as noted above, this is a dup of rejected ('better docs needed', really)
ticket #130562.
Only *@foo and *%foo are slurpy, as in "slurping up the rest of the arguments.
But the term "variadic" refers to all optional arguments including named ones,
so it would be incorrect to call those "slurpy", because they don't. It's like
the difference between * and ? in regex.
Larry
On Fri, 1
Only *@foo and *%foo are slurpy, as in "slurping up the rest of the arguments.
But the term "variadic" refers to all optional arguments including named ones,
so it would be incorrect to call those "slurpy", because they don't. It's like
the difference between * and ? in regex.
Larry
On Fri, 1
We now warn on the ambiguity of >> or » when used where it could easily be
intended as either a hyper or the quotewords terminator. While we could, in
theory, do some lookahead to try to suppress this warning in some cases, it
will be brittle in the face of languages that mutate the postfix spa
On Fri, 09 Jan 2015 10:59:08 -0800, masak wrote:
> m: say :256["☺".ords]
> rakudo-moar c5dcdf: OUTPUT«9786»
> m: say :256[0x263a]
> rakudo-moar c5dcdf: OUTPUT«9786»
> seems we could use a check there...
> m: say :256[256,256]
> rakudo-moar c5dcdf: OUTPUT«65792»
> * masak submits rakudobug
On Fri, Sep 23, 2016 at 11:42:20PM -0700, Itsuki Toyota wrote:
: # New Ticket Created by Itsuki Toyota
: # Please include the string: [perl #129346]
: # in the subject line of all future correspondence about this issue.
: # https://rt.perl.org/Ticket/Display.html?id=129346 >
:
:
: See the fol
Rakudo now gives a decent error (X::Syntax::Signature::InvocantNotAllowed), and
there's even a test for it.
I'm fine with the rakudo behavior here.
The chance of someone using $. inside a regex and meaning what it means in Perl
5 is minimal. Best to just leave this as a "can never match".
Test was bogus. Replaced with test that assumes Empty semantics on next.
test fixed in 06f9c5d010986a7a8dde907971e25985e8ba4601
The code generator in nqp for char ranges was incorrectly using ordat and
ordfirst to find the character to compare, which throw away information on
synthetic characters. We now use the getcp_s instruction instead, which leaves
synthetics negative, so that they drop out of the character range c
Binding of the map routine internally now requires list elements to bind as
Pair, which improves the error message.
(The alternate approach of inserting a CATCH into the map closure could in
theory produce an even better message, but it appeared to slow things down more
than the Pair binding ap
Some method calls were not properly sunk as a final statement in a loop.
Fix in 977797fa401856e5310155f13469b7e6ff5f620a
Test in bc8fa4fd8d449573eb6001b5f43f8890f65b9196
The unwanted() routine needed to add an explicit sink to certain methods found
in a block-final Want node. (Method calls for dispatch:<.=> and Pair.new are
exempt, however. In the case of .=, it is 'nosink' because it's essentially
going to cause a side effect anyway, and doing it twice tends t
The repeat and loop constructs weren't properly self-sinking at statementlist
level.
Fixed in 589061eac14f2847e2c4b401d2ff2eb30c62675e
Test in cbbff3ba0f1120fe7dfded0a980f9b73263f0868
The repeat and loop constructs were not properly sinking themselves at
statementlist level.
Fixed in 589061eac14f2847e2c4b401d2ff2eb30c62675e
Untodo'd existing test.
We now examine the preceding character, and if it's a closing brace, suggest
use of whitespace before curlies taken as a hash subscript.
Fixed in 7ec824e52ab5b285cda47179e6f41e452d870762
This turns out to be a fascinating bug, not the usual "useless use of useless
use".
We were cloning a closure twice because we were calling EXPR twice on the same
expression, namely inside the 'for' rule that looks for a C-style for loop. It
was doing this inside a because it was just conject
We've split the non-associative exceptions into the base class,
X::Syntax::NonAssociative, with a subclass off X::Syntax::NonListAssociative.
nqp's EXPR now calls a different method to fail list associativity, and rakudo
provides the alternate method to get the appropriate message.
nqp fix in
The onearg form of reduce wasn't correctly marking wantedness of either the
operator or the argument.
Fixed in fc28b67185d711cf8e4b3f9e6987e1ceee34e37b.
(We don't test sink warnings currenlty.)
The logical ops andthen, notandthen, and orelse were not propagating wantedness
to their thunky args.
Fixed in 7ba6dbfae97f5ff9398336e49267d51606512df9.
Note that we don't generally test sink warnings currently.
Not A Bug.
LTM requires it to recognize => over = inside, and then you're missing a >.
Looking at it from the other direction, thinking that it will find the >> on
the end and then back up to isolate the = is a subtle mental trap of two-pass
parsing, which is typically forbidden in Perl 6. To
Now says: Virtual method call $.foo may not be used on partially constructed
object (maybe you mean $!foo for direct attribute access here?)
Fix in 5a69da88b9b16f916125add8f89aff68113a9877
Dup of #127013, see fix there.
Dup of #127013.
Tests for this particular ticket in a8bbde8fa06d5d55bc6d5879a0c84a669d7f0481
Fix in 386905f6f62f9fa3525c887a8a86fa48b22b4b35 and
37e742f0bb6f36f1a9d9a5f947c5c0de15d236c2
Test in ba521fa8101f3114c87ec1a295707cb68b5b
Fixed in 02588190492349fabde00c5a15b873ea61a9333e
Tested in 2f126a3ab7d0991767ca84c562b8f3ae97b25c4e
There are no tests there for with or whenever, but those did not appear to
misbehave when I tried them on the command line. Feel free to add more tests
for those.
A new restricted dialect of regex is implemented in
28ab83f947b4899a4f8698eee5bc056742f356f1 and
19d84be0066978f616ace6fa9f506e742161a378
Tests in 1becd7c9b456b707a14bfba40d672ec28945f199
Fixed in 091ee7507464595e7712f4ae911d95d467e5281b
Tests in 8b97aa4f6191affdd91da78607eca4ae6dc73b11
fixed in 323a5c077efeaa058de48871963046507e33b272
Minimal test case:
{ my $f := Failure.new("bar"); }
This doesn't seem to be sink related, at least not directly. It seems more to
be related to the difference between storing things in a local vs in a lexical,
and how those are treated on statement or return boundaries.
I shouldn't file bugs when I haven't slept...
~~ is now chaining where it can be; it obviously makes little sense to chain
something on both sides that is not a normal data value. So if you include a
regex or a closure, it must be the final test. Also, in order
to get $a ~~ $b ~~ $c to work, we cannot topicalize $b.
Fix in f457007181bb6e2
Fixed, along with all the other metaops, in:
1e1556b1a25bc4c73a505fdd249d4179ffc813de
0a2303c0f6a2a3782fecb13db1523cb5442467de
67202d697d3fe48b800e95262bebe6da17bfcf49
e2e23fb8853808839884f23a0b8aa91f458fd310
97ef742f350e84dae275ed2dc9d453795f057dba
6516930c86d6ff4296ee8699a64eb1315eed2583
Tests:
The add_categorical method was assuming it was adding a fresh definition of an
operator, not one borrowed from a module, so it overrode the existing
precedence with the defaults, which are wrong if the existing precedence
doesn't happen to match the default.
Fixed with bb598968c68bff2163322aea0
Fixed with 67795245fd9b17ca11036b63aa04e17deabb8e7a
Tests needed.
The default of die is to, er, die. You can resume after a die, but only if you
do so explicitly, in which case you are responsible for overriding the
expectations of whoever wrote the die and likely did not expect it to return.
> p6 'sub a($a) { $a(); CATCH { default { say "default"; .resume }
fix in MoarVM, 6da907f72a8a0015f4631b7d11a20fc428e9aad4
test in 0d2a5c01972d11c0a35573e8362c040bf974cde3
The purpose of stubbing is to guarantee the public interface is complete, and
since the public interface of attributes is entirely via accessors, it suffices
to merely stub the accessor, and leave it up to the class whether it should
implement that name via an explicit method or an attribute dec
Dup of #126597
Matching only the final match is not desirable, in my opinion. It should match
the string traversed by all the matches in $0, including intervening
separators, if any. The problem is that ~$0 has spaces interpolated, which will
match only if the separators happen to be a single space, so there i
Fixed in 9e4902f772b0e86fe96771b22039aaf1a57fae34
Fixed in 36a35142a0b7dadd65a5b09bcba7f460845ae3e9
Tests in 2ccb4443d61efd053419239203106e5636b021ce and
7cd9f97ccdad6299c3b6dc4d4b071c6580c0b66c
On Mon Oct 19 07:02:44 2015, elizabeth wrote:
> Fixed with a31cc91a0d604a8a74529 . Tests are still needed
>
> > On 19 Oct 2015, at 03:42, Carsten Hartenfels (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Carsten Hartenfels
> > # Please include the string: [perl #126394]
On Sat Oct 10 08:33:13 2015, FROGGS.de wrote:
> say class { has Int $.foo is default(0) }.new.foo
> rakudo-moar 025ec1: OUTPUT«(Int)»
>
> class Foo { has Int $.foo is default(0) }; say Foo.new.foo
> rakudo-moar 025ec1: OUTPUT«(Int)»
>
> I would expect that foo is zero in both cases.
Even less
Fixed with 23248109c9c93db2774fcc9ce0c849a73a01fdad
Tested with f8c0844fbffeac6022603cda8bfbc4f1f35e9a57
On Wed Oct 14 09:46:18 2015, larry wrote:
> 09:39 < TimToady> HLL::Compiler is very confused about what is the language
> name/version vs compiler name/version, and this shows up in both -v and -V
> 09:40 < TimToady> "This is perl6 version 2015.09-373-g254c1a8"
> 09:42 < TimToady> should be more l
nqp fix in a79e4abbe60d28f59b451416e7946ee433db7199
rakudo fix in 091637fd5ace48a0835fc8af786f2caa372381cf
roast fix in dc3e1335232bb617b42d335ddbcc42be0a9dedaa
Statement modifiers now behave as terminators. Tests in
6fa03d9816b1613762f12def4bbc556dbb5fb3d5
This works now, due to the precedence changes associated with adding the dot
infix operator.
Whoops, posted the wrong examples. These actually show the difficulty:
> p6 'say() <== map { $_ * 2 } <== 1...10'
(2 4 6 8 10 12 14 16 18 20)
> p6 'say() <== map { $_ * 2 },0 <== 1...10'
(0 20)
So this really looks like an insidious case of accidental one-arg semantics.
In C culture, a bare return means "This is a procedure, not a function, and I'm
not expecting to return anything", and so I think the absence of a meaningful
value is properly conveyed by Nil in Perl 6. If the intent of a return is to
allow interpolation of Slip or (), then that choice should b
Don't need this, using the Top or other rule name is sufficient.
There's no reason orelse should bind a single undefined value to multiple
formals. Test removed with https://github.com/perl6/roast/commit/30f08b143a
Mu ~~ 0 now works but will always return False, since we don't want people to
start using Mu as a numeric semipredicate.
62 matches
Mail list logo
