[perl #128657] [BUG] multi from parent which does same role doesn't work
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #128657] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128657 > role R { proto method foo {*} }; class A does R { multi method foo { say "A" } }; class B is A does R { }; B.foo === Use of uninitialized value of type Any in string context Any of .^name, .perl, .gist, or .say can stringify undefined things, if needed in block at -e line 1 Cannot resolve caller foo(B); none of these signatures match: in block at -e line 1' === My opinion is that B should clone the dispatcher from A. Any candidates added in B would then be added to it. In any case, candidate merging should be smarter in classes that do the same role IMO.
[perl #128656] [LTA] unfinished postcircumfix inside quote causes awful side effects
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #128656] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128656 > class A { method foo { "$name(" } }; role C { method foo { } }; class B { method foo { } }; ===SORRY!=== Error while compiling -e Package 'A' already has a method 'foo' (did you mean to declare a multi-method?)
[perl #128655] Mixup in candidates through optimizer
# New Ticket Created by Elizabeth Mattijsen # Please include the string: [perl #128655] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128655 > m: Buf.new((my int $i = 10) +& 0xFF) Type check failed in initializing element #0 to Buf; expected uint8 but got Int (10) in any at gen/moar/m-Metamodel.nqp line 1736 in block at line 1 Actually thrown at: in any at gen/moar/m-Metamodel.nqp line 3055 in an… On further inspection, it appears that the value found in the argument list is a BOOTInt, rather than an Int, and that fails the nqp::istype($a,Int) test. It *feels* like it calling the int/int candidate, when it thinks it's calling the Int:D/Int:D candidate. Since the int/int candidate returns an int, but the optimizer probably thinks it is getting an Int, the native is not marshalled into an Int when it should. This bug probably existed for a long time already, but was uncovered by de5d9e70cbfe678d2371d284 . Before, going through all of the iterator stuff, would marshall the int into an Int It appears that all bitwise operators that return an int/Int have the same problem with the calling them with a native parameter. The problem goes away if optimizing is somehow inhibited, but that, I feel, is just masking the problem. Ways of stopping optimization are: - calling perl6 with —optimize=0 or —optimize=1 - adding an nqp::null to the native int candidate multi sub infix:<+&>(Int:D \a, Int:D \b) { nqp::bitand_I(nqp::decont(a), nqp::decont(b), Int) } multi sub infix:<+&>(int $a, int $b) { nqp::null; # stops optimization nqp::bitand_i($a, $b) } Note that the problem gets fixed by adding an optimizer stopper to the candidate that is *not* being called, as 0xFF is an Int, and thus int $i +& 0xFF is calling the Int:D/Int:D candidate!! Since this idiom is quite normal, a quick fix seems in order.
Re: Announce: Rakudo Perl 6 compiler, Release #101 (2016.07)
There is a release candidate at http://pl6anet.org/drop/rakudo-star-2016.07-RC0.tar.gz S On 16 July 2016 at 18:51, wrote: > > Quoting Parrot Raiser <1parr...@gmail.com>: > >> When's the next Rakudo* likely to be out? > > > There's a serious consideration to cut a release this month, so you will > likely see one in the next couple of weeks. > > Cheers, > ZZ > -- 4096R/EA75174B Steve Mynott
[perl #126001] Blockless LAST phaser puts Mu in the iteration variable
Behaviour for Moar is unchanged. The code works as expected on JVM: $ perl6-j -e 'for 1, 2 { LAST say $_ }' 2 I added a test to S04-phasers/in-loop.t with commit https://github.com/perl6/roast/commit/a1c52bacd3 BTW, this ticket looks related to the failing tests from https://rt.perl.org/Ticket/Display.html?id=121722
[perl #128553] multi method cache causes Base64 regression
On Sat Jul 09 07:13:48 2016, jn...@jnthn.net wrote: > On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote: > > Note that the final decode-base64 candidate shows the correct results > > when debugging statements are added > > > > This gist also shows a small change that makes it produce the correct > > values but it still segfaults more often than not > > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d > > Having dug into it a little, I'm not sure that the new multi-caching > stuff has caused this, so much as uncovered it (perhaps by moving GC > collection points You are right. I golfed it down to the following gist which does not use multi methods: https://gist.github.com/ugexe/7ce08d3ad4cfd36f275c437ba9713471 In the gist comments there is also a link to the bisect output, but for brevity: bisect output: https://gist.github.com/Whateverable/e0a28162b19f601616aa8776f24dd027 rakudo commit: https://github.com/rakudo/rakudo/commit/5581b24
[perl #128123] [JVM] failing test in S03-metaops/hyper.t after change from postfix:<++> to prefix:<++>
I found another strange failure which dies the same way. The error happens in S32-list/combinations.t and can be golfed down to this: $ ./perl6-j -e 'say (1).combinations(0..1); say ().combinations' (() (1)) Expected a native int argument for '$a' Like my original report this happens while using 'combinations' (this time as a method). Even if this one blows up in postfix:<++> I believe there is the same bug surfacing. Therefore I use this ticket to report the new error. I didn't bisect yet, but 78ba3df7e1 was still good and bc722abe2c was already bad. Note, that there is an NQP bump in between. $ perl6-j --ll-exception -e 'say (1).combinations(0..1); say ().combinations' (() (1)) Expected a native int argument for '$a' in postfix:<++> (gen/jvm/CORE.setting:9361) in postfix:<++> (gen/jvm/CORE.setting:2268) in pull-one (gen/jvm/CORE.setting:14468) in first (gen/jvm/CORE.setting:5229) in first (gen/jvm/CORE.setting:5228) in call_with_capture (gen/jvm/Metamodel.nqp:3854) in (gen/jvm/CORE.setting:698) in (gen/jvm/CORE.setting:14715) in first (gen/jvm/CORE.setting:14702) in combinations (gen/jvm/CORE.setting:16223) in combinations (gen/jvm/CORE.setting:16218) in (-e:1) in (-e:1) in eval (gen/jvm/stage2/NQPHLL.nqp:1198) in (gen/jvm/stage2/NQPHLL.nqp:1288) in command_eval (gen/jvm/stage2/NQPHLL.nqp:1285) in command_eval (src/Perl6/Compiler.nqp:27) in command_line (gen/jvm/stage2/NQPHLL.nqp:1269) in MAIN (gen/jvm/main.nqp:37) in (gen/jvm/main.nqp:33) in (gen/jvm/main.nqp)
[perl #128094] [JVM] Issues with rakudo-j after merge of branch 'relocateable-precomp'
The remaining issues are resolved now. Therefore, I'm closing this ticket.
[perl #128652] [BUG] Rakudo 2016.07 release installation error at $*REPO.install
# New Ticket Created by Andy Weidenbaum # Please include the string: [perl #128652] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128652 > The process is not looking for CompUnit::Repository::Staging in the Arch Linux temporary build sandbox at `@*ARGS[0]: "/pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6"`. Rather, it is looking for CompUnit::Repository::Staging in `/usr/share/perl6`, which does not exist at the time of installation: ``` $ make DESTDIR="$pkgdir" install mkdir -p -- /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/bin mkdir -p -- /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/nqp/lib/Perl6 cp -- blib/Perl6/ModuleLoader.moarvm blib/Perl6/World.moarvm blib/Perl6/Grammar.moarvm blib/Perl6/Ops.moarvm blib/Perl6/Actions.moarvm blib/Perl6/Optimizer.moarvm blib/Perl6/Pod.moarvm blib/Perl6/Compiler.moarvm blib/Perl6/Metamodel.moarvm blib/Perl6/BOOTSTRAP.moarvm blib/Perl6/DebugPod.moarvm /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/nqp/lib/Perl6 mkdir -p -- /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/lib mkdir -p -- /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/runtime cp -- CORE.setting.moarvm RESTRICTED.setting.moarvm /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/runtime cp -- perl6.moarvm perl6-debug.moarvm /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/runtime mkdir -p -- /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/runtime/dynext cp -- dynext/libperl6_ops_moar.so /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/runtime/dynext ./perl6-m tools/build/upgrade-repository.pl /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6 ./perl6-m tools/build/upgrade-repository.pl /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/vendor ./perl6-m tools/build/upgrade-repository.pl /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6/site ./perl6-m tools/build/install-core-dist.pl /pkgbuilds/perl6/rakudo/pkg/rakudo/usr/share/perl6 Installing Pod::To::Text for CORE Installing NativeCall::Compiler::MSVC for CORE Installing CompUnit::Repository::Staging for CORE Installing experimental for CORE Installing newline for CORE Installing NativeCall::Compiler::GNU for CORE Installing NativeCall for CORE Installing NativeCall::Types for CORE Installing Test for CORE Installing TAP for CORE Precompiling 2ACCA56EF5582D3ED623105F00BD76D7449263F7 (NativeCall::Compiler::MSVC) ===SORRY!=== Could not find CompUnit::Repository::Staging at line 0 in: /usr/share/perl6 CompUnit::Repository::AbsolutePath<14734480> CompUnit::Repository::NQP<46586384> CompUnit::Repository::Perl5<46586424> in block at tools/build/install-core-dist.pl line 21 make: *** [Makefile:565: m-install] Error 1 ```
Re: [perl #128632] [BUG] get freezes terminal on x64 Windows implementation
Looking at the version numbers, 2016.04 on vs 2016.06 suggests it might have been fixed. Can you get the later version on the Windows box? On 7/16/16, Josh Helzer wrote: > # New Ticket Created by Josh Helzer > # Please include the string: [perl #128632] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=128632 > > > > Hello. > > On Rakudo version 2016.04 built on MoarVM version 2016.04 implementing Perl > 6.c on x64 Windows Server 2012 R2, running perl6 within cmd.exe and > entering the following > > my $in = get; > > results in an apparently frozen interpreter: Input is not echoed, nor does > entering any number of newlines do anything, nor Ctrl+d, nor Ctrl+z, nor > even Ctrl+c. > > I get similar unresponsive behavior with prompt, too. > > Neither issue occurs if I use Rakudo version 2016.06-281-gcd42657 built on > MoarVM version 2016.06-9-g8fc21d5 implementing Perl 6.c on x64 Ubuntu > 16.04. >