timotimo sounds like you did 00:00
[Coke] I did a realclean, removed all the .precomps, and rebuilt. still fails. 00:04
(also removed ./install)
00:06 BenGoldberg joined 00:11 sortiz joined
timotimo ugh 00:12
let me have a look-see
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)
[Coke] it fails about one every six times or so 00:17
TEST_JOBS=10 make test 00:18
2/3 failures..
2/6 failures... 00:19
timotimo runs for the third time now 00:21
oh, i don't set TEST_JOBS
without the TEST_JOBS i can run it a whole bunch of times without trouble 00:34
to be honest, i'm also having some trouble making it fail with TEST_JOBS=10 01:08
[Coke] still failing regularly here. what sort of diagnostics can I provide from the mac? 01:34
timotimo oof 01:35
that's a difficult question :|
01:38 dalek joined 03:01 Ben_Goldberg joined
[Tux] <drumroll>ā€¦</drumroll> 07:34
test 20.948
test-t 12.222
csv-parser 25.180
07:52 FROGGS joined 08:20 RabidGravy joined 09:29 stmuk_ joined 09:34 stmuk joined
lizmat 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 :-(
breakfast& 10:14
10:22 stmuk_ joined 10:29 stmuk joined 10:44 stmuk_ joined 10:49 stmuk joined 10:54 stmuk_ joined
dalek kudo/nom: 02babcb | lizmat++ | src/core/Version.pm:
Make some tests on JVM build pass
 11:32
11:50 stmuk joined 12:12 stmuk_ joined
dalek kudo/nom: a136eb7 | lizmat++ | src/core/Mu.pm:
Correct error message

Just for the record: it should really not get there, like ever.		 12:12
[Coke] lizmat: well, at least it's not just me. :) 12:18
lizmat yeah... I have no ideas wrt this issue :-( 12:19
12:22 stmuk joined
lizmat actually, I'm slightly more worried about RT #127748 12:23
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127748
lizmat I'm hoping it is a simple case of a problem that's been lurking causing instability for months 12:24
jnthn 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.
Moar should never SEGV unless you're monkey with nativecall the wrong way
*monkeying
lizmat agree, and that this happens to a newbie writing simple code, is not really encouraging :-(
lizmat gives up on trying to fix NativeCall issues on JVM for now 12:26
jnthn lizmat: We have the resources we have.
lizmat yeah, I know :-) 12:27
psch hm, what are the codes in BUILD_LEAST_DERIVED? is that written somewhere?
jnthn lizmat: We really need a lot more test coverage to catch such things...well, it'll come with time, I guess :)
psch: Probably in BUILDPLAN.nqp or so 12:28
psch jnthn: ah, yes, thanks
so the dying case is attr vivification during mixin 12:29
jnthn Yeah, that's when BUILD_LEAST_DERIVED happens
psch well, it is a Sub+{NativeCall::Native[Sub,Str] that dies vOv 12:33
...that's probably some kind of design-ish thing that'd take me ages to figure :) 12:35
well, letting getattr transparently work where currently only getattr_{s,i,n} work that is 12:36
13:32 AlexDaniel joined
[Coke] anyone have any ideas on rt.perl.org/Ticket/Display.html?id=127750 ? I'm happy to try to get some more diagnostics. 13:34
jnthn Valgrind? 13:36
timotimo jnthn: allegedly wonky on osx
but ASAN might be an idea
jnthn Aww
Valgrind catches a few more things though, afaik 13:37
[Coke] I can run it through valgrind. give me a moment.
does it have to also fail, or is any valgrind run sufficient? 13:38
also, lots of " no debug symbols in executable" - do we need a debuggable build?
jnthn [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
[Coke] right now seems frozen. assuming just valgrind slow. 13:47
jnthn yeah, it's very slow :)
timotimo yeah, valgrind slow most likely
people who are told valgrind is slow are still regularly surprised by valgrind being slow
[Coke] ugh, outlook is also chewing a cpu. love it. :|
jnthn bash.org/?400403 13:49
dalek ast: 6c47e2e | lizmat++ | S09-typed-arrays/native-str.t:
Add basic native str array tests
 13:50
13:51 colomon joined
dalek kudo/nom: 006d4b5 | lizmat++ | t/spectest.data:
Add testing of native str arrays
 13:56
14:02 skids joined
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:03
jnthn timotimo: I'd rather analyze it a bit further 14:05
timotimo: Got a backtrace?
timotimo gimme a second
at_key (tc=0x6037c0, st=<optimized out>, root=0x7ffff5195fb8, data=0x7ffff5195fd0,
key=0x31817a0, result=0x6b2ac0, kind=8) at src/6model/reprs/MVMContext.c:43
jnthn I don't like us sticking null checks everywhere in general, though...
timotimo 43 MVMLexicalRegistry *lexical_names = frame->static_info->body.lexical_names, *entry;
jnthn Hmm 14:06
timotimo it's at_key directly called from MVM_interp_run
jnthn Yeah, I want to look at that more closely
timotimo (gdb) print body[0]
$4 = {context = 0x0}
yeah
at <unknown>:1 (/home/timo/perl6/install/share/nqp/lib/Perl6/Metamodel.moarvm:vivify_for)
from gen/moar/m-CORE.setting:693 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:) 14:07
jnthn o.O
timotimo from gen/moar/m-CORE.setting:13793 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:)
from gen/moar/m-CORE.setting:13780 (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:first)
jnthn I'm also curious how that simple code ends up there.
Oh, through a nextsame or so it seems
timotimo ah, potentially 14:08
14:25 perlpilot joined 14:28 FROGGS joined
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:31
[Coke] gist.github.com/coke/bf23c484c765bb38c874 - here's the valgrind so far, in case that's at all interesting. 14:38
timotimo Ran bigpackids 10,000 times (sequential): 551.782789 14:43
Ran bigpackids 10,000 times (parallel): 653.1724352
i don't get callers shown at all :\ 14:45
neither callers nor callees 14:46
dalek kudo/nom: d075501 | moritz++ | .travis.yml:
Travis reporting to #p6dev
p: da4689a | moritz++ | .travis.yml:
Travis reporting to #p6dev
 14:47
kudo/nom: 54ce66e | lizmat++ | src/core/native_array.pm:
Make sure .join doesn't die on holes in str @a

Unassigned elements in a native str array, are null_s (as in nqp::isnull_s giving a true value). Trying to join them with nqp::join will skip these elements completely, which is inconsistent with other uses of join.
Rather than creating a shadow str array with "" filled in, it seemed like a better idea to bind the empty elements to the same empty string and then join that. Perhaps nqp::join should do something like this under the hood.		 15:13
jnthn lizmat: Hmm...sounds like we should fix nqp::join to save you that... 15:14
lizmat: But where do the nulls come from? :)
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ā¤ā¤Ā»
lizmat huh?
jnthn lizmat: nqp::atpos_s or @a[0] ? :)
lizmat m: use nqp; my str @a; @a[5] = "a"; say nqp::isnull_s(nqp::atposref_s(@a,0)) # duh
camelia rakudo-moar d07550: OUTPUTĀ«1ā¤Ā»
lizmat that's where the nulls come from :-) 15:16
jnthn ah :)
I suspect we should patch the join on to not do that though
lizmat so fix nqp::join that it does't skip isnull_s elements ? 15:17
and then undo my commit ?
well, that would have to be for 2016.04 then, as Moar is already tagged for this release, right > 15:18
??
jnthn lizmat: Right 15:19
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 %)
jnthn :D 15:21
[Coke] regrets killing the valgrindn and starting over. 15:23
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
[Coke] valgrind taking 0% of CPU, normal? 15:45
timotimo huh, absolute 0%? that doesn't seem right 15:58
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: rt.perl.org/Ticket/Display.html?id=127460
timotimo: yes, absolute 0. 16:00
timotimo: not sure if the partial valgrind output I posted gives any hints as to why
timotimo doesn't seem helpful, no :(
[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
^^ merlyn
17:04 Skarsnik joined
lizmat hmmm... getting internal server errors while pushing to github 17:13
17:15 FROGGS joined
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:15
dalek ast: b8f04ae | lizmat++ | S09-typed-arrays/native- (3 files):
Add native array .join tests
 17:22
lizmat seems github can be pushed to again
dalek p: 4d61b1f | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Make the default be to turn off continuations support.
 17:28
p: 15805af | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Adapt things so that more lexicals can be compiled as dynamic variables.
p: 1291513 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Move is_dynamic_var to BlockInfo.
p: e16b505 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Make declaration_static also create a closure.
18:10 ugexe joined 18:23 RabidGravy joined 18:45 RabidGravy joined
nine Does this output explain why a simple EVAL 'CompUnit::DependencySpecification.new(...)' creates a closure? gist.github.com/niner/7faf2af9f802f150aa0c 18:58
[Coke] ok, it's been 3.5 hours or so, still waiting... nothing past the initial valgrind dump I posted earlier. 19:06
Anything else I can do?
killed it. it was doing nothing, going nowhere. 19:19
timotimo urgh :( 20:04
lizmat is back 20:38
London has risen again :-)
[Coke]: wrt to the union error, I'm afraid we're not going to fix that right now :-( 20:39
20:45 geekosaur joined
stmuk hopes his flat didn't get destroyed by Hollywood 20:45
lizmat if you're living in the inner ring, good chance it got it :-) 20:46
[Coke] I'm not particularly comfortable cutting a release with that failure in it, but we can do so if there's consensus. 20:47
lizmat [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
and we have more of those, that we haven't considered blockers yet
m: my $a = { say $_ }; $a(42) # something else, this works 21:00
camelia rakudo-moar 54ce66: OUTPUTĀ«42ā¤Ā»
lizmat m: sub a { say $_ }; a 42 # this doesn't, is that intentional ?
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ā¤Ā»
lizmat or is that the optimizer being too picky ?
hmmm... guess not, even with --optimize=0, this fails 21:01
timotimo no, it's sub vs block syntax 21:08
psch which one, the first one?
timotimo i think it's intentional
lizmat ok, just checking :-)
psch oh
i got that wrong, i thought changing --optimize *changes* the result :)
jnthn lizmat: It's intentional; a block (but not a routine) without a signture defaults to something like -> $_ = OUTER::<$_> { ... } 21:10
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
technically, I mean 21:12
there is no issue, afaics
so there's a language design reason, I gather
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.
psch it's perl5's @_ all over again otherwise 21:13
well, except a single positional instead of a slurpy
lizmat ok, fair enough...
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:14
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:15
lizmat
.oO( may you find few interesting error messages )
 21:17
jnthn o.O 21:18
lizmat jnthn nine psch any opinion on the release blocker ? 21:19
timotimo IMO we can go ahead with the release, but it's not my call to make :) 21:20
21:20 lucasb joined
psch same here 21:22
i haven't looked at it, and i don't think i'm up for it now anymore
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... :)
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?
stmuk does it only affect mac? 21:26
lizmat stmuk: afaik, it happens on all platforms 21:27
nine: indeed, it could be from before the last release
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 22:07 synopsebot6 joined 22:22 synopsebot6 joined
lizmat p6weekly.wordpress.com/2016/03/21/...happening/ 22:23
22:28 synopsebot6 joined
lizmat good night, #p6dev! 22:37
TimToady lizmat++
23:22 Ben_Goldberg joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!