00:22 hungrydonkey joined 00:31 patrickz joined 00:34 patrickb left 00:39 Xliff left 00:42 patrickz left 01:34 sena_kun joined 01:36 Altai-man_ left 01:59 entonian joined 02:14 ufobat__ joined 02:18 ufobat_ left 03:04 cognomin_ joined 03:07 cognominal left 03:33 Altai-man_ joined 03:36 sena_kun left 03:57 hungryd88 joined 04:00 hungrydonkey left 04:56 MasterDuke left 05:34 sena_kun joined 05:36 Altai-man_ left 07:25 hungryd88 left 07:33 Altai-man_ joined 07:36 sena_kun left 07:45 hungrydonkey joined 08:09 hungryd95 joined 08:12 hungrydonkey left 08:14 hungrydonkey joined 08:15 hungryd95 left 08:34 hungryd26 joined 08:38 hungrydonkey left 09:10 hungrydonkey joined 09:13 hungryd26 left 09:34 sena_kun joined 09:36 Altai-man_ left 09:39 hungryd98 joined 09:40 hungrydonkey left
lizmat vrurg: I have a patch that replaces Dummy with something more indicative 09:57
11:00 MasterDuke joined 11:03 dumarchie joined
dumarchie Can someone merge github.com/rakudo/rakudo/pull/3502 if there are no objections against the changes? 11:05
I don't have the permissions to do it myself.
MasterDuke dumarchie: i think we're waiting to merge a bunch of stuff until after the release (which is likely to be today or so) 11:12
dumarchie Okay, I understand. But I don't understand why github.com/rakudo/rakudo/issues/3459 is not considered a blocker. 11:13
A colleague of mine could replicate the issue on his wife's Windows laptop. 11:14
I suspect it's a MoarVM issue, maybe compiler-dependent. 11:16
MasterDuke hm. same problem with older versions of rakudo? 11:17
dumarchie Not in latest Rakudo Star version 2019.03.1 11:18
MasterDuke oh, or can you try rebuilding moarvm with a different compiler? e.g., `perl Configure.pl --cc=clang && make install` 11:19
dumarchie I will try to install clang 11:21
MasterDuke i've gotten a little confused following the issue. now you think it's not a DateTime problem, but multi-dispatch on native nums?
can you create a small test case? 11:22
sena_kun, lizmat: ^^^ 11:23
dumarchie The first call to `DateTime.now` in t\spec\S32-temporal\DateTime.t reliably triggers a crash on Windows 10 with MoarVM compiled with `gcc`. 11:27
sena_kun ouch 11:29
tellable6 2020-02-21T23:31:49Z #raku-dev <lizmat> sena_kun suggest you cherry pick github.com/rakudo/rakudo/commit/21aa02ba0d into the release
lizmat dumarchie: I think there's a release branch already made, so merging now would not put it in the release, and I would be against cherrypicking that 11:30
MasterDuke dumarchie: what kind of crash? can you run it in gdb and get a backtrace?
sena_kun dumarchie, what about full build? as in, can you build and then if you DateTime.now in repl, would that crash?
1)the release is not built yet, so we can put a blocker last minute (now); 2)I don't have any issues with merging new features, we have a stable commit to release from + I'll cherry-pick a couple of fixes; 11:31
lizmat dumarchie: what doe 'use nqp; dd nqp::time_n' say ?
Geth rakudo: 8ccfa87e22 | (Peter du Marchie van Voorthuysen)++ | src/core.c/Sequence.pm6
Make Seq.list return the cached list if it exists

This is more efficient than returning a new List. It is also more consistent with List.list.		 11:32
dumarchie The problem is that DateTime.now only crashes if called at that specific point in the spectest.
rakudo: d1d931a7bf | (Peter du Marchie van Voorthuysen)++ | src/core.c/Sequence.pm6
Base .List and .Slip on .list

This is more efficient as .list may return a cached list.
rakudo: 65cc0a8b68 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Sequence.pm6
Merge pull request #3502 from dumarchie/Seq.list

Make listing and coercion of sequences more efficient
dumarchie lizmat++ 11:33
11:33 Altai-man_ joined
dumarchie c:\raku\rakudo\install\bin>perl6-m -e "use nqp; dd nqp::time_n" 11:35
1582371291.8625455e0
lizmat ok, so it is not with nqp::time_n per se
dumarchie: can you gist the exact output of: perl6-m --ll-exception -e 'DateTime.now' 11:36
11:36 sena_kun left
dumarchie MasterDuke, `perl Configure.pl --cc=clang` doesn't work for me. 11:37
It can't find stdlib.h
I don't mind running the spectest in the debugger, but I have absolutely no experience with that so you'll have to guide me. 11:38
I do appear to have a working gdb 11:39
MasterDuke same problem with `--compiler=clang`?
getting the entire spectest to run in gdb won't be easy, and might not be all that helpful anyway 11:40
dumarchie How do I get out of the gdb shell?
MasterDuke q
but frequently problems show up under load
dumarchie Thanks :)
MasterDuke if you have a spectest running at the same time, does DateTime.now by itself ever crash? 11:41
lizmat I think dumarchie said that it did
ah, maybe not 11:42
dumarchie DateTime.now crashes in t\spec\S32-temporal\DateTime.t, both if I ran it standalone and when I run `gmake spectest`. 11:43
Other `num` related tests only crash as part of `gmake spectest` 11:44
`perl Configure.pl --compiler=clang` also complains about not being able to find stdlib.h 11:45
I'll restart Windows to see if that makes the paths available. Back in a minute. 11:46
lizmat dumarchie++
11:46 dumarchie left
[Tux] Rakudo version 2020.01-256-g65cc0a8b6 - MoarVM version 2020.01.1-45-g926349cde
csv-ip5xs0.757 - 0.770
csv-ip5xs-205.814 - 6.313
csv-parser23.286 - 23.499
csv-test-xs-200.357 - 0.361
test7.341 - 7.393
test-t1.835 - 1.835
test-t --race0.805 - 0.877
test-t-2030.927 - 31.605
test-t-20 --race9.138 - 10.318
 11:47
11:48 dumarchie joined
lizmat fwiw, have run the S32-temporal/DateTime.t 100x, no fail whatsoever 11:49
dumarchie That's on Linux/Mac I suppose? 11:50
lizmat Mac yes
dumarchie Yeah, I think it's really a Windows floating point issue.
lizmat thought I'd run the test in a loop, just in case it was some timing issue that was more likely to show up on Win
dumarchie I actually tried different compilation options for MoarVM. 11:51
`CFLAGS=-mstackrealign` did not make a difference.
MasterDuke what i'd suggest now is running it under gdb and seeing if you can get a backtrace 11:52
dumarchie Neither did options `--no-optimize` and `--no-jit`
MasterDuke i.e., something like `gdb --args ./perl6-m -I lib t\spec\S32-temporal\DateTime.t`
then when gdb starts, `run` in the shell to start the perl6 process. then if/when it crashes, `bt` to get a backtrace 11:53
lizmat dumarchie: if you change the "nqp::time_n" in DateTime.now to just "now", could you see if that makes a difference ? 11:54
MasterDuke oh, but you should build MoarVM with `--debug=3`
dumarchie Well, I got something already: 11:55
Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000069bc3cd6 in MVM_args_get_required_pos_num () from c:\raku\rakudo\install\bin\moar.dll
lizmat yeah, so it looks like a dispatch issue... 11:56
well, argument binding
dumarchie: could you try the s/nqp::time_n/now/ change in DateTime.now ?
dumarchie That will require a lengthy rebuild. I already determined that boxing time_n avoids the crash. 11:58
lizmat ok, so what is the patch that you used for that ?
dumarchie github.com/rakudo/rakudo/pull/3463 11:59
Masterduke: (gdb) bt 12:00
#0 0x0000000069bc3cd6 in MVM_args_get_required_pos_num () from c:\raku\rakudo\install\bin\moar.dll
#1 0x000000000ffe34f5 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
So maybe this is a stack alignment issue? 12:01
Windows 4-byte alignment versus floating point 16-byte alignment or something like that? 12:02
Geth rakudo: 65ef7db198 | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6
Temporary fix for R#3459

So we have a whole release to find out what the exact source of the problem is on Windows.
linkable6 R#3459 [open]: github.com/rakudo/rakudo/issues/3459 [BLOCKER] Issue with native num on Windows
lizmat Altai-man_ ^^ suggest cherry-picking that, so we fix the 2020.02 release 12:03
and work on what is going on without the pressure of a release
Altai-man_ lizmat, can't disagree. Thanks.
dumarchie It only fixes the DateTime.now issue. Other num-related tests still fail under the stress of `gmake spectest`. 12:04
lizmat dumarchie: ah.. :-( which ones ?
dumarchie t\spec\S02-types\num.rakudo.moar quite reliably fails when run as part of `gmake spectest` 12:05
...but not when run standalone 12:06
lizmat any idea which test fail / where it crashes ?
MasterDuke dumarchie: did you rebuild moarvm with --debug=3?
dumarchie No, I will do that now. 12:07
MasterDuke dumarchie: and does t\spec\S02-types\num.rakudo.moar fail when run byitself if there's a spectest running in the background (to create load)
dumarchie I can try that after rebuilding MoarVM 12:08
MasterDuke and i don't know anything about stack alignments, etc. might need to get jnthn, timotimo, nine, brrt to help out
dumarchie With --debug=3 the output of `bt` does not change. 12:16
I ran t\spec\S02-types\num.rakudo.moar a number of times by itself while running `gmake spectest`. 12:21
By itself it never failed, but it did fail in `gmake spectest`. 12:22
MasterDuke hm, no line numbers in the backtrace now? 12:25
dumarchie No line numbers 12:28
MasterDuke huh
afk for a bit &
12:36 Ven`` joined
dumarchie In interp.c, OP(captureposarg_n), what's the point of `.arg.n64`? 12:50
It does not have an equivalent in OP(captureposarg_i) or OP(captureposarg_s) 12:51
lizmat jnthn nine timo brrt ^^ 12:57
MasterDuke dumarchie: interesting...does removing it change anything for you?
dumarchie I can try 13:01
MasterDuke oh, and what about disabling the jit when running? e.g., `MVM_JIT_DISABLE=1 gmake m-spectest` 13:03
nine Just removing it will only give you a compiler error
But....it's unnecesary for sure. Give me a sec
dumarchie compiling src\core\interp.o 13:05
nine dumarchie: please try with this patch applied: gist.github.com/niner/be4b8b5b77fd...e9bc413137
MasterDuke nine: heh, was just looking at that exact same code
nine Looks like someone went through all the trouble to split off MVM_args_get_required_pos_num from MVM_args_get_pos_num but forgot to actually cash in on the benefits :) 13:07
dumarchie Even with both `.arg.n64` instances removed compilation fails.
src\core\interp.c: In function 'MVM_interp_run': 13:08
src\core\interp.c:1079:40: error: incompatible types when assigning to type 'MVMnum64' {aka 'double'} from type 'MVMArgInfo' {aka 'struct MVMArgInfo'}
nine dumarchie: please try my patch
dumarchie GET_REG(cur_op, 0).n64 = MVM_args_get_required_pos_num(tc, &tc->cur_frame->params, 13:09
MasterDuke nine: looks like i'm the guilty one
dumarchie ^
nine dumarchie: please try my patch. 13:10
gist.github.com/niner/be4b8b5b77fd...e9bc413137
MasterDuke dumarchie: yeah, you can't just remove if from interp.c, but it can moved into MVM_args_get_required_pos_num, and it's return type changed (i.e., what nine++'s patch does)
nine: github.com/MoarVM/MoarVM/commit/e5...5596e57397 whoops, didn't follow the example in github.com/MoarVM/MoarVM/commit/e4...1c71b420cb closely enough 13:11
nine MasterDuke: this also means that the JIT implementation does not match the one in interp.c. And how structs are returned is platform dependend, which would perfectly explain why it only breaks on Windows 13:12
MasterDuke nine: makes sense, but why does it only show up now? 13:13
nine Because we have sooo many Windows users? :)
Though --no-jit reportedly didn't make a difference... 13:16
dumarchie It didn't.
Compiling now.
13:18 Kaiepi left
dumarchie B.t.w. I read somewhere that 25% of users is on Windows. But apparently not many core devs :) 13:18
MasterDuke nine: it looks like --no-jit is a no-op
13:21 Kaiepi joined
dumarchie nine: after gmake install of MoarVM with your patch (applied manually), install\bin\perl6 t\spec\S32-temporal\DateTime.t still crashes at the same point 13:22
I'll run the complete spectest to see if something else improved 13:23
MasterDuke nine: well, maybe it isn't a no-op. if i build normally (without it) i don't see any reference, but if i do add it it looks like something changes
timotimo c: releases my $a = { a => $++ } xx 3; say $a[0] ~~ Code 13:25
committable6 timotimo, ¦releases (41 commits): «True␤» 13:26
timotimo is the anonymous state variable interpreted the same way $_ would be to cause this to become a block?
dumarchie nine: t\spec\S02-types\num.rakudo.moar still crashes when run as part of the spectest 13:27
MasterDuke huh, that seemed like it might be a fix... 13:29
dumarchie Afk for lunch
13:34 sena_kun joined 13:36 Altai-man_ left
MasterDuke oh, isn't there a way to run a verbose spectest? that way we could at least see how far into t\spec\S02-types\num.rakudo.moar it gets before crashing 13:37
nine I'd just run it with raku -Ilib t\spec\S02-types\num.rakudo.moar 13:38
MasterDuke but dumarchie says there aren't any errors when run directly, even with a spectest running in the background 13:39
dumarchie: could you try another spectest setting TEST_VERBOSE=1 ?
nine dumarchie: have you tried running with MVM_JIT_DISABLE=1 and/or MVM_SPESH_DISABLE=1? 13:40
13:48 Ven`` left
lizmat afk for a few hours& 14:04
dumarchie With TEST_VERBOSE=1 there's no output at all ... at least not while running. 14:16
Same with the other options. I'll first restore MoarVM and restart Windows. 14:20
14:20 japhb left
dumarchie Btw I always get the following warnings when compiling MoarVM: gist.github.com/dumarchie/87745296...ae212ec6f2 14:26
Apart from the many -Wformat* warnings. 14:27
14:31 dumarchie left 14:33 dumarchie joined
dumarchie Setting TEST_VERBOSE=1 has no effect. But the summary is always the same: 14:40
t\spec\S02-types\num.rakudo.moar (Wstat: 1280 Tests: 79 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 108 tests but ran 79.
lucs I really hate "pat-on-the-back" tests. 14:41
Test suites that go "OK, OK, OK, ..., (200 lines late), OK, not OK, OK, OK... 14:42
I don't care about the OKs, and when I get a "not OK", give me details!
</end-of-rant> 14:44
"later
Grrr!
*later
dumarchie Setting MVM_JIT_DISABLE=1 and MVM_SPESH_DISABLE=1 does have an effect! 14:45
t\spec\S02-types\num.rakudo.moar now passes when run as part of `gmake spectest`
MasterDuke can you try with just MVM_JIT_DISABLE=1 ? 14:47
and btw, when you run a spectest, does it show you the command it's running? something like `'/usr/bin/perl' -I'/home/dan/Source/perl6/rakudo/tools/lib' -I'/home/dan/Source/perl6/rakudo/3rdparty/nqp-configure/lib' t/harness5 --moar --fudge --keep-exit-code --tests-from-file=t/spec/spectest.data`
dumarchie I will, when the current test run finishes. That takes a while on 4 just CPUs.
MasterDuke k, thanks 14:48
if so, can you try the command manually, but adding `--verbosity=1` ? it still doesn't seem to show everything, but maybe it'll give more info on failure 14:49
dumarchie But t\spec\S02-types\num.rakudo.moar doesn't crash if I run it stand-alone... 14:50
nine dumarchie: you could try MVM_SPESH_BLOCKING=1 to make it crash reliably 14:52
MasterDuke the command for the whole spectest, but with that added --verbosity=1 14:58
and maybe MVM_SPESH_NODELAY=1 might help make things crash even outside a spectest 15:02
dumarchie Outside a spectest and with MVM_SPESH_BLOCKING=1 the output stops at: 15:03
ok 79 - infix:<**>(num, num)
MasterDuke ooo, that's promising
dumarchie is-approx log(my num $ = 42e0), my num $ = 3.74e0, '42', 15:06
MasterDuke that crashes?
dumarchie Yes
MasterDuke can you run that in gdb?
dumarchie Thread 1 received signal SIGSEGV, Segmentation fault. 15:09
(corrupt stack?)
Very similar to the backtrace for DateTime.now 15:10
MasterDuke m: use Test; is-approx log(my num $ = 42e0), my num $ = 3.74e0
evalable6 (exit code 1) not ok 1 -
# Failed test at /tmp…
MasterDuke, Full output: gist.github.com/401644a53bcd22a254...390f1b37ba
15:12 hungryd98 left
MasterDuke huh 15:13
dumarchie That falls within the :abs-tol(.01)
m: use Test; is-approx log(my num $ = 42e0), my num $ = 3.74e0, :abs-tol(.01) 15:14
evalable6 ok 1 -
MasterDuke oh, ha. didn't see that and got really confused
dumarchie :)
MasterDuke so the backtrace still points to MVM_args_get_required_pos_num? 15:16
dumarchie Yes, but note that I reverted the changes to MoarVM as they did not appear to have an effect on DateTime.now. 15:19
With MVM_JIT_DISABLE=1 and MVM_SPESH_DISABLE=1 enabled the only spectest that exits early is t\spec\S02-literals\radix.rakudo.moar
MasterDuke well, that change is required, the previous state was definitely wrong. if fact nine just pushed it the moarvm master a little while ago 15:20
btw, mind trying something i randomly found on stackoverflow? 15:21
dumarchie Okay, I'll rebuild the whole of rakudo first.
MasterDuke in gdb, after it crashes: set $pc = *(void **)$rsp; set $rsp = $rsp + 8
then see if bt shows anything different 15:22
dumarchie I'll try that when I've build everything from scratch. 15:31
Currently compiling MoarVM.
MasterDuke you shouldn't have to rebuild nqp/rakudo
dumarchie I shouldn't ... but I rather to make sure there is no lingering cruft. 15:33
15:33 Altai-man_ joined 15:36 sena_kun left 15:46 lucasb joined
dumarchie First runniing `gmake spectest` with just MVM_JIT_DISABLE=1 15:53
t\spec\S02-types\num.rakudo.moar doesn't crash, so it looks like a JIT issue 15:56
MasterDuke ah, that's good to know 16:01
dumarchie MasterDuke:
MasterDuke how about just MVM_JIT_EXPR_DISABLE=1 ?
dumarchie (gdb) set $pc = *(void **)$rsp 16:02
I'll try `gmake spectest` with just MVM_JIT_EXPR_DISABLE=1 when the current test run is finished. 16:04
MasterDuke you tried those two commands in gdb?
dumarchie Yes, after the crash in `gdb --args install\bin\raku t\spec\S02-types\num.rakudo.moar` 16:05
MasterDuke did the backtrace look any different? 16:06
dumarchie There was less information for #0 and no #1 16:08
Otherwise not
MasterDuke oh well, that was a stab in the dark anyway 16:09
nine dumarchie: are you running current MoarVM git master including my commit dd20883c34f69c607d7741935d5284983d5f499a?
dumarchie c:\raku\rakudo\nqp\MoarVM>git status 16:10
nine git describe should read 2020.01.1-47-gdd20883c3
dumarchie c:\raku\rakudo\nqp\MoarVM>git describe 16:12
Why, I did a completely fresh checkout and build of rakudo?
MasterDuke are you using --gen-nqp? 16:13
nine You did that before I pushed the commit
dumarchie I always use `perl Configure.pl --gen-moar --gen-nqp --backends=moar` 16:14
MasterDuke you probably want `--gen-nqp=master --gen-moar=master` in this case, to pull in the most recent changes to moarvm
nine just cd nqp/MoarVM && git pull && make install
MasterDuke or you could probably just git pull in moarvm
dumarchie Okay, when `gmake spectest` has finished I'll do `git pull` and `make install` 16:15
Shall I then first run `gmake spectest` without any MVM_* variables set, or with just MVM_JIT_EXPR_DISABLE=1 ? 16:17
nine try without please 16:19
MasterDuke fyi, for moarvm only, make -j4 should be a little faster 16:20
dumarchie Okay, I'll interrupt the current test run which appears to hang at t\spec\S17-supply\classify.t 16:21
Hang HARD, co Ctrl-C doesn't even work ... this maybe a Windows thing. 16:22
vrurg .tell lizmat I have that patch too. Thanks! :) 16:23
tellable6 vrurg, I'll pass your message to lizmat
MasterDuke i think rba was working on getting us some credits for windows machines for CI, hopefully we can get them running spectests, and not just the rakudo tests like we do in appveyor 16:24
rba MasterDuke: We got some AWS credits. Not sure though if we can use them for Windows CI. 16:26
MasterDuke maybe even just a windows vm that the core devs could log into and test on?
rba MasterDuke: I think this I can arrange. 16:27
MasterDuke cool
rba Either on AWS or somewhere else.
How urgent is it?
MasterDuke i wouldn't say it's an emergency. but we do appear to have a release blocker only on windows 16:29
but dumarchie is helping us now
i'm likely going to be afk for a while
dumarchie Running `gmake spectest` without any MVM_* environment variables against latest MoarVM master. 16:34
MasterDuke, note that many spectests are failing on Windows. Mostly due to *nix assumptions about the filesystem and newlines. 16:35
More than a year ago ugexe made a summary: github.com/perl6/roast/issues/504 16:41
nine: `gmake spectest` now hangs after t\spec\S17-supply\migrate.t 16:55
I had to kill t\spec\S17-supply\min.t and t\spec\S17-supply\minmax.t before output resumed. 17:02
And the first output was that those tests AND t\spec\S17-supply\on-demand.t returned 1 (wstat 256, 0x100) 17:04
nine: the good news is that your commit appears to have fixed the issue with `num` on Windows :) 17:12
I'll now revert the workaround for DateTime.now that lizmat applied and rerun the spectest 17:13
17:34 sena_kun joined 17:36 Altai-man_ left
Geth rakudo: dumarchie++ created pull request #3506:
Revert workaround for issue with num		 17:59
sena_kun bisectable6, say "foo" but False eqv "foo" but False 18:42
bisectable6 sena_kun, On both starting points (old=2015.12 new=65ef7db) the exit code is 0 and the output is identical as well
sena_kun, Output on both points: «False␤»
MasterDuke dumarchie: glad to hear that particular problem is fixed. maybe you could update ugexe's summary with the current status 19:23
19:35 Altai-man_ joined 19:36 sena_kun left 20:00 dumarchie left
Geth rakudo: 4064023cc1 | (Peter du Marchie van Voorthuysen)++ | src/core.c/DateTime.pm6
Revert workaround for issue with num
 21:05
rakudo: 858a0e3237 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/DateTime.pm6
Merge pull request #3506 from dumarchie/master

Revert workaround for issue with num
lizmat Altai-man_ is there anything I can do now? 21:15
tellable6 2020-02-22T16:23:17Z #raku-dev <vrurg> lizmat I have that patch too. Thanks! :)
lizmat I cannot pack a MoarVM release... I know samcv can 21:18
Altai-man_: perhaps I should bump MoarVM anyway now? 21:19
Altai-man_ lizmat, I don't think there is. It has turned into an interesting situation. We have to bump moarvm to get the fix and then re-test everything to ensure we can release.
lizmat, yes, please bump
lizmat ok, will do
Altai-man_ lizmat, also, I saw one of your recent commits (not in release) broke PDF module, but decided to notify about it later, if you're interested, I can share it. 21:20
lizmat the sooner the better
Altai-man_ s/later/after release stuff/ 21:21
but I guess no hurt...
PDF – Fail, Bisected: 539e96c2629d5f7d33bb8cd9a373631d21e72cfb 21:22
Geth nqp: 91da25aa02 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarV<M to get native num fix
lizmat running spectest now 21:27
Geth rakudo: 271d0b4bea | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get native num fixes

  dumarchie++ for perseverance and the golden tip, nine++ for the
actual fix.		 21:31
lizmat Altai-man_: probably the test in PDF is too specific... and in I fixed one incompatibility with 3f637af9e11233074d9 21:32
linkable6 (2020-02-21) github.com/rakudo/rakudo/commit/3f637af9e1 Remove period to fix test
lizmat so good chance it is already ok again after the next Blin run 21:33
21:34 sena_kun joined, ufobat__ left 21:36 Altai-man_ left
sena_kun sigh, this connection... 21:38
lizmat sena_kun: in a few years, you can have Internet from the sky anywhere in the world :-) 21:39
sena_kun I am running errata tests with latest and blin. if blin is ok (which I am not sure about, but will see, maybe we're lucky), it's green light for the release. 21:40
[Coke] when I have internet from the sky, then can i watch picard without it skipping? (probably not)
lizmat [Coke]: you can wait for the DVD :-) 21:42
so I felt lucky and locally reverted the cas -> nqp::cas fix 21:44
and ran the lock async stress test again, repeatedly
sena_kun *excited drums fill*
lizmat alas, it failed, so this native num fix does not fix the lock::async / cas / multi-dispatch cache issue 21:45
sena_kun sigh
lizmat you can't kill all birds with one stone
sena_kun sane enough 21:46
noooooo... restarting stresstest and hoping it's a flapper 21:52
jnthn
.oO( meteorites have a good record of killing a lot of birds... )
lizmat true... but that's more like deleting the repository to fix all the bugs :-) 21:54
sena_kun inb4: if you're hoping for something to be a flapper, you're The Worst™
lizmat also runs a stresst test 21:55
.oO( that's very stressed :-)
 21:56
sena_kun lizmat, I am running 6.c-errata. ok, it was a flapper...
t/spec/S14-roles/basic.rakudo.moar (Wstat: 256 Tests: 0 Failed: 0) 21:57
lizmat sena_kun: stresstest was clean for me 22:01
on master
sena_kun runs blin and goes afk 22:04
Geth rakudo: 6354c9155a | (Elizabeth Mattijsen)++ | src/core.c/CompUnit.pm6
Change the default "from" to "Raku"

This caused 1 test to break, testing specifically for "Perl6". It appears to not interfere with any installation of modules or anything else, so I'm actually not sure what this actually means. But shortly after a release is the right time to do this change.		 22:11
roast: 30f3b43e5f | (Elizabeth Mattijsen)++ | S22-package-format/local.t
Fix checking of "from", because default is now "Raku"
 22:13
rakudo: 8dcf652d52 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit.pm6
Revert "Change the default "from" to "Raku""

This reverts commit 6354c9155ae0f6deb5722045304cd6e424460bca.
Hmmm... looks like this breaks zef, will look more in depth later		 22:47
roast: e380549210 | (Elizabeth Mattijsen)++ | S22-package-format/local.t
Revert "Fix checking of "from", because default is now "Raku""

This reverts commit 30f3b43e5f3dc3e7ef9b3c3256cdb18693aca913.
lizmat calls it a day... 22:48
23:33 cognominal joined, Altai-man_ joined 23:36 sena_kun left, cognomin_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!