Xliff MasterDuke: Don't know. Didn't know about it until you mentioned it. 00:41
I'll have to take a look at it, later.
Xliff I've been stuck in the weeds for hours with no solution. 00:41
Xliff MasterDuke: Thanks for letting me know, though! :) 00:42
Xliff gist.github.com/Xliff/b27f77e33539...9c28c4ed68 <- Help, please? 08:34
nine Xliff: yes, runtime is too late. Also this sounds like a question better suited for #raku 08:36
lizmat Files=1336, Tests=113586, 223 wallclock secs (29.62 usr 8.48 sys + 3102.68 cusr 288.28 csys = 3429.06 CPU) 08:57
Xliff nine: Thanks. I've posted this twice in raku and no one responded.
So I would have to implement a run-time version of handles, then? 08:58
nwc10 Is there an easy Rakudo way to generate the sort of information that is in: 09:21
This is perl 5, version 16, subversion 3 (v5.16.3) built for ppc64-linux-thread-multi
particularly the architecture thingy (versions are boring) 09:22
alhgough I guess that Perl 5 has more "fun" in its architecture, because "thread" and "multi" are both Configure-time choices
whereas MoarVM is MoarVM is MoarVM
lizmat nwc10: perhaps somewhere in say .key ~ ": " ~ .value for $*VM.config.pairs.sort ? 09:29
nwc10 $*VM.config.<osvers> seems to be the most useful 09:31
OK, interesting. 09:32
nothing in $*VM.config seems to be able to report whether MoarVM is built with a 32 or 64 bit ABI
that's probably actually a bug. 09:33
because it's possible to build either on (at least) x86_64, ppc64 and sparc64 (And I assume also mips64 and aarch64)
and we have no way of filtering user bug reports based on which way someone else built their MoarVM
in that, I have build rakdudo on both 3.10.0-957.27.2.el7.ppc64 and 3.10.0-957.27.2.el7.ppc64 :-) 09:35
spot the difference.
and, even more WTF - I've built it for: 4.19.0 09:40
(ooh, and my local machine reports 4.9.0)
I'm not even sure *where* theose numbers are coming from. I guess I should go did, as they are considerably LTA 09:41
chocolate-teapot LTA
MasterDuke nwc10: does the `-V` option to raku show anything useful? 10:21
lizmat MasterDuke: afaik, that just dumps $*VM.config 10:22
?
nine We probably also want to report whether rakudo is build relocatably 10:43
Geth rakudo: lizmat++ created pull request #3907:
Parallel module install
11:05
[TuxCM] Rakudo version 2020.08.2-59-ge65466fcd - MoarVM version 2020.08-91-g590bac47e
csv-ip5xs0.968 - 0.991
csv-ip5xs-2010.161 - 10.177
csv-parser25.464 - 27.605
csv-test-xs-200.390 - 0.390
test7.752 - 7.885
test-t1.899 - 1.928
test-t --race0.847 - 0.927
test-t-2033.178 - 33.938
test-t-20 --race9.170 - 9.858
11:16
Geth ¦ problem-solving: tbrowder assigned to rba Issue Add a Raku blog site as "blogs.raku.org" github.com/Raku/problem-solving/issues/231 11:52
¦ problem-solving: lizmat unassigned from rba Issue Add a Raku blog site as "blogs.raku.org" github.com/Raku/problem-solving/issues/231 11:54
Kaiepi with my dns pr, i find myself having to go back and redo chunks of changes every now and then when i change my mind about how parts of it should work, which wastes a lot of time 12:45
i skimmed over jnthn++'s rakuast pr and noticed he hardly does anything like this though... are there things you guys do to avoid this?
ugexe m: say $*KERNEL.arch 12:57
camelia x86_64
tellable6 2020-09-01T14:05:54Z #raku <[Coke]> ugexe do you accept tony-o's nomination, btw?
MasterDuke Kaiepi: i often change stuff too, but it isn't always visible because i may do a lot of local rebasing/merging/deleting/etc commits before pushing 13:24
Kaiepi ah 13:37
nine Kaiepi: from what I know jnthn takes much time to think things through before starting with the implementation. See for example his design documents for the new dispatching mechanism in MoarVM 13:38
Personally I have two distinct modes of operation, depending on my familiarity with the subject. When designing an API I also like to take much time beforehand, preferrably away from the keyboard to get at a good design. This is for an area where I know most of what's involved. 13:42
The other way is a kind of exploratory implementation, where I discover mostly through trial and error. That's for areas where I lack most of the expertise like "let's jump in and fix BEGIN time EVAL" 13:43
In the latter case git rebase -i is my best friend :) 13:44
[Coke] Reminder: Voting for RSC is open 16:14
Geth rakudo/rakuast: 926e02904c | (Jonathan Worthington)++ | 4 files
RakuAST handling of dotty infixen (`.`, `.=`)

This handles the cases where they are parsed as infixes.
16:31
Geth rakudo/rakuast: df8f7b28ae | (Jonathan Worthington)++ | 6 files
RakuAST handling of capture terms
17:10
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/09/07/2020-...ime-again/ 21:15
[Coke] lizmat++ 22:14