🦋 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.
lizmat Files=1352, Tests=117183, 287 wallclock secs (35.37 usr 9.79 sys + 4026.36 cusr 327.13 csys = 4398.65 CPU) 07:50
Geth rakudo: ef68d4ad4c | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/DependencySpecification.pm6
Hopefully fix problem in JVM backend\

Apparently caused by 1b75e3fa0c . If this fixes it, then maybe the JVM backend cannot handle native str return constraints?
08:20
lizmat bartolin ^^
Geth rakudo: ffc06bb9ae | (Elizabeth Mattijsen)++ | tools/nuke-precomps.raku
Add a script to empty out all precomp in the repo chain

Intended to be used by core developers who research / maintain the precompilation process in Rakudo.
Please note that removing all precomp files does *not* change functionality of an installation: it will merely free up a lot of diskspace of you're a core developer compiling the setting over and over again. And it will slow down every first load of a compilation unit.
09:17
rakudo: 5658f4da07 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Supply.pm6
Fix race condition in Rakudo::Supply::BlockState

Fixes #4853
10:23
Geth rakudo: d059eaffdb | (Elizabeth Mattijsen)++ | tools/nuke-precomps.raku
Go after the precomp dirs, not the stores

But keep the uppermost "precomp" dir itself
10:59
lizmat PSA: on a fresh Rakudo checkout, "make install" currently does not correctly install Rakudo 11:44
investigating
lizmat PSA: false alarm, was a local snafu 12:35
[Tux] Rakudo v2022.03-160-gd059eaffd (v6.d) on MoarVM 2022.03-15-g43e1b00a6
csv-ip5xs0.798 - 0.801
csv-ip5xs-205.134 - 5.163
csv-parser3.543 - 3.754
csv-test-xs-200.400 - 0.415
test6.433 - 6.645
test-t1.379 - 1.399
test-t --race0.818 - 0.851
test-t-2020.971 - 21.339
test-t-20 --race6.808 - 7.292
13:22
MasterDuke 1.379, is that a new record? 13:25
vrurg Looks like it!
[Tux] Nope 13:39
20220307 1.399❙20220324 1.393❙20220322 1.386❙20220407 1.379❙20220324 1.359❙ 13:40
24-03 was 1.359
lizmat still #2 is nice 13:46
lizmat m: dd $?COMPILATION-ID # is that a implementation detail ? 14:40
camelia "C64B70F20F185B1FB98E5D17CECB016F02F5892B"
lizmat *an
it does not appear to be documented
nor are there tests for it 14:42
in fact, it doesn't appear to be referenced anywhere but in VM.pm6 14:44
seems to have been introduced in 3b94378276 14:46
japhb lizmat: Possibly implicit? If the value changes with each compile, it may be doing nothing but forcing the compiled data to change.
japhb m: dd $?COMPILATION-ID 14:47
camelia "C64B70F20F185B1FB98E5D17CECB016F02F5892B"
japhb Ah, interesting, it's the same again
lizmat it's a constant
japhb Oh, yeah, now looking at that commit. It's clearly based on the compiler's compilation-id 14:48
lizmat ah, it is tested in make test 15:05
but spectest is otherwise clean 15:10
Geth rakudo: lizmat++ created pull request #4854:
Remove the $?COMPILATION-ID constant
15:37
[Coke] lizmat: what about the method compilation-id ? 16:41
lizmat that lives in NQP 16:42
as part of HLL::Compiler afaics 16:43
[Coke] src/Perl6/Compiler.nqp has one
don't see it called anywhere in rakudo. 16:44
lizmat ah duh, should be looking for compilation-id not compiler-id :-)
[Coke] doesn't look like that's called in roast, either. 16:45
(checked master) 16:46
lizmat ok, that can go as well then :-) good spot 16:47
[Coke] yay, deleted code is debugged code.
lizmat m: BEGIN say $*W.handle 16:48
camelia BBDF497A86F06A2D0E6651DFF6F465EEA9F6BB71
lizmat I do think we're going to need *some* abstraction for that, as src/Perl6/World.nqp will not survive the RakuAST branch
Geth rakudo/remove-COMPILATION-ID: a852ad423a | (Elizabeth Mattijsen)++ | src/Perl6/Compiler.nqp
Can also remove Perl6::Compiler.compilation-id

Spotted by Coke++
16:59
Geth rakudo/CATCH-at-start: 64d397da9e | (Elizabeth Mattijsen)++ | 23 files
Put CATCH blocks at the start of the scope

CATCH blocks affect the **entire** scope they're in. So they should be as close to the start of the scope they're in, so that you realize that they can fire well before you think they'd might fire.
This did not change the Rakudo::Internals::JSON class, as that is being kept in sync with JSON::Fast.
18:37
rakudo: lizmat++ created pull request #4855:
Put CATCH blocks at the start of the scope
MasterDuke weekly: lwn.net/Articles/889312/ 19:21
notable6 MasterDuke, Noted! (weekly)
Geth rakudo: 86927cba53 | (Elizabeth Mattijsen)++ | 2 files
Make repo upgrade test faster

  - make the upgrade script take multiple args
  - adapt the makefile to only call it once, with 3 parameters
Saves about 280 msecs for every core build. Yes, it's not a lot but I do that a *lot*.
19:35
Geth rakudo/rakuast: 7475888262 | (Jonathan Worthington)++ | src/Raku/ast/variable-declaration.rakumod
Fix mis-compile of state intializer

In the case where we're not initializing the state variable, we should still evaluate to the l-value.
21:20
Geth rakudo/update-core-meta: 93e6b1acbe | (Elizabeth Mattijsen)++ | 2 files
Update the meta info of the core

  - in Compiler, auth to Yet Another Society, the official name of TPF
  - in install-core-dist.raku, use the info from Compiler
Mostly because it felt better to have the info in the META match what is in Compiler, and to be more specific in Compiler now that there is no Perl in the name anymore.
21:52
rakudo: lizmat++ created pull request #4856:
Update the meta info of the core
[Coke] lizmat++ 21:56