[00:01] *** CurtisOvidPoe joined [00:05] i forget why exactly we have cmp and then <=> [00:05] m: "omgwtf" cmp 123 [00:05] rakudo-moar 4f7cb8: OUTPUT«WARNINGS for /tmp/e4ZgHUrtWz:␤Useless use of "cmp" in expression "\"omgwtf\" cmp 123" in sink context (line 1)␤» [00:05] m: say "omgwtf" cmp 123 [00:05] rakudo-moar 4f7cb8: OUTPUT«More␤» [00:05] m: say "omgwtf" cmp Mu.new [00:05] rakudo-moar 4f7cb8: OUTPUT«X::Multi::NoMatch exception produced no message␤ in block at /tmp/ObAkKP3A74 line 1␤␤» [00:05] is that what we do this for? [00:05] m: say "omgwtf" cmp Any.new [00:05] rakudo-moar 4f7cb8: OUTPUT«More␤» [00:09] well, we're also doing expensive parameter binding/signature binding somewhere [00:24] *** colomon joined [02:41] *** pyrimidi_ joined [02:47] *** ilbot3 joined [02:51] *** FROGGS_ joined [03:58] rakudo/repl6: 55a71b3 | hoelzro++ | src/core/REPL.pm: [03:58] rakudo/repl6: REPL6: Set up path to history file if it doesn't exist [03:58] rakudo/repl6: review: https://github.com/rakudo/rakudo/commit/55a71b39c5 [04:31] rakudo/repl6: 8e5705a | hoelzro++ | src/core/REPL.pm: [04:31] rakudo/repl6: REPL6: Insulate REPL implementation helpers from setting [04:31] rakudo/repl6: [04:31] rakudo/repl6: We don't want to leak things like mkpath out into the setting; [04:31] rakudo/repl6: wrap them in their own lexical context [04:31] rakudo/repl6: review: https://github.com/rakudo/rakudo/commit/8e5705a347 [05:06] *** colomon joined [08:09] *** geekosaur joined [09:46] *** RabidGravy joined [10:56] rakudo/nom: 65d42bc | lizmat++ | docs/ChangeLog: [10:56] rakudo/nom: Add some ChangeLog entries [10:56] rakudo/nom: [10:56] rakudo/nom: At least the ones I recognized from the rakudo git log. This is by [10:56] rakudo/nom: no means to be considered complete: I probably missed a lot of MoarVM [10:56] rakudo/nom: and nqp improvements. [10:56] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/65d42bc622 [11:02] <[Tux]> test 20.841 [11:02] <[Tux]> test-t 13.219 [11:02] <[Tux]> csv-parser 48.993 [11:08] [Tux]: that's significantly less than yesterday, right (13.704) ? [11:09] <[Tux]> 2016-03-16 11:07:16 test-t 13.702 [11:09] <[Tux]> 2016-03-17 08:30:57 test-t 14.080 [11:09] <[Tux]> 2016-03-18 07:51:52 test-t 13.704 [11:09] <[Tux]> 2016-03-19 11:58:49 test-t 13.219 [11:38] lizmat, Buf[num32] and Buf[num64] can be created, but aren't supported and in jnthn++ opinion the way is prohibit these. I don't know how. Ideas? [11:52] oof [11:52] we really want it to not steal much performance [11:52] I would suggest a conditional die in the mainline of the Blob role that tests T === num32 || T === num64 ? [11:52] oh, of course [11:52] that's what runs at compose time [11:53] i forgot that bit :) [11:53] sortiz ^^^ [11:54] timotimo: fwiw, I have a patch that eliminates copying the indices array in p6sort, but I only see a ~ 4% improvement [11:54] so, apart from using less memory, there's not a lot to be had tere [11:54] *there [11:55] do you see a good way to make the two closures inside the sort method better? [11:55] the one that does $foo cmp $bar || $foo <=> $bar [11:56] in the profile, that seemed to really take a lot of time [11:56] i think it may be the cause behind the high amount of Bool invocations perhaps? [11:56] because it uses infix:<||>? [11:57] lizmat, A naked die or a typed Exception? [11:57] something like InvalidArgumentException :P [11:57] NYI I would say ? [11:57] X::NYI ? [11:57] we could do that, yeah [11:58] i can imagine a Buf with nums to be implementable later [11:58] so, but Buf(num) works ? [11:59] timotimo, It's implementable now, adding all required *_n [11:59] Now all the Blob machinery expects ints [11:59] right [12:00] it'll probably end up looking like the NumTypedNativeArray or whatever that role is called [12:00] well, this feels like another code generating job :-) [12:00] Yep [12:00] righto [12:01] lizmat: if you find a good way to describe it, we've got a fix for certain unicode characters segfaulting moarvm since the last release [12:01] directory listings now use utf8-c8 [12:02] is utf8-c8 fixed btw ? [12:02] not yet [12:04] rakudo/nom: 319ec8e | lizmat++ | docs/ChangeLog: [12:04] rakudo/nom: Some ChangeLog additions, timotimo++ [12:04] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/319ec8e414 [12:05] timotimo, Umm Are you sure that the mainline of a role is run at compose time? COMPOSE phaser is NYI and the failed optim case of NativeCall worries me. [12:06] optim case? [12:07] lizmat++ attempted optimization but tater reverted case. [12:08] s/tater/later/ [12:08] I still think that's a hesienbug: I intend to reapply the patch after the release and see how it simmers out :-) [12:09] I have a working version, with the test for initialization inside of setup. [12:10] there's a few memory-related optimizations in moar for this month's release; would they go into the changelog, too? [12:14] *** colomon joined [12:16] bbl o/ [12:19] timotimo: I think they should [12:20] timotimo: perhaps it would help if we added native int candidates for infix:<&&> ? [12:21] isn't there also some compiler component to that? because we short-circuit that? [12:22] timotimo: no idea [12:22] oh, i think that's what's up. if we have native ints we'll use the compiler's own && implementation [12:22] could that be it? [12:22] I have no idea, my compiler knowledge doesn't go that deep [12:22] and anyways, I'm off for some fresh air :-) [12:23] afk for a few hours& [12:24] i think at least in the case of the sort thingie, we'd benefit from short-circuiting that [12:24] hmm. [12:24] i dunno [12:24] i feel too tired to figure this out :) [13:13] *** AlexDaniel joined [13:22] Both && and || compile into QAST if/unless nodes, which in turn are smart enough to do sensible things with natives. [14:11] *** RabidGravy joined [15:07] there's something very right about them compiling to if/unless nodes. [15:07] it also shows Yet Another Difference between QAST and Q. [15:08] because in QAST, that kind of "operational" similarity is the central concern. [15:08] in Q, an if statement is a different kind of thing from a (short-circuiting) infix operator. [15:13] Yeah, that's one of those places where it's not clear Q will be a net simplification from a compiler point of view. [16:29] oh, you wanted compiler simplifications? that will be a tough one to square with having macros, yes :P [16:30] because macros essentially expose a number of (usually) internal compiler things [16:30] especially parsing, but sometimes also related to control flow and the like [16:50] Well, it's possible that having a higher-level AST might make some manipulations easier though [18:40] *** colomon joined [19:39] yes, definitely [22:07] *** AlexDaniel joined [22:23] rakudo/nom: 8437418 | lizmat++ | src/core/Buf.pm: [22:23] rakudo/nom: Disallow Buf/Blobbing with anything but Int [22:23] rakudo/nom: [22:23] rakudo/nom: Pointed out by sortiz++ [22:23] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8437418432 [22:27] good night, #p6dev [23:04] *** colomon joined