[03:15] *** lucasb left [04:52] *** tyil left [04:53] *** raku-bridge left [04:54] *** raku-bridge joined [04:54] *** raku-bridge left [04:54] *** raku-bridge joined [04:54] *** raku-bridge1 joined [04:54] *** raku-bridge1 left [04:54] *** raku-bridge1 joined [04:55] *** Geth_ joined [04:58] *** raku-bridge left [04:58] *** raku-bridge1 is now known as raku-bridge [05:00] *** maggotbrain left [05:07] *** raku-bridge1 joined [05:10] *** Geth left [05:12] *** tyilanmenyn joined [05:12] *** raku-bridge1 left [05:24] *** Geth joined [05:28] *** raku-bridge2 joined [05:28] *** raku-bridge2 left [05:28] *** raku-bridge2 joined [05:33] *** raku-bridge2 left [05:37] *** raku-bridge3 joined [05:37] *** raku-bridge3 left [05:37] *** raku-bridge3 joined [05:39] *** raku-bridge3 left [05:40] *** raku-bridge4 joined [05:40] *** raku-bridge4 left [05:40] *** raku-bridge4 joined [05:41] *** tyildesu joined [06:17] *** tyilanmenyn is now known as tyil [07:09] *** [Tux] left [07:17] *** [Tux] joined [07:36] *** JJMerelo joined [07:48] *** sena_kun joined [07:51] ¦ rakudo/JJ-patch-1: 11afa53b32 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp [07:51] ¦ rakudo/JJ-patch-1: Add read-from-input option, closes #3743 [07:51] ¦ rakudo/JJ-patch-1: review: https://github.com/rakudo/rakudo/commit/11afa53b32 [07:51] ¦ rakudo: JJ++ created pull request #3744: Add read-from-input option, closes #3743 [07:51] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3744 [07:51] RAKUDO#3743 [open]: https://github.com/rakudo/rakudo/issues/3743 Behavior of (raku -) command [08:00] .tell patrickb what's with these pipeline errors? https://dev.azure.com/Rakudo/rakudo/_build/results?buildId=117&view=logs&j=2db7a664-d2d0-5ac0-d075-a564c179f8bb&t=9b1b8be0-c42d-510a-e0a4-326d15e1fa02&l=9 [08:00] JJMerelo, I'll pass your message to patrickb [08:09] *** Altai-man_ joined [08:12] *** sena_kun left [08:30] .tell MasterDuke the blin problem is still here with the patch suggested yesterday. [08:30] Altai-man_, I'll pass your message to MasterDuke [08:34] Files=1306, Tests=111376, 215 wallclock secs (28.97 usr 8.27 sys + 3012.17 cusr 281.46 csys = 3330.87 CPU) [08:57] ¦ rakudo: 999d04aae5 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.pm6 [08:57] ¦ rakudo: Don't check whether to actually close when calling .close [08:57] ¦ rakudo: [08:57] ¦ rakudo: 61046d7695615d67 unified some logic regarding closing of file handles. [08:57] ¦ rakudo: Unfortunately, that broke the semantics regarding .lock/.unlock, [08:57] ¦ rakudo: specifically wrt closing a locked file. Fixed by undoing the unification [08:57] ¦ rakudo: of that logoc: only DESTROY will now not close an open handle if it was [08:57] ¦ rakudo: told not to do so. An explicit call to .close will *always* close the [08:57] ¦ rakudo: file handle. Spotted by ugexe++. Fixes #3742 [08:57] RAKUDO#3742 [closed]: https://github.com/rakudo/rakudo/issues/3742 New IO::Handle auto-closing logic is broken [08:57] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/999d04aae5 [08:59] Altai-man_: hm, well i think it's a needed change anyway. but maybe 999d04aae5 fixes it [08:59] (2020-06-04) https://github.com/rakudo/rakudo/commit/999d04aae5 Don't check whether to actually close when calling .close [08:59] 2020-06-04T08:30:24Z #raku-dev MasterDuke the blin problem is still here with the patch suggested yesterday. [09:01] *** JJMerelo left [09:01] Oh, very interesting. [09:03] ¦ rakudo: 11afa53b32 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp [09:03] ¦ rakudo: Add read-from-input option, closes #3743 [09:03] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/11afa53b32 [09:03] ¦ rakudo: 8509621b41 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Compiler.nqp [09:03] ¦ rakudo: Merge pull request #3744 from rakudo/JJ-patch-1 [09:03] ¦ rakudo: [09:03] ¦ rakudo: Add read-from-input option, closes #3743 [09:03] RAKUDO#3743 [closed]: https://github.com/rakudo/rakudo/issues/3743 Behavior of (raku -) command [09:03] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/8509621b41 [09:12] *** leont joined [09:25] ¦ nqp: 59c6124d08 | (Elizabeth Mattijsen)++ | src/HLL/Compiler.nqp [09:25] ¦ nqp: Start up REPL if "-" given *and* STDIN is a tty [09:25] ¦ nqp: [09:25] ¦ nqp: This mimics the Python behaviour: when started with "-" as the single [09:25] ¦ nqp: positional parameter, it will check if STDIN is connected to a terminal. [09:25] ¦ nqp: If so, it will start up the REPL, else it will start processing whatever [09:25] ¦ nqp: is given on STDIN. [09:25] ¦ nqp: review: https://github.com/Raku/nqp/commit/59c6124d08 [09:40] ¦ rakudo: 83b2a15cd4 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION [09:40] ¦ rakudo: Bump NQP to get new "-" behaviour [09:40] ¦ rakudo: [09:40] ¦ rakudo: When you start Raku with "-" as a single positional parameter, it [09:40] ¦ rakudo: will now check if STDIN is connected to a terminal. If it is, then [09:40] ¦ rakudo: the REPL will be started, rather than appearing to freeze waiting [09:40] ¦ rakudo: for the user to enter something and issue an EOF. If STDIN is *not* [09:40] ¦ rakudo: connected to a terminal, then Raku will read from STDIN and process [09:40] ¦ rakudo: that as the source of a program. [09:40] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/83b2a15cd4 [09:55] ¦ rakudo: 45df9bc423 | (Elizabeth Mattijsen)++ | src/Perl6/Compiler.nqp [09:55] ¦ rakudo: Adapt usage to reflect new "-" behaviour [09:55] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/45df9bc423 [09:55] *** tyildesu left [09:56] *** tyilanmenyn joined [09:57] *** zostay left [09:57] *** zostay joined [10:10] *** sena_kun joined [10:12] *** Altai-man_ left [10:31] re: https://stackoverflow.com/questions/62188938/how-does-raku-deal-with-the-diamond-problem/62192483#62192483 [10:31] I wonder whether we couldn't use some syntactic sugar for: [10:31] BEGIN D.^add_method("speak",C.^find_method("speak")); [10:32] method speak is alias-of(C) { } [10:37] `method speak(|c) { self.C::speak(|c) }` is shorter [10:38] Also, C::speak style dispatches are already quite well optimized [10:38] The capture bit less so, but I'd rather just speed that up than pile on yet more syntax. [10:45] <[Tux]> Rakudo version 2020.05.1-237-g45df9bc42 - MoarVM version 2020.05-28-g2922f3d1a [10:45] <[Tux]> csv-test-xs-20 0.386 - 0.400 [10:45] <[Tux]> test-t --race 0.807 - 0.828 [10:45] <[Tux]> csv-ip5xs 0.824 - 0.891 [10:45] <[Tux]> test-t 1.963 - 1.975 [10:45] <[Tux]> csv-ip5xs-20 8.100 - 8.474 [10:45] <[Tux]> test 7.579 - 8.483 [10:45] <[Tux]> test-t-20 --race 9.080 - 9.597 [10:45] <[Tux]> csv-parser 26.512 - 28.265 [10:45] <[Tux]> test-t-20 31.652 - 32.636 [10:46] *** lizmat left [10:50] (Also, if we did, `alias-of` is a bit awkward there in that it leaves the question of "what is the method body about"...) [10:51] In principle though, with the capture stuff better optimized, the overhead could inline away [11:02] *** lizmat joined [11:13] ¦ rakudo: 8cbd4e47b0 | LLFourn++ | src/Perl6/World.nqp [11:13] ¦ rakudo: Fix RT #126759 [11:13] ¦ rakudo: [11:13] ¦ rakudo: create a sneaky lexical EXPORTHOW package so if you do: [11:13] ¦ rakudo: [11:13] ¦ rakudo: use MyDeclarator; [11:13] ¦ rakudo: EVAL 'my-declarator my-class { }' [11:13] ¦ rakudo: [11:13] ¦ rakudo: it will work because my-declarator is available in %*HOW in EVAL [11:13] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/8cbd4e47b0 [11:13] ¦ rakudo: 3ad8fedf76 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/World.nqp [11:13] ¦ rakudo: Merge pull request #613 from LLFourn/eval_exporthow [11:13] ¦ rakudo: [11:13] ¦ rakudo: Fix RT #126759 [11:13] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3ad8fedf76 [11:21] Hm, that's a cute fix [11:24] Hmm...though I wonder if it might accidentally cause a module to leak its EXPORTHOWs [11:24] e.g. if I `use OO::Monitors` in a module M, I get `monitor` available. But if something uses M then it does not get monitor (good since we don't want language tweaks to "escape") [11:25] I'm not able to convince myself either way if the PR changes that as a side-effect of its desirable behavior of fixing EVAL [11:25] (I'd try it, but my build is in quite a few pieces...) [11:25] ¦ rakudo: lizmat self-assigned @a[-42..∞]:delete does not work https://github.com/rakudo/rakudo/issues/3658 [11:26] jnthn: merging that was a mistake, reverting [11:27] lizmat: Feel free to assign it to me [11:27] ¦ rakudo: a0efef5ead | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp [11:27] ¦ rakudo: Revert fix for RT #126759 [11:27] ¦ rakudo: [11:27] ¦ rakudo: It broke Inline::Perl5 and probably others such as OO::Monitors. [11:27] ¦ rakudo: Sorry for the noise. [11:27] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a0efef5ead [11:28] Did it actaully break OO::Monitors? [11:28] Wow [11:28] That I didn't expect [11:28] no, it broke Inline::Perl5 for sure [11:28] you want me to assign 3658 to you, or the old RT one ? [11:28] Ah, perhaps due to the leakage I mentioned. [11:28] The PR [11:29] I have to rework those things a bit in RakuAST anyway [11:29] I'll assign the #126759 to you then [11:30] Works for me [11:34] rba: https://rakudo.org/bugs is a 404 [11:34] https://rt.perl.org has a link to that for "Rakudo Bugs" [11:35] perhaps redirect to https://github.com/rakudo/rakudo/issues ? [11:37] lizmat, redirect to https://rakudo.org/issue-trackers could be better [11:37] probably, sena_kun++ [11:53] *** leont left [12:05] *** leont joined [12:09] *** Altai-man_ joined [12:11] *** sena_kun left [12:19] * jnthn back [12:31] *** raku-bridge2 joined [12:31] *** raku-bridge2 left [12:31] *** raku-bridge2 joined [12:31] *** MasterDuke left [12:31] *** raku-bridge5 joined [12:31] *** raku-bridge5 left [12:31] *** raku-bridge5 joined [12:31] *** lizmat_ joined [12:32] *** dogbert11 joined [12:32] *** Kaeipi joined [12:33] *** nebuchad` joined [12:36] *** lizmat left [12:36] *** raku-bridge4 left [12:36] *** raku-bridge left [12:36] *** Kaiepi left [12:36] *** nebuchadnezzar left [12:36] *** Geth left [12:36] *** tyil left [12:36] *** sivoais left [12:36] *** dogbert17 left [12:36] *** krunen left [12:36] *** tyildesu joined [12:36] *** sivoais joined [12:36] *** tyildesu left [12:36] *** tyildesu joined [12:36] *** sivoais left [12:36] *** sivoais joined [12:37] *** raku-bridge2 is now known as raku-bridge [12:37] *** krunen joined [12:49] *** tyildesu is now known as tyil [12:49] *** lizmat_ is now known as lizmat [12:57] ¦ rakudo/new-disp: de50a36c7e | (Jonathan Worthington)++ | 3 files [12:57] ¦ rakudo/new-disp: Start using dispatcher for return value type check [12:57] ¦ rakudo/new-disp: [12:57] ¦ rakudo/new-disp: This does not yet handle the coercions case yet, but otherwise seems to [12:57] ¦ rakudo/new-disp: work quite decently. (For now, requires that spesh is disabled, since so [12:57] ¦ rakudo/new-disp: far MoarVM doesn't handle spesh with dispatchers.) [12:57] ¦ rakudo/new-disp: review: https://github.com/rakudo/rakudo/commit/de50a36c7e [13:04] ¦ roast: 8943531beb | (Elizabeth Mattijsen)++ | S32-io/slurp.t [13:04] ¦ roast: Add tests for R#3566 [13:04] ¦ roast: review: https://github.com/Raku/roast/commit/8943531beb [13:04] R#3566 [open]: https://github.com/rakudo/rakudo/issues/3566 [tests needed] Unexpected, slurp(:bin) returns type Str [13:09] *** nebuchad` is now known as nebuchadnezzar [13:15] ¦ rakudo: lizmat assigned to jnthn Issue Looping sized native typed array is slow https://github.com/rakudo/rakudo/issues/3532 [13:47] ¦ rakudo/new-disp: 30c27c71ba | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp [13:47] ¦ rakudo/new-disp: Start sketching out some more dispatchers [13:47] ¦ rakudo/new-disp: review: https://github.com/rakudo/rakudo/commit/30c27c71ba [13:48] *** MasterDuke joined [14:06] *** patrickb joined [14:10] *** sena_kun joined [14:12] *** Altai-man_ left [14:29] *** MasterDuke left [14:45] ¦ rakudo: 4ba70b7a4b | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6 [14:45] ¦ rakudo: Make constants real code objects with proper sigil [14:45] ¦ rakudo: [14:45] ¦ rakudo: No functional change, but these are needed as actually callable things [14:45] ¦ rakudo: for some upcoming optimizations [14:45] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/4ba70b7a4b [15:13] *** raku-bridge5 left [15:13] *** tyilanmenyn left [15:22] *** JJMerelo joined [15:22] *** MasterDuke joined [15:33] *** travis-ci joined [15:33] Rakudo build errored. Elizabeth Mattijsen 'Make constants real code objects with proper sigil [15:33] https://travis-ci.org/rakudo/rakudo/builds/694681602 https://github.com/rakudo/rakudo/compare/a0efef5ead10...4ba70b7a4bce [15:33] *** travis-ci left [16:00] ¦ nqp/new-disp: 358c0de0f8 | (Jonathan Worthington)++ | t/moar/53-dispatch.t [16:00] ¦ nqp/new-disp: Test basic use of dispatcher-track-attr [16:00] ¦ nqp/new-disp: review: https://github.com/Raku/nqp/commit/358c0de0f8 [16:09] *** Altai-man_ joined [16:12] *** sena_kun left [16:30] *** JJMerelo left [17:04] *** maggotbrain joined [17:15] *** ShimmerFairy left [17:18] *** ShimmerFairy joined [17:26] *** patrickb left [18:10] *** sena_kun joined [18:12] *** Altai-man_ left [18:46] *** lichtkind joined [19:02] ¦ rakudo: 9fe471cf1c | (Christian Bartolomäus)++ | src/core.c/IO/Handle.pm6 [19:02] ¦ rakudo: Unbreak the JVM and JS build [19:02] ¦ rakudo: [19:02] ¦ rakudo: The referenced variable $openend and method !forget-about-closing [19:02] ¦ rakudo: are only defined for the MoarVM backend. With 999d04aae5 they [19:02] ¦ rakudo: were used on other backends, too. This patch should restore [19:02] ¦ rakudo: the state from 61046d7695^ for the JVM and JS backend. [19:02] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/9fe471cf1c [19:09] bartolin++ [19:11] lizmat++ MasterDuke++ The issue with locking is fixed! I'm posting a round ticket... [19:20] nice. lizmat++ [19:31] ¦ rakudo: Altai-man assigned to lizmat Issue Blin 2020.06, round 1 https://github.com/rakudo/rakudo/issues/3745 [19:39] *** squashable6 left [19:40] *** squashable6 joined [19:43] sena_kun: looks nice [19:44] except all of the problems seem to be caused by my commits [19:44] I guess that's only fair, since I did produce the most commits since the last release :-) [19:44] *** squashable6 left [19:45] lizmat++ :) [19:45] *** squashable6 joined [19:55] ¦ rakudo: 496e91663c | (Elizabeth Mattijsen)++ | src/core.c/List.pm6 [19:55] ¦ rakudo: Slightly improve error message [19:55] ¦ rakudo: [19:55] ¦ rakudo: cross( (1,2,3), (4,5,6), :with(42) ) would die with the perplexing [19:55] ¦ rakudo: error message: "Unexpected named argument 'with' passed". This is [19:55] ¦ rakudo: caused by the candidate that *does* accept :with has a Callable [19:55] ¦ rakudo: constraint on it. And since 42 is not a Callable, that candidate [19:55] ¦ rakudo: is not selected, so the next candidate is, except for the fact that [19:55] ¦ rakudo: <…commit message has 11 more lines…> [19:55] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/496e91663c [20:09] *** Altai-man_ joined [20:11] *** sena_kun left [20:18] Oh, so much progress :) I finally got past my issue with lexicals. And understand the issue that I was trying to solve in the first place [20:21] bisectable6: old=2020.02 dir "/tmp", :test(&say) [20:21] lizmat, Bisecting by output (old=2020.02 new=496e916) because on both starting points the exit code is 0 [20:22] lizmat, bisect log: https://gist.github.com/dbe855a5a1ae48bc8f75ececd5c04195 [20:22] lizmat, (2020-02-22) https://github.com/rakudo/rakudo/commit/6354c9155ae0f6deb5722045304cd6e424460bca [20:22] bisectable6: old=2020.05 dir "/tmp", :test(&say) [20:22] lizmat, Bisecting by output (old=2020.05 new=496e916) because on both starting points the exit code is 0 [20:22] lizmat, bisect log: https://gist.github.com/adbda37525a7e1644c953c68df7ebba7 [20:22] lizmat, (2020-05-03) https://github.com/rakudo/rakudo/commit/2b6a5829aebd2602310451507bb55ea48530fc19 [20:23] clearly that's not working :-( [20:23] bisectable6: old=2020.05 dir "/tmp", :test( { die if $_ eq "." } ) [20:23] lizmat, On both starting points (old=2020.05 new=496e916) the exit code is 1 and the output is identical as well [20:23] lizmat, Output on both points: «Died␤ in block at /tmp/cJwhz6xrCE line 1␤␤» [20:24] bisectable6: old=2020.02 dir "/tmp", :test( { die if $_ eq "." } ) [20:24] lizmat, On both starting points (old=2020.02 new=496e916) the exit code is 1 and the output is identical as well [20:24] lizmat, Output on both points: «Died␤ in block at /tmp/7_uBc97Uj9 line 1␤␤» [20:29] bisectable6: old=2020.05 dd "/proc/cpuinfo".IO.slurp [20:29] lizmat, Bisecting by output (old=2020.05 new=496e916) because on both starting points the exit code is 0 [20:29] lizmat, bisect log: https://gist.github.com/3568748241006fa63f043fc3b1c10872 [20:29] lizmat, (2020-05-03) https://github.com/rakudo/rakudo/commit/2b6a5829aebd2602310451507bb55ea48530fc19 [20:30] m: dd "/proc/cpuinfo".IO.slurp [20:30] rakudo-moar 496e91663: OUTPUT: «""␤» [20:30] m: dd "/proc/cpuinfo".IO.lines [20:30] rakudo-moar 496e91663: OUTPUT: «("processor\t: 0", "vendor_id\t: GenuineIntel", "cpu family\t: 6", "model\t\t: 6", "model name\t: QEMU Virtual CPU version 2.1.0", "stepping\t: 3", "microcode\t: 0x1", "cpu MHz\t\t: 3411.482", "cache size\t: 4096 KB", "physical id\t: 0", "siblings\t: …» [20:32] m: dd "/proc/cpuinfo".IO.e [20:32] rakudo-moar 496e91663: OUTPUT: «Bool::True␤» [20:48] ¦ rakudo/new-disp: 4e9fe020dd | (Jonathan Worthington)++ | 2 files [20:48] ¦ rakudo/new-disp: Move to a dispatcher for return value decont [20:48] ¦ rakudo/new-disp: [20:48] ¦ rakudo/new-disp: Instead of the spesh plugin. Has almost all the functionality, missing [20:48] ¦ rakudo/new-disp: only the v6.c rw/Proxy bug compatibility. [20:48] ¦ rakudo/new-disp: review: https://github.com/rakudo/rakudo/commit/4e9fe020dd [20:52] So, to give code objects created by BEGIN time EVAL access to the setting, I need to add a load_setting call and forceouterctx. These go into a deserialization frame. I now share these between nested compilers, so they actually get used. But this also causes the outer's tasks to leak in. [20:53] And then an EVAL tries to forceouterctx with a block that's not finished compiling yet [20:53] So I must not share the list but add the inner's task to the outer's when done [20:53] Same as with the frames list (which is why I got those lexical errors) [20:58] nine: Hmm, how does the BEGIN-time EVAL get to see symbols that are declared in the scope of the BEGIN block? [20:58] Uh, that was unclear. I mean the scopes between the setting and the BEGIN? [20:58] class C { }; BEGIN EVAL 'C.new' [20:59] Well, the C is a WVal so it's a bad example maybe... [21:01] jnthn: EVAL does a forceouterctx [21:01] But that only works at runtime. Doesn't do much good for BEGIN EVAL 'sub foo() { say "yes" }' [21:01] Indeed [21:03] I mean more like `sub foo() { "hello " }; my &x = BEGIN EVAL 'sub bar() { say foo() ~ "world" }'; x() [21:03] ` [21:03] So I now know how to solve making the setting available. Not so sure about an outer context as like I said, that's not even compiled at that time [21:03] Yeah, that's the thorny issue :S [21:03] I guess that'd require defering compilation of that deserialize frame to the very end [21:04] Well, it's either that, or we have to look a bit deeper to if we're missing a primitive. [21:05] I mean, it'd be nice if we could let the runtime (and serialization) know about scopes we're going to be compiling later, but we ain't done with yet. [21:05] Then when we do compile them later, it's "filling in" the thing we promised with an implementation. [21:06] That's kinda-ish what the whole markcodestub (iirc) thing was trying to achieve but...maybe it's not sufficient. [21:07] Or in between. compile_node(QAST::BVal $bv, :$want) could just not die in case it doesn't find the corresponding mast_frame, but instead take a note of the place in the bytecode where it wanted to store the reference and put it into a list for filling later [21:07] Hm, intersting. [21:11] Compared to the whole SubBuffer dance I had to do for compiling frames in the first place, that sounds downright trivial [21:12] Oh, and we already have exactly the same case with labels. Which often are referenced before they actually put into the bytecode [21:12] I've been starting to ponder this space a bit, 'cus the RakuAST work is going to end up touching on all these bits too [21:14] (So I'm really glad I've got somebody to ask who understands how it works today :)) [21:15] There's a few things I'd really like to try and get rid of, including the double-compilation of role bodies [21:15] And the massive fake outer frame that we build up when doing a BEGIN that has All The Things in it [21:16] I'm sure there's at least 10% of CORE.setting compilation time reduction to be had on that [21:17] ¦ rakudo: cde948aee0 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6 [21:17] ¦ rakudo: Fix IO::Path.slurp for special files [21:17] ¦ rakudo: [21:17] ¦ rakudo: If a file claimed it only had 0 bytes, then no attempt would be made [21:17] ¦ rakudo: to actually read from that file. This semantic however broke the [21:17] ¦ rakudo: Linux::Cpuinfo module in the ecosystem, because that is trying to [21:17] ¦ rakudo: read the /proc/cpuinfo special file that does not claim to consist [21:17] ¦ rakudo: of any data. [21:17] ¦ rakudo: [21:17] ¦ rakudo: Now, if a file claims to have 0 bytes, then it will be read in 1M [21:17] ¦ rakudo: increments until it produces less than that. This should fix [21:17] ¦ rakudo: Linux::Cpuinfo, but alas, cannot verify as committer is on MacOS. [21:17] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/cde948aee0 [21:20] afk& [21:22] jnthn: yeah, I've wondered how long I'll be able to work in this space before I've got to rethink that All The Things frame. So far I got away with just a minor adjustment [21:33] oooo, potential 10% reduction in CORE.setting compilation time!!! nice [22:10] *** sena_kun joined [22:12] *** Altai-man_ left [22:35] *** zostay left [22:36] *** chansen_ left [22:37] *** tbrowder left [22:37] *** SmokeMachine left [22:38] *** chansen_ joined [22:38] *** SmokeMachine joined [22:39] *** tbrowder joined [22:40] *** zostay joined [23:26] *** sena_kun left