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:02 reportable6 left 00:05 reportable6 joined 00:52 [Coke] left, [Coke] joined 01:32 ggoebel__ joined 02:34 ggoebel__ left 03:35 reportable6 left, coverable6 left, statisfiable6 left, quotable6 left, linkable6 left, shareable6_ left, bisectable6 left, tellable6 left, committable6_ left, benchable6 left, notable6_ left, bloatable6 left, squashable6 left, evalable6 left, greppable6 left, sourceable6 left, releasable6 left, nativecallable6 left, unicodable6 left, shareable6 joined 03:36 benchable6 joined 03:37 tellable6 joined, bloatable6 joined, quotable6 joined, evalable6 joined, greppable6 joined, sourceable6 joined, unicodable6 joined, nativecallable6 joined, reportable6 joined 04:36 notable6 joined 04:37 bisectable6 joined, squashable6 joined 04:38 linkable6 joined 05:36 committable6 joined 05:37 statisfiable6 joined 05:38 releasable6 joined 06:02 reportable6 left 06:36 coverable6 joined 06:38 CIAvash joined 06:47 CIAvash left
MasterDuke does a `git status` in the moarvm repo always show `modified: 3rdparty/ryu (untracked content)` for anybody else? 07:53
08:03 reportable6 joined
Nicholas I see this too. We've cloned their repository and they don't have .gitignore set up to ignore (most) things 08:17
such as 3rdparty/ryu/ryu/d2s.o
MasterDuke yeah. i tried adding that to moarvm's .gitignore, but that doesn't seem to do anything 08:19
Geth MoarVM: 634f23b6b5 | (Nicholas Clark)++ | src/spesh/graph.h
lit_ui32 in union MVMSpeshOperand should be MVMuint32

Not MVMuint16. Whoops!
This thinko doesn't seem to have caused any actual bugs yet.
Nicholas Annoyingly that is not the cause of ongoing big endian bad hair day
MasterDuke wow, sure looks like it could have 08:22
Nicholas yes. that's the annoyance. It looked plausible 08:25
MasterDuke arg, now an error in the nqp build, with two ops reverted? ok, maybe [Coke] was right and i'll just create a new PR and cherry pick in commits from the other one at a time 08:40
Geth MoarVM: MasterDuke17++ created pull request #1555:
Jit some not so common ops		 08:42
08:48 liltechdude joined
liltechdude Hello! Could you provide in documentation page mail address for sending patches? <github.com/MoarVM/MoarVM> says only about GitHub, but I'm does not have interest with this type of sharing development. 08:53
MasterDuke i don't believe moarvm has its own mailing list, but you could probably use the perl6-compiler list mentioned here raku.org/archive/lists/ 08:57
liltechdude Okay 09:01
Honestly, if you think about it, it's a bad idea to use different sources of development, so you probably have to use a github, but at least you are aware that this is not for everyone. 09:02
sorry, "you" -> "me". Sorry for my poor english
"not for everyone" -> "not suit for everyone" 09:03
MasterDuke i don't think we have any objection to getting patches via email 09:08
liltechdude Sure?
For some this inconvinience so much that they review 1 pathes per week or so 09:09
Geth MoarVM: 9b6dd5ce94 | (Daniel Green)++ | azure-pipelines.yml
Remove ubuntu 16.04 jobs from CI pipeline

Per github.com/actions/virtual-environ...ssues/3287 it's not going to be offered past Oct 18, 2021.		 09:12
MasterDuke yeah, i can't really offer any guarantees on how quickly anything (emails, PRs on github, etc) will be reviewed, but questions on that mailing list do get answered, so i wouldn't hesitate to try that route if you don't want to use github 09:15
09:22 liltechdude left
nine jnthnwrthngtn: sounds great! So in the perfect case native calls would turn iut to be a single op. What I don't know yet is how we'd enter that dispatcher. Would the standard call dispatchers have to check for a flag and delegate? Or is there another way? 09:58
MasterDuke two CI fails on master (the job that ran after my commit removing ubuntu 16.04) dev.azure.com/MoarVM/MoarVM/_build...ew=results 10:05
nine jnthwrthngton: same question is open for Inline::Perl5: is there a way to hook into dispatch? Because all the marshalling and unmarshalling it does really mirrors NativeCall at one level higher.
MasterDuke t/02-rakudo/19-mkdir.t (Wstat: 29696 Tests: 0 Failed: 0)
Non-zero exit status: 116
Parse errors: Bad plan. You planned 1 tests but ran 0.
^^^ on windows
t/08-performance/02-qast-rewrites.t (Wstat: 11 Tests: 0 Failed: 0) 10:06
Non-zero wait status: 11
Parse errors: No plan found in TAP output
^^^ on mac
if i'm reading these scripts correctly, the MoarVM CI jobs do a full clone of nqp and rakudo, and then build them at their HEAD. so we could instead just clone them with `--depth 1` and that should be a lot quicker 10:56
let me PR that change...
Geth MoarVM: MasterDuke17++ created pull request #1556:
Simplify cloning NQP and Rakudo repos in CI jobs		 11:08
MasterDuke huh. everything builds ok, and the 'checkout repositories' stage went from 23s down to 3s, but during the nqp and rakudo builds there are complaints about "no names found, can't describe anything" and "Use of uninitialized value $VERSION in scalar chomp at /home/vsts/work/1/nqp/tools/build/gen-version.pl line 31." 11:47
12:02 reportable6 left 12:08 sena_kun left 12:41 sena_kun joined
MasterDuke dev.azure.com/MoarVM/MoarVM/_build...4b005545f7 segv in t/02-rakudo/15-gh_1202.t 13:10
it's on my branch, but i don't think it's caused by any of my changes
disp_program_run 13:11
Geth MoarVM: 76afe93cf0 | (Daniel Green)++ | tools/build/checkout-repos-for-test.pl
Simplify cloning NQP and Rakudo repos in CI jobs

Since we build them at HEAD we don't need the full history, but we do need enough of it for `git describe` to work. Also do the clone and checkout of 'master' in a single command.		 13:13
MoarVM: dfb5837880 | MasterDuke17++ (committed using GitHub Web editor) | tools/build/checkout-repos-for-test.pl
Merge pull request #1556 from MasterDuke17/simplify_cloning_nqp_and_rakudo_repos_in_ci_jobs
14:01 linkable6 left, evalable6 left, linkable6 joined 15:01 linkable6 left, committable6 left 15:02 evalable6 joined 15:04 reportable6 joined
japhb MasterDuke: `git describe` (used to determine build version numbers) wants to reference a previous tag commit and determine how many commits since that tag. So not super surprised it's broken with a depth 1 shallow clone. 15:55
Ah, I see you already noticed that, never mind. 15:56
MasterDuke yeah. i thought 50 would be enough, but it wasn't, so 250 seems to work ok. easy to change it in the future if it becomes a problem again 16:01
16:02 linkable6 joined
MasterDuke just got an `MoarVM panic: Internal error: invalid thread ID 292 in GC work pass` in t/04-nativecall/08-callbacks.t in one of the runs on my pr 16:07
japhb There's a part of me that's concerned with possible false negatives from that CI in the future, but I can see that such a massive difference in CI cycle time may be worth that risk.
MasterDuke again, pretty sure it's not actually a problem with my commit (so far), but i think there's at least one existing problem that i'm just hitting because of the number of ci runs i've been generating 16:08
well, with a depth of 1 everything passed, there was a failure to build across the board with 50. so i think if it fails in the future it'll be loudly and obvious why 16:09
i've seen github.com/Raku/roast/blob/master/...tion.t#L49 fail a couple times, but it might just be a timing/load thing, since it looks like it need something to happen in 5s github.com/Raku/roast/blob/master/...tion.t#L37 . should that 5s be bumped up? 16:34
nine MasterDuke: I wouldn't mind having it loop infinitely. At some point a destructor has to be run hasn't it? 16:43
MasterDuke i would think so 16:44
nine That fudge makes it look like destructors don't work on the jvm though? 16:45
MasterDuke guess so, we'd have to skip the loop on the jvm then. btw, the comment says "try to force some GC here". why don't we just/also stick in some `$*VM.request-garbage-collection` calls? 16:49
nine We can do that. This probably didn't exist when the test was written 16:50
18:02 reportable6 left
dogbert17 hmm, t/02-rakudo/15-gh_1202.t failed with whats seems to be a hidden SEGV 18:15
#0 0x00007fc2097e58e4 in MVM_disp_program_run (tc=tc@entry=0x7fc1f01c6fb0, dp=0x55e977d11770, record=record@entry=0x7fc1e0063870, spesh_cid=spesh_cid@entry=0, bytecode_offset=bytecode_offset@entry=200, 18:16
dp_index=dp_index@entry=3) at src/disp/program.c:2933
2933 if (STABLE(val.o) != (MVMSTable *)dp->gc_constants[op.arg_guard.checkee])
MasterDuke you caught it, nice. i've been trying for a while with no success 18:35
dogbert17 was lucky I guess :) 18:39
(gdb) p val
$3 = {o = 0x0, s = 0x0, i8 = 0 '\000', u8 = 0 '\000', i16 = 0, u16 = 0, i32 = 0, u32 = 0, i64 = 0, u64 = 0, n32 = 0, n64 = 0}
(gdb) f 1 18:41
#1 0x00007f73a8fbcc0f in dispatch_polymorphic (tc=0x7f73940fc0f0, entry_ptr=0x55b8b00253e8, seen=0x55b8b0c06868, id=0x55b8afa1c0b0, callsite=0x55b8ad89c7c0, arg_indices=0x7f73a5895286,
source=0x7f738009d0d0, sf=0x55b8afa17610, bytecode_offset=200) at src/disp/inline_cache.c:178
178 MVMROOT2(tc, id, sf, {
19:03 reportable6 joined 19:04 committable6 joined 20:52 colemanx joined
MasterDuke ok, so this is interesting 21:54
github.com/MoarVM/MoarVM/pull/1555...d63077c87b definitely seems to cause problems on windows. dev.azure.com/MoarVM/MoarVM/_build...1dbf500efa 21:55
but i have no idea why, the commit looks correct
can somebody give it a second pair of eyes?
[Coke] let me know if/when I should try a windows builda again. 22:14
.seen rjbs 23:16
tellable6 [Coke], I saw rjbs 2021-06-21T17:44:15Z in #raku: <rjbs> XS is definitely a big ball and chain.
23:29 evalable6 left, linkable6 left 23:31 linkable6 joined 23:33 ggoebel__ joined 23:36 WQy joined 23:38 WQy left
[Coke] github.com/rakudo/rakudo/issues/1540 - the code snippet for me doesn't compile, and timo says it's fixed in 2018. Can we close it? 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!