🦋 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.
CIAvash Should the error messages produced by the compiler(text or JSON output) be considered implementation-dependent? Roast does not defined them? And will not do that in the future? I'm asking just to be clear; if that's the case, the name of tools created which use these error messages should have `rakudo` in their name? 06:29
moon-child CIAvash: I am not in charge of deciding such things, but: that sounds reasonable 07:23
nine We've had lots of commits in roast where a previous check for a certain error message was replaced by a type check on the exception or at least made more flexible by only testing for parts of error messages (when it's an Adhoc exception). 07:45
I haven't seen anyone considering precise error messages as public API (as that would prevent us from improving those messages even). Those overly specific tests have always been considered mistakes. 07:46
Geth rakudo: 980bfe168c | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Loader.pm6
Remove CATCH from CompUnit::Loader.load-source

It occurred to me that the CATCH was merely there for restoring the value in hllsym('Raku','GLOBAL') and then rethrow. And have the same done on exit. Feels to me a single LEAVE phaser would do that with less code.
08:18
lizmat Files=1352, Tests=117184, 297 wallclock secs (36.39 usr 9.65 sys + 4120.64 cusr 339.69 csys = 4506.37 CPU) 08:19
[TuxCM] Rakudo v2022.03-218-g980bfe168 (v6.d) on MoarVM 2022.03-17-g794e1d589
csv-ip5xs0.757 - 0.770
csv-ip5xs-204.967 - 5.018
csv-parser3.385 - 3.566
csv-test-xs-200.401 - 0.402
test6.532 - 6.557
test-t1.408 - 1.446
test-t --race0.816 - 0.889
test-t-2019.811 - 20.299
test-t-20 --race6.604 - 7.051
08:41
Geth rakudo: 2ad2a94a46 | (Elizabeth Mattijsen)++ | 4 files
Introduce X::File::NotFound and use it

  - reduce the amount of CPU used to signal failure to load
  - removes the recently introduced .not-found(-list) methods
  ugexe++ nine++ for input
09:05
Geth rakudo: 504b1512ac | (Elizabeth Mattijsen)++ | 4 files
s/X::File::NotFound/X::NotFoundInRepository
09:29
lizmat m: sub a(Int :@a) { dd @a }; a 10:33
camelia Array[Mu].new()
lizmat that feels like a bug to me
expected the array to be Array[Int] 10:34
m: sub a(Int :%a) { dd %a }; a
camelia (my Int %)
lizmat seems to work ok with hashes
m: sub a(Int :@a) { dd @a }; a (1,2,3) 10:36
camelia Too many positionals passed; expected 0 arguments but got 1
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a(Int :@a) { dd @a }; a a => (1,2,3)
camelia Type check failed in binding to parameter '@a'; expected Positional[Int] but got List ((1, 2, 3))
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat so it does know about it somehow>?
bisectable6: sub a(Int :@a) { dd @a }; a 10:37
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/ae97f5421fb39ac27e...e22014a192
lizmat, More than 4 changes to bisect, please try a narrower range like old=2021.12 new=HEAD
lizmat bisectable6: old=2020.06 new=2020.07 sub a(Int :@a) { dd @a }; a 10:38
bisectable6 lizmat, Bisecting by output (old=2020.06 new=2020.07) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/ee07f2752b3537796b...3ad7cc2ab1 10:39
lizmat, (2020-07-09) github.com/rakudo/rakudo/commit/90...d7784c6a17
CIAvash ok. another question, `pos` is avaialable in JSON error output(for some error messages), but all `column` fields are `null`, why is that? column is also not reported in text error messages 10:44
lizmat CIAvash which JSON module are you referring to ? 10:46
Geth rakudo: dcb0ac0998 | (Elizabeth Mattijsen)++ | src/core.c/Array/Typed.pm6
Fix typed named argument arrays not reporting type correctly

This refines 90f86d4c9154898f5e081fa944f222d7784c6a17 in that it will first try the original code path, and if that fails does the code path from that commit to fix #3784
This fixes the output of "sub a(Int :@a) { dd @a }; a" from
   Array[Mu].new()
to
   Array[Int].new()
10:54
CIAvash sorry, I meant JSON output of rakudo errors, output of `RAKU_EXCEPTIONS_HANDLER=JSON raku -c` 10:55
lizmat ah, ok, so that'd be the internal one 10:57
CIAvash: I guess an issue is in order then :-)
m: sub a(Int @a is copy) { dd @a }; a Array[Int].new: 1,2,3 10:58
camelia [1, 2, 3]
lizmat looks like "is copy" loses typing
bisectable6: sub a(Int @a is copy) { dd @a }; a Array[Int].new: 1,2,3 10:59
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/3a8a483f8c977fe8fd...48a42e5a0e
lizmat, bisect log: gist.github.com/66accc32da775f0444...891f110565
lizmat, Output on all releases and bisected commits: gist.github.com/e62eff790d569ed0bd...f86b25dd4f
lizmat ok, looks like an issue like forever 11:00
github.com/rakudo/rakudo/issues/4882 11:18
Geth rakudo/lizmat-binder-elsifs: 77ef4fac75 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Turn some else/if sequences into elsifs in binder

Probably not very important, but since the binder is pretty hot code I thought it might be worthwhile.
12:08
rakudo: lizmat++ created pull request #4883:
Turn some else/if sequences into elsifs in binder
12:09
Geth rakudo/lizmat-attribute-binder: bfc052afbb | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Micro optimize "self" lookup for attribute binding

Assuming in most cases, the search is successful, it makes more sense to just do the nqp::atkey and if that fails, then do the error handling. Instead of first looking up whether it exists at all, and then do another lookup if the first check is successful.
12:34
¦ rakudo/lizmat-attribute-binder: review: github.com/rakudo/rakudo/commit/bfc052afbb 12:35
rakudo: lizmat++ created pull request #4884:
Micro optimize "self" lookup for attribute binding
[Coke] github.com/Raku/doc/issues/1246 - 164.90.207.89:10010/ has an updated version of the docs site. Any comments on it definitely appreciated (it's a dynamic site with updates to the UI, search, etc.). Please feel free to comment here or to me and I can summarize on the ticket, or add to the ticket directly (or the linked website repo) 13:55
Please go easy on the site since it's privately hosted (no automation, I mean)
er, don't *run* automated stuff against it, I mean. 13:56
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
jdv lizmat: did you noticed the blin stuff? the bisects seem to hint at your stuff. 15:15
been a bit too busy lately. will try to get the changelogs out by tomorrow some time. probably do a blin run on wed or thurs. maybe a release on friday:) 15:16
[Coke] jdv: I uncommented a skipped test in nqp, so if you see a new failure in there, that might be the culprit 15:22
m: say "../\x[308]" 15:24
camelia ../̈
[Coke] why is github.com/raku-community-modules/...hildSecure using nqp:: opcodes? 15:28
there should definitely be a comment explaining that in the lib, and we shouldn't be encouraging it outside of core, IMO 15:29
should probably also remove MONKEY-GUTS and use nqp only. 15:30
nine I don't see a reason why that code would need nqp. I guess it's really just a modified copy of code from the setting 15:31
japhb nine: Might be the other way around -- IIRC IO-Path-ChildSecure was published before improved code went into the setting. 15:32
Geth IO-Path-ChildSecure: coke++ created pull request #4:
respect OS directory separator for combiner test
15:52
[Coke] added github.com/raku-community-modules/...e/issues/5 15:53
Geth roast: vrurg++ created pull request #804:
Add tests for `will complain`
23:47