[00:00] sounds like you did [00:04] <[Coke]> I did a realclean, removed all the .precomps, and rebuilt. still fails. [00:04] <[Coke]> (also removed ./install) [00:06] *** BenGoldberg joined [00:11] *** sortiz joined [00:12] ugh [00:12] let me have a look-see [00:16] All tests successful. [00:16] Files=45, Tests=595, 44 wallclock secs ( 0.14 usr 0.04 sys + 42.16 cusr 2.21 csys = 44.55 CPU) [00:17] <[Coke]> it fails about one every six times or so [00:18] <[Coke]> TEST_JOBS=10 make test [00:18] <[Coke]> 2/3 failures.. [00:19] <[Coke]> 2/6 failures... [00:21] * timotimo runs for the third time now [00:21] oh, i don't set TEST_JOBS [00:34] without the TEST_JOBS i can run it a whole bunch of times without trouble [01:08] to be honest, i'm also having some trouble making it fail with TEST_JOBS=10 [01:34] <[Coke]> still failing regularly here. what sort of diagnostics can I provide from the mac? [01:35] oof [01:35] that's a difficult question :| [01:38] *** dalek joined [03:01] *** Ben_Goldberg joined [07:34] <[Tux]> [07:34] <[Tux]> test 20.948 [07:34] <[Tux]> test-t 12.222 [07:34] <[Tux]> csv-parser 25.180 [07:52] *** FROGGS joined [08:20] *** RabidGravy joined [09:29] *** stmuk_ joined [09:34] *** stmuk joined [10:13] good *, #perl6! [10:13] whereas I couldn't get the 13-union.t test to fail last night, the first time I tried it this morning, it failed :-( [10:14] breakfast& [10:22] *** stmuk_ joined [10:29] *** stmuk joined [10:44] *** stmuk_ joined [10:49] *** stmuk joined [10:54] *** stmuk_ joined [11:32] rakudo/nom: 02babcb | lizmat++ | src/core/Version.pm: [11:32] rakudo/nom: Make some tests on JVM build pass [11:32] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/02babcb59b [11:50] *** stmuk joined [12:12] *** stmuk_ joined [12:12] rakudo/nom: a136eb7 | lizmat++ | src/core/Mu.pm: [12:12] rakudo/nom: Correct error message [12:12] rakudo/nom: [12:12] rakudo/nom: Just for the record: it should really not get there, like ever. [12:12] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a136eb73b9 [12:18] <[Coke]> lizmat: well, at least it's not just me. :) [12:19] yeah... I have no ideas wrt this issue :-( [12:22] *** stmuk joined [12:23] actually, I'm slightly more worried about RT #127748 [12:23] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=127748 [12:24] I'm hoping it is a simple case of a problem that's been lurking causing instability for months [12:25] lizmat: It's unlikely to be a regression, though, so not a release blocker. [12:25] But yeah, I'll look into it this week. [12:25] Moar should never SEGV unless you're monkey with nativecall the wrong way [12:25] *monkeying [12:25] agree, and that this happens to a newbie writing simple code, is not really encouraging :-( [12:26] * lizmat gives up on trying to fix NativeCall issues on JVM for now [12:26] lizmat: We have the resources we have. [12:27] yeah, I know :-) [12:27] hm, what are the codes in BUILD_LEAST_DERIVED? is that written somewhere? [12:27] lizmat: We really need a lot more test coverage to catch such things...well, it'll come with time, I guess :) [12:28] psch: Probably in BUILDPLAN.nqp or so [12:28] jnthn: ah, yes, thanks [12:29] so the dying case is attr vivification during mixin [12:29] Yeah, that's when BUILD_LEAST_DERIVED happens [12:33] well, it is a Sub+{NativeCall::Native[Sub,Str] that dies vOv [12:35] ...that's probably some kind of design-ish thing that'd take me ages to figure :) [12:36] well, letting getattr transparently work where currently only getattr_{s,i,n} work that is [13:32] *** AlexDaniel joined [13:34] <[Coke]> anyone have any ideas on https://rt.perl.org/Ticket/Display.html?id=127750 ? I'm happy to try to get some more diagnostics. [13:36] Valgrind? [13:36] jnthn: allegedly wonky on osx [13:36] but ASAN might be an idea [13:36] Aww [13:37] Valgrind catches a few more things though, afaik [13:37] <[Coke]> I can run it through valgrind. give me a moment. [13:38] <[Coke]> does it have to also fail, or is any valgrind run sufficient? [13:38] <[Coke]> also, lots of " no debug symbols in executable" - do we need a debuggable build? [13:42] [Coke]: If valgrind finds any undefiend behavior then a debuggable build would help us understand it [13:42] [Coke]: But it shouldn't affect whether it finds it or not [13:47] <[Coke]> right now seems frozen. assuming just valgrind slow. [13:47] yeah, it's very slow :) [13:47] yeah, valgrind slow most likely [13:47] people who are told valgrind is slow are still regularly surprised by valgrind being slow [13:47] <[Coke]> ugh, outlook is also chewing a cpu. love it. :| [13:49] http://bash.org/?400403 [13:50] roast: 6c47e2e | lizmat++ | S09-typed-arrays/native-str.t: [13:50] roast: Add basic native str array tests [13:50] roast: review: https://github.com/perl6/roast/commit/6c47e2e0ba [13:51] *** colomon joined [13:56] rakudo/nom: 006d4b5 | lizmat++ | t/spectest.data: [13:56] rakudo/nom: Add testing of native str arrays [13:56] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/006d4b5d30 [14:02] *** skids joined [14:03] jnthn: should i go ahead and put a null-pointer-check where that script liz showed is segfaulting, and turn the problem into a panic instead? [14:05] timotimo: I'd rather analyze it a bit further [14:05] timotimo: Got a backtrace? [14:05] gimme a second [14:05] at_key (tc=0x6037c0, st=, root=0x7ffff5195fb8, data=0x7ffff5195fd0, [14:05] key=0x31817a0, result=0x6b2ac0, kind=8) at src/6model/reprs/MVMContext.c:43 [14:05] I don't like us sticking null checks everywhere in general, though... [14:05] 43 MVMLexicalRegistry *lexical_names = frame->static_info->body.lexical_names, *entry; [14:06] Hmm [14:06] it's at_key directly called from MVM_interp_run [14:06] Yeah, I want to look at that more closely [14:06] (gdb) print body[0] [14:06] $4 = {context = 0x0} [14:06] yeah [14:06] at :1 (/home/timo/perl6/install/share/nqp/lib/Perl6/Metamodel.moarvm:vivify_for) [14:07] from gen/moar/m-CORE.setting:693 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:) [14:07] o.O [14:07] from gen/moar/m-CORE.setting:13793 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:) [14:07] from gen/moar/m-CORE.setting:13780 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:first) [14:07] I'm also curious how that simple code ends up there. [14:07] Oh, through a nextsame or so it seems [14:08] ah, potentially [14:25] *** perlpilot joined [14:28] *** FROGGS joined [14:31] can we decrease the pressure on frame inc/dec ref with regards to locking if we know our stack already has a reference on a given frame? [14:38] <[Coke]> https://gist.github.com/coke/bf23c484c765bb38c874 - here's the valgrind so far, in case that's at all interesting. [14:43] Ran bigpackids 10,000 times (sequential): 551.782789 [14:43] Ran bigpackids 10,000 times (parallel): 653.1724352 [14:45] i don't get callers shown at all :\ [14:46] neither callers nor callees [14:46] rakudo/nom: d075501 | moritz++ | .travis.yml: [14:46] rakudo/nom: Travis reporting to #p6dev [14:46] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d075501039 [14:47] nqp: da4689a | moritz++ | .travis.yml: [14:47] nqp: Travis reporting to #p6dev [14:47] nqp: review: https://github.com/perl6/nqp/commit/da4689adab [15:13] rakudo/nom: 54ce66e | lizmat++ | src/core/native_array.pm: [15:13] rakudo/nom: Make sure .join doesn't die on holes in str @a [15:13] rakudo/nom: [15:13] rakudo/nom: Unassigned elements in a native str array, are null_s (as in nqp::isnull_s [15:13] rakudo/nom: giving a true value). Trying to join them with nqp::join will skip these [15:13] rakudo/nom: elements completely, which is inconsistent with other uses of join. [15:13] rakudo/nom: [15:13] rakudo/nom: Rather than creating a shadow str array with "" filled in, it seemed [15:13] rakudo/nom: like a better idea to bind the empty elements to the same empty string [15:13] rakudo/nom: and then join that. Perhaps nqp::join should do something like this [15:13] rakudo/nom: under the hood. [15:13] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/54ce66eeb0 [15:14] lizmat: Hmm...sounds like we should fix nqp::join to save you that... [15:14] lizmat: But where do the nulls come from? :) [15:15] m: use nqp; my str @a; @a[5] = "a"; say nqp::isnull_s(@a,0) [15:15] rakudo-moar d07550: OUTPUT«This representation (VMArray) cannot unbox to a native int␤ in block at /tmp/3AXVM1LR0s line 1␤␤» [15:15] huh? [15:15] lizmat: nqp::atpos_s or @a[0] ? :) [15:15] m: use nqp; my str @a; @a[5] = "a"; say nqp::isnull_s(nqp::atposref_s(@a,0)) # duh [15:15] rakudo-moar d07550: OUTPUT«1␤» [15:16] that's where the nulls come from :-) [15:16] ah :) [15:16] I suspect we should patch the join on to not do that though [15:17] so fix nqp::join that it does't skip isnull_s elements ? [15:17] and then undo my commit ? [15:18] well, that would have to be for 2016.04 then, as Moar is already tagged for this release, right > [15:18] ?? [15:19] lizmat: Right [15:20] lizmat: Not urgent, just we'd win a speedup without the extra pass [15:20] i always find it a bit amusing that the perlweekly comes out multiple hours before the perl6 weekly, and so 7 days after a post, everybody on the internet starts talking about it %) [15:21] :D [15:23] * [Coke] regrets killing the valgrindn and starting over. [15:34] m: use nqp; my int @a = ^5; nqp::setelems(@a,0); @a[4] = 22; say @a.join(":") # continued from #perl6 [15:34] rakudo-moar 54ce66: OUTPUT«0:1:2:3:22␤» [15:37] *** [Tux] joined [15:45] <[Coke]> valgrind taking 0% of CPU, normal? [15:58] huh, absolute 0%? that doesn't seem right [15:59] in the assembly language talk recording from brrt, the microphone is picking up swallowing noises very clearly %) [15:59] <[Coke]> we have another cunion ticket already open, btw: https://rt.perl.org/Ticket/Display.html?id=127460 [16:00] <[Coke]> timotimo: yes, absolute 0. [16:00] <[Coke]> timotimo: not sure if the partial valgrind output I posted gives any hints as to why [16:00] doesn't seem helpful, no :( [16:26] <[Coke]> seen on facebook: "I've got a couple of near-immediate FLOSS Weekly spots to fill. If anyone has a Perl-ish thing they could talk about for 30-45 minutes, please let me know very soon. [16:26] <[Coke]> ^^ merlyn [17:04] *** Skarsnik joined [17:13] hmmm... getting internal server errors while pushing to github [17:15] *** FROGGS joined [17:15] The last several FLOSS Weekly look like merlyn has interviewed teams of people. It would be neat to see N > 2 Perl 6 devs on there to talk about something [17:22] roast: b8f04ae | lizmat++ | S09-typed-arrays/native- (3 files): [17:22] roast: Add native array .join tests [17:22] roast: review: https://github.com/perl6/roast/commit/b8f04aef9e [17:22] seems github can be pushed to again [17:28] nqp: 4d61b1f | (Pawel Murias)++ | src/vm/js/ (2 files): [17:28] nqp: [js] Make the default be to turn off continuations support. [17:28] nqp: review: https://github.com/perl6/nqp/commit/4d61b1ffe8 [17:28] nqp: 15805af | (Pawel Murias)++ | src/vm/js/Compiler.nqp: [17:28] nqp: [js] Adapt things so that more lexicals can be compiled as dynamic variables. [17:28] nqp: review: https://github.com/perl6/nqp/commit/15805af0ce [17:28] nqp: 1291513 | (Pawel Murias)++ | src/vm/js/Compiler.nqp: [17:28] nqp: [js] Move is_dynamic_var to BlockInfo. [17:28] nqp: review: https://github.com/perl6/nqp/commit/129151335d [17:28] nqp: e16b505 | (Pawel Murias)++ | src/vm/js/Compiler.nqp: [17:28] nqp: [js] Make declaration_static also create a closure. [17:28] nqp: review: https://github.com/perl6/nqp/commit/e16b50544a [18:10] *** ugexe joined [18:23] *** RabidGravy joined [18:45] *** RabidGravy joined [18:58] Does this output explain why a simple EVAL 'CompUnit::DependencySpecification.new(...)' creates a closure? https://gist.github.com/niner/7faf2af9f802f150aa0c [19:06] <[Coke]> ok, it's been 3.5 hours or so, still waiting... nothing past the initial valgrind dump I posted earlier. [19:06] <[Coke]> Anything else I can do? [19:19] <[Coke]> killed it. it was doing nothing, going nowhere. [20:04] urgh :( [20:38] * lizmat is back [20:38] London has risen again :-) [20:39] [Coke]: wrt to the union error, I'm afraid we're not going to fix that right now :-( [20:45] *** geekosaur joined [20:45] * stmuk hopes his flat didn't get destroyed by Hollywood [20:46] if you're living in the inner ring, good chance it got it :-) [20:47] <[Coke]> I'm not particularly comfortable cutting a release with that failure in it, but we can do so if there's consensus. [20:53] [Coke]: fwiw, I can't get it to fail when run by itself, or with TEST_JOBS= [20:53] so it's somehow dependent on load [20:53] and we have more of those, that we haven't considered blockers yet [21:00] m: my $a = { say $_ }; $a(42) # something else, this works [21:00] rakudo-moar 54ce66: OUTPUT«42␤» [21:00] m: sub a { say $_ }; a 42 # this doesn't, is that intentional ? [21:00] rakudo-moar 54ce66: OUTPUT«===SORRY!=== Error while compiling /tmp/QD5i2vm7Mz␤Calling a(Int) will never work with declared signature ()␤at /tmp/QD5i2vm7Mz:1␤------> sub a { say $_ }; ⏏a 42 # this doesn't, is that intention␤» [21:00] or is that the optimizer being too picky ? [21:01] hmmm... guess not, even with --optimize=0, this fails [21:08] no, it's sub vs block syntax [21:08] which one, the first one? [21:08] i think it's intentional [21:08] ok, just checking :-) [21:08] oh [21:08] i got that wrong, i thought changing --optimize *changes* the result :) [21:10] lizmat: It's intentional; a block (but not a routine) without a signture defaults to something like -> $_ = OUTER::<$_> { ... } [21:11] lizmat: 'cus otherwise you couldn't write for @list { .say } [21:11] yeah, I get that, I just don't understand why that doesn't work for subs [21:12] technically, I mean [21:12] there is no issue, afaics [21:12] so there's a language design reason, I gather [21:12] Just a lang design call. We decided that it's more useful for a routine with no signature to default to wanting zero args, and a method to only wanting the invocant. [21:13] it's perl5's @_ all over again otherwise [21:13] well, except a single positional instead of a slurpy [21:13] ok, fair enough... [21:14] Yeah. I guess routines tend to make up your API, so you want to be a bit stricter, while blocks tend to be inside your code and so the slop isn't harmful. [21:15] My error messages become more and more interesting: QAST -> MAST failed while compiling op callmethod: Code ref '' does not exist in serialization context [21:17] .oO( may you find few interesting error messages ) [21:18] o.O [21:19] jnthn nine psch any opinion on the release blocker ? [21:20] IMO we can go ahead with the release, but it's not my call to make :) [21:20] *** lucasb joined [21:22] same here [21:22] i haven't looked at it, and i don't think i'm up for it now anymore [21:23] just ship it with a notice in the announcement about a known issue that will be fixed in a future release :) [21:23] well, it's also somewhat mvm guts-y, so it's not really that much in my reach anyway... :) [21:25] What's the blocker? Is it that cunion test? [21:25] AFAIK we don't even know if it's new, do we? [21:26] does it only affect mac? [21:27] stmuk: afaik, it happens on all platforms [21:27] nine: indeed, it could be from before the last release [21:38] Given that it's hard to reproduce, I could imagine it being there for a long time already, so I guess the chances of us having released a version with the bug already are rather high. [21:38] I'm not inclined to block on it, if we're not even really sure it's a regression. We do have various heisenbugs that we'd really rather fix, but don't block releases on. [22:06] *** synopsebot6 joined [22:07] *** synopsebot6 joined [22:22] *** synopsebot6 joined [22:23] https://p6weekly.wordpress.com/2016/03/21/2016-12-less-happening/ [22:28] *** synopsebot6 joined [22:37] good night, #p6dev! [22:37] lizmat++ [23:22] *** Ben_Goldberg joined