🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
japhb Red failure bisecting is getting close. rakudo-moar-2022.02-24-gb67d38c4e : PASS, rakudo-moar-2021.12-206-gdf09bef0b (first commit on branch) : PASS, rakudo-moar-2022.02-27-gfafcca315 (merge commit) : FAIL 05:13
Building the remaining commit on the branch now.
Looks like I found it. rakudo-moar-2021.12-207-gc50f51f95 : FAIL 05:50
vrurg: ^^
This commit is the first on which Red won't build anymore. 05:51
lizmat Files=1351, Tests=117115, 297 wallclock secs (35.35 usr 9.93 sys + 4115.01 cusr 335.79 csys = 4496.08 CPU) 09:01
Geth nqp: 6a1c69981f | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get unsigned int spesh fixes

  MasterDuke++
09:35
rakudo: 54f98fd76c | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MoarVM unsigned int spesh fixes

  MasterDuke++
09:49
nine releasable6: status 11:25
releasable6 nine, Next release in ≈11 days and ≈7 hours. There are no known blockers. Changelog for this release was not started yet
nine, Details: gist.github.com/fb5e454a142694f1fa...c7456ae141
Geth nqp: 0fd161cdc4 | (Stefan Seifert)++ | 3 files
Fix all returned native integers getting treated as signed

Use the new ops for dispatching with unsigned result and returning native unsinged integers on MoarVM
12:44
nqp: 096fa9929c | niner++ (committed using GitHub Web editor) | 3 files
Merge pull request #767 from Raku/fix_all_returned_native_integers_getting_treated_as_signed

Fix all returned native integers getting treated as signed
Geth rakudo: 0831a3b5fd | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get returned unsigned int fix
13:10
lizmat notable6: weekly 13:54
notable6 lizmat, 4 notes: gist.github.com/7a52d7f175791d7edb...c821c1f532
lizmat notable6: weekly reset 14:14
notable6 lizmat, Moved existing notes to “weekly_2022-03-07T14:14:26Z”
vrurg japhb: can you elaborate on the problem with Red? An issue would be the best. 14:26
japhb Sure, give me a few 14:36
vrurg: github.com/rakudo/rakudo/issues/4809 14:45
vrurg japhb: thanks, will try to have a look when have time. BTW, don't format commit hashes, github makes them convenient links. 14:48
japhb D'oh! Should have assumed that
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/03/07/2022-...-promoted/ 14:54
sena_kun lizmat++ 14:58
vrurg lizmat: correction: Log::Dispatch is a new module. I just had to bump its version two times. :) 15:38
lizmat fixed! vrurg++ 15:40
vrurg lizmat: thanks! And, most of all – for the dedication! 15:46
lizmat you're welcome! 15:47
afk for a few hours&
[Tux] Rakudo v2022.02-91-g0831a3b5f (v6.d) on MoarVM 2022.02-34-geb4480d88
csv-ip5xs0.768 - 0.809
csv-ip5xs-205.053 - 5.121
csv-parser3.463 - 3.542
csv-test-xs-200.422 - 0.438
test6.988 - 7.383
test-t1.441 - 1.492
test-t --race0.889 - 0.889
test-t-2021.301 - 21.448
test-t-20 --race6.904 - 7.391
18:32
lizmat pretty cool!
japhb Woah! 18:41
SmokeMachine my %column = :references, :model-name; say so(%column{<model-name model-type>.none}:exists) == so(%column{<model-name model-type>.all}:!exists) # is that expected to have changed to false? (that's breaking Red) 19:11
evalable6 False
japhb vrurg: ^^ 19:13
vrurg I saw, was about to type a reply. 19:14
SmokeMachine: please, add to the issue.
japhb Ah, sorry, didn't mean to jump the gun. (And yeah, I asked him to ping the issue too. ;-) )
*add to the issue 19:15
(Sorry, have been pinging so many people for $day-job today that I feel like a sonar station.)
vrurg japhb: :D 19:16
Hopefully, I could be able to take care of this as I have mounted so many postponed tasks that it starts affecting my mood. :( 19:19
SmokeMachine it seems there is something else wrong as well... 20:55
on 2021.12, raku -e 'say "yes" if (|<1 2 3>).any ~~ -> Any $_ { .HOW.?name($_) }' prints "yes" 20:56
m: say "yes" if (|<1 2 3>).any ~~ -> Any $_ { .HOW.?name($_) }
camelia Cannot find method 'not' on object of type BOOTStr
in block <unit> at <tmp> line 1
vrurg SmokeMachine: I have replied to the issue. It actually works as it has to. 21:35
SmokeMachine vrurg: yes, I agree that's a fix, thanks! What about this "new" one? ☝️ 21:38
vrurg Oh, I thought you're experimenting with that one... Trying not to get too deep as I'm tight on spare time. :(
SmokeMachine vrurg: ok, thanks! :) 21:39
vrurg SmokeMachine: BOOTStr must not leak, that's certainly a bug. 21:40
But why .?name ?
SmokeMachine: with .^name you wouldn't have the problem. 21:57
But the question is why .?name doesn't hllize. 21:58
SmokeMachine it wasn't name... I just used name for testing...
vrurg: this was my real case: github.com/FCO/Red/blob/master/lib...L.pm6#L780 21:59
vrurg Then it looks like .? doesn't hllize if invoked on a NQP class though it has to.
SmokeMachine sorry, that's after "fixed"... 22:00
SmokeMachine it was like this: github.com/FCO/Red/commit/f664df0a...16b7d6L780 22:01
vrurg SmokeMachine: why sorry? It's a bug, after all. 22:03
SmokeMachine I mean sorry because I sent the wrong link...
vrurg Ah, ignore me then. 22:05
;)
SmokeMachine :) 22:20
Geth rakudo: vrurg++ created pull request #4810:
Workaround for cases where ACCEPTS may return non-Raku object
22:27
vrurg SmokeMachine: ^^
vrurg We need a blin run. Looks like the latest fixes of unsigneds resulted in modules fallout. 22:56
MasterDuke jdv: could we get a blin run? tia 23:05
Geth rakudo: f1f5d5cdba | (Vadim Belman)++ | src/vm/moar/dispatchers.nqp
Workaround for cases where ACCEPTS may return non-Raku object

This may happen with `Code` objects on RHS, for example.
23:11
rakudo: 26e77d987f | (Vadim Belman)++ (committed using GitHub Web editor) | src/vm/moar/dispatchers.nqp
Merge pull request #4810 from vrurg/workaround-non-hll-ACCEPTS-return

Workaround for cases where ACCEPTS may return non-Raku object