Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good *, #moarvm 07:48
nine Good IRC! 07:55
Geth MoarVM/master: 7 commits pushed by (Stefan Seifert)++, niner++ 08:05
Nicholas I slack. I can't think of any uint puns. 08:11
and (as foretold) github has disabled git:// support, and at least one thing I was running still got caught out because the previous brownouts didn't spot it 08:15
(a private thing. I wasn't actively seeking them out to fix)
timo uint me both, buddy 08:27
nine Nicholas: Truth is, you'll probably not recover the time spent on shallow clones. But the time saved for all users and CI runs and disk space saved will be worth a whole lot! 08:38
Nicholas yes, this I agree with 08:39
I wasn't sure how much it would affect CI runs (cumulatively) but I didn't see it hurting...
even if Azure pipelines are in the same rack as github servers, and connected with ∞Base-T 08:41
dogbert17 is the build somehow broken 11:02
dogbert@dogbert-VirtualBox:~/repos/rakudo$ perl Configure.pl --gen-moar --gen-nqp --backends=moar 11:03
===ATTENTION===
No --prefix supplied, building and installing to /home/dogbert/repos/rakudo/install
Segmentation fault (core dumped)
or do I need to update nqp as well? 11:04
nine You may need to
dogbert17 ok 11:11
dogbert17 runs away to get a booster shot 11:35
Nicholas odd co-incidence. I had one 2 hours ago 11:38
no, wait, 1 hour ago
MasterDuke interesting. that segfault exposed by that warning only happens when the code that triggers it runs in the optimizer 12:50
m: say &infix:<< +> >>.prec<iffy>   # doesn't die 12:51
camelia (Any)
dogbert17 nine: updating nqp worked. There's only one spectest failure, in t/spec/S32-io/IO-Socket-Async.t, which I haven't seen before 13:29
ok 22 - server's peer-port seems right 13:30
Unhandled exception in code scheduled on thread 4
address already in use
MasterDuke spectest all clear for me 13:44
dogbert17 and now it's clear for me too. I actually had a program running which used the address in question, oops 13:47
MasterDuke jnthnwrthngtn: you commented on stackoverflow.com/questions/705256...ositionals and i think i've asked before about this and you said rakuast should eventually enable a speculated feature for exactly that case (needing multiple multis for handling every combination of position of parameters based 14:24
on type, when you really don't care about position and just want to do something with whatever parameter is of a certain type)
jnthnwrthngtn Should be possible 14:32
Geth MoarVM: d783bf2717 | (Stefan Seifert)++ | src/spesh/disp.c
Fix speshed native calls with rw args assigning into wrong target

For rw args of native calls we emit appropriate assign_i instructions after the call to write back the native values from the argument registers to the NativeRef. However the register holding the NativeRef will already have been released at the callsite (as for non-speshed calls writing back is handled by MVM_nativecall_dispatch). If one of the ... (9 more lines)
15:01
MoarVM: a75aacc642 | niner++ (committed using GitHub Web editor) | src/spesh/disp.c
Merge pull request #1627 from MoarVM/fix_rw_native_calls

Fix speshed native calls with rw args assigning into wrong target
MasterDuke m: BEGIN say &infix:<< +> >>.prec<iffy>     # huh, why doesn't this segv? 16:28
camelia (Any)
MasterDuke i guess BEGIN isn't quite the same as happens-in/during-Optimizer.nqp 16:31
MasterDuke so right here github.com/rakudo/rakudo/blob/mast....nqp#L2745 `$obj.prec` is a P6opaque instead of a VMHash 16:49
then we call P6opque's at_key and it segfaults here github.com/MoarVM/MoarVM/blob/mast...ue.c#L1469 because `del`is 0x0 16:52
so obviously rakudo shouldn't segfault in this situation 16:58
but i'm not sure if there's insufficient checking happening in P6opaque's at_key (same thing happens if i put an explicit nqp::existskey first, it just segfaults there instead)?
or did something prior incorrectly change a VMHash into a P6opaque? 16:59
m: BEGIN say &infix:<< +> >>.prec.WHAT 17:05
camelia (Hash) 17:06
MasterDuke m: BEGIN say &infix:<< eq >>.prec.WHAT 17:07
camelia (Hash)
Geth MoarVM: 677d1fd6c8 | (Nicholas Clark)++ | 2 files
Run `git submodule --quiet update --depth 1` if git is new enough.

This reduces .git by about 32M at little cost, as most folks aren't looking at submodule history. If you need the history, it's easy to get back with:
git submodule foreach git fetch --unshallow
19:40