00:14 melezhik2 joined 00:22 melezhik2 left 00:24 melezhik left 01:24 evalable6 left, linkable6 left 01:26 linkable6 joined 01:27 evalable6 joined 01:34 lucasb left 03:09 raku-bridge left, raku-bridge joined 04:33 evalable6 left, coverable6 left, linkable6 left, tellable6 left, unicodable6 left, bloatable6 left, quotable6 left, squashable6 left, bisectable6 left, shareable6 left, notable6 left, committable6 left, releasable6 left, nativecallable6 left, greppable6 left, sourceable6 left, benchable6 left, statisfiable6 left 04:34 bloatable6 joined, releasable6 joined, linkable6 joined 04:35 tellable6 joined, notable6 joined, statisfiable6 joined, shareable6 joined, evalable6 joined, coverable6 joined, quotable6 joined 04:36 committable6 joined, sourceable6 joined, nativecallable6 joined, bisectable6 joined, greppable6 joined, benchable6 joined 04:37 unicodable6 joined, squashable6 joined 05:27 frost-lab joined
AlexDaniel` c: sprintf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff; printf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff 08:44
committable6 AlexDaniel`, ¦sprintf: «Cannot find this revision (did you mean “Berlin”?)»
AlexDaniel` * 6c: sprintf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff; printf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff 08:45
6c: sprintf "ux%04x = '%c'\n", $, $ for 0x2500 .. 0x25ff; printf "ux%04x = '%c'\n", $, $ for 0x2500 .. 0x25ff
committable6 AlexDaniel`, gist.github.com/b071d27f42552ee45d...df84c552bc
AlexDaniel` uh, so apparently only in the REPL 08:48
6c: sprintf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff; sprintf "ux%04x = '%c'\n", $_, $_ for 0x2500 .. 0x25ff 09:04
committable6 AlexDaniel`, ¦6c (49 commits): «»
09:35 sena_kun joined
lizmat Files=1345, Tests=117140, 232 wallclock secs (30.29 usr 8.92 sys + 3204.67 cusr 308.04 csys = 3551.92 CPU) 09:49
10:59 patrickb joined 11:01 stoned75 joined
Geth_ rakudo: stoned++ created pull request #4055:
Fix typo
stoned75 hi. I was working on adding documentation for env var {RAKU,PERL6}_TEST_TIMES when I found the typo for wich I made the preceding PR 11:06
Now I'm wondering if the typo should be documented, as it had been out there for more than 6 months :-} 11:07
Geth_ rakudo: d84ed4e946 | (Stoned Elipot)++ | lib/Test.rakumod
Fix typo
rakudo: 551b679579 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/Test.rakumod
Merge pull request #4055 from stoned/test-times-typo

Fix typo
rakudo: 15ec4fe672 | (Elizabeth Mattijsen)++ | t/packages/Test/Helpers.pm6
Move "is test-assertion" to candidates

Apparently, it is not being seen if it just lives on the proto, probably because the proto is not seen in callframe walking?
roast: 58b3ad5f16 | (Elizabeth Mattijsen)++ | packages/Test-Helpers/lib/Test/Util.pm6
Move "is test-assertion" from proto to candidates

Apparently, the protos are not seen in a callframe walk, and this causes the "is test-assertion" marker to be missed.
12:10 Altai-man joined 12:12 sena_kun left
lizmat stoned75: feels to me the lack of documentation inhibited the widespread adoption of that feature :-) 12:22
so no need to document the typo
stoned75 ok understood 12:27
I suppose the test timing feature predates 6c, because since 6c a native num var has a NaN default value, thus a timed test with no plan results in an 't=NaN' output 12:31
try something like env RAKU_TEST_TIMES=1 raku -e 'use Test; pass 1;' 12:32
vs env RAKU_TEST_TIMES=1 raku -e 'use Test; plan 1; pass 1;'
lizmat FWIW, at several occassions I was very close to ripping that feature out 12:33
stoned75 eh :)
lizmat I'm not sure what it is for, really, or if anybody is using it
patrickb ping tyil 12:42
tyil pong
patrickb I want to extend our binary release filenames with the toolchain used (msvc, gcc, clang) 12:43
so rakudo-moar-2019.11.02-01-linux-x86_64.tar.gz -> rakudo-moar-2019.11.02-01-linux-x86_64-gcc.tar.gz
That would also affect the star builds.
tyil yes, but that should be easily adaptable on my end 12:44
patrickb So you are not against it?
tyil it should be fine, so go ahead :> 12:45
patrickb I'm in progress of adapting rakudo.org respectively. Plan is to write a small script, that bulk renames all existing releases accordingly.
lizmat patrickb++ tyil++
tyil the existing rakudo stars come bundled, so they shouldn't be affected
patrickb (I'm unsure about the bulk rename though. Has potential for breaking things for users that somehow rely on the old archive names).
tyil if moarvm 2020.12 has it, I have a full month to update it in rakudo star
I would suggest against renaming existing tars for that reason, yes 12:46
but it shouldn't affect r* itself
patrickb tyil: What compilers do you use for the respective platforms?
tyil I believe its using gcc in all circumstances right now (since I haven't incorporated mac/win builds) 12:47
patrickb the monthly prebuilt releases use: win-msvc, mac-clang, linux-gcc 12:48
[Tux] Rakudo v2020.11-24-g15ec4fe67 (v6.d) on MoarVM 2020.11-1-gca5d19d21
csv-ip5xs0.813 - 0.867
csv-ip5xs-207.751 - 7.918
csv-parser25.484 - 26.315
csv-test-xs-200.384 - 0.385
test7.548 - 7.865
test-t1.934 - 1.972
test-t --race0.853 - 0.867
test-t-2032.879 - 33.138
test-t-20 --race9.622 - 10.087
13:12 patrickb left 13:13 frost-lab left
tyil vrurg: is the RSC meeting next Sunday still going to be using zoom? 13:18
Altai-man releasable6, status 13:21
releasable6 Altai-man, Next release in ≈27 days and ≈5 hours. 1 blocker. Changelog for this release was not started yet
Altai-man, Details: gist.github.com/ebb6fd1bf3c8923e89...90851b5c5c
lizmat afk for a few hours& 13:30
14:43 domidumont joined 15:27 MasterDuke left 15:29 MasterDuke joined
Geth_ rakudo: 7c0a81f501 | (Elizabeth Mattijsen)++ | 2 files
Make the REPL a little bit smarter

Basically, any line that does *not* create any direct output to STDOUT, becomes part of the code that will be executed whenever the next line is input. This is a behaviour similar to what is done when a line is deemed incomplete. The only difference is, is that this new behaviour will not be visible because of a prompt ... (9 more lines)
MasterDuke vrurg, timotimo: another example of a performance regression from thundergnat over in #raku. a rough comparison of profiles looks like inlining and scalar replacement. on 2010.10 both were 99%, on HEAD it was 60% and 44% 15:52
also, only one gc on 2020.10 but 300+ on HEAD. and essentially 100% jitted on 2020.10, but only 60% on HEAD 15:53
lizmat++ 15:54
Altai-man lizmat++ # just simply awesome 16:03
MasterDuke, was commit bisected? 16:08
MasterDuke no(t yet)
16:12 sena_kun joined 16:13 Altai-man left
MasterDuke sena_kun, vrurg: bisects to the same as dogbert17's example, 1f090e04dcd4ed 16:23
linkable6 (2020-11-15) github.com/rakudo/rakudo/commit/1f090e04dc Merge pull request #3891 from vrurg/raku_1285
sena_kun That's something I suspected. :| 16:24
16:45 MasterDuke left
Kaiepi now that the release is made, any comments on github.com/Raku/problem-solving/issues/243 ? 17:12
17:42 stoned75 left 19:23 Altai-man joined 19:24 TreyHarris left 19:25 sena_kun left 19:34 domidumont left 19:50 MasterDuke joined 19:53 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 20:07 patrickb joined 20:11 sena_kun joined 20:13 Altai-man left 20:22 camelia left 20:25 camelia joined 20:27 jdv79 left 20:28 jdv79 joined
patrickb I do not have access to the rakudo.org repository anymore (access got lost during the Perl6 -> rakudo move I guess). 20:42
Can someone either give me access again or merge the two open PRs? Please. :-) 20:43
vrurg patrickb: 54 and 55? 20:45
Ah, same problem. I neither have access now.
patrickb Whoever does have access: Can you please add vrurg back again as well? 20:47
21:09 sena_kun left 21:12 patrickb left
lizmat lemme see what I can do 21:17
vrurg patrickb should have access now 21:19
vrurg lizmat: thanks! 21:20
lizmat merged the PRs as well
22:47 morayj joined 22:49 morayj left 23:07 leont joined
Geth_ rakudo: f2f2cf8246 | (Elizabeth Mattijsen)++ | 44 files
Remove all easily removable nqp::stmts

Basically, whenever an nqp::stmts aligned with an outer scope, and it was already laid out in a familiar way (to me at least). Another step toward de-nqpifying the core setting.
Should not have any semantic changes, nor noticeable performance effects. Should allow for better error reporting (because an execution error inside an nqp::stmts is reported at the start of the nqp::stmts, which can be a long way off from the actual location of the error).
lizmat and that concludes my hacking for today& 23:33
23:49 leont left