🦋 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.
rakudo: ugexe++ created pull request #4758:
Fix precomp file rename race condition
rakudo/ugexe-patch-3: f972c432ac | (Nick Logan)++ (committed using GitHub Web editor) | t/08-performance/05-processkeys.t
Update test to account for $*THREAD
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:39 frost joined
Geth rakudo/ugexe-patch-4: 0f5e670b7e | (Nick Logan)++ | src/core.c/Rakudo/Internals.pm6
Enable INITTHREAD on jvm
rakudo/ugexe-patch-3: 25f30c17b1 | (Nick Logan)++ | src/core.c/Rakudo/Internals.pm6
Enable INITTHREAD on jvm
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:
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 ? 09:54
in the case of AT-POS, we could have a *single* Int:D candidate that just throws 09:55
and get rid of a lot of code
otoh, it looks like something with a UInt:D doesn't even qualify for inlining 10:11
nine The irony is that adding a uint candidate right now would make things even slower. There seems to be an issue with spesh. sub foo(Int $a, uint $b) speshes just fine. But sub foo(Int:D $a, uint $b) bails argument spesh because $b is suddenly a UIntLexRef instead of a uint 10:13
I guess, the issue is somewhere in the dispatcher, but I haven't found anything so far 10:14
MasterDuke is that unique to uints? or is it the same for `int $b`? 10:16
10:19 [Tux] left
nine same for int 10:19
lizmat also: adding a uint candidate to List.AT-POS doesn't inline because of:
AT-POS BB(5668, 192 bytes) -> BB(1):
target has a :noinline instruction - ins: param_rp_o
nine lizmat: see what I just wrote :D 10:20
MasterDuke oh, so possible general optimization
lizmat ok, glad it is another expression of the same issue
10:47 [Tux] joined 12:07 reportable6 left 12:09 reportable6 joined
nine Ooh, that weird spesh issue: it's the optimizer 12:09
MasterDuke static optimizer or spesh optimizer? 12:34
nine static 12:35
The static optimizer is supposed to simplify native refs for non-rw arguments (can just pass the value for those). But for some reason the trial_bind to the signature ends with "not sure" as soon as a :D argument is in the signature 12:36
lizmat nine: and that would always be true for an instance method, right? 12:41
MasterDuke m: sub a(Int:D $b) {}; dd &a.signature.params[0].multi-invocant   # is this correct/expected? 13:02
camelia Bool::True
lizmat perhaps not 13:03
looks like the default when building a Parameter object is set to True
but the method doesn't actually check the attribute? 13:04
ah, oops, the BUILD only sets a flag
and that flag is checked
so it feels like an error in building the Parameter object ? 13:05
MasterDuke m: sub a(;;Int:D $b) {}; dd &a.signature.params[0].multi-invocant   # oh, this is what it's for 13:07
camelia Bool::False
13:09 linkable6 left, evalable6 left
lizmat naming of that feature feels...meh :-) 13:11
MasterDuke yeah 13:12
it's this case github.com/rakudo/rakudo/blob/mast...1101-L1107 13:19
i added a note in there and it hits for `sub a(Int:D $b, int $c) { say $c }; a(1, 3);` but not `sub a(Int $b, int $c) { say $c }; a(1, 3);` 13:20
$flags = 131200 in the not sure case 13:26
nine Adding $SIG_ELEM_DEFINED_ONLY there gets you further, but still not through with postcircumfix:sym([ ]) 13:37
That's because the proto sub postcircumfix:<[ ]>($, |) is nodal {*} has that $ in the signature which throws off trial_bind 13:43
But even if that is out of the way, we still do not succeed, because then it finds 2 matching multi candidates and will not enter the branch where it simplifies the refs 13:44
lizmat fwiw, having those signatures on protos in core, still feels like a ginormous hack 13:47
nine What's it for? 13:55
lizmat so that things like sort can introspect 14:00
14:02 carlmasak joined 14:10 linkable6 joined 16:09 evalable6 joined
jdv nine: still a bunch 16:36
nine Well Data::ExampleDatasets – Fail, Bisected: 4e1a772 is certainly bogus. There's just no way that this commit could cause a free() error and they have been cropping up for a while (most likely mimalloc related( 16:41
Archive::Libarchive – Fail, Bisected: c92833f is a bug in the module. 16:44
Digest and PDF already have PRs for the bugs in the modules. Should I mark them as done? 16:46
HarfBuzz::Font also buggy, also causes the failure in HTML::Canvas 16:51
jdv yup. i think just marking them and maybe a comment is fine 17:14
nine Yes, I started marking them, as I noticed that I was already losing track of the PRs I submitted :D 17:15
17:37 carlmasak left 18:08 reportable6 left, reportable6 joined
Geth rakudo: a35a779133 | (Stefan Seifert)++ | 2 files
Allow for using uint and int as indexes in native array slice assignment

Fixes "This container does not reference a native integer" errors.
nine Oh, so close: github.com/pdf-raku/Font-FreeType-...c0e3aa5fa7 18:35
The test was already anticipating Rakudo getting fixed to no longer return -1 for an unsigned, but used the wrong alternative value 18:36
11/18 taken care of so far. I expect the remaining uint issues to be bugs in those modules as well. I'll be mostly afk tomorrow though. 20:08
japhb nine++ # Excellent progress! 20:11
21:03 Xliff joined
Xliff Hello. Does anyone know if the RakuAST branch has the ability to introspect the AST of existing code? 21:04
Ie if I have something like this: my $a = sub { 42 }; Then I can get the AST of the sub in $a by something like $a.ast? 21:05
21:09 squashable6 left
[Tux] Rakudo v2021.12-192-ga35a77913 (v6.d) on MoarVM 2021.12-120-g6ecb89383
csv-ip5xs0.770 - 0.781
csv-ip5xs-204.902 - 5.174
csv-parser3.911 - 4.053
csv-test-xs-200.411 - 0.412
test6.760 - 6.790
test-t1.504 - 1.519
test-t --race0.873 - 0.900
test-t-2022.819 - 24.328
test-t-20 --race7.463 - 7.585
MasterDuke Xliff: no idea. my only idea would be to look at new tests on that branch and see if any of them do anything like that 21:18
vrurg Xliff: unlikely for run-time. 21:31
nine: Can you also have a look at LibXML regression? The bisected commit doesn't look relevant. It throws in lib/LibXML/ErrorHandling.rakumod, line 281. There is nothing related to smartmatch and the error message is about native int. 21:44
22:12 squashable6 joined
Geth rakudo/ugexe-patch-3: 36c784ef33 | (Nick Logan)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Use non-clashing 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 a uniquish path extension part to avoid the aforementioned scenario.