Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-03-19

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary