00:01 CurtisOvidPoe joined
timotimo i forget why exactly we have cmp and then <=> 00:05
m: "omgwtf" cmp 123
camelia rakudo-moar 4f7cb8: OUTPUT«WARNINGS for /tmp/e4ZgHUrtWz:␤Useless use of "cmp" in expression "\"omgwtf\" cmp 123" in sink context (line 1)␤»
timotimo m: say "omgwtf" cmp 123
camelia rakudo-moar 4f7cb8: OUTPUT«More␤»
timotimo m: say "omgwtf" cmp Mu.new
camelia rakudo-moar 4f7cb8: OUTPUT«X::Multi::NoMatch exception produced no message␤ in block <unit> at /tmp/ObAkKP3A74 line 1␤␤»
timotimo is that what we do this for?
m: say "omgwtf" cmp Any.new
camelia rakudo-moar 4f7cb8: OUTPUT«More␤»
timotimo well, we're also doing expensive parameter binding/signature binding somewhere 00:09
00:24 colomon joined 02:41 pyrimidi_ joined 02:47 ilbot3 joined 02:51 FROGGS_ joined
dalek kudo/repl6: 55a71b3 | hoelzro++ | src/core/REPL.pm:
REPL6: Set up path to history file if it doesn't exist
 03:58
kudo/repl6: 8e5705a | hoelzro++ | src/core/REPL.pm:
REPL6: Insulate REPL implementation helpers from setting

We don't want to leak things like mkpath out into the setting; wrap them in their own lexical context		 04:31
05:06 colomon joined 08:09 geekosaur joined 09:46 RabidGravy joined
dalek kudo/nom: 65d42bc | lizmat++ | docs/ChangeLog:
Add some ChangeLog entries

At least the ones I recognized from the rakudo git log. This is by no means to be considered complete: I probably missed a lot of MoarVM and nqp improvements.		 10:56
[Tux] test 20.841 11:02
test-t 13.219
csv-parser 48.993
lizmat [Tux]: that's significantly less than yesterday, right (13.704) ? 11:08
[Tux] 2016-03-16 11:07:16 test-t 13.702 11:09
2016-03-17 08:30:57 test-t 14.080
2016-03-18 07:51:52 test-t 13.704
2016-03-19 11:58:49 test-t 13.219
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:38
timotimo oof 11:52
we really want it to not steal much performance
lizmat I would suggest a conditional die in the mainline of the Blob role that tests T === num32 || T === num64 ?
timotimo oh, of course
that's what runs at compose time
i forgot that bit :) 11:53
lizmat sortiz ^^^
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
*there
timotimo 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
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?
because it uses infix:<||>?
sortiz lizmat, A naked die or a typed Exception? 11:57
timotimo something like InvalidArgumentException :P
lizmat NYI I would say ?
X::NYI ?
timotimo we could do that, yeah
i can imagine a Buf with nums to be implementable later 11:58
lizmat so, but Buf(num) works ?
sortiz timotimo, It's implementable now, adding all required *_n 11:59
Now all the Blob machinery expects ints
timotimo right
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 :-)
sortiz Yep
timotimo righto
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
lizmat is utf8-c8 fixed btw ? 12:02
timotimo not yet
dalek kudo/nom: 319ec8e | lizmat++ | docs/ChangeLog:
Some ChangeLog additions, timotimo++
 12:04
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:05
timotimo optim case? 12:06
sortiz lizmat++ attempted optimization but tater reverted case. 12:07
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 :-)
sortiz I have a working version, with the test for initialization inside of setup. 12:09
timotimo there's a few memory-related optimizations in moar for this month's release; would they go into the changelog, too? 12:10
12:14 colomon joined
sortiz bbl o/ 12:16
lizmat timotimo: I think they should 12:19
timotimo: perhaps it would help if we added native int candidates for infix:<&&> ? 12:20
timotimo isn't there also some compiler component to that? because we short-circuit that? 12:21
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
could that be it?
lizmat I have no idea, my compiler knowledge doesn't go that deep
and anyways, I'm off for some fresh air :-)
afk for a few hours& 12:23
timotimo i think at least in the case of the sort thingie, we'd benefit from short-circuiting that 12:24
hmm.
i dunno
i feel too tired to figure this out :)
13:13 AlexDaniel joined
jnthn Both && and || compile into QAST if/unless nodes, which in turn are smart enough to do sensible things with natives. 13:22
14:11 RabidGravy joined
masak there's something very right about them compiling to if/unless nodes. 15:07
it also shows Yet Another Difference between QAST and Q.
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.
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. 15:13
masak oh, you wanted compiler simplifications? that will be a tough one to square with having macros, yes :P 16:29
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
jnthn Well, it's possible that having a higher-level AST might make some manipulations easier though 16:50
18:40 colomon joined
masak yes, definitely 19:39
22:07 AlexDaniel joined
dalek kudo/nom: 8437418 | lizmat++ | src/core/Buf.pm:
Disallow Buf/Blobbing with anything but Int

Pointed out by sortiz++		 22:23
lizmat good night, #p6dev 22:27
23:04 colomon joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!