Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-03-21

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 timotimo 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 #p6dev
00:11 sortiz joined #p6dev
00:12 timotimo ugh
00:12 timotimo let me have a look-see
00:16 timotimo All tests successful.
00:16 timotimo 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 timotimo oh, i don't set TEST_JOBS
00:34 timotimo without the TEST_JOBS i can run it a whole bunch of times without trouble
01:08 timotimo 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 timotimo oof
01:35 timotimo that's a difficult question :|
01:38 dalek joined #p6dev
03:01 Ben_Goldberg joined #p6dev
07:34 [Tux] <drumroll>…</drumroll>
07:34 [Tux] test            20.948
07:34 [Tux] test-t          12.222
07:34 [Tux] csv-parser      25.180
07:52 FROGGS joined #p6dev
08:20 RabidGravy joined #p6dev
09:29 stmuk_ joined #p6dev
09:34 stmuk joined #p6dev
10:13 lizmat good *, #perl6!
10:13 lizmat 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 lizmat breakfast&
10:22 stmuk_ joined #p6dev
10:29 stmuk joined #p6dev
10:44 stmuk_ joined #p6dev
10:49 stmuk joined #p6dev
10:54 stmuk_ joined #p6dev
11:32 dalek rakudo/nom: 02babcb | lizmat++ | src/core/Version.pm:
11:32 dalek rakudo/nom: Make some tests on JVM build pass
11:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/02babcb59b
11:50 stmuk joined #p6dev
12:12 stmuk_ joined #p6dev
12:12 dalek rakudo/nom: a136eb7 | lizmat++ | src/core/Mu.pm:
12:12 dalek rakudo/nom: Correct error message
12:12 dalek rakudo/nom:
12:12 dalek rakudo/nom: Just for the record: it should really not get there, like ever.
12:12 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a136eb73b9
12:18 [Coke] lizmat: well, at least it's not just me. :)
12:19 lizmat yeah...  I have no ideas wrt this issue  :-(
12:22 stmuk joined #p6dev
12:23 lizmat actually, I'm slightly more worried about RT #127748
12:23 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127748
12:24 lizmat I'm hoping it is a simple case of a problem that's been lurking causing instability for months
12:25 jnthn lizmat: It's unlikely to be a regression, though, so not a release blocker.
12:25 jnthn But yeah, I'll look into it this week.
12:25 jnthn Moar should never SEGV unless you're monkey with nativecall the wrong way
12:25 jnthn *monkeying
12:25 lizmat 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 jnthn lizmat: We have the resources we have.
12:27 lizmat yeah, I know  :-)
12:27 psch hm, what are the codes in BUILD_LEAST_DERIVED?  is that written somewhere?
12:27 jnthn lizmat: We really need a lot more test coverage to catch such things...well, it'll come with time, I guess :)
12:28 jnthn psch: Probably in BUILDPLAN.nqp or so
12:28 psch jnthn: ah, yes, thanks
12:29 psch so the dying case is attr vivification during mixin
12:29 jnthn Yeah, that's when BUILD_LEAST_DERIVED happens
12:33 psch well, it is a Sub+{NativeCall::Native[Sub,Str] that dies vOv
12:35 psch ...that's probably some kind of design-ish thing that'd take me ages to figure :)
12:36 psch well, letting getattr transparently work where currently only getattr_{s,i,n} work that is
13:32 AlexDaniel joined #p6dev
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 jnthn Valgrind?
13:36 timotimo jnthn: allegedly wonky on osx
13:36 timotimo but ASAN might be an idea
13:36 jnthn Aww
13:37 jnthn 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 jnthn [Coke]: If valgrind finds any undefiend behavior then a debuggable build would help us understand it
13:42 jnthn [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 jnthn yeah, it's very slow :)
13:47 timotimo yeah, valgrind slow most likely
13:47 timotimo 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 jnthn http://bash.org/?400403
13:50 dalek roast: 6c47e2e | lizmat++ | S09-typed-arrays/native-str.t:
13:50 dalek roast: Add basic native str array tests
13:50 dalek roast: review: https://github.com/perl6/roast/commit/6c47e2e0ba
13:51 colomon joined #p6dev
13:56 dalek rakudo/nom: 006d4b5 | lizmat++ | t/spectest.data:
13:56 dalek rakudo/nom: Add testing of native str arrays
13:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/006d4b5d30
14:02 skids joined #p6dev
14:03 timotimo 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 jnthn timotimo: I'd rather analyze it a bit further
14:05 jnthn timotimo: Got a backtrace?
14:05 timotimo gimme a second
14:05 timotimo at_key (tc=0x6037c0, st=<optimized out>, root=0x7ffff5195fb8, data=0x7ffff5195fd0,
14:05 timotimo key=0x31817a0, result=0x6b2ac0, kind=8) at src/6model/reprs/MVMContext.c:43
14:05 jnthn I don't like us sticking null checks everywhere in general, though...
14:05 timotimo 43     MVMLexicalRegistry *lexical_names = frame->static_info->body.lexical_names, *entry;
14:06 jnthn Hmm
14:06 timotimo it's at_key directly called from MVM_interp_run
14:06 jnthn Yeah, I want to look at that more closely
14:06 timotimo (gdb) print body[0]
14:06 timotimo $4 = {context = 0x0}
14:06 timotimo yeah
14:06 timotimo at <unknown>:1  (/home/timo/perl6/install/share/nqp/lib/Perl6/Metamodel.moarvm:vivify_for)
14:07 timotimo from gen/moar/m-CORE.setting:693  (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:)
14:07 jnthn o.O
14:07 timotimo from gen/moar/m-CORE.setting:13793  (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:)
14:07 timotimo from gen/moar/m-CORE.setting:13780  (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:first)
14:07 jnthn I'm also curious how that simple code ends up there.
14:07 jnthn Oh, through a nextsame or so it seems
14:08 timotimo ah, potentially
14:25 perlpilot joined #p6dev
14:28 FROGGS joined #p6dev
14:31 timotimo 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 timotimo Ran bigpackids 10,000 times (sequential): 551.782789
14:43 timotimo Ran bigpackids 10,000 times (parallel): 653.1724352
14:45 timotimo i don't get callers shown at all :\
14:46 timotimo neither callers nor callees
14:46 dalek rakudo/nom: d075501 | moritz++ | .travis.yml:
14:46 dalek rakudo/nom: Travis reporting to #p6dev
14:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d075501039
14:47 dalek nqp: da4689a | moritz++ | .travis.yml:
14:47 dalek nqp: Travis reporting to #p6dev
14:47 dalek nqp: review: https://github.com/perl6/nqp/commit/da4689adab
15:13 dalek rakudo/nom: 54ce66e | lizmat++ | src/core/native_array.pm:
15:13 dalek rakudo/nom: Make sure .join doesn't die on holes in str @a
15:13 dalek rakudo/nom:
15:13 dalek rakudo/nom: Unassigned elements in a native str array, are null_s (as in nqp::isnull_s
15:13 dalek rakudo/nom: giving a true value).  Trying to join them with nqp::join will skip these
15:13 dalek rakudo/nom: elements completely, which is inconsistent with other uses of join.
15:13 dalek rakudo/nom:
15:13 dalek rakudo/nom: Rather than creating a shadow str array with "" filled in, it seemed
15:13 dalek rakudo/nom: like a better idea to bind the empty elements to the same empty string
15:13 dalek rakudo/nom: and then join that.  Perhaps nqp::join should do something like this
15:13 dalek rakudo/nom: under the hood.
15:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/54ce66eeb0
15:14 jnthn lizmat: Hmm...sounds like we should fix nqp::join to save you that...
15:14 jnthn lizmat: But where do the nulls come from? :)
15:15 lizmat m: use nqp; my str @a; @a[5] = "a"; say nqp::isnull_s(@a,0)
15:15 camelia rakudo-moar d07550: OUTPUT«This representation (VMArray) cannot unbox to a native int␤  in block <unit> at /tmp/3AXVM1LR0s line 1␤␤»
15:15 lizmat huh?
15:15 jnthn lizmat: nqp::atpos_s or @a[0] ? :)
15:15 lizmat m: use nqp; my str @a; @a[5] = "a"; say nqp::isnull_s(nqp::atposref_s(@a,0))  # duh
15:15 camelia rakudo-moar d07550: OUTPUT«1␤»
15:16 lizmat that's where the nulls come from  :-)
15:16 jnthn ah :)
15:16 jnthn I suspect we should patch the join on to not do that though
15:17 lizmat so fix nqp::join that it does't skip isnull_s elements ?
15:17 lizmat and then undo my commit ?
15:18 lizmat well, that would have to be for 2016.04 then, as Moar is already tagged for this release, right >
15:18 lizmat ??
15:19 jnthn lizmat: Right
15:20 jnthn lizmat: Not urgent, just we'd win a speedup without the extra pass
15:20 timotimo 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 jnthn :D
15:23 * [Coke] regrets killing the valgrindn and starting over.
15:34 lizmat m: use nqp; my int @a = ^5; nqp::setelems(@a,0); @a[4] = 22; say @a.join(":")   # continued from #perl6
15:34 camelia rakudo-moar 54ce66: OUTPUT«0:1:2:3:22␤»
15:37 [Tux] joined #p6dev
15:45 [Coke] valgrind taking 0% of CPU, normal?
15:58 timotimo huh, absolute 0%? that doesn't seem right
15:59 timotimo 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 timotimo 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 #p6dev
17:13 lizmat hmmm... getting internal server errors while pushing to github
17:15 FROGGS joined #p6dev
17:15 perlpilot 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 dalek roast: b8f04ae | lizmat++ | S09-typed-arrays/native- (3 files):
17:22 dalek roast: Add native array .join tests
17:22 dalek roast: review: https://github.com/perl6/roast/commit/b8f04aef9e
17:22 lizmat seems github can be pushed to again
17:28 dalek nqp: 4d61b1f | (Pawel Murias)++ | src/vm/js/ (2 files):
17:28 dalek nqp: [js] Make the default be to turn off continuations support.
17:28 dalek nqp: review: https://github.com/perl6/nqp/commit/4d61b1ffe8
17:28 dalek nqp: 15805af | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
17:28 dalek nqp: [js] Adapt things so that more lexicals can be compiled as dynamic variables.
17:28 dalek nqp: review: https://github.com/perl6/nqp/commit/15805af0ce
17:28 dalek nqp: 1291513 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
17:28 dalek nqp: [js] Move is_dynamic_var to BlockInfo.
17:28 dalek nqp: review: https://github.com/perl6/nqp/commit/129151335d
17:28 dalek nqp: e16b505 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
17:28 dalek nqp: [js] Make declaration_static also create a closure.
17:28 dalek nqp: review: https://github.com/perl6/nqp/commit/e16b50544a
18:10 ugexe joined #p6dev
18:23 RabidGravy joined #p6dev
18:45 RabidGravy joined #p6dev
18:58 nine 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 timotimo urgh :(
20:38 * lizmat is back
20:38 lizmat London has risen again  :-)
20:39 lizmat [Coke]: wrt to the union error, I'm afraid we're not going to fix that right now :-(
20:45 geekosaur joined #p6dev
20:45 * stmuk hopes his flat didn't get destroyed by Hollywood
20:46 lizmat 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 lizmat [Coke]: fwiw, I can't get it to fail when run by itself, or with TEST_JOBS=
20:53 lizmat so it's somehow dependent on load
20:53 lizmat and we have more of those, that we haven't considered blockers yet
21:00 lizmat m: my $a = { say $_ }; $a(42)   # something else, this works
21:00 camelia rakudo-moar 54ce66: OUTPUT«42␤»
21:00 lizmat m: sub a { say $_ }; a 42   # this doesn't, is that intentional ?
21:00 camelia 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 lizmat or is that the optimizer being too picky ?
21:01 lizmat hmmm... guess not, even with --optimize=0, this fails
21:08 timotimo no, it's sub vs block syntax
21:08 psch which one, the first one?
21:08 timotimo i think it's intentional
21:08 lizmat ok, just checking  :-)
21:08 psch oh
21:08 psch i got that wrong, i thought changing --optimize *changes* the result :)
21:10 jnthn lizmat: It's intentional; a block (but not a routine) without a signture defaults to something like -> $_ = OUTER::<$_> { ... }
21:11 jnthn lizmat: 'cus otherwise you couldn't write for @list { .say }
21:11 lizmat yeah, I get that, I just don't understand why that doesn't work for subs
21:12 lizmat technically, I mean
21:12 lizmat there is no issue, afaics
21:12 lizmat so there's a language design reason, I gather
21:12 jnthn 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 psch it's perl5's @_ all over again otherwise
21:13 psch well, except a single positional instead of a slurpy
21:13 lizmat ok, fair enough...
21:14 jnthn 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 nine 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 lizmat .oO( may you find few interesting error messages )
21:18 jnthn o.O
21:19 lizmat jnthn nine psch any opinion on the release blocker ?
21:20 timotimo IMO we can go ahead with the release, but it's not my call to make :)
21:20 lucasb joined #p6dev
21:22 psch same here
21:22 psch i haven't looked at it, and i don't think i'm up for it now anymore
21:23 lucasb just ship it with a notice in the announcement about a known issue that will be fixed in a future release :)
21:23 psch well, it's also somewhat mvm guts-y, so it's not really that much in my reach anyway... :)
21:25 perlpilot What's the blocker?  Is it that cunion test?
21:25 nine AFAIK we don't even know if it's new, do we?
21:26 stmuk does it only affect mac?
21:27 lizmat stmuk: afaik, it happens on all platforms
21:27 lizmat nine: indeed, it could be from before the last release
21:38 nine 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 jnthn 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 #p6dev
22:07 synopsebot6 joined #p6dev
22:22 synopsebot6 joined #p6dev
22:22 synopsebot6 joined #p6dev
22:23 lizmat https://p6weekly.wordpress.com/2016/03/21/2016-12-less-happening/
22:28 synopsebot6 joined #p6dev
22:37 lizmat good night, #p6dev!
22:37 TimToady lizmat++
23:22 Ben_Goldberg joined #p6dev

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary