[04:13] m: sub (int $i) { $i() } [04:13] rakudo-moar 1f29cb: OUTPUT«===SORRY!===␤callee expression must be an object␤» [04:14] still no 'New Ticket' button on RT? :/ [04:14] huggable, rakudobug [04:14] Zoffix, [email@hidden.address] or use perl6 query on http://rt.perl.org ; see https://github.com/rakudo/rakudo/#reporting-bugs [04:16] .oO( have you people heard of reCAPTCHA.... ) [04:19] Ticket for the above https://rt.perl.org/Ticket/Display.html?id=129772 [05:07] m: use nqp; sub foo (Int:D $offset) { dd nqp::islt_i(nqp::unbox_i($offset),0) }(-1) [05:07] rakudo-moar 1f29cb: OUTPUT«1␤» [05:07] m: use nqp; sub foo (Int:D $offset) { dd nqp::islt_i($offset,0) }(-1) [05:07] rakudo-moar 1f29cb: OUTPUT«1␤» [05:08] What is the purpose of nqp::unbox_i() in that code? [05:09] e.g. here: https://github.com/rakudo/rakudo/blob/nom/src/core/Array.pm#L1058 [05:12] m: use nqp; my $x = -1; sub foo (Int:D $offset) { dd nqp::islt_i($offset,0) }($x) [05:12] rakudo-moar 1f29cb: OUTPUT«1␤» [05:42] m: [].splice: 0, [] # weeeeeeeeeeee [05:43] rakudo-moar 1f29cb: OUTPUT«Memory allocation failed; could not allocate 80320 bytes␤» [05:44] s: [], 'splice', \(0, []) [05:44] Zoffix, Sauce is at https://github.com/rakudo/rakudo/blob/1f29cb2/src/core/Array.pm#L1142 [05:44] .oO( well, there's yer problem ) [06:17] rakudo/nom: 28bf874 | (Zoffix Znet)++ | / (2 files): [06:17] rakudo/nom: Fix hang on incorrect .splice arguments [06:17] rakudo/nom: [06:17] rakudo/nom: Fixes RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [06:17] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/28bf87439e [06:17] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [06:20] roast: 3253db3 | (Zoffix Znet)++ | S32-array/splice.t: [06:20] roast: Test .splice(offset, array) throws [06:20] roast: [06:20] roast: RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [06:20] roast: review: https://github.com/perl6/roast/commit/3253db362c [06:20] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [06:21] rakudo/nom: 4ffeeab | bartolin++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java: [06:21] rakudo/nom: Mention typename in X::Assignment::RO on JVM [06:21] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4ffeeabc74 [06:21] rakudo/nom: 3299111 | (Zoffix Znet)++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java: [06:21] rakudo/nom: Merge pull request #892 from usev6/patch-3 [06:21] rakudo/nom: [06:21] rakudo/nom: Mention typename in X::Assignment::RO on JVM [06:21] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3299111391 [07:11] roast: f56934b | usev6++ | S (2 files): [07:11] roast: Unfudge passing tests for JVM [07:11] roast: review: https://github.com/perl6/roast/commit/f56934bdd8 [07:21] aw, crap [07:21] Rakudo build errored. Zoffix Znet 'Fix hang on incorrect .splice arguments [07:21] https://travis-ci.org/rakudo/rakudo/builds/164218938 https://github.com/rakudo/rakudo/compare/1f29cb23bd6f...28bf87439e4c [07:21] [].splice: 0e0, 0 also hangs [07:22] 'cause there's no type constraint on $offset [07:22] Is there a better way than adding 9 candidates for this case? [07:29] m: multi foo (Int:D $x, $y, @a) {say "got it"}; multi foo ($x, $y, *@a) { &foo.cando(\($x, $y, @a))[0].signature eqv &?BLOCK.signature and die; foo $x, $y, @a }(0e0, 0, 1, 2, 3) [07:29] rakudo-moar 329911: OUTPUT«Died␤ in sub foo at line 1␤ in block at line 1␤␤» [07:29] * Zoffix benches [07:39] :/ or not... seems I hit a module loading hang now :\ [07:44] yup \o/ [07:55] nqp: 726735e | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/CStruct.java: [07:55] nqp: Adjust error message for zero size CStruct, jnthn++. [07:55] nqp: review: https://github.com/perl6/nqp/commit/726735ec98 [07:59] Rakudo build failed. Zoffix Znet 'Merge pull request #892 from usev6/patch-3 [07:59] https://travis-ci.org/rakudo/rakudo/builds/164219328 https://github.com/rakudo/rakudo/compare/28bf87439e4c...32991113917a [08:16] this is just weird.... [08:17] bug happens just when a particular checkout is present in current directory :) [08:22] which bug? [08:22] the multi one? [08:23] Nah, the module loading one :) [08:23] * Zoffix is debugging it atm [08:23] oh [08:56] should the nqp test suit use and &is sub instead of using ok(... eq 'expected') all over the place [08:56] ? [08:57] nqp: 815ecaf | (Pawel Murias)++ | src/vm/js/nqp-runtime/co (2 files): [08:57] nqp: [js] Fix nqp::iscont on typeobjects. [08:57] nqp: review: https://github.com/perl6/nqp/commit/815ecaf733 [08:57] nqp: 503b29a | (Pawel Murias)++ | t/nqp/067-container.t: [08:57] nqp: Test nqp::iscont on typeobjects. [08:57] nqp: review: https://github.com/perl6/nqp/commit/503b29aff2 [08:57] nqp: 2934378 | (Pawel Murias)++ | src/vm/js/Compiler.nqp: [08:57] nqp: [js] Remove dead commented out code. [08:57] nqp: review: https://github.com/perl6/nqp/commit/2934378df2 [08:57] nqp: 0da41f3 | (Pawel Murias)++ | t/qast/01-qast.t: [08:57] nqp: Add a test for mixing a QAST::Var param with setup with a contvar. [08:57] nqp: review: https://github.com/perl6/nqp/commit/0da41f3635 [08:57] nqp: 66e5843 | (Pawel Murias)++ | / (2 files): [08:57] nqp: [js] Setup contvars and statics before we are running the setup code inside the params. [09:02] Hm. I see what the issue is. CompUnit::Repository::FileSystem basically recurses and finds all .pm6? files, slurps all of them, concatenates all of them, and then sha1s the result. [09:02] So if you happen to run stuff in a dir with lots of .pm6 files, you're screwed. [09:08] Wouldn't using an absolute path as repo ID work? [09:09] (well, sha version of it) [09:11] .tell nine maybe you'll have a better idea of how this can be fixed: https://rt.perl.org/Ticket/Display.html?id=129776 [09:11] Zoffix: I'll pass your message to nine. [09:22] oh, that's a regex, not a question [09:22] pm6? i mean [09:26] I'm not sure that one's easily fixed [09:28] It needs to generate what is essentially a GUID for a tree, but in such a way that the same tree will always get the same GUID [09:29] That'll have to depend on the file contents in some way [09:32] Best we can do is probably faster SHA computations [09:33] Might be faster to SHA individual files, and XOR those together [09:40] <[Tux]> This is Rakudo version 2016.09-98-g3299111 built on MoarVM version 2016.09-3-g9b39aa5 [09:40] <[Tux]> csv-ip5xs 3.392 [09:40] <[Tux]> test 16.304 [09:40] <[Tux]> test-t 7.220 [09:40] <[Tux]> csv-parser 17.856 [09:42] <[Tux]> arnsholt, timotimo, csv-ip5xs is perl6 + Inline::Perl5 + Text::CSV_XS, test is the first simple draft of what became test-t, no optimisations, pure perl6, test-t is the full-fledged implementation of Text::CSV_XS in pure perl6 with all options enabled and language specific optimizations applied [09:42] <[Tux]> csv-parser is the perl6 CSV::Parser module [09:43] Cool. Thanks! [09:47] nqp: dea98a2 | peschwa++ | tools/build/MOAR_REVISION: [09:47] nqp: Bump MOAR_REVISION for CStruct fix [09:47] nqp: review: https://github.com/perl6/nqp/commit/dea98a2f6c [09:47] rakudo/nom: c4a8855 | peschwa++ | tools/build/NQP_REVISION: [09:47] rakudo/nom: Bump NQP_REVISION for CStruct fix [09:47] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c4a885554c [09:47] rakudo/nom: 46e0ede | peschwa++ | t/04-nativecall/06-struct.t: [09:47] rakudo/nom: Adjust error message in zero size CStruct test [09:47] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/46e0edebc5 [10:45] Rakudo build passed. Pepe Schwarz 'Adjust error message in zero size CStruct test' [10:45] https://travis-ci.org/rakudo/rakudo/builds/164237981 https://github.com/rakudo/rakudo/compare/32991113917a...46e0edebc593 [12:08] arnsholt, but why does it need file tree contents? [12:08] As in, why is the absolute path alone not enough [12:10] Files=1144, Tests=53182, 228 wallclock secs (12.88 usr 3.61 sys + 1400.44 cusr 131.94 csys = 1548.87 CPU) [12:10] that seems like a low number [12:11] timotimo: in what sense? [12:11] 228 wallclock seconds? [12:11] is that lower than usual? [12:11] not for me... [12:11] OK [12:12] it's been around 228 the past week [12:12] OK! [12:12] http://irclog.perlgeek.de/perl6-dev/search/?nick=&q=%22wallclock+secs%22 [12:15] The mu repo has 1022 module files and perl6 chokes on that. By comparison, Perl 5's Date::Manip distro has 862 module files. So our Filesystem *repository* would choke on a single distro like that in it. [12:17] Zoffix: yup, ran into that myself some weeks ago :-( [12:19] feels to me we should actually be ok with shaing the last modified / file size of a dir [12:43] m: https://gist.github.com/zoffixznet/f2e97446c4327916e51a3556c903972e [12:43] rakudo-moar 46e0ed: OUTPUT«===SORRY!===␤Failed to create directory '/home/zoffix/CPANPRC/rakudo/bug/.precomp/F0F0ACA3B2DE672560EA87C94EF371AC81E75BC9.1475316625.64084' with mode '0o777': Failed to mkdir: 13␤» [12:44] heh [12:44] m: https://gist.github.com/zoffixznet/f72faa3f78f52e718e9ea6ef6d194e8f [12:45] rakudo-moar 46e0ed: OUTPUT«(timeout)starting␤*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': malloc(): smallbin double linked list corrupted: 0x0000000005aad5c0 ***␤» [12:45] \o/ [12:45] I don't get the timeout, just the consistent segfault locally [12:52] "Your session has expired. Please log in again"... And yes, please, do delete the email I spent 5 minutes typing and wanted to send. [12:52] ugh [12:59] m: my ($x, $y, @a); say \(Array:D: $x, $y, @a) [12:59] rakudo-moar 46e0ed: OUTPUT«Cannot resolve caller say(Array:D: Capture); none of these signatures match:␤ (Mu $: *%_)␤ in block at line 1␤␤» [12:59] m: my ($x, $y, @a); say \(Array:D $: $x, $y, @a) [12:59] rakudo-moar 46e0ed: OUTPUT«===SORRY!=== Error while compiling ␤Two terms in a row␤at :1␤------> my ($x, $y, @a); say \(Array:D⏏ $: $x, $y, @a)␤ expecting any of:␤ infix␤ infix stopper␤ statement end␤ statement m…» [12:59] Apparently today is Annoy Zoffix With Bugs day :/ [13:00] oh maybe not [13:00] m: my ($x, $y, @a); say \(Array:D, $x, $y, @a) [13:00] rakudo-moar 46e0ed: OUTPUT«\(Array:D, Any, Any, [])␤» [13:00] \o/ [13:05] m: https://gist.github.com/zoffixznet/c31428d337c108987b0ad98a2bb25969 [13:05] rakudo-moar 46e0ed: OUTPUT«starting␤Before: 0.61891633␤ After: 5.1659245␤ Diff: -88.02%␤» [13:12] This kinda looks daft, https://gist.github.com/zoffixznet/da2703d5c82caa0af8c545a11d140a32 [13:13] Alternate solutions: checking lookup signature 88% relative difference (slower); checking istype on all args 30% rel.dif (slower). [13:13] m: [].splice: 0e0, 0 # fix for this hang [13:13] rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 40816 bytes␤» [13:13] Should I commit that? [13:14] and using where {} clauses is also ridiculously slow in the 98% rel dif [14:14] rakudo/js: 936b5a5 | (Pawel Murias)++ | src/vm/js/perl6-runtime/runtime.js: [14:14] rakudo/js: [js] Update due to nqp changes. [14:14] rakudo/js: review: https://github.com/rakudo/rakudo/commit/936b5a5f23 [14:14] rakudo/js: 424d190 | (Pawel Murias)++ | src/vm/js/ (2 files): [14:14] rakudo/js: [js] Implement nqp::p6var. [14:14] rakudo/js: review: https://github.com/rakudo/rakudo/commit/424d19083a [14:15] nqp: 76815d2 | (Pawel Murias)++ | t/qast/01-qast.t: [14:15] nqp: Update skip count in test. [14:15] nqp: review: https://github.com/perl6/nqp/commit/76815d208b [14:15] nqp: 34b2df3 | (Pawel Murias)++ | src/core/testing.nqp: [14:15] nqp: Add &is to the setting for better failure diagnostics. [14:15] nqp: review: https://github.com/perl6/nqp/commit/34b2df3585 [14:15] nqp: 1ca74f3 | (Pawel Murias)++ | src/vm/js/ (4 files): [14:15] nqp: [js] Evaluate arguments to a method/sub in proper order, requires refactoring how we handle the arguments. [14:15] nqp: review: https://github.com/perl6/nqp/commit/1ca74f3aad [14:15] nqp: 556fc2e | (Pawel Murias)++ | t/qast/01-qast.t: [14:15] nqp: Test that named and positional (flattened or otherwise) arguments to a methodcall are evaluated in the proper order. [14:15] nqp: review: https://github.com/perl6/nqp/commit/556fc2e1ee [15:02] jnthn: here is the thing we were talking about yesterday: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:02] hmm perhaps camelia can also do it [15:02] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:02] rakudo-moar 46e0ed: ( no output ) [15:03] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:03] rakudo-moar 46e0ed: ( no output ) [15:03] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:03] rakudo-moar 46e0ed: ( no output ) [15:03] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:03] rakudo-moar 46e0ed: ( no output ) [15:03] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:03] rakudo-moar 46e0ed: ( no output ) [15:03] m: await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) [15:03] rakudo-moar 46e0ed: ( no output ) [15:03] maybe not [15:03] m: for ^100 {await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) } [15:03] rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤» [15:03] m: for ^10 {await (for ^7 { start ‘/any/file/really’.IO ~~ :e }) } [15:03] rakudo-moar 46e0ed: OUTPUT«Memory allocation failed; could not allocate 4 bytes␤Memory allocation failed; could not allocate 4 bytes␤» [15:03] gist of the valgrind output: https://gist.github.com/MasterDuke17/9ab9ec5bdbc483bfe63213bf26f82316 [15:04] gc_free huh? Who would've thought [15:34] jnthn: would it make sense to return $!closed from Channel.send? [15:37] jnthn: the exception could be .resume and a Bool check after send could be done via `or last` to leave a loop that got a .send inside [15:39] jnthn: catching the exception is a bit tricky if there are any methods/subs called that could also do some Channeling. [15:44] jnthn: i found a way to handle it by having a block around the sends with `CATCH { when X::Channel::ReceiveOnClosed { last } }` inside [16:18] <[Tux]> https://github.com/Tux/CSV/blob/master/nc-c.pl => Internal error: Unwound entire stack and missed handler [16:18] <[Tux]> $ perl6 nc-c.pl NativeCall eroor. I'm stuck [16:22] roast: 34ee3d8 | usev6++ | / (5 files): [16:22] roast: Add ticket number to fudged tests (RT #129782) [16:22] roast: review: https://github.com/perl6/roast/commit/34ee3d871c [16:22] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129782 [16:41] jnthn: btw, RT #129781 is for the segfault AlexDaniel was talking about earlier [16:41] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129781 [16:48] Quick! Let's all give jnthn things to do! \o/ :) [16:51] i also have a house that needs to be painted... [17:00] rakudo/nom: 058de71 | (Zoffix Znet)++ | src/core/Array.pm: [17:00] rakudo/nom: Remove trailing whitespace [17:00] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/058de71fab [17:06] rakudo/nom: b77d2b7 | (Zoffix Znet)++ | src/core/Array.pm: [17:06] rakudo/nom: Fix infinihang on incorrect .split offset [17:06] rakudo/nom: [17:06] rakudo/nom: Further fix for RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [17:06] rakudo/nom: [17:06] rakudo/nom: This is really gross, but all alternatives I could think of take at least 1.5x [17:06] rakudo/nom: more time to run. The `where` clause makes things ~14x slower. The nqp::istype [17:06] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [17:06] rakudo/nom: checks, make things ~1.5x slower. The .^lookup+cando candidate signature check [17:06] rakudo/nom: is about 10x slower. [17:06] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b77d2b71db [17:10] damn.... s/.split/.splice/; [17:12] roast: 5d87503 | (Zoffix Znet)++ | S32-array/splice.t: [17:12] roast: .splice with incorrect offset type does not hang [17:12] roast: [17:12] roast: Further test for RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [17:12] roast: review: https://github.com/perl6/roast/commit/5d8750321d [17:12] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [17:21] rakudo/nom: 2dd6230 | MasterDuke17++ | src/Perl6/Actions.nqp: [17:21] rakudo/nom: Error when multiple *s are in a double closure [17:21] rakudo/nom: [17:21] rakudo/nom: Fixes RT #129780 [17:21] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2dd6230b72 [17:21] rakudo/nom: c4c0718 | lizmat++ | src/Perl6/Actions.nqp: [17:21] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129780 [17:21] rakudo/nom: Merge pull request #893 from MasterDuke17/RT129780 [17:21] rakudo/nom: [17:21] rakudo/nom: Error when multiple *s are in a double closure [17:21] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c4c071859f [18:01] Rakudo build errored. Zoffix Znet 'Remove trailing whitespace' [18:01] https://travis-ci.org/rakudo/rakudo/builds/164292885 https://github.com/rakudo/rakudo/compare/46e0edebc593...058de71fab55 [18:01] whitespace considered significant? :) [18:02] In what context? [18:02] docs, I believe [18:02] * Zoffix kicks bug[TAB] [18:02] I was just kidding. dunno why travis errored [18:02] AWOL! That's punnishable by death! [18:03] It errored due to timed out build [18:03] death? bit late for that, no? [18:03] https://travis-ci.org/rakudo/rakudo/builds/164292885 [18:03] [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0) [18:04] there :) [18:05] oh, it's just the jvm build, right? [18:06] yup [18:22] Oh, god.... [18:23] * Zoffix spots another missing splice candidate that infinihangs [18:23] m: [].splice: *, {;} [18:23] rakudo-moar c4c071: OUTPUT«Memory allocation failed; could not allocate 131072 bytes␤» [18:23] There's a lesson in all of this: don't go mental with letting your arguments be super flexible [18:23] YAGNI [19:07] Rakudo build errored. lizmat 'Merge pull request #893 from MasterDuke17/RT129780 [19:07] https://travis-ci.org/rakudo/rakudo/builds/164296325 https://github.com/rakudo/rakudo/compare/b77d2b71db17...c4c071859fec [19:07] [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0) [19:27] i'm wondering if we should bug travis about that [19:27] or is their timeout only changable with some paid plan? [19:28] still, i'm kinda happy to have r-j in there again with (usually) passing 'make test' :) [19:30] in any case, the no-output timeout is somewhat weird and probably hints at a resource limitation on travis' end [19:30] 'cause that step shouldn't really take more than maybe 3 or so minutes on a reasonable machine, barring any osx bugs [19:32] I'm not actually sure that's a travis thing. I've seen enough failures with automated github accesses to make me wonder if github is actually that unreliable... [19:32] .tell timotimo Awww, now I haz a sad. Any idea *why* changing the calling convention for enqueue made almost no difference if it was 50% of your runtime? [19:32] japhb: I'll pass your message to timotimo. [19:33] but mostly instead of extended failures it's one access fails the next works [19:33] geekosaur: well, the travis failure (and similar ones before) happens during compilation of one specific .nqp file [19:33] oh, I didn't actually look and thought this was the usual timeout issue (travis access github and fail) [19:33] geekosaur: in this case it was NQPHLL.nqp that produced no output [19:34] (which pretty much every travis-using project seems to have on a regilar basis) [19:34] geekosaur: ah. no, this is travis timing out the build because there was no output for 10 minutes [19:34] and subsequently killing it because it must be stuck [19:34] which, honestly, i wouldn't discount as a possibility, but afair it's consistenly osx that does that [19:34] osx is probably oversubscribed [19:35] they didn't support it at all for a long time, because apple licensing means you have to have a bunch of (mostly rack-unfriendly) macs --- can't use vms [19:35] unless theyre running on macs [19:35] so, yeah, maybe we have some weird race on osx that keeps happening only on nqp master (which sounds kind of ridiculous because nqp master is a moving target) or osx doesn't have enough hardware behind it on travis [19:35] right, yeah, that's what i'm thinking [19:35] the latter is very very likely :/ [19:35] * TimToady read that as VMS, not VMs [19:35] 28 Sep 2016 12:56Z TimToady: I've ran into a Unicode regex syntax ambiguity issue if you've a moment to look: https://github.com/perl6/specs/issues/118 [19:36] as i said, that file in particular should take something like 3 or so minutes on reasonable hardware, and it's one of the longer-running ones too [19:36] so, yeah, seems more likely that they don't have enough power behind it to serve it in time [19:37] i mean, optimizing nqp-j somehow might help [19:37] but that's kind of a really hard thing to do, especially considering there's hardly anyone around who really gets the jvm backend *and* wants to work on it :P [19:37] IIRC there's an option to make it wait longer [19:38] https://docs.travis-ci.com/user/customizing-the-build#Build-Timeouts suggests otherwise [19:38] It's in the link the failing build suggests at the end [19:38] ah, you're right, Zoffix++ [19:39] not sure it's a good idea though, 'cause we just move the same target further [19:39] and, well, buggable++ is pretty great too [19:39] thing is, it shouldn't even time out with 10 minutes, honestly [19:40] hrm [19:40] "If you expect the command to take more than 20 minutes, prefix travis_wait with a greater number." [19:40] "install: travis_wait 30 mvn install" [19:40] that's not a prefix travis [19:41] :) [19:45] rakudo/nom: 4abc28c | (Zoffix Znet)++ | src/core/Array.pm: [19:45] rakudo/nom: Add splice(Whatever, Callable) candidates [19:45] rakudo/nom: [19:45] rakudo/nom: This should be the last nail in the coffin of infinihang in [19:45] rakudo/nom: RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [19:45] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [19:45] rakudo/nom: [19:45] rakudo/nom: These candidates aren't super useful and another way to fix it is to [19:45] rakudo/nom: get rid of slurpy candidates for this, but then we lose the consistency [19:45] rakudo/nom: that both offset and size can be any of Int:D|Callable|Whatever and [19:45] rakudo/nom: introduce a special exception to the rule, along with forcing the users [19:45] rakudo/nom: to add special checks for it when types of args aren't known. [19:45] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4abc28ca07 [19:45] roast: 8a702b9 | (Zoffix Znet)++ | S32-array/splice.t: [19:45] roast: Test splice(Whatever, Callable) candidates [19:45] roast: [19:45] roast: Part of RT#129773: https://rt.perl.org/Ticket/Display.html?id=129773 [19:45] roast: review: https://github.com/perl6/roast/commit/8a702b9d75 [19:45] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=129773 [19:53] japhb: did you try running the thing locally? [19:53] 19:32Z timotimo: Awww, now I haz a sad. Any idea *why* changing the calling convention for enqueue made almost no difference if it was 50% of your runtime? [19:58] :-| i just got a segfault with Concurrent::File::Find [20:00] :( [20:05] .tell japhb i imagine if i don't clear the frame buffer and only enqueue blocks that have changed, it'd give a decent performance win ... [20:05] timotimo: I'll pass your message to japhb. [20:10] . [20:10] 20:05Z japhb: i imagine if i don't clear the frame buffer and only enqueue blocks that have changed, it'd give a decent performance win ... [20:10] timotimo: Can't run it locally at the moment, I'm remoting through a couple tunnels, so have no way to test SDL stuff. [20:16] hehe [20:16] it'd probably be enough to just rip out every mention of SDL ;) [20:16] the slowest piece of the whole thing is enqueue, which only does some CArray stuff [20:39] Rakudo build passed. Zoffix Znet 'Add splice(Whatever, Callable) candidates [20:39] https://travis-ci.org/rakudo/rakudo/builds/164317706 https://github.com/rakudo/rakudo/compare/c4c071859fec...4abc28ca0712 [20:42] japhb: my idea was worth a whole lot [20:43] put enqueue in the 11th spot when sorting by exclusive time [20:43] and it has less than 50% exclusive time of its inclusive time [20:48] Wheeee [20:49] How's the overall speed improved? [20:50] it's ~44sec for 500 frames now [20:51] is there a way how much RAM rakudo hogs from within a script? [20:52] used to be 1:36m [20:53] gfldex: you can get an approximation from malloc with their stats function, but i forgot its name [20:53] japhb: ^^^ [20:54] gfldex: a crazy idea is to use $*PID and pass that to 'top -p 1234' or something :D [20:55] gfldex: idk if that would work, or how to get a simple text output [20:58] probably better to call "ps" and pass the pid and scan the output [21:01] alternatively, read the file /proc/PIDNUMBER/stat :) [21:01] ps -p$*PID -o vsz [21:01] or use /proc yeh [21:15] timotimo: That's not a bad improvement. Still not a rockin' frame rate, but better than 5 fps was .... [21:16] of course [21:16] What's the top cost now? Is it back to SDL? [21:18] down to 40 seconds by rendering the rects immediately rather than bunching them up [21:19] now the costliest part is the inner loop [21:19] i.e. the one looping over y values that's inside the loop that loops over x values [21:19] by over 2x, next one is the min method, then postcircumfix:<[ ]> [21:25] timotimo: I guess then you get to TimToady's idea to precompute all neighborhoods, like he did with forest-fire. [21:27] i'm not 100% on that, but if someone else would implement it, i'd measure it :P [21:34] m: say (slurp '/proc/' ~ $*PID ~ '/stat').lines[0].split(' ')[23-1] [21:34] rakudo-moar 4abc28: OUTPUT«93929472␤» [21:34] :) [21:35] m: say (slurp '/proc/' ~ $*PID ~ '/stat').lines[0].split(' ')[23-1,20-1] [21:35] rakudo-moar 4abc28: OUTPUT«(93945856 1)␤» [21:39] other relevant proc files are /proc/1234/statm and /proc/1234/status. maybe they are better suited for your task :) [22:12] m: my $statm = slurp "/proc/$*PID/statm"; my $mem = $statm ~~ /(\d+)\s+\d+$$/ && $0 * 4 / 1024; say $mem > 1024 ?? sprintf("%.3fG", $mem/1024) !! sprintf("%.1fM", $mem); [22:12] rakudo-moar 4abc28: OUTPUT«53.4M␤» [22:12] gfldex: ^^ [22:13] m: my @a = ^999999; say @a.elems; my $statm = slurp "/proc/$*PID/statm"; my $mem = $statm ~~ /(\d+)\s+\d+$$/ && $0 * 4 / 1024; say $mem > 1024 ?? sprintf("%.3fG", $mem/1024) !! sprintf("%.1fM", $mem); [22:13] rakudo-moar 4abc28: OUTPUT«999999␤160.7M␤» [22:27] m: [].^lookup('splice').canidates.elems.say [22:27] rakudo-moar 4abc28: OUTPUT«No such method 'canidates' for invocant of type 'Method+{}'␤ in block at line 1␤␤» [22:27] m: [].^lookup('splice').candidates.elems.say [22:27] rakudo-moar 4abc28: OUTPUT«31␤» [22:27] :} [22:28] yeesh :) [22:29] huh [22:29] that's a bit harsh [22:29] Yeah. Speed is the reason. [22:29] i mean, i caught a bit of what brought this on, but yeah [22:29] m: Buf.new.^lookup('splice').canidates.elems.say [22:29] rakudo-moar 4abc28: OUTPUT«No such method 'canidates' for invocant of type 'Method'␤ in block at line 1␤␤» [22:30] m: Buf.new.^lookup('splice').candidates.elems.say [22:30] rakudo-moar 4abc28: OUTPUT«8␤» [22:30] m: say (slurp '/proc/'~$*PID~'/status').lines».split(":\t")[*;1]».trim[16, 15] [22:30] rakudo-moar 4abc28: OUTPUT«(69448 kB 69448 kB)␤» [22:31] Zoffix: does Buf.splice needs the same fixing you did for Array.splice? [22:31] that is VmSize and VmPeak [22:31] lucasb_, yeah. It's what I'm working on now. That's how I discovered all the hanging cases in Array.splice [22:31] ok, Zoffix++ [23:32] roast: 0892f24 | (Zoffix Znet)++ | S32-array/splice.t: [23:32] roast: [coverage] Test all Array.splice candidates [23:32] roast: review: https://github.com/perl6/roast/commit/0892f24e57 [23:34] roast: b8d710f | (Zoffix Znet)++ | S32-array/splice.t: [23:34] roast: OCD [23:34] roast: review: https://github.com/perl6/roast/commit/b8d710fbcb [23:41] ++ for OCD commit ;D