Xliff m: say 42.?"bbb"() 08:40
camelia Nil
Xliff m: say 42.?"sin"()
camelia -0.9165215479156338
[Tux] is JJ here on IRC? 11:55
ignore that question. tickets are already on github 11:57
Geth rakudo/expose-junction-type: befb03df26 | (Elizabeth Mattijsen)++ | src/core.c/Junction.pm6
Expose the type of a Junction

any <any all none one>		 12:50
rakudo: lizmat++ created pull request #4087:
Expose the type of a Junction		 12:51
sena_kun Is there anything like Hash::Concurrent? 14:16
lizmat I think jnthn implemented something like that ? 14:50
ah, no, Concurrent::Iterator 14:51
ugexe 6c: my @needles = "foo"; do given any(@needles) { when "foo" { say "OK" }; default { say "wut" }; }; 14:59
committable6 ugexe, gist.github.com/f51e3cccd5cde992d5...9954eb1238 15:00
ugexe bisectable6: my @needles = "foo"; do given any(@needles) { when "foo" { say "OK" }; default { say "wut" }; };
bisectable6 ugexe, Will bisect the whole range automagically because no endpoints were provided, hang tight
ugexe, Output on all releases: gist.github.com/5691f8317eef4abfd0...b33e60c698
ugexe, Bisecting by output (old=2020.11 new=6c7044e) because on both starting points the exit code is 0
ugexe, bisect log: gist.github.com/9177f3864738a3cc95...c0eb6a41c7
ugexe, (2020-11-15) github.com/rakudo/rakudo/commit/c0...7e013c09ca
ugexe, Output on all releases and bisected commits: gist.github.com/6654304382f29b778f...e816a45f89 15:01
ugexe MasterDuke: ^
that causes the --verbose --debug etc flags of zef to be ignored 15:03
github.com/rakudo/rakudo/issues/4089 15:23
MasterDuke ugexe: hm, have a possible fix for that to try, but maybe the whole thing needs to be scrapped. will probably give it a go today or tomorrow 16:25
lizmat MasterDuke: shall I revert the commit for now then? 16:32
to reduce the pressure on you ?
MasterDuke lizmat: i actually have a couple min now to work on it, but if it doesn't work then yeah 16:42
MasterDuke lizmat: are errors in t/spec/S09-typed-arrays/native-num.rakudo.moar expected right now? 16:57
# Expected: Cannot delete from a natively typed array
# Got: Cannot delete from a native num array
lizmat I think you missed a roast update ?
nooo... I forgot to do a commit and a push 16:58
MasterDuke cd t/spec && git pull --ff-onlyAlready up to date.
Geth roast: 1a84eefa47 | (Elizabeth Mattijsen)++ | S09-typed-arrays/native-num.t
Fix up more exact error message
 16:59
lizmat MasterDuke++ thanks for the headsup
MasterDuke heh, glad it wasn't a problem with my fix
Geth rakudo: lizmat self-assigned calling an undeclared routine in the REPL undeclares all variables github.com/rakudo/rakudo/issues/4088
MasterDuke17++ created pull request #4091: Use Raku instead of NQP ops for literals in a when
 17:12
MasterDuke ok, looks like the fix works 17:19
[Coke] MasterDuke++ lizmat++ 17:31
Nothing like a 6am saturday prod rollout for $dayjob... 17:32
ugexe i know the pain... this is the first weekend i've had off in weeks -_- 17:37
Altai-man releasable6, status 18:01
releasable6 Altai-man, Next release in ≈14 days and ≈0 hours. 3 blockers. 0 out of 95 commits logged
Altai-man, Details: gist.github.com/56ea33f5d3360e6b67...60fab2bc62
ugexe oh, was that regression in the last release? 18:06
ah nope, the commit is that old but it wasnt merged till after
Altai-man rba, ping? 18:07
Geth rakudo: 6f7718cef2 | (Elizabeth Mattijsen)++ | src/core.c/REPL.pm6
Only reset "before" code in the REPL when we can

Fixes #4088		 18:43
linkable6 RAKUDO#4088 [closed]: github.com/rakudo/rakudo/issues/4088 calling an undeclared routine in the REPL undeclares all variables
Geth ¦ problem-solving: Altai-man assigned to JJ Issue Documentation search categories are not standartized github.com/Raku/problem-solving/issues/250 19:28
ugexe Im starting to think IO::Path.relative() and Spec.abs2rel are not thread safe 19:53
github.com/rakudo/rakudo/blob/6f77...#L214-L218 19:54
github.com/rakudo/rakudo/blob/6f77...#L271-L273
the code in the first link calls into the code in the second. my guess is that $*CWD in the second link can become stale 19:56
`zef install HTTP::UserAgent --test-degree=2` occasionally triggers an error where one of the first tests cant find some file because its prefixed with an additional ../../ 20:04
MasterDuke so github.com/rakudo/rakudo/pull/4091 passes all tests (and gives the correct result for the example in github.com/rakudo/rakudo/issues/4088), but the example in the PR where i originally introduced the change now warns 'Use of Nil in numeric context' 20:08
github.com/rakudo/rakudo/commit/c0...7e013c09ca
because we're returning a `Nil` instead of a `Failure` 20:09
and with the nqp:: ops i was first using it didn't match, but also didn't warn 20:11
(and didn't warn before my changes either)
i could return `Empty` instead, but is that really a good choice? 20:12
m: say Empty == 5; say Nil == 5
camelia False
Use of Nil in numeric context
False
in block <unit> at <tmp> line 1
MasterDuke nope, because Empty == 0 20:32
so does False
oh, and NaN also breaks my proposed fix 20:35
m: say NaN == NaN; say NaN ~~ NaN
camelia False
True
MasterDuke `Mu` seems to work 20:43
ugexe regarding the thread safety of IO::Path.relative i mentioned earlier... it was happening for me on 2020.06, i golfed it to this gist.github.com/ugexe/50f056eedbc7...2ced2a8cda and then discovered it must already be fixed cause i cant get it to die on HEAD 21:12
ugexe it seems like spawning a process in a specific cwd was required to make it happen 21:17
indeed the bug exists in 2020.11, so it was fixed very recently 21:52
Geth rakudo: b3a255801c | (Daniel Green)++ | 3 files
Use Raku instead of NQP ops for literals in a when

Otherwise Junctions won't autothread and we could get the wrong result. Requires returning `Mu` instead of `Nil` when `val()` fails, otherwise you get a warning about 'Use of Nil in numeric context'.
Fixes #4089		 22:23
linkable6 RAKUDO#4089 [closed]: github.com/rakudo/rakudo/issues/4089 [BLOCKER][regression] 'when' no longer working with junctions
Geth rakudo: cce2fa26e2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Merge pull request #4091 from MasterDuke17/gen_raku_ops_not_nqp_ops_for_literal_when_comparisons

Use Raku instead of NQP ops for literals in a when
Geth rakudo: c4c4ba98cc | (Elizabeth Mattijsen)++ | src/core.c/Capture.pm6
Make the while loop in NQP

This fixes the problem that Blin found with Trait::Traced.		 22:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!