github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 13:20
nwc10 o/ 13:41
brrt . 17:42
AlexDaniel brrt: so what do we do with github.com/MoarVM/MoarVM/pull/1207 ? 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'
dogbert17 looks as if valgrind is still not happy with t/spec/S32-str/encode.t 18:58
timotimo wakelift.de/p/c3f095d6-8827-426f-9...1a230731d/ 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 github.com/rakudo/rakudo/issues/3262 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 github.com/rakudo/rakudo/issues/3268
samcv: otherwise we're pretty close 19:33
samcv: that is, I don't know about any other issue
although…
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
dogbert17 AlexDaniel: M#1208 19:42
synopsebot M#1208 [open]: github.com/MoarVM/MoarVM/issues/1208 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: api.github.com/search/issues?q=is:...el:BLOCKER
so that's the same as github.com/issues?utf8=%E2%9C%93&a...%3ABLOCKER
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:05
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 github.com/rakudo/rakudo/pull/3236 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
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]: github.com/MoarVM/MoarVM/pull/1209 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
oops
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 wrong...but...how 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
vrurg jnthn: fixed. 23:21
jnthn OK, *now* it makes more sense :) 23:23
vrurg NQP, Rakudo, and spectests are passing. 23:26
jnthn Stuck an approve on it, I let CI run. 23:28
vrurg++
vrurg Sure. Thanks jnthn! 23:28
timotimo wakelift.de/2019/10/26/introducing...apshot-ui/ - 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

Powered by Cro and the Raku® Programming Language.

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

Thank you!