| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:02 lucasb left 00:14 Kaiepi left 00:15 Kaiepi joined 00:21 Kaiepi left, Kaiepi joined 04:19 Kaiepi left 04:20 Kaiepi joined 06:35 domidumont joined 06:42 domidumont left 06:44 domidumont joined 06:54 sena_kun joined 09:28 moon_child is now known as elronnd 09:29 elronnd is now known as moon_child 09:55 domidumont left 09:57 zakharyas joined 10:37 zakharyas left 10:41 zakharyas joined 10:54 zakharyas1 joined 10:56 zakharyas left 11:01 brrt joined 11:10 ggoebel joined 11:21 ggoebel left 11:31 zakharyas1 left 11:42 brrt left 11:54 ggoebel joined 12:33 domidumont joined 13:11 brrt joined 13:18 lucasb joined
brrt \o 13:20
13:33 ggoebel left 13:34 brrt left
nwc10 o/ 13:41
14:18 zakharyas joined 14:40 Kaeipi joined 14:42 Kaiepi left 15:15 zakharyas left 15:30 patrickb joined 15:31 domidumont left 16:34 MasterDuke joined 17:07 ggoebel joined 17:31 ggoebel left 17:42 brrt joined
brrt . 17:42
AlexDaniel brrt: so what do we do with ? Just merge it? 18:36
it doesn't pass tests
src\io\asyncsocketudp.c(557) : error C2039: 'async_task' : is not a member of 'SocketSetupInfo'
src\io\asyncsocketudp.c(487) : see declaration of 'SocketSetupInfo'
18:49 ggoebel joined
dogbert17 looks as if valgrind is still not happy with t/spec/S32-str/encode.t 18:58
timotimo pls2review 19:14
jnthn AlexDaniel: If it's that error, it doesn't even compile, let alone pass tests...certainly not to merge in that state. 19:18
AlexDaniel samcv: so that's the current state of things. Waiting for a revert to resolve but the PR reverting things is not complete yet 19:32
samcv: there's also this ticket which sounds pretty bad if it's true, but in my view it's not confirmed yet
samcv: otherwise we're pretty close 19:33
samcv: that is, I don't know about any other issue
dogbert17: that's new, right?
dogbert17: is it the only file with that issue? Is it new? 19:34
dogbert17: can you file a ticket with more info about “not happy”? :)
dogbert17 I think it's a leftover from some recent work by MasterDuke but I could be wrong 19:35
19:36 brrt left
dogbert17 AlexDaniel: M#1208 19:42
synopsebot M#1208 [open]: Valgrind errors when running t/spec/S32-str/encode.t
MasterDuke the valgrind errors i saw went away after my PR was merged, but i can check again 19:49
tellable6 2019-10-23T21:16:51Z #raku-dev <pmurias> MasterDuke nqp::for is not yet implemented, but the optimizer sometimes turns it into things that are
AlexDaniel ohh 19:52
that's how you do multiorg issue queries:
so that's the same as
and there doesn't seem to be a way to do it otherwise, hmm
AlexDaniel plugs that into releasable6 19:53
dogbert17 so, what's a stroopwafel ? 20:00
Geth MoarVM: vrurg++ created pull request #1209:
Fix for run-away CORE context on closures
20:16 sena_kun left, releasable6 left 20:21 greppable6_ joined, greppable6_ left 20:25 releasable6 joined 20:40 Kaeipi left 20:41 Kaeipi joined
japhb dogbert17: At the risk of repeating what you'd find in a search result ... a stroopwafel is a very tasty Dutch waffle wafer cookie with a caramel core designed to melt when you rest the cookie over a hot beverage. 20:43
AlexDaniel japhb: oh… 21:08
I thought you just eat it straight like that
at least that's how I was eating it
:( 21:09
patrickb It might make sense to merge pre release. 21:10
Opinions? 21:11
Wait, wrong channel, sory.
japhb AlexDaniel: I mean, you can. But then you miss the fun part IMO. :-) 21:12
Kaeipi jnthn, what message should that jit function in the openbsd build pr panic with?
AlexDaniel japhb: it sounds like a great idea, I missed a lot of fun over the years :(
japhb No better time to start than now! Or you know, whenever you can get your hands on a resupply. ;-) 21:13
22:48 patrickb left
jnthn Kaeipi: "Linear scan: could not select live range to spill" or some such will be fine 22:52
Kaeipi aight 22:53
jnthn Kaeipi: tbh it's not going to mean that much to most folks reading it, it's mostly to give us a string to grep for in the unlikely event it ever actually happens.
vrurg jnthn: may I ask you to merge M#1209? 23:10
synopsebot M#1209 [open]: Fix run-away CORE context on closures
jnthn I didn't read the code yet, just the nice-looking description... 23:11
Let me have a look and try to understand what it's doing.
vrurg: Hm, it's chekcing `((MVMCode *)static_code)->body.outer == NULL` and if it is, assigning it into f->outer? So the second line could be `MVM_ASSIGN_REF(tc, &(f->header), f->outer, ((MVMCode *)static_code)->body.outer);`? 23:13
Could be `MVM_ASSIGN_REF(tc, &(f->header), f->outer, NULL);`? 23:14
vrurg jnthn: OOPS.... No, it must check on f.
That was too much debug code and inertia of typing. Ok, I would have to re-test everything. 23:15
jnthn I thought that looked did it pass new tests?
vrurg jnthn: thanks for spotting this!
jnthn I was trying to figure out if nulling it triggered autoclose but that made no sense either 'cus that's inovke time... :)
vrurg Because in other case outer_idx is true and it didn't bother trying the other if branch. 23:16
Basically, checking f->outer for NULL is likely to be redundant. But I'm not 100% sure. 23:17
23:17 redable joined 23:19 redable left 23:21 redable joined
vrurg jnthn: fixed. 23:21
jnthn OK, *now* it makes more sense :) 23:23
23:23 redable left
vrurg NQP, Rakudo, and spectests are passing. 23:26
23:27 redable joined
jnthn Stuck an approve on it, I let CI run. 23:28
23:28 redable left
vrurg Sure. Thanks jnthn! 23:28
23:31 redable joined 23:32 redable left 23:33 redable joined, redable left
timotimo - lol i blogged 23:34
vrurg jnthn: I'm probably tired, but the check for static_code outer was almost correct except it had to check if it's outer exists and only then set new context outer to it. 23:38
vrurg is retesting and going to re-commit. :( 23:39
23:47 redable joined