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
nine 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:32
06:54 kawaii left 06:55 zostay left 06:56 kawaii joined 06:57 zostay joined
AlexDaniel` nine: so why does it go nowhere 07:13
nine Because we all went to bed :D
AlexDaniel` no, because people won't admit that it's crap and therefore there's no way of redoing things 07:14
nine 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.
AlexDaniel` 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
nine 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.
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
AlexDaniel` and I'm not saying that it should immediately, but productivity is generally measurable
nine 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:18
japhb nine: Did that make it into the mainline? 07:19
nine 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.
japhb nine: Yeah, understood. 07:23
nine 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:27
AFAIK we don't statically optimize regexes at all. 07:28
timotimo 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
i.e. the same code we use for "index" that can skip, at best, the entirety of the string every step 07:36
and of course we optimize NFAs, which is the majority of time spent when adding new rules (like operators) to rakudo's grammar 07:38
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:01
0.49user 2.38system 0:02.95elapsed 97%CPU (0avgtext+0avgdata 5768904maxresident)k 08:02
look at this growth rate
almost 6 gigs in about 3 seconds
08:03 sena_kun joined 08:04 Altai-man_ left
timotimo 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
i'm not sure where code should go that figures this out 08:12
lizmat Files=1307, Tests=113021, 216 wallclock secs (28.80 usr 8.19 sys + 3021.96 cusr 284.36 csys = 3343.31 CPU) 08:15
08:20 leont joined 08:28 dogbert17 left
[Tux] Rakudo version 2020.06-58-g16d24a212 - MoarVM version 2020.06-20-g187b4564e
csv-ip5xs0.821 - 0.843
csv-ip5xs-207.891 - 8.447
csv-parser25.397 - 26.205
csv-test-xs-200.391 - 0.439
test7.492 - 7.811
test-t1.881 - 2.184
test-t --race0.832 - 0.902
test-t-2031.894 - 32.480
test-t-20 --race9.285 - 9.698
08:39 patrickb joined
Geth rakudo: 305fc7bdfa | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path use its own .succ / .pred logic

So it no longer depends on the Str.succ / .pred logic
patrickb .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
tellable6 patrickb, I'll pass your message to rba
08:52 lichtkind joined
Geth rakudo: 07009cc0dd | (Elizabeth Mattijsen)++ | 3 files
Remove placeholder files

These will probably not be needed, so remove them for now.
09:13 lichtkind_ joined 09:15 lichtkind left
jnthn timotimo: There's a permit mechanism I started adding for doing such backpressure control 09:26
10:02 Altai-man_ joined 10:05 sena_kun left
Geth rakudo/rakuast: 8e561ebccc | (Elizabeth Mattijsen)++ | src/Raku/ast/README.md
Complete missing line
rakudo/rakuast: f5ba45ebe3 | (Elizabeth Mattijsen)++ | src/Raku/ast/README.md
Fix spello
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, [Coke] left, [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, commavir_ is now known as commavir 16:56 unclechu left, AlexDaniel` left 16:59 Geth left 17:01 AlexDaniel` joined
timotimo 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, lichtkind joined 19:15 lichtkind left
lizmat hmmm.... github.com/rakudo/rakudo/blob/mast...m.pm6#L254 19:15
19:15 lichtkind joined
lizmat why are we creating a new Distribution object, and then cloning that ? 19:16
[Coke] ... looks like to get a specific dist-id?? 19:23
(don't know why) 19:24
timotimo 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:41
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" 19:59
20:03 sena_kun joined 20:05 Altai-man_ left
timotimo i'll be running an entire dnf system upgrade on my desktop, it'll take a couple of hours :( 20:12
20:13 Geth joined
Geth nqp/try-smaller-moarop-mappers: 911eaa5048 | (Timo Paulssen)++ | 2 files
WIP on maybe saving a kilobyte or two in the moarop mappers
rakudo/hyper_codegen: 9 commits pushed by (Timo Paulssen)++ 20:15
timotimo (^ just a rebase)
20:24 maggotbrain left 20:25 maggotbrain joined
Geth rakudo: d4eef8d41c | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Make sure we don't allow files with wrong extensions

The check was on <rakumod pm6 pm> *without* the period, so allowing files like foo.barakumod
[Coke] ^^ looks like the period was in the code, not the list, and you moved the period? 20:45
lizmat yeah, the second change was to accommodate that usage of @extensions 20:49
but there is also an ends-with test that is now correct 20:50
that didn't need any change itsel
[Coke] +1 20:51
Apologies for my half-assed review. :)
lizmat nooo... thanks! 20:54
I've been corrected many times by many people looking at my commits... :-)
rypervenche I thought "barakumod" was a nice touch. 21:00
Geth rakudo: f3b1c8dfd7 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Re-imagine CompUnit::Repository::FileSystem!distribution

  - make sure extension precedence is rakumod / pm6 / pm, fixes R#3783
  - split off the directory reading logic into a !dist-from-ls method
  - use for loops assigning to hashes rather than inline Pair creation
  - keep original comments as much as possible
linkable6 R#3783 [open]: 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, Voldenet left, Voldenet joined 23:23 leont left