🦋 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.
00:06 reportable6 left 01:06 benchable6 left, greppable6 left, committable6 left, bisectable6 left, nativecallable6 left, statisfiable6 left, squashable6 left, unicodable6 left, sourceable6 left, linkable6 left, quotable6 left, evalable6 left, shareable6 left, tellable6 left, coverable6 left, notable6 left, releasable6 left, bloatable6 left 01:07 releasable6 joined 01:08 notable6 joined, evalable6 joined, benchable6 joined, linkable6 joined, greppable6 joined 01:10 sourceable6 joined 01:27 frost joined 01:47 frost left 01:50 frost joined 02:06 frost left 02:07 shareable6 joined, statisfiable6 joined 02:08 squashable6 joined, frost joined, bloatable6 joined, reportable6 joined 02:09 nativecallable6 joined 02:13 frost left 02:59 frost joined 03:07 coverable6 joined, quotable6 joined 04:07 linkable6 left, releasable6 left, notable6 left, greppable6 left, sourceable6 left, benchable6 left, evalable6 left, nativecallable6 left, bloatable6 left, quotable6 left, coverable6 left, squashable6 left, reportable6 left, statisfiable6 left, shareable6 left 04:08 quotable6 joined, nativecallable6 joined, shareable6 joined 04:09 notable6 joined, statisfiable6 joined, unicodable6 joined, tellable6 joined, committable6 joined 04:10 sourceable6 joined 05:08 releasable6 joined, bloatable6 joined 05:09 greppable6 joined, reportable6 joined 05:11 squashable6 joined
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
06:08 reportable6 left, linkable6 joined 06:58 squashable6 left 07:07 bisectable6 joined 07:47 discord-raku-bot left, discord-raku-bot joined 07:59 squashable6 joined 08:10 benchable6 joined, evalable6 joined 08:11 reportable6 joined 08:12 Shane__ left
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
10:09 coverable6 joined 11:09 evalable6 left, linkable6 left 11:11 linkable6 joined
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
12:06 reportable6 left 12:10 evalable6 joined
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
12:49 TempIRCLogger joined 12:58 squashable6 left 13:09 reportable6 joined
Geth rakudo: 0831a3b5fd | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get returned unsigned int fix
13:10
13:54 frost left
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
15:00 squashable6 joined
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&
18:01 Shane__ joined 18:07 reportable6 left
[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
20:09 reportable6 joined
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
21:13 Shane__ left
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
22:00 Shane__ joined
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: ^^
22:49 melezhik joined
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
23:26 melezhik left 23:52 discord-raku-bot left 23:53 discord-raku-bot joined