[00:02] *** reportable6 left [00:05] *** reportable6 joined [00:52] *** [Coke] left [00:52] *** [Coke] joined [01:32] *** ggoebel__ joined [02:34] *** ggoebel__ left [03:35] *** reportable6 left [03:35] *** coverable6 left [03:35] *** statisfiable6 left [03:35] *** quotable6 left [03:35] *** linkable6 left [03:35] *** shareable6_ left [03:35] *** bisectable6 left [03:35] *** tellable6 left [03:35] *** committable6_ left [03:35] *** benchable6 left [03:35] *** notable6_ left [03:35] *** bloatable6 left [03:35] *** squashable6 left [03:35] *** evalable6 left [03:35] *** greppable6 left [03:35] *** sourceable6 left [03:35] *** releasable6 left [03:35] *** nativecallable6 left [03:35] *** unicodable6 left [03:35] *** shareable6 joined [03:36] *** benchable6 joined [03:37] *** tellable6 joined [03:37] *** bloatable6 joined [03:37] *** quotable6 joined [03:37] *** evalable6 joined [03:37] *** greppable6 joined [03:37] *** sourceable6 joined [03:37] *** unicodable6 joined [03:37] *** nativecallable6 joined [03:37] *** reportable6 joined [04:36] *** notable6 joined [04:37] *** bisectable6 joined [04:37] *** 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 [07:53] does a `git status` in the moarvm repo always show `modified: 3rdparty/ryu (untracked content)` for anybody else? [08:03] *** reportable6 joined [08:17] 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 [08:19] yeah. i tried adding that to moarvm's .gitignore, but that doesn't seem to do anything [08:19] ¦ MoarVM: 634f23b6b5 | (Nicholas Clark)++ | src/spesh/graph.h [08:19] ¦ MoarVM: lit_ui32 in union MVMSpeshOperand should be MVMuint32 [08:19] ¦ MoarVM: [08:19] ¦ MoarVM: Not MVMuint16. Whoops! [08:19] ¦ MoarVM: [08:19] ¦ MoarVM: This thinko doesn't seem to have caused any actual bugs yet. [08:19] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/634f23b6b5 [08:19] Annoyingly that is not the cause of ongoing big endian bad hair day [08:22] wow, sure looks like it could have [08:25] yes. that's the annoyance. It looked plausible [08:40] 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:42] ¦ MoarVM: MasterDuke17++ created pull request #1555: Jit some not so common ops [08:42] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1555 [08:48] *** liltechdude joined [08:53] Hello! Could you provide in documentation page mail address for sending patches? says only about GitHub, but I'm does not have interest with this type of sharing development. [08:57] i don't believe moarvm has its own mailing list, but you could probably use the perl6-compiler list mentioned here https://raku.org/archive/lists/ [09:01] Okay [09:02] 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 [09:03] "not for everyone" -> "not suit for everyone" [09:08] i don't think we have any objection to getting patches via email [09:08] Sure? [09:09] For some this inconvinience so much that they review 1 pathes per week or so [09:12] ¦ MoarVM: 9b6dd5ce94 | (Daniel Green)++ | azure-pipelines.yml [09:12] ¦ MoarVM: Remove ubuntu 16.04 jobs from CI pipeline [09:12] ¦ MoarVM: [09:12] ¦ MoarVM: Per https://github.com/actions/virtual-environments/issues/3287 it's not [09:12] ¦ MoarVM: going to be offered past Oct 18, 2021. [09:12] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9b6dd5ce94 [09:15] 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:22] *** liltechdude left [09:58] 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? [10:05] two CI fails on master (the job that ran after my commit removing ubuntu 16.04) https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=711&view=results [10:05] 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. [10:05] t/02-rakudo/19-mkdir.t (Wstat: 29696 Tests: 0 Failed: 0) [10:05] Non-zero exit status: 116 [10:05] Parse errors: Bad plan. You planned 1 tests but ran 0. [10:05] ^^^ on windows [10:06] t/08-performance/02-qast-rewrites.t (Wstat: 11 Tests: 0 Failed: 0) [10:06] Non-zero wait status: 11 [10:06] Parse errors: No plan found in TAP output [10:06] ^^^ on mac [10:56] 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... [11:08] ¦ MoarVM: MasterDuke17++ created pull request #1556: Simplify cloning NQP and Rakudo repos in CI jobs [11:08] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1556 [11:47] 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." [12:02] *** reportable6 left [12:08] *** sena_kun left [12:41] *** sena_kun joined [13:10] https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=719&view=logs&jobId=2bf6b64d-baac-5f67-4029-4903c2efd584&j=2bf6b64d-baac-5f67-4029-4903c2efd584&t=15869504-03e7-5c45-a33a-274b005545f7 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 [13:11] disp_program_run [13:13] ¦ MoarVM: 76afe93cf0 | (Daniel Green)++ | tools/build/checkout-repos-for-test.pl [13:13] ¦ MoarVM: Simplify cloning NQP and Rakudo repos in CI jobs [13:13] ¦ MoarVM: [13:13] ¦ MoarVM: Since we build them at HEAD we don't need the full history, but we do [13:13] ¦ MoarVM: need enough of it for `git describe` to work. Also do the clone and [13:13] ¦ MoarVM: checkout of 'master' in a single command. [13:13] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/76afe93cf0 [13:13] ¦ MoarVM: dfb5837880 | MasterDuke17++ (committed using GitHub Web editor) | tools/build/checkout-repos-for-test.pl [13:13] ¦ MoarVM: Merge pull request #1556 from MasterDuke17/simplify_cloning_nqp_and_rakudo_repos_in_ci_jobs [13:13] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dfb5837880 [14:01] *** linkable6 left [14:01] *** evalable6 left [14:01] *** linkable6 joined [15:01] *** linkable6 left [15:01] *** committable6 left [15:02] *** evalable6 joined [15:04] *** reportable6 joined [15:55] 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:56] Ah, I see you already noticed that, never mind. [16:01] 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:02] *** linkable6 joined [16:07] 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] 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. [16:08] 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:09] 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:34] i've seen https://github.com/Raku/roast/blob/master/S12-construction/destruction.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 https://github.com/Raku/roast/blob/master/S12-construction/destruction.t#L37 . should that 5s be bumped up? [16:43] MasterDuke: I wouldn't mind having it loop infinitely. At some point a destructor has to be run hasn't it? [16:44] i would think so [16:45] That fudge makes it look like destructors don't work on the jvm though? [16:49] 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:50] We can do that. This probably didn't exist when the test was written [18:02] *** reportable6 left [18:15] hmm, t/02-rakudo/15-gh_1202.t failed with whats seems to be a hidden SEGV [18:16] #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 [18:16] 2933 if (STABLE(val.o) != (MVMSTable *)dp->gc_constants[op.arg_guard.checkee]) [18:35] you caught it, nice. i've been trying for a while with no success [18:39] was lucky I guess :) [18:39] (gdb) p val [18:39] $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} [18:41] (gdb) f 1 [18:41] #1 0x00007f73a8fbcc0f in dispatch_polymorphic (tc=0x7f73940fc0f0, entry_ptr=0x55b8b00253e8, seen=0x55b8b0c06868, id=0x55b8afa1c0b0, callsite=0x55b8ad89c7c0, arg_indices=0x7f73a5895286, [18:41] source=0x7f738009d0d0, sf=0x55b8afa17610, bytecode_offset=200) at src/disp/inline_cache.c:178 [18:41] 178 MVMROOT2(tc, id, sf, { [19:03] *** reportable6 joined [19:04] *** committable6 joined [20:52] *** colemanx joined [21:54] ok, so this is interesting [21:55] https://github.com/MoarVM/MoarVM/pull/1555/commits/b8e230ea8e74d4081c3381cc10a64cd63077c87b definitely seems to cause problems on windows. https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=728&view=logs&j=1bbd921f-2da8-56be-a1c6-2e0444a912f9&t=137db432-0269-555c-46e5-ce1dbf500efa [21:55] but i have no idea why, the commit looks correct [21:55] can somebody give it a second pair of eyes? [22:14] <[Coke]> let me know if/when I should try a windows builda again. [23:16] <[Coke]> .seen rjbs [23:16] [Coke], I saw rjbs 2021-06-21T17:44:15Z in #raku: XS is definitely a big ball and chain. [23:29] *** evalable6 left [23:29] *** linkable6 left [23:31] *** linkable6 joined [23:33] *** ggoebel__ joined [23:36] *** WQy joined [23:38] *** WQy left [23:48] <[Coke]> https://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?