#raku-dev on 3 February 2022 - Raku Programming Language Log

🦋 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:08 reportable6 left 00:10 reportable6 joined 00:19 linkable6 joined

Geth

rakudo/ugexe-patch-3: f1999ef471 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/PrecompilationStore/File.pm6
Use unique path for temporary precomp files

Previously when two threads were trying to load the same module they could attempt to rename the same temporary file. This adds some uniquifying path extension parts to avoid the aforementioned scenario.

00:44

rakudo: ugexe++ created pull request #4758:
Fix precomp file rename race condition

00:45

rakudo/ugexe-patch-3: f972c432ac | (Nick Logan)++ (committed using GitHub Web editor) | t/08-performance/05-processkeys.t
Update test to account for $*THREAD

01:51

rakudo/ugexe-patch-3: f3c1a2ecaa | (Nick Logan)++ | 2 files
Use unique path for temporary precomp files

Previously when two threads were trying to load the same module they could attempt to rename the same temporary file. This adds some uniquifying path extension parts to avoid the aforementioned scenario.

02:22

02:39 frost joined

Geth

rakudo/ugexe-patch-4: 0f5e670b7e | (Nick Logan)++ | src/core.c/Rakudo/Internals.pm6
Enable INITTHREAD on jvm

02:50

rakudo/ugexe-patch-3: 25f30c17b1 | (Nick Logan)++ | src/core.c/Rakudo/Internals.pm6
Enable INITTHREAD on jvm

02:54

03:01 frost left 04:01 linkable6 left, reportable6 left, sourceable6 left, nativecallable6 left, bisectable6 left, greppable6 left, releasable6 left, tellable6 left, evalable6 left, squashable6 left, unicodable6 left, statisfiable6 left, benchable6 left, bloatable6 left, shareable6 left 04:02 tellable6 joined, statisfiable6 joined 04:03 benchable6 joined, nativecallable6 joined 04:04 greppable6 joined 05:02 linkable6 joined 05:04 committable6 joined, releasable6 joined, unicodable6 joined, squashable6 joined 05:05 shareable6 joined 05:26 frost joined 05:42 frost left 06:02 sourceable6 joined, quotable6 joined 06:04 bloatable6 joined 07:03 coverable6 joined, evalable6 joined 07:04 bisectable6 joined 07:05 reportable6 joined 07:25 camelia left, zostay left, vrurg left, japhb left, kjp left, timo left, maettu left, ilogger2 left 07:26 jjatria left, rypervenche left, Util left, samebchase left, Merfont left, qorg11 left, ugexe left, eof left, RakuIRCLogger left, sjn left, TempIRCLogger__ left, dogbert17 left, lucs left, patrickb left, SmokeMachine left, CIAvash left, samcv left, tonyo left, bartolin_ left, gfldex left, nine left, leont left, kawaii_ left, rba left, codesections left, AlexDaniel left, [Tux] left, JRaspass left, jdv left, masak left, sena_kun left, Geth left, nebuchadnezzar left, [Coke] left, lizmat left, reportable6 left, bisectable6 left, evalable6 left, coverable6 left, bloatable6 left, sourceable6 left, quotable6 left, shareable6 left, squashable6 left, unicodable6 left, releasable6 left, committable6 left, linkable6 left, greppable6 left, nativecallable6 left, benchable6 left, statisfiable6 left, tellable6 left, Voldenet left, djinni` left, moon-child left, sivoais left, MasterDuke left, discord-raku-bot left 07:28 vrurg joined, japhb joined, kjp joined, timo joined, maettu joined, ilogger2 joined, camelia joined, zostay joined

nine

I submitted a PR with the single characater fix to PDF.

08:10

As long as UInt is a subset, we won't be able to forgoe those range checks for array indexes. But! Now that uint is fully recognized by multi dispatch, we could have a:

08:25

multi sub postcircumfix:<[ ]>( array::uintarray:D \SELF, uint $pos) is raw {

nqp::atposref_u(nqp::decont(SELF), $pos)

}

Also a multi method AT-POS(List:D: uint $pos).

08:27

08:28 [Coke] left 08:31 [Coke] joined 09:03 notable6 joined

lizmat

Files=1351, Tests=117097, 285 wallclock secs (34.95 usr 9.47 sys + 3981.39 cusr 329.78 csys = 4355.59 CPU)

09:19

nine: want me to add those candidates ?

09:20

m: multi a(Int:D) { dd }; multi a(UInt:D) { dd }; a 42 # so why not use UInt candidates

09:22

camelia

sub a(UInt)

lizmat

nine ^^

or even get rid of all the Int:D candidates:

09:23

m: multi a(uint) { dd }; multi a(UInt:D) { dd }; a -42

camelia

Cannot resolve caller a(Int:D); none of these signatures match:
(uint)
(UInt)
in block <unit> at <tmp> line 1

lizmat

m: multi a(uint) { dd }; multi a(UInt:D) { dd }; a my int $ = 42 # even the native int handling is sorta ok in that case

09:24

camelia

sub a(UInt)

moon-child

hmm that should be 'none of these signatures matches'

09:32

because 'none' is singular

09:33

nine

lizmat: because I think that UInt:D is not actually cheaper. A type check for UInt:D is: * a type check for Int, * a concrete check, * running the subset where block

09:51

lizmat

yeah, but otherwise the check needs to be done inside the code

increasing the size of the candidate, and thus prevent inlining in some cases

nine

That's the point: with uint, no check has to be done at all

lizmat

right, but even UInt:D would have a positive

09:52

nine

But UInt still includes that runtime check

moon-child

nine: supposing the caller has a UInt already, though; then could the check not be skipped?

nine

It's just implicit, but the code is still there

lizmat

nine: yes, I'm not saying we shouldn't have a uint candidate

09:53

I'm saying that we should drop the Int:D candidate for a UInt:D candidate

nine

moon-child: no, it cannot, because UInt is just a subset.

m: my UInt $a = 1; say $a.^name

camelia

Int

nine

lizmat: that doesn't buy us anything

lizmat

not wrt to inlining ?