[01:47] *** ilbot3 joined [05:58] *** TimToady joined [05:59] *** RabidGravy joined [06:17] *** sno joined [06:31] *** lizmat joined [08:16] *** [TuxCM] joined [08:16] *** lizmat joined [08:41] rakudo/nom: 63fd14f | lizmat++ | src/core/Num.pm: [08:41] rakudo/nom: Streamline some Num infixes [08:41] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/63fd14f819 [08:51] ok, I think we need to revisit NaN.Int and NaN.Rat [08:51] as well as Inf.Int and Inf.Rat [08:51] they both now fail [08:51] m: NaN.Int [08:51] rakudo-moar 63fd14: OUTPUT«Cannot coerce NaN to an Int␤ in block at /tmp/14Mto5fMdk line 1␤␤Actually thrown at:␤ in block at /tmp/14Mto5fMdk line 1␤␤» [08:51] m: NaN.Rat [08:51] rakudo-moar 63fd14: OUTPUT«Cannot coerce NaN to a Rat␤ in block at /tmp/QepqhxrXo3 line 1␤␤Actually thrown at:␤ in block at /tmp/QepqhxrXo3 line 1␤␤» [08:52] m: Inf.Int [08:52] rakudo-moar 63fd14: OUTPUT«Cannot coerce Inf to an Int␤ in block at /tmp/nc9oDyzOT2 line 1␤␤Actually thrown at:␤ in block at /tmp/nc9oDyzOT2 line 1␤␤» [08:52] m: Inf.Rat [08:52] rakudo-moar 63fd14: OUTPUT«Cannot coerce Inf to a Rat␤ in block at /tmp/309s0PH0QL line 1␤␤Actually thrown at:␤ in block at /tmp/309s0PH0QL line 1␤␤» [08:52] however, spectests indicate the opposite view [08:53] S32-num/rat.t, test 749-751 (which now fail) [08:53] and S02-types/infinity.t that has 3 todo'd tests [08:53] either we should match rakudo with the tests, or vice-versa [08:54] fwiw, *I* prefer the current behaviour, meaning tests should be adapted [08:55] if in the future, we manage to hack Inf into Int and Rat, we can lift the fail [08:57] rakudo/nom: 689d079 | lizmat++ | src/core/Rat.pm: [08:57] rakudo/nom: Streamline some Rats [08:57] rakudo/nom: [08:57] rakudo/nom: - Rat.perl if denominator is 1 [08:57] rakudo/nom: - return Failure instead of failing for FatRat.Rat [08:57] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/689d079559 [09:05] roast: 61e65a4 | lizmat++ | S32-num/rat.t: [09:05] roast: Todo NaN/Inf/-Inf.Rat tests [09:05] roast: [09:05] roast: Since we've todo'd the NaN/Inf/-Inf.Int as well [09:05] roast: review: https://github.com/perl6/roast/commit/61e65a4937 [09:13] rakudo/nom: 45be4ef | lizmat++ | src/core/Any-iterable-methods.pm: [09:13] rakudo/nom: Change some fails into Failure.new [09:13] rakudo/nom: [09:13] rakudo/nom: Because if it's the value we're about to return anyway, we don't need [09:13] rakudo/nom: the fail exception to deliver it [09:13] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/45be4ef0d5 [09:20] Cannot invoke this object (REPR: Null) [09:20] t/78_fragment.t ... Dubious, test returned 1 (wstat 256, 0x100) [09:20] No subtests run [09:20] broken between yesterday and now [09:20] p6 t/78_fragment.t [09:20] PASS [09:21] *** [TuxCM] joined [09:21] consistent fail when invoked as «prove -j4 -e 'perl6 -I. -Ilib' t» [09:22] interesting... [09:22] does this include any of my patches of this morning ? [09:22] aka, what is "now" ? [09:23] This is Rakudo version 2016.04-89-gec6c3b8 built on MoarVM version 2016.04 [09:24] perl6 was built on 10:37 [09:25] if a standalone run passes, but prove fails, where shall the cause be found? [09:25] if you include PERL6LIB=lib in standalone run ? [09:30] env PERL6LIB=lib make test => PASS / make test => FAIL [09:30] This is Rakudo version 2016.04-89-gec6c3b8 built on MoarVM version 2016.04 [09:30] test 21.623 [09:30] test-t 13.254 [09:30] csv-parser 37.589 [09:31] p6 t/78_fragment.t => PASS, env PERL6LIB=lib p6 t/78_fragment.t => PASS [09:32] prove -j4 -e 'perl6 -I. -Ilib' t/78_fragment.t => PASS, prove -j4 -e 'perl6 -I. -Ilib' t => FAIL [09:33] so, parrallel testing conflict? [09:36] that would be weird ? [09:39] will look at it in a mo [09:41] rakudo/nom: a56d039 | lizmat++ | src/core/Any.pm: [09:41] rakudo/nom: Streamline some Any fallbacks [09:41] rakudo/nom: [09:41] rakudo/nom: - don't fail if we can directly return a Failure [09:41] rakudo/nom: - use ternaries where possible [09:41] rakudo/nom: - use postfix loops where possible [09:41] rakudo/nom: - make smarter use of loop indexes where possible [09:41] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a56d0395aa [10:03] rakudo/nom: 6a82e2a | lizmat++ | src/core/Array.pm: [10:03] rakudo/nom: Streamline some Array ops [10:03] rakudo/nom: [10:03] rakudo/nom: - return Failure if we can, instead of fail [10:03] rakudo/nom: - use ternaries where possible [10:03] rakudo/nom: - don't bother creating local aliases for private attribute [10:03] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6a82e2a010 [10:14] boom [10:46] *** brrt joined [10:47] rakudo/nom: 1939405 | lizmat++ | src/core/Buf.pm: [10:47] rakudo/nom: Streamline Blob/Buf [10:47] rakudo/nom: [10:47] rakudo/nom: - don't fail when we can return a Failure [10:47] rakudo/nom: - use ternaries where possible [10:47] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/193940524d [11:09] rakudo/nom: 4e4cac0 | lizmat++ | src/core/Capture.pm: [11:09] rakudo/nom: Streamline Capture [11:09] rakudo/nom: [11:09] rakudo/nom: - return Failure instead of failing [11:09] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4e4cac000d [11:37] rakudo/nom: 480709d | lizmat++ | src/core/Complex.pm: [11:37] rakudo/nom: Streamline Complex [11:37] rakudo/nom: [11:37] rakudo/nom: - use ternary when possible [11:37] rakudo/nom: - return Failure rather than failing [11:37] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/480709d65e [11:43] *** brrt joined [13:08] *** brrt joined [13:34] rakudo/nom: 1ee27e6 | jnthn++ | src/core/Promise.pm: [13:34] rakudo/nom: Harden Promise.result against spurious wakeups. [13:34] rakudo/nom: [13:34] rakudo/nom: This prevents it from bogusly returning that a Promise was kept in [13:34] rakudo/nom: cases where it was not, in fact, kept, and the OS just signalled the [13:34] rakudo/nom: condvar spuriously. [13:34] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1ee27e660a [13:34] rakudo/nom: 475063a | jnthn++ | src/core/Mu.pm: [13:34] rakudo/nom: Harden Mu.Str against moving GC. [13:34] rakudo/nom: [13:34] rakudo/nom: We have various cases of this in tests: [13:34] rakudo/nom: [13:36] lizmat: 1ee27e6 hopefully nails that Promise issue you mentioned being kinda common on OSX [13:36] <[Coke]> 6.c-errata now failing tests: t/spec/S32-num/rat.rakudo.moar [13:37] <[Coke]> (and t/spec/S17-supply/syntax.t just hung there again on os x) [13:37] <[Coke]> also 2 passing todo'd tests. [13:39] rakudo/moar/reframe: 19e7a1b | jnthn++ | src/vm/moar/ops/perl6_ops.c: [13:39] rakudo/moar/reframe: Sync with MoarVM API changes. [13:39] rakudo/moar/reframe: review: https://github.com/rakudo/rakudo/commit/19e7a1bf1a [13:39] rakudo/moar/reframe: df1db5e | jnthn++ | src/vm/moar/ops/perl6_ops.c: [13:39] rakudo/moar/reframe: Add an MVMROOT on ctx, now frames are GCable. [13:39] rakudo/moar/reframe: review: https://github.com/rakudo/rakudo/commit/df1db5ea74 [13:42] (just rebased that branch) [13:45] you rebased reframe... i'll rebase reframe-jit too, then [13:46] shall i merge reframe-jit on top of reframe? [13:46] brrt: no, only the Rakudo moar/reframe branch [13:46] oh, ok [13:46] nm :-) [13:46] Just to ease testing, 'cus otherwise I see failing spectests 'cus I'm missing Rakudo commits [13:54] <[Coke]> lizmat: I assume the failing 6.c tests are the same as http://irclog.perlgeek.de/p6dev/2016-05-04#i_12431564 - I'm opening a ticket, making it a blocker for the next release. [14:01] <[Coke]> still no volunteer for the may release for rakudo/nqp [14:25] *** perlpilot_ joined [14:27] *** perlpilot joined [14:43] *** dalek joined [14:44] *** perlpilot_ joined [14:50] *** brrt joined [14:52] *** skids joined [14:57] This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04 [14:57] test 21.708 [14:57] test-t 13.397 [14:57] csv-parser 34.835 [14:57] lizmat, na re-make [14:57] dus geen FAIL meer [14:57] sorry, that was Dutch [15:06] woah that seems to be quite the improvement! [15:07] I thought test-t used to be 12.something? Or did one of the other numbers I watch less get better? :) [15:13] jnthn: looks like it was even close to 11 at one point http://irclog.perlgeek.de/perl6/search/?nick=&q=test-t [15:15] http://tux.nl/Talks/CSV6/speed4.html includes the full history: http://tux.nl/Talks/CSV6/speed.log [15:18] nqp: 5676e10 | (Pawel Murias)++ | src/vm/js/Compiler.nqp: [15:18] nqp: [js] Support declaring a variable as a static lexical and then using it as a typevar. [15:18] nqp: review: https://github.com/perl6/nqp/commit/5676e109d0 [15:18] nqp: f280dff | (Pawel Murias)++ | src/vm/js/Operations.nqp: [15:18] nqp: [js] Expose the BOOL type when declaring ops from compiled code. [15:18] nqp: review: https://github.com/perl6/nqp/commit/f280dff233 [15:18] nqp: 25600fd | (Pawel Murias)++ | src/vm/js/ (7 files): [15:18] nqp: [js] Keep privates attributes from ancestor classes separate. [15:18] nqp: review: https://github.com/perl6/nqp/commit/25600fd03b [15:18] nqp: 510670b | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp: [15:18] nqp: [js] Access the attributes of the cursor in regexes properlyy [15:18] nqp: review: https://github.com/perl6/nqp/commit/510670b1b4 [15:21] nqp: 0e80681 | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp: [15:21] nqp: [js] Remove debugging leftover. [15:21] nqp: review: https://github.com/perl6/nqp/commit/0e8068178b [15:21] nqp: 3011392 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js: [15:21] nqp: [js] Remove dead code. [15:21] nqp: review: https://github.com/perl6/nqp/commit/30113920b1 [15:22] Tux__: cool thanks for the link! [15:29] nqp: 116df25 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js: [15:29] nqp: [js] Implement nqp::hintfor. [15:29] nqp: review: https://github.com/perl6/nqp/commit/116df25f58 [16:28] nqp: a69e45c | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [16:28] nqp: [js] Fix bug. [16:28] nqp: review: https://github.com/perl6/nqp/commit/a69e45cfd5 [16:28] nqp: 10069d7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js: [16:28] nqp: [js] Make nqp::hintfor return -1 when encountering something that's not a P6opaque. [16:28] nqp: review: https://github.com/perl6/nqp/commit/10069d7277 [16:28] nqp: 43fb5d6 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [16:28] nqp: [js] Fix bug. [16:28] nqp: review: https://github.com/perl6/nqp/commit/43fb5d6885 [17:01] .seen Skarsnik [17:54] *** hankache joined [18:21] *** dalek joined [18:34] *** perlpilot joined [18:57] jnthn: re 475063a , shouldn't we harden .WHERE ? [18:58] lizmat: ??? [18:58] No [18:58] The point of .WHERE is "where is the object in memory" [18:58] ok [18:58] There's nothing to harden [18:59] but where it is in memory, is basically volatile info [18:59] Correct :) [18:59] Which is why we've nqp::objectid (which .WHICH uses) [18:59] if an object has moved out of the nursery, can we be sure that it will stay at the same memory address ? [19:00] Well, the present MoarVM answer is yes, but the Perl 6 answer in general is no [19:00] ah, ok, gotcha... [19:00] All it'd take for it not to be true on Moar is us stating to compact gen2 also [19:01] And the JVM has a range of collectors [19:01] I wonder whether we should mix in a role in the .WHERE value [19:01] that would make it croak when used in a NativeCall related environment ? [19:01] because that would be obviously a wrong thing to do ? [19:01] It'd be a weird thing to do though [19:02] I mean, you'd be passing the address of a Perl 6 object, not something that'll make sense in C-land. [19:02] well, some people might think that [19:02] especially coming from p5 land [19:05] It's still a stretch IMO...you'd have gotten an Int back from WHERE, and so to be able to pass it would have had to purposefully translate the signature of the C function you planned to call in such a way that you wrote Int in the signature in place of something wanting a pointer. [19:06] sub foo(SomeCStruct $foo) is native(...) {*}; will die if called as foo($something.WHERE) already [19:06] bbi10 [19:11] jnthn: fwiw, 1ee27e660a8dce3ae03177 makes spectest run with HARNESS_TYPE=6 [19:11] running one now with TEST_JOBS=1 [19:20] hmmm... had a test hanging, now ran it with TEST_JOBS=8, and got a segfault [19:20] I guess I'm going to try this again when the Moar changes have landed :-) [19:26] Still, progress... [19:27] I've still got various smaller ways to trigger problems that I need to hunt down. [19:28] (Beyond the ones I already fixed in the reframe branch) [19:28] yes, definitely progress [19:28] So I'll chug through those before trying to find 'em from the 6harness :) [19:28] also, the hang could have been caused by me recompiling rakudo underneath :-) [19:28] ah [19:28] Maybe [19:28] I'll start another run before going to bed [19:29] it's slow with TEST_JOBS=1 :-) [19:29] lol [19:29] No [19:29] It's slow with an 11.5KB nursery :P [19:30] That run came out really well compared to the one I did a couple of weeks ago, though. [19:51] m: sub a(--> Nil) { Failure.new("foo") }; a.defined # this feels peculiar [19:51] rakudo-moar 475063: OUTPUT«foo␤ in block at /tmp/CiklublGPh line 1␤␤Actually thrown at:␤ in sub a at /tmp/CiklublGPh line 1␤ in block at /tmp/CiklublGPh line 1␤␤» [19:51] m: sub a() { Failure.new("foo") }; a.defined # silent without the --> Nil [19:51] rakudo-moar 475063: ( no output ) [19:54] guessing... it's smart enough to not bother trying to sink something that is known at compile time not to produce a result? [19:54] (thus the a.defined never "happens") [19:56] I think the --> Nil makes it sink the body and return Nil [19:56] So the Failure just gets sunk inside the sub [19:56] And so what geekosaur said - you never hit defined [19:56] guess so :-) [19:57] sub a(--> Nil) { ... } I think compiles into sub a() { ...; Nil } roughly [19:57] hm, is --> Nil for subs/methods that aren't supposed to return anything a good performance optimization already? [19:58] Not sure it makes a huge difference. With sub calls the static optimizer could spot the sink call ain't needed and throw it out I guess [19:59] Spesh is making a kinda lame job on the .sink calls at the moment. [20:02] yeah, i remember something about that [20:03] *** sno joined [20:03] Spesh is also on my list of "things in MoarVM due some good attention soon" :) [20:34] How could this give a "Too many positionals passed; expected 1 argument but got 2"? $precomp-file.print($*REPO.id ~ "\n" ~ $dependencies ~ "\n"); [20:37] are you looking at the right place ?? (--ll-exception maybe?) [20:38] Oh, I did not pass a mode to open(), so $precomp-file may be a Failure and it's Mu's print I'm calling [20:38] there you go :) [20:38] those pesky Failures! :-) [20:38] In this case, getting a Failure really does not help more than Perl 5's silence on open failures :/ [20:47] well, in newio I once tried to throw the failure immediately [20:47] and it caused quite some spectest breakage :-( [20:47] (at least in my memory) [20:49] It's more that .print is a method in Mu, so the Failure fallback doesn't apply [20:50] Method fallback, that is [20:50] And .print is at the same time something you'd quite often want to do on a file handle [20:53] Yeah. I agree it's LTA. Too tired to know the right place to fix it. :) [20:54] Well on the up side, my failure case was "file does not exist and stupid programmer forgot to specify write mode on open()", i.e. it's a fail during development, not a case you'd encounter in production [21:05] <[Coke]> http://xkcd.com/1676/ - mmm, new unicode to look forward to (hover text) [21:12] It's a snake! [21:12] rakudo/nom: c403742 | lizmat++ | src/core/ (16 files): [21:12] rakudo/nom: A lot more streamlining [21:12] rakudo/nom: [21:12] rakudo/nom: - use ternaries where possible [21:12] rakudo/nom: - return Failure rather than failing [21:12] rakudo/nom: - boolify reverse logic ternaries [21:12] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c40374237b [21:13] Who's idea was it to de-huffmanize ternaries because they are rarely used? [21:13] :-) [21:14] fwiw, I like the congruity with && || [21:15] "boolify reverse logic ternaries"? [21:16] Yep, I actually like their look more in Perl 6. I also seem to use them more in Perl 6 than in other languages... [21:16] i also prefer the way they look in p6, tbh [21:20] Wow...I'm scared. I actually have a working combined mbc + dependency info precomp file implementation [21:22] timotimo: [21:22] complication expression ?? False !! True [21:23] *complicated [21:29] oh [21:36] They're flow control, so I think it's kinda nice they stand out :) [21:37] nine_: ooh, nice :) [21:38] nine_++ [21:40] whooooaaa [21:40] good work, nine :) [21:40] * jnthn hopes he sleeps well enough to night to have the concentration to get his frame refactors mostly finished up tomorrow :) [21:41] *tonight [21:41] \o/ [21:41] <[Coke]> RT: 1286; GLR: 6; JVM: 60; LHF: 2; LTA: 68; OSX: 3; PATCH: 3; PERF: 16; POD: 3; PRECOMP: 3; SEGV: 22; STAR: 1; TESTNEEDED: 17; UNI: 5; WEIRD: 2 [21:41] This part is less bad in so far as if I screw it up I can have Moar reliably explode (as in, no stress test required) :) [21:42] \o/ [21:43] Also I'll do the minimum "make it work" to get to the merge point, but then there'll be further optimizations on top of it afterwards. [21:50] jnthn ++ [22:03] good night, #perl6! [22:03] gnite lizmat [22:03] eh, #p6dev :-) [22:03] harr [22:10] 'night, lizmat [22:30] * jnthn sleeps also :) 'night