[00:43] *** zakharyas joined [01:48] *** ilbot3 joined [06:16] *** domidumont joined [06:21] *** domidumont joined [07:19] *** domidumont joined [07:51] *** FROGGS joined [07:56] geez moar is confusing :P [07:56] also i'm clearly not awake enough yet to hack on it either [07:57] 'cause now i've pushed (to my fork behind the PR, but still) a change that fails with (something like) "invalid identifier" or so [08:09] alright, i think i've got it now :l [08:10] i've pushed the adjusted error message on nqp-j already, so i'd say after the merge we bump moar & nqp rev and then i push the adjusted test [08:12] *** domidumont joined [08:54] *** domidumont joined [09:21] *** Dunearhp joined [09:38] * jnthn wonders what's confusing about moar... :) [09:40] MoarVM: cbb1178 | peschwa++ | src/6model/reprs/CStruct.c: [09:40] MoarVM: Die on CStruct without any fields. [09:40] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cbb11781a3 [09:40] MoarVM: 98975c8 | peschwa++ | src/6model/reprs/CStruct.c: [09:40] MoarVM: Adjust error message for zero size CStruct, jnthn++. [09:40] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/98975c81af [09:40] MoarVM: 174fc71 | peschwa++ | src/6model/reprs/CStruct.c: [09:40] MoarVM: Pass the STable into compute_allocation_strategy. [09:40] MoarVM: [09:40] MoarVM: Otherwise, well, it's not there and we cannot ask it for the debug_name. [09:40] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/174fc71230 [09:40] MoarVM: 6b8fa2e | jnthn++ | src/6model/reprs/CStruct.c: [09:40] MoarVM: Merge pull request #416 from peschwa/master [09:40] MoarVM: [09:42] MoarVM: 0672713 | cygx++ | src/io/syncfile.c: [09:42] MoarVM: make MVM_file_open_fh() throw if the file we opened was a directory [09:42] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0672713e6a [09:42] MoarVM: 727114d | cygx++ | src/io/syncfile.c: [09:42] MoarVM: Document why it's ok to ignore fstat errors in MVM_file_open_fh() [09:42] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/727114d13c [09:42] MoarVM: fb40d63 | cygx++ | src/io/syncfile.c: [09:42] MoarVM: Fix bug and memory leaks in MVM_file_open_fh() [09:42] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fb40d6378f [09:42] MoarVM: 0dce897 | jnthn++ | src/io/syncfile.c: [09:42] MoarVM: Merge pull request #406 from cygx/fail-open-if-dir [09:42] MoarVM: [09:44] MoarVM: 8726735 | labster++ | build/probe.pm: [09:44] MoarVM: Add error message for likely macOS build failure (that I personally experienced) [09:44] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/872673596c [09:44] MoarVM: 34c375a | jnthn++ | build/probe.pm: [09:44] MoarVM: Merge pull request #408 from labster/master [09:44] MoarVM: [09:44] MoarVM: Add error message for likely macOS build failure [09:44] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/34c375a563 [10:05] *** travis-ci joined [10:05] MoarVM build failed. Jonathan Worthington 'Merge pull request #416 from peschwa/master [10:05] https://travis-ci.org/MoarVM/MoarVM/builds/164237184 https://github.com/MoarVM/MoarVM/compare/9b39aa56abcd...6b8fa2ed3a27 [10:05] *** travis-ci left [10:06] --no-jit and no --has-libffi (which i assume is also --no--libffi..?) [10:09] okay i don't think i understand what travis tests there..? [10:10] 'cause, well, it creates install-jvm-runner.pl and then dies because of an too old moar version..? [10:10] *** domidumont joined [10:10] ohh, it builds nqp [10:10] right, moar doesn't have tests [10:21] *** travis-ci joined [10:21] MoarVM build failed. Jonathan Worthington 'Merge pull request #406 from cygx/fail-open-if-dir [10:21] https://travis-ci.org/MoarVM/MoarVM/builds/164237500 https://github.com/MoarVM/MoarVM/compare/6b8fa2ed3a27...0dce8974453b [10:21] *** travis-ci left [10:55] *** zakharyas joined [11:43] *** btyler joined [11:52] *** domidumont joined [12:23] *** Ven_ joined [13:58] MoarVM: 8e92125 | (Dominique Dumont)++ | Configure.pl: [13:58] MoarVM: Fix build without libtommath source [13:58] MoarVM: [13:58] MoarVM: Debian policy requires (as far as possible) to remove convenience [13:58] MoarVM: copy of source code before build. [13:59] *** dalek joined [15:31] *** Ven_ joined [15:45] *** Ven_ joined [16:05] *** domidumont joined [16:56] *** btyler joined [17:15] *** brrt joined [17:45] *** btyler joined [17:45] good * #moarvm [17:45] \o btyler [17:46] hiya brrt \o [17:47] * brrt is finally progressing on the JIT by deciding not to care about some design things [17:49] hmm, just had an idea… let me put it here before it slips my mind [17:50] optimistic store removal can be a completely local thing [17:50] (in which case, it doesn't help much, but okay) [17:50] in which case, the only 'natural storage position' for a value would be the last [17:51] e.g.: suppose we have a sequence of LOAD, COPY, (equalling SET), another COPY, and then a STORE [17:52] if the definition of the first COPY would be the last one, the STORE would be inserted anyway; but it'd be equally safe just to store it in the final place [17:52] (in which case… *drumroll* we can detect-and-eliminate that double store [17:53] not sure if this is anything but hypothetical, but still a nice simplication [17:53] trainswitch & [17:54] *** btyler joined [18:03] *** FROGGS joined [18:09] *** brrt joined [18:10] anyway… any plans for LPW? [18:14] (just yesterday i finally installed Fedora 24. And I finally got rid of selinux. I wonder which one contributes most to the thing feeling much faster [18:29] MoarVM/even-moar-jit: c3fd80c | brrt++ | src/jit/linear_scan.c: [18:29] MoarVM/even-moar-jit: Implement naive spilling and splitting [18:29] MoarVM/even-moar-jit: [18:29] MoarVM/even-moar-jit: The actual logic of the 'spill' decision needs some work because [18:29] MoarVM/even-moar-jit: it needs to decide whether or not to split a range in the first [18:29] MoarVM/even-moar-jit: place. Also, splits should probably be rangeable (which means [18:29] MoarVM/even-moar-jit: that the split logic may be more complicated). [18:29] MoarVM/even-moar-jit: [18:29] MoarVM/even-moar-jit: And it needs the mysterious function 'create_new_live_range' [18:29] MoarVM/even-moar-jit: and 'get_storage_location', which probably aren't really very [18:29] MoarVM/even-moar-jit: complicated but I don't want to think about them right now :-) [18:29] MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c3fd80ce7b [18:47] i wonder how hard it'd be to have a minor program that links moar, builds an expr tree (from a file?), compiles and runs it [18:47] possibly the parsing bit is hardest, but, sexpr [18:48] why not write it in nqp? [18:48] because NQP is itself jitted [18:49] ah, you don't want that [18:49] or, you mean, the parser [18:49] i want some more fine-grained control for it, anyway [18:49] well, moar will only really run stuff it has bytecode for ... [18:49] nqp::jitdisable(), nqp::jitenable(), slt [18:49] sounds sensible [18:49] and easy to do, i guess? [18:49] not sure [18:49] though i'm not sure if we rely on that flag not changing :D [18:50] yeah, i wonder how that interoperates with speshing [18:50] which is kind of asynchronous from the viewpoint of the user [18:50] right [18:51] * timotimo BBL [18:51] (furthermore, it has clear action-at-a-distance for mutlithreaded applications, unless we bind the flag to threadcontext) [18:51] see you :-) [18:52] right, the flag is in the instance right now [18:53] which… is really easy to change, but also, probably not worth it [19:41] *** Ven_ joined [21:08] *** Ven_ joined [21:11] i think we could also trigger a major collection when the number of gen2 roots has increased a noticable amount [21:28] *** Ven_ joined [21:38] *** Ven_ joined [22:18] *** Ven_ joined [23:05] *** dalek joined