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.
00:07 reportable6 left 00:09 reportable6 joined 00:30 CaCode left 00:56 frost joined 01:19 frost left 01:59 frost joined 02:05 frost left 02:24 frost joined 02:30 frost left 02:43 frost joined 03:12 discord-raku-bot left, discord-raku-bot joined 03:16 frost left 03:21 frost joined 03:41 frost left 03:51 frost joined 03:56 frost left 06:07 reportable6 left 06:19 frost joined 07:10 reportable6 joined 07:38 frost left 07:47 frost joined
Nicholas good *, #moarvm 07:48
07:53 frost left
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
10:13 linkable6 left, evalable6 left 10:16 evalable6 joined 10:27 frost joined 10:32 frost left 10:42 frost joined 10:55 frost left 11:02 frost joined
dogbert17 is the build somehow broken 11:02
dogbert@dogbert-VirtualBox:~/repos/rakudo$ perl Configure.pl --gen-moar --gen-nqp --backends=moar 11:03
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
11:26 frost left
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
11:47 frost joined 11:51 frost left 12:07 reportable6 left 12:14 linkable6 joined
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)
13:07 frost joined
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
13:41 frost left
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
14:10 reportable6 joined
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
14:48 MasterDuke left
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)
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
15:06 MasterDuke joined
MasterDuke m: BEGIN say &infix:<< +> >>.prec<iffy>     # huh, why doesn't this segv? 16:28
camelia (Any)
16:31 kjp left
MasterDuke i guess BEGIN isn't quite the same as happens-in/during-Optimizer.nqp 16:31
16:34 kjp joined
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)
18:04 cognominal joined 18:06 squashable6 left 18:08 reportable6 left 18:10 reportable6 joined 18:24 squashable6 joined 19:07 [Coke]_ joined 19:10 [Coke] left
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
20:52 [Coke]_ left 20:55 [Coke] joined 22:09 cognominal left 22:10 cognominal joined 22:11 cognominal left 23:51 evalable6 left, linkable6 left 23:53 linkable6 joined