[00:00] *** MasterDuke left [00:03] *** sena_kun joined [00:05] *** Altai-man_ left [01:22] *** lizmat left [01:28] *** lizmat joined [02:02] *** Altai-man_ joined [02:05] *** sena_kun left [04:03] *** sena_kun joined [04:04] *** Altai-man_ left [06:02] *** Altai-man_ joined [06:05] *** sena_kun left [06:22] *** stoned75 joined [06:32] AlexDaniel`: reading through yesterday's discussion, there's 2 take aways for me: whenever the discussion is about "Raku is bloated crap and we need to re-do it", the discussion gets nowhere. On the other hand the two concrete issues (regex performance and ...) got lots of attention and productive discussions. [06:54] *** kawaii left [06:55] *** zostay left [06:56] *** kawaii joined [06:57] *** zostay joined [07:13] nine: so why does it go nowhere [07:13] Because we all went to bed :D [07:14] no, because people won't admit that it's crap and therefore there's no way of redoing things [07:14] Oh you meant the first part? Because its just not specific enough. The statement is too generic, invites argument, forces the reader to become defensive and doesn't even hint on any actionables. [07:15] as for productive discussions, I don't see how it's productive because rakudo didn't become 25 times faster for regex matching [07:15] All of us admitted freely and immediately that our regex performance sucks and that ... is a horrible mess. Several people even mentioned that they had a bunch of issues with Raku. [07:17] I just won't admit that Raku as such is crap as that's simply not true for me. As I mentioned at work we moved to it because it's simply better than Perl for us. And we got amazing things done with Perl to start with. [07:17] and I'm not saying that it should immediately, but productivity is generally measurable [07:18] I do hate our compilation time (thus regex performance) enough to have spent the past month or two on getting in-process precompilation running, so we at least get rid of the startup overhead. [07:19] nine: Did that make it into the mainline? [07:20] The thing about the regex engine is really just that it's probably the oldest part of rakudo, and hasn't seen a major overhaul since. But I know that jnthn has given it some thought already and seems to have ideas for how to improve it. And I wouldn't be surprised if that's his next project after new-dispatch and RakuAST [07:20] japhb: not yet. It's hard to get the final 5 % working, but I'm on it. [07:23] nine: Yeah, understood. [07:27] I guess that RakuAST will bring opportunities to improve regex performance, too, as it will make it easier to analyse the regex and detect that it doesn't need any magic at all, allowing for it to be compiled to something simpler. [07:28] AFAIK we don't statically optimize regexes at all. [07:35] we do [07:35] one of the biggest wins is perhaps turning a scan followed by a literal string into a proper search for needle-in-haystack [07:36] i.e. the same code we use for "index" that can skip, at best, the entirety of the string every step [07:38] and of course we optimize NFAs, which is the majority of time spent when adding new rules (like operators) to rakudo's grammar [08:01] holy crap, you do *not* want to run `yes` with Proc::Async if you're not going to soak up all the output quickly enough [08:02] 0.49user 2.38system 0:02.95elapsed 97%CPU (0avgtext+0avgdata 5768904maxresident)k [08:02] look at this growth rate [08:02] almost 6 gigs in about 3 seconds [08:03] *** sena_kun joined [08:04] *** Altai-man_ left [08:07] perhaps the on_read should unpermit itself if the queue of work items to be handled by the raku-level eventloop thread reaches, oh i dunno, 100k [08:07] takes about 5 seconds for that to happen in my example [08:12] i'm not sure where code should go that figures this out [08:15] Files=1307, Tests=113021, 216 wallclock secs (28.80 usr 8.19 sys + 3021.96 cusr 284.36 csys = 3343.31 CPU) [08:20] *** leont joined [08:28] *** dogbert17 left [08:38] <[Tux]> Rakudo version 2020.06-58-g16d24a212 - MoarVM version 2020.06-20-g187b4564e [08:38] <[Tux]> csv-test-xs-20 0.391 - 0.439 [08:38] <[Tux]> csv-ip5xs 0.821 - 0.843 [08:38] <[Tux]> test-t --race 0.832 - 0.902 [08:38] <[Tux]> test-t 1.881 - 2.184 [08:39] <[Tux]> test 7.492 - 7.811 [08:39] <[Tux]> csv-ip5xs-20 7.891 - 8.447 [08:39] <[Tux]> test-t-20 --race 9.285 - 9.698 [08:39] <[Tux]> csv-parser 25.397 - 26.205 [08:39] <[Tux]> test-t-20 31.894 - 32.480 [08:39] *** patrickb joined [08:42] ¦ rakudo: 305fc7bdfa | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6 [08:42] ¦ rakudo: Make IO::Path use its own .succ / .pred logic [08:42] ¦ rakudo: [08:42] ¦ rakudo: So it no longer depends on the Str.succ / .pred logic [08:42] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/305fc7bdfa [08:48] .tell rba: Can you teach me how to deploy changes to rakubrew.org myself and upload releases? I'd really like to be able to do them myself... [08:48] patrickb, I'll pass your message to rba [08:52] *** lichtkind joined [09:08] ¦ rakudo: 07009cc0dd | (Elizabeth Mattijsen)++ | 3 files [09:08] ¦ rakudo: Remove placeholder files [09:08] ¦ rakudo: [09:08] ¦ rakudo: These will probably not be needed, so remove them for now. [09:08] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/07009cc0dd [09:13] *** lichtkind_ joined [09:15] *** lichtkind left [09:26] timotimo: There's a permit mechanism I started adding for doing such backpressure control [10:02] *** Altai-man_ joined [10:05] *** sena_kun left [10:48] ¦ rakudo/rakuast: 8e561ebccc | (Elizabeth Mattijsen)++ | src/Raku/ast/README.md [10:48] ¦ rakudo/rakuast: Complete missing line [10:48] ¦ rakudo/rakuast: review: https://github.com/rakudo/rakudo/commit/8e561ebccc [10:56] ¦ rakudo/rakuast: f5ba45ebe3 | (Elizabeth Mattijsen)++ | src/Raku/ast/README.md [10:56] ¦ rakudo/rakuast: Fix spello [10:56] ¦ rakudo/rakuast: review: https://github.com/rakudo/rakudo/commit/f5ba45ebe3 [12:03] *** sena_kun joined [12:04] *** Altai-man_ left [12:48] *** Kaiepi left [12:51] *** Kaiepi joined [12:55] *** patrickb left [12:58] *** patrickb joined [13:54] *** [Coke] left [14:02] *** Altai-man_ joined [14:05] *** sena_kun left [14:21] *** TimToady left [14:29] *** camelia left [14:31] *** camelia joined [14:34] *** [Coke] joined [14:34] *** [Coke] left [14:34] *** [Coke] joined [14:43] *** TimToady joined [15:03] *** dogbert17 joined [16:03] *** sena_kun joined [16:05] *** Altai-man_ left [16:51] *** commavir_ joined [16:55] *** commavir left [16:55] *** commavir_ is now known as commavir [16:56] *** unclechu left [16:56] *** AlexDaniel` left [16:59] *** Geth left [17:01] *** AlexDaniel` joined [17:10] jnthn: aye, i've looked into that. i've written a super shitty patch that made the memory usage on that one workload very manageable, but it was literally "after stdout was tapped, set permit to like 128 every second using Supply.interval" [17:10] and that's not great for upstream :D [17:15] *** unclechu joined [17:23] *** patrickb left [18:01] *** Kaiepi left [18:02] *** Altai-man_ joined [18:04] *** sena_kun left [18:10] *** Kaiepi joined [18:35] *** stoned75 left [18:36] *** stoned75 joined [18:48] *** lichtkind_ left [18:48] *** lichtkind joined [19:15] *** lichtkind left [19:15] hmmm.... https://github.com/rakudo/rakudo/blob/master/src/core.c/CompUnit/Repository/FileSystem.pm6#L254 [19:15] *** lichtkind joined [19:16] why are we creating a new Distribution object, and then cloning that ? [19:23] <[Coke]> ... looks like to get a specific dist-id?? [19:24] <[Coke]> (don't know why) [19:41] a friend is scolding me for `run` being implemented using async i/o, because a user should expect the default mechanism for subprocesses to behave just like unix does [19:59] the options you have for the pipe lock problem are: "lock the program up, like the unix gods intended", "keep reading until the system crashes because it runs out of memory, which rakudo / moarvm currently do", or "drop data on the floor, a crime against the entirity of programmers" [20:03] *** sena_kun joined [20:05] *** Altai-man_ left [20:12] i'll be running an entire dnf system upgrade on my desktop, it'll take a couple of hours :( [20:13] *** Geth joined [20:14] ¦ nqp/try-smaller-moarop-mappers: 911eaa5048 | (Timo Paulssen)++ | 2 files [20:14] ¦ nqp/try-smaller-moarop-mappers: WIP on maybe saving a kilobyte or two in the moarop mappers [20:14] ¦ nqp/try-smaller-moarop-mappers: review: https://github.com/Raku/nqp/commit/911eaa5048 [20:15] ¦ rakudo/hyper_codegen: 9 commits pushed by (Timo Paulssen)++ [20:15] ¦ rakudo/hyper_codegen: d5f5b0980f | first sketch of code-gen for hyper op formulas in optimizer [20:15] ¦ rakudo/hyper_codegen: 74a002f51a | more hyperoptimizer, rewrite, add env var to turn on [20:15] ¦ rakudo/hyper_codegen: b0d0d2c8bf | implement proper size check and zip metaop [20:15] ¦ rakudo/hyper_codegen: 20d0fd7cdb | fix which argument gets extended by dwimmy ops [20:15] ¦ rakudo/hyper_codegen: 9dc4cb49a6 | support for dwimming single int or num values [20:15] ¦ rakudo/hyper_codegen: 645ff9fa36 | put bitwise ops in [20:15] ¦ rakudo/hyper_codegen: 9a764a228a | improve debug output a tiny bit [20:15] ¦ rakudo/hyper_codegen: 4274d38479 | put a comment because docs are good [20:15] ¦ rakudo/hyper_codegen: 0d5086e85e | initial impl of .reverse support [20:15] ¦ rakudo/hyper_codegen: review: https://github.com/rakudo/rakudo/compare/371a093cec3e...0d5086e85ebf [20:15] (^ just a rebase) [20:24] *** maggotbrain left [20:25] *** maggotbrain joined [20:42] ¦ rakudo: d4eef8d41c | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/FileSystem.pm6 [20:42] ¦ rakudo: Make sure we don't allow files with wrong extensions [20:42] ¦ rakudo: [20:42] ¦ rakudo: The check was on *without* the period, so allowing [20:42] ¦ rakudo: files like foo.barakumod [20:42] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/d4eef8d41c [20:45] <[Coke]> ^^ looks like the period was in the code, not the list, and you moved the period? [20:49] yeah, the second change was to accommodate that usage of @extensions [20:50] but there is also an ends-with test that is now correct [20:50] that didn't need any change itsel [20:50] f [20:51] <[Coke]> +1 [20:51] <[Coke]> Apologies for my half-assed review. :) [20:54] nooo... thanks! [20:54] I've been corrected many times by many people looking at my commits... :-) [21:00] I thought "barakumod" was a nice touch. [21:29] ¦ rakudo: f3b1c8dfd7 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/FileSystem.pm6 [21:29] ¦ rakudo: Re-imagine CompUnit::Repository::FileSystem!distribution [21:29] ¦ rakudo: [21:29] ¦ rakudo: - make sure extension precedence is rakumod / pm6 / pm, fixes R#3783 [21:29] ¦ rakudo: - split off the directory reading logic into a !dist-from-ls method [21:29] ¦ rakudo: - use for loops assigning to hashes rather than inline Pair creation [21:29] ¦ rakudo: - keep original comments as much as possible [21:29] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/f3b1c8dfd7 [21:29] R#3783 [open]: https://github.com/rakudo/rakudo/issues/3783 Raku loads Perl modules first when Raku modules have the same base name [21:41] *** tobs left [21:42] *** Akhil joined [21:43] *** Akhil left [21:50] *** tobs joined [22:02] *** Altai-man_ joined [22:05] *** sena_kun left [22:43] *** Voldenet left [22:52] *** Voldenet joined [22:52] *** Voldenet left [22:52] *** Voldenet joined [23:23] *** leont left