jnthn Time for some rest... o/ 00:01
timotimo o/
00:05 lizmat joined
timotimo hm 00:05
am i supposed to uv_udp_recv_stop after receiving a datagram? 00:06
for the synchronous case, that is
nwc10 good *, not-#jvm 08:03
diakopter heh 08:08
08:13 zakharyas joined 08:14 kjs_ joined 08:29 rurban joined 08:57 Ven joined 09:06 Ven joined 09:14 brrt joined
brrt \o 09:20
09:30 kjs_ joined 09:55 FROGGS joined 10:58 kjs_ joined 11:13 kjs_ joined 11:54 kjs_ joined 12:21 kjs_ joined 12:24 oetiker joined
dalek arVM: 325d551 | jnthn++ | src/jit/graph.c:
Basic JIT of iscont_[ins].
 12:42
12:43 Ven joined 12:46 oetiker joined 12:52 oetiker joined
jnthn That patch was while I had lunch... Also discovered that native ++/-- ops aren't getting inlined yet. 13:04
Not immediately sure why. Something to investigate later :) 13:05
timotimo that could be why most of the native loop benchmarks aren't better on native_ref than before 13:16
jnthn Oh, I didn't expect them to be *better* 13:21
I was mostly worried about not regressing
native-ref wasn't about performance improvement, it was about being able to use native things in l-value contexts
It does mean people can write more performant code without it being annoying, though :) 13:22
timotimo well, they are a bit worse, not just "not better" 13:23
jnthn Do you have an updated set post-merge? 13:30
I musta missed them...
timotimo yes, gimme a minute 13:31
t.h8.lv/p6bench/2015-03-02-pre_post...veref.html
IIRC blue is post-merge 13:32
jnthn Yeah, the dates of the commits suggest so 13:33
heh, while_int2str_native got a lot faster
timotimo got an idea why? 13:34
because we have $s = ... ?
jnthn No, 'cus I added a couple of extra mutli candidates :) 13:35
timotimo oh
fair enough :)
jnthn We still didn't recover all the lexical => local opts we used to be able to do 13:36
timotimo ah
jnthn So that probably accounts for a good number of the minor slowdowns
timotimo that sounds reasonable, yeah 13:38
what new qast stuff would the optimizer need to understand here?
jnthn Well, at the moment we don't have any support for localref 13:41
We can't really do that at all on JVM. We can on Moar though
So the plan is something like, get register refs working fully on Moar. Then implement QAST -> MAST support for them. 13:42
timotimo OK
timotimo watches fosdem talks
jnthn Then put something on the HLL::Backend object for "does this backend support localref scope"
13:42 kjs_ joined
jnthn Then update Perl6::Optimizer to use it when it can 13:42
timotimo jnthn: where do all the pretty pictures come from that you put in the background of your slides? did you buy a life-long subscription to a stock photo service for those that you didn't take? 13:58
hm. how do grammar.
"for those pictures you didn't take yourself" doesn't sound right enough, either
jnthn timotimo: Believe it or not, many of them are from the PowerPoint gallery, with effects applied to make them non-annoying as background images. :) 14:04
timotimo oh?
didn't know about that, sounds nice to have :)
jnthn It's some work 14:05
For now, I kinda like the look
timotimo i like the look, too
jnthn Just have to be very careful not to make the slide content hard to read.
timotimo yes, very 14:06
i don't think you've failed a single time so far; at least in the slides i've seen
jnthn Good to hear. :)
timotimo in the "static" vs "dynamic" slide, the sort of dark purple-ish color you used for static didn't stand out from the black it was before, though 14:07
especially given video compression
with the "4:2:0" chroma or what it's called
jnthn Yeah...those things are tricky
timotimo no, wait ... am i even talking about the right thing?
i just recall that anything sort of pink comes out really, really smushy in h264 and friends 14:08
jnthn What looks right on my desktop screen != what looks right on my laptop screen != what will look good on a projector != what will look good on a different projector :)
The latter two are the really "fun" ones 14:09
timotimo yes ;(
jnthn When I do Git teaching I do a lot of time demonstrating stuff. Sometimes a black console background comes out better, other times a white one comes out way better, so the first task of the day, after finding where to get coffee at wherever I happen to be teaching, is working out which one is gonna be better with the projector in the room I've got :) 14:10
timotimo was the "Ah-a!" moment thing on purpose? because so far i've only seen it spelled "aha!" or "a-ha!" :)
jnthn uh, no, that sounds not every on purpose :) 14:11
A-ha is a Norwegian rock band too :)
14:19 brrt joined
timotimo oh look 14:25
in the "use is lexical" example you have
"nok now, 0, 'time is nonzero'"
i think the "0, " is superfluous
not terrible, as it was meant to fail anyway 14:26
jnthn uh, yes 14:28
I guess I wanted a nis :P
timotimo nproblem 14:29
you remember how i fumbled around with making nqp::time_n() - 0.5e0 inline the native - candidate? 14:37
i wasn't able to fix this yet (annotating things in the optimizer with .returns(int) or .returns(find sybmbol "int") gave me either a compilation failure or no change 14:38
maybe this is what you've noticed when you said "Also discovered that native ++/-- ops aren't getting inlined yet"?
jnthn uh, you want .returns(num) for those, no? 14:42
timotimo er, yes 14:45
i had one for int and one for num
checking for names ending in _i or _n
nwc10 jnthn: surely "first task of the day after" is "second task of the day". Unless "find coffee" is axomiatically "task zero" 14:48
jnthn It's kinda a pre-req for doing tasks... :P
nwc10 I found a new variant of the coffee bootstrapping problem this afternoon 14:49
need to remeber to stop the (manual) expresso machine filling the cup
this is *easier* after you have had the coffee 14:50
14:56 viyyozio joined 15:00 dalek joined
jnthn nwc10: Is the failure mode "flood" or "way too much expresson"? 15:01
jnthn caused a coffee flood at the office one
*once
nwc10 flood. well, firstly overflow the cup into the drip tray 15:04
as the coffee machine is manually filled from the tap, the size of the potential coffee slick is bounded
jnthn Thankfully, it was bounded in my case too :) 15:07
The amount of time people remember said incident seems unbounded so far, alas... :P
nwc10 I'm sure that there are worse things one can get remembered for 15:08
15:27 harrow joined
timotimo oh, i just remembered 16:51
under the shower i had a thought
do we ever actually use branching to give us more information?
like "on one branch from an isconcrete + if we'll have a concrete, on the other we have an inconcrete value"? 16:52
(i suppose a few of these things would be caught just by logging register contents, though)
(and also: how do we represent this? should we give the "same" register on both sides of a branch different versions, even though there is not necessarily a PHI node?) 17:02
jnthn I suspect trace JIT can handle this better :) 17:03
17:19 kjs_ joined
jnthn If we wanted to do it under the current model you could insert a r1(unique_new_version) = PHI(r1(checked_version)), and extend the facts... 17:24
But you'd have to update the things reachable in the branch to talk about the new version.
timotimo the ifs and branches are clear early enough to do this before the whole thing, no? 17:29
jnthn Oh, you mean do it during the initial SSA tran? 17:32
timotimo yes
jnthn Hmmmm
timotimo afterwards the fact discovery can do the rest, i thought
jnthn Mebbe :)
timotimo the fact discovery happens after the dominator tree has been built, so that's very good 17:33
in a first step i'd only dare build these extra facts based off of branching when there's only a single predecessor
18:06 brrt joined 18:15 rurban joined 19:11 FROGGS joined 20:07 dalek joined 20:14 kjs_ joined 21:23 donaldh joined 21:33 colomon joined 21:36 colomon joined
dalek arVM: f370a5c | jnthn++ | src/core/nativecall.c:
Args must be rooted during entire native callback.
 21:46
22:34 colomon joined
dalek arVM: dbb83b2 | (sue spence)++ | src/6model/serialization.c:
Silence op precedence warning.
 23:42
arVM: 95ff54f | jnthn++ | src/6model/serialization.c:
Merge pull request #179 from virtualsue/master

Silence op precedence warning on clang

Powered by Cro and the Raku® Programming Language.

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

Thank you!