[00:00] gnight [00:00] I am going to bed [00:12] Same... 'night [00:45] * timotimo is partying [00:46] i was hoping i could perhaps re-use the party to be a rakudo-on-moarvm-does-hello-world-party, but alas ... :( [01:34] *** BenGoldberg joined [01:41] *** colomon joined [01:43] *** BenGoldberg joined [02:03] Missing serialize REPR function for REPR MVMStaticFrame - should i be seeing this right now? [02:24] *** ssutch joined [03:55] *** ggoebel110 joined [04:10] *** rurban joined [04:44] *** ssutch joined [08:10] *** ssutch joined [08:15] *** FROGGS joined [08:40] currently SEGVs when compiling lib/Test.pm [08:40] 1200 const MVMContainerSpec *spec = STABLE(cont)->container_spec; [08:40] cont is 0x0 [08:40] I assume that this is known [10:57] *** dalek joined [11:55] *** woolfy joined [12:53] *** woolfy left [13:36] *** ggoebel110 joined [13:57] *** colomon joined [14:15] *** tgt joined [14:20] *** colomon joined [14:49] MoarVM: 4cc8691 | (Tobias Leich)++ | / (2 files): [14:49] MoarVM: add support for --optimize=1 --debug=3 [14:49] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4cc86910a4 [14:49] timotimo: might be interesting for you [14:50] I'll use --optimize=1 --debug=3 now to be able to build in a reasonable time again... [14:50] oh, neat :) [14:50] jnthn: I have no luck to hunt that bug down [14:50] what are the numbers for? [14:51] I know that 0 == nothing and 3 == most [14:51] but I don't know what the numbers mean [14:51] OK [14:51] I think gcc has -Od these days, as in ""ptimize to make debugging easier [14:51] or maybe it's named differently [14:51] i think it's -Og [14:51] just like -g [14:51] oh, yes [14:51] --debug adds the -g [14:52] * tadzik resists the urge to rant about screen and tmux's default keybindings [14:52] and according to arnsholt++ -g3 even let you use macros in gdb [14:52] :o [14:52] oh wow [14:53] dang, my optimizations are causing fallout when parsing regexes ... how am i even doing that? [14:54] :/ [14:57] oh, huh [14:57] is > supposed to generate a scan instruction inside it? [14:57] ohh, I have to fix -O in rakudo now :/ [14:58] what's that? [15:00] ahh no, a make clean is need in MoarVM [15:00] the optimize flag [15:01] timotimo: It could never actually scan, I guess... [15:01] I think I make the generated config.c depend on the Makefile [15:01] it couldn't? [15:01] timotimo: It's just that we always put the scan int. [15:02] i think i'm confused about something [15:02] timotimo: Well, the thunk passed to must always be anchored so can never scan. [15:02] ah, i didn't know that [15:02] good. [15:02] But it's mostly a "emit code we don't need" thing... [15:03] i'm trying to figure out which of my changes is causing errors like "unrecognized metacharacter +, must be quoted to match literally" [15:03] fortunately the p6regex grammar itself isn't super-huge [15:03] i may be able to see it in the QAST. [15:05] MoarVM: 10cf894 | (Tobias Leich)++ | build/Makefile.in: [15:05] MoarVM: rebuild from source files when Makefile changed [15:05] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/10cf89453d [15:25] [A [15:26] get up [15:26] (get on up) [15:26] get up [15:26] tadzik: I've been using ^J, ^O and ^_ [15:26] (get on up) [15:26] I think if I wanted another level of tmux, I'd try ^^ [15:26] (not tried it on tmux. Worked on screen) [15:26] I don't use those control keys much for other stuff [15:26] but yes, ^a and ^b are less than awesome [15:26] I had C-z on screen [15:31] *** FROGGS[mobile] joined [15:40] nwc10: I get the same error as you btw, cont is NULL in [15:40] at src/core/interp.c:1200 [15:40] 1200 const MVMContainerSpec *spec = STABLE(cont)->container_spec; [15:42] gcc -c -fPIC -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC -O%d ... [15:42] oops, borked. [15:42] hehe [15:46] Yes, I'm working on that at the moment :) [15:49] nwc10: reconfigure moarvm [15:50] IIRC I did [15:50] (and reinstall and reconfigure rakudo) [15:51] ohh, bug found [15:51] if you dont pass --optimize... [15:52] :-) [15:53] that would explain a lot [15:56] MoarVM: 5b77ecf | (Tobias Leich)++ | Configure.pl: [15:56] MoarVM: fix optiflags when --optimize is not passed [15:56] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5b77ecf80d [16:09] *** ggoebel110 joined [16:36] * jnthn finally gets NQP tests clean again after the auto-viv stuff [16:37] Well, container viv really... [16:39] *** cxreg2 joined [16:39] FROGGS: works on my machine *but*, if I don't pass --optimize or anything, what compiler flags is moarvm supposed to be using now? [16:41] nwc10: nothing [16:41] no -Osomething and no -gsomething [16:41] at least it was like that before [16:42] nope, pretty sure that before it was defaulting to -g [16:43] because I've not changed how I'm configuring moarvm [16:43] and I don't have debugging symbols now [16:44] debug used to default to "not optimise" [16:44] # fiddle with flags [16:44] -$args{debug} //= 0 + !$args{optimize}; [16:44] -$args{optimize} //= 0 + !$args{debug}; [16:52] ahh, I see [16:53] dunno what to do about that though [16:53] I think for most everything else I've ever met, the default is "optimise" [16:53] the assmuption is that if you're building with defaults, you're not a developer of it [16:55] that default bit me in the butt real hard recently [16:57] .oO( bad ass-umption, eh? ) [16:58] +1 from my side [17:00] yup [17:01] if your default is the one that makes more sense to your own developers than to end users, you're implicitly saying that you're not ready for prime time [17:02] fwiw, the end users would be using --gen-nqp anyway, which does pass --optimize to the parrot generating step and the same goes for moarvm. [17:02] not necessarily. I suspect that OS packagers (and equivalent, such as *ports) will build each of the 3 in turn [17:03] but we're not there yet :-/ [17:03] mhm [17:05] MoarVM: d1500d7 | jnthn++ | src/6model/reprs/P6opaque.c: [17:05] MoarVM: Implement attribute container auto-viv in P6opaque [17:05] MoarVM: [17:05] MoarVM: We need to be able to differentiate an assigned null from unvivified. [17:05] MoarVM: We'll get this for free in the future when we improve null handling; [17:05] MoarVM: for now, this will do us. [17:05] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d1500d7061 [17:05] nwc10: When we haven't actually reached the point where we run Rakudo yet, I think claiming to be ready for prime time would be a bit premature... :) [17:05] I'm still in Stage mast from last time! :-) [17:06] jnthn: me too on that metric. But I'm still thinking that by that point, the default should be optimize, so avoiding redoing work would imply to default to that currently [17:06] or at least, on non-gcc, default to optmise [17:06] nwc10: Yes, by then... [17:06] and on gcc and gcc-wannabes, try for -g and -O [17:08] For gcc-like I'd even argue for -g3 [17:09] some debuggers choke on it, but I think that that's "buyer beware" [17:09] Oh, in that case maybe not [17:09] I don't think that any distro is daft enough to ship a gcc which is too new for its gdb [17:10] I was really happy when I discovered -g3 at the YAPC::NA hackathon this year. Makes debugging macro-heavy code so much less of a chore =) [17:11] i can't build nqp at the moment, at least in my branch [17:11] This type does not support elems [17:11] is that my branch's fault? [17:12] timotimo: On Moar? You need the stuff from master. [17:12] OK. [17:12] ah yes, i see. [17:15] We're up to line 6568 of the setting loading. [17:15] \o/ [17:15] what's stopping us now? [17:15] Another "This type does not support elems" :) [17:16] 6.5k, that's about a third of the setting, no? [17:17] arnsholt: Yeah, though this is all the pieces that run at startup [17:17] arnsholt: So it's really about where we hit those. [17:17] Right, right [17:17] We're mostly hitting missing bits of the binder and list guts so far. [17:17] So, just NYIs. [17:20] Right, that sounds reasonable [18:03] Ah...the current blocker seems to have been a thinko in p6shiftpush [18:04] pfusch, as I said :o) [18:12] OK, 11,970 now. [18:12] !!! [18:12] \o/ [18:12] jnthn++ [18:12] Nice! [18:12] that's ossum! :) [18:13] Capture binding NYI [18:13] bah :) [18:13] :D [18:31] Done that and now 13,499 [18:32] $PROCESS::IN = open('-'); [18:32] O.o [18:32] how does that explode? [18:32] I'll know in about 7 or 8 minutes [18:33] Trying to get to the bottom of that right now. [18:33] Deep, anyway [18:33] k [18:33] Somewhere in IO::Handle.new [18:34] And within there, in BUILDALL [18:37] Something to do with attribute defaults, I think. [18:37] the Bool::True? [18:38] /home/froggs/dev/rakudo/src/core/IO.pm:92: has $.chomp = Bool::True; [18:38] Or the 0...not sure. [18:39] It's somehow landing in the default invocation fallback [18:44] Got a guess...trying a patch. [18:45] I get: [18:45] Unhandled exception: Cannot find method 'Nil' [18:45] at src/gen/m-BOOTSTRAP.nqp:2222 (blib/Perl6/BOOTSTRAP.moarvm:frame_name_735:18) [18:47] Yeah, that's a failing fail [18:47] Do a perl6-m -e "say 'hi'" [18:47] uh [18:47] Do a perl6-m --ll-exception -e "say 'hi'" [18:48] Cannot find method 'postcircumfix:<( )>' [18:48] I see [18:54] Yeah, got a fix for that now [18:54] Onto the next thing... :) [18:55] Still in open, but at least we get a bit further now... [18:55] default cont desc NYI [18:57] ahh, yeah [19:13] "Internal error: invalid thread ID in GC work pass" [19:13] :( [19:14] oh, duh [19:14] I didn't root [19:14] might that be the bug I've seen? [19:17] It *may* be, but the code I just wrote has a bug that could cause it too... [19:17] mhm [19:20] I'm betting if I get us past this IO stuff, we next block in temporal... [19:22] Um, we hang... [19:22] I hope we don't block for long there :o) [19:22] uhh [19:55] Who worked on nqp::replace, ooc? [19:56] hm, doesn't look it could hang... [20:01] was it timotimo++? [20:02] yes, see https://github.com/MoarVM/MoarVM/commit/b2da0b7cfc26161aa86553ec6e6eb0442aa31b95 [20:02] oh? [20:02] yes, i did that [20:03] did i forget to increment a counter in a loop or something? [20:03] timotimo: I can't see hwo [20:04] i got lots of help with that piece of code [20:04] Yeah, it's not guilty. [20:04] phew [20:04] It's C that's doing the wrong thing, it seems [20:06] that does sound like something that could be backend dependent. [20:12] Um... [20:12] How does this ever work normally... [20:12] :D [20:12] DYNAMIC, if it doesn't find what it's after, calls fail [20:13] fail contains die $value if $*FATAL; [20:13] :D [20:13] which calls DYNAMIC, which... :) [20:14] ah, 'cus $PROCESS::FATAL = False; [20:16] stage parse under valgrind not finished, after nearly 18 minutes runtime :( [20:16] is that what a bootstrapping compiler does? a calls b that calls that calls a? :P [20:16] moritz: it can take hours [20:17] i do not evny you. [20:27] Oh, damn, I know what it is... [20:27] the WHENCE thing isn't implemented yet... [20:30] jnthn: http://perlpunks.de/paste/show/529b9c35.797d.2ae the first valgrind output while parsing the setting [20:36] ooh [20:36] That looks like soemthing to fix. [20:56] *** BenGoldberg joined [20:57] * moritz can't seem to figure it out [20:59] result = malloc(lengthu + 1); [20:59] for (i = 0; i < lengthu; i++) { ... }; result[i] = 0; [21:00] that looks like result is \0-terminated [21:01] and MVM_coerce_s_n just calls atof() on result [21:01] and I don't think atof reads past the string, does it? [21:02] unless my libc is, like, totally b0rked [21:02] ____strtod_l_internal is what's marked as guilty...I guess atof maybe using that? [21:02] I guess too, because the man page for atof says "The behavior is the same as strtod(nptr, (char **) NULL);" [21:03] ... "except that atof() does not detect errors." [21:03] OK, well somehow we're reading past the end... [21:03] yes, atof() is awesome. I baked you a result, but maybe I eated it. Or maybe not. [21:03] *** dalek joined [21:03] and atoi [21:04] nwc10: What's the Right Thing to use? :) [21:04] probably strtod() or strtol() or strtoul() [21:04] I'm a bit distrubted it'd read past the end of a null terminated thing though... [21:05] well, maybe my analysis was just wrong :-) [21:05] but, of course, they will parse stuff-you-probably-didn't-want if the locale isn' "C" [21:05] and seems that there's a bug in the MSVC runtime where strtol() and stroul() *clear* errno if nothing is wrong [21:06] well, this is, like, totally gcc land here :-) [21:06] FROGGS: Um, I think 10cf89453 busted the Windows build :( [21:07] makefile(392) : fatal error U1086: inference rule cannot have dependents [21:07] moritz: when you say "looks like the result is NUL terminated" did oyu mean that gdb shows the value as a 0 byte at that address read from? Or that you can see that the address read from is definately in range, and it wasn't just gdb getting lucky? [21:07] jnthn: :o( [21:07] revert it please [21:08] nwc10: I meant that, reading the code, I see no way it would *not* be 0-terminated [21:09] nwc10: which isn't best debugging practise, I know :-) [21:09] ah OK. hmm. [21:10] FROGGS: Will do [21:11] https://github.com/MoarVM/MoarVM/blob/master/src/strings/ascii.c#L52 that's the code that generates the string [21:13] moritz: no, I can't see how it won't. But MVM_string_ascii_decode is going to leak the memory from malloc() if it throws its exception. [21:14] and none of those functions document that it's the caller's responsbility to free() the thing they were given. [21:14] that is why valgrind is not helpful if the program exits not cleanly [21:14] although I'm not sure if that sort of thing is implied as the default in MoarVM [21:15] *** cognominal joined [21:16] It shouldn't leak if it throws, but certainly all of the encoding things give back something you need to free. [21:16] jnthn: oh, right, I think I see. The MVMString is rooted somewhere, so the malloc() doesn't get lost? [21:17] nwc10: When I say "it shoudln't leak" I mean "it soudns buggy at present" [21:17] I might have misread it [21:18] but I'm with moritz - I can't see how the problem can be there. [21:19] *nod* [21:19] I don't immediately see it either, though I'm doing about 3 others patches at the moment, so... :) [21:29] MoarVM: 4a939f3 | jnthn++ | build/Makefile.in: [21:29] MoarVM: Revert "rebuild from source files when Makefile changed" [21:29] MoarVM: [21:29] MoarVM: This reverts commit 10cf89453d1e5599b7191c6b22fbc7d97c5e628c, which [21:29] MoarVM: breaks the makefile for nmake. [21:29] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4a939f3ab4 [21:29] MoarVM: b7c8f26 | jnthn++ | src/6model/reprs/P6opaque.c: [21:29] MoarVM: Make the P6opaque null sentinel more robust. [21:29] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b7c8f26210 [21:29] MoarVM: fc2bedc | jnthn++ | src/core/interp.c: [21:29] MoarVM: Avoid segfault on bad outer indexing. [21:29] MoarVM: [21:29] MoarVM: We'll be able to optimize this away in the future, but should not just [21:29] MoarVM: blindly trust the bytecode. [21:29] MoarVM: 80f8b53 | jnthn++ | src/strings/ops.c: [21:29] MoarVM: Add a flatten call, as other string ops have. [21:29] MoarVM: [21:29] MoarVM: Just to be on the safe side, while ropes are still a bit ropey. [21:29] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80f8b533e9 [21:39] whoa [21:44] bah, now we need p6routinereturn :) [21:52] Unhandled exception: Cannot invoke this object [21:52] at src/gen/m-CORE.setting:12138 (./CORE.setting.moarvm:MATCH_SAVE:41) [21:52] from src/gen/m-CORE.setting:12320 (./CORE.setting.moarvm:ACCEPTS:56) [21:54] * FROGGS dares to run it again with -O3 [21:54] umm: [21:55] src/vm/moar/ops/container.c: In function ‘Rakudo_containers_get_scalar’: [21:55] src/vm/moar/ops/container.c:84:5: warning: return discards ‘const’ qualifier from pointer target type [enabled by default] [21:55] return &rakudo_scalar_spec; [21:55] that is new I think [21:55] ^ [21:55] (forgot about the hint :o) [21:56] k, -O gives me this now: Heap corruption detected: pointer 0x2b5e89d47650 to past fromspace [22:05] MoarVM: e50ef3a | jnthn++ | src/core/frame.h: [22:05] MoarVM: Add lexical lookups to public API. [22:05] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e50ef3a2a6 [22:23] Ugh, next one seems weird... [22:54] *** woolfy joined [23:26] *** lizmat joined [23:38] *** woolfy left