🦋 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.
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
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
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
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 ? 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
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
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
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
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
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.		 18:20
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
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
[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
 21:12
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
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.		 23:54

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!