🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
timo1 is anyone else surprised by the size of svgs for the typegraph in the docs being above a gigabyte apparently? 04:28
oh huh, this "announcements" feature on docs.raku.org is interesting, but are we showing that to every first-time user on their first visit? how about people who generally have cookies turned off or whatever we use to only cause the popup to happen once? 04:31
japhb timo1: I'd be quite surprised by SVGs that were more than a *mega*byte. 05:31
SVGs should be really small unless they have inline-encoded bitmaps in them, but there's no reason for that to occur in something that is basically just generated from a GraphViz DOT file (or at least, that was the case when I first created them; I know there have been refactorings since then) 05:33
05:56 sena_kun left, sena_kun joined
timo1 japhb: > The difference between a fresh install and a rebuild is that the directory Website/plugins/typegraph/typegraphs/ is empty on a fresh install and contains 3GB in 423 .svg files thereafter. 06:01
m: say 3 * 1024 / 423, " megabytes per svg file average" 06:02
camelia 7.262411 megabytes per svg file average
timo1 more probably there's like, one svg file that has every type ever in it, including about two hundred exception classes? or i guess every exception class svg typegraph has every other exception in it?? 06:03
07:42 sena_kun left 07:45 sena_kun joined 07:50 finanalyst joined 08:11 lizmat_ joined 08:12 Geth left, [Tux] left 08:14 lizmat left 08:16 lizmat_ left, lizmat joined 08:24 [Tux] joined
lizmat bisectable6: =fortnite 08:33
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/e6c99f7a8a388f65b4...1bde5a888f
lizmat, Bisecting by output (old=2017.11 new=2017.12) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/36e47ee780b3aea4f4...83c8dd03e2
lizmat, (2017-12-13) github.com/rakudo/rakudo/commit/2c...9482ca398b
lizmat, Output on all releases and bisected commits: gist.github.com/cad68212ec671811ab...24132f1e6e
08:36 nine left, nine joined 09:00 Geth joined
Geth roast: a557dc07b3 | (Elizabeth Mattijsen)++ | S17-promise/nonblocking-await.t
Make sure non-blocking tests don't block forever

Every once in a while this test file hangs "make spectest". Make sure that *if* it fails, it fails in a more friendly way
09:01
rakudo/main: 587cd72f62 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Fixups.rakumod
RakuAST: handle F<foo|bar> the same as L<foo|bar>
09:02
09:09 sena_kun left
nine lizmat: 20s sounds rather tight. That test file takes some 3s on my really fast desktop. Cloud based CI can be much, much slower and also suffer from stutters in execution. If we introduce such last-resort arbitrary timeouts, please lets make them _large_. At least several minutes. 09:40
Geth roast: 4cb2348142 | (Elizabeth Mattijsen)++ | S17-promise/nonblocking-await.t
Increase timeout to 2 minutes
09:42
09:56 [Tux] left 10:08 [Tux] joined
patrickb nine: I'm curious, any news wrt your grant? 11:35
nine patrickb: nope. Getting ghosted by the grants committee. 11:38
That's the reason why I have stopped working on RakuAST. Can't justify the hours when it doesn't generate income. Better invest them into the startup I'm involved with. 11:40
patrickb Meh. Hope they move forward at some point. 11:52
[Coke] I apologize retroactively for all the times I ghosted someone when I was in that position. 11:59
nine Well "ghosted" is a bit tongue in cheek. It's all volunteers with real lifes and all. I will hear from them eventually. 12:01
lizmat bisectable6: say (^20).map: { LAST say "last"; last if $_ == 10; $_ } 12:11
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat m: say (^20).map: { LAST say "last"; last if $_ == 10; $_ }
camelia (0 1 2 3 4 5 6 7 8 9)
lizmat why doesn't it say "last" ? 12:12
bisectable6 lizmat, Output on all releases: gist.github.com/071e65d12b0b6ccaeb...84957fbb30
lizmat, Bisecting by output (old=2021.06 new=2021.07) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/d2f11c525098c7deea...c0acd4e157
lizmat, (2021-07-14) github.com/rakudo/rakudo/commit/bf...6874ade571
lizmat, Output on all releases and bisected commits: gist.github.com/ed60b9ac97dad07d20...657efc6aaa
lizmat aha! 12:13
seems this got borked 3 years ago :-(
nine Depends on whether you interpret a "last" call as "abort loop processing so we never get to process the last iteration" or as "declare this to be the last iteration of this loop"
lizmat m: (^20).map: { LAST say "last"; last if $_ == 10; $_ } 12:15
camelia last
lizmat the semantics of the LAST phaser are clear: it *should* have said "last" 12:16
in both case, and it used to until that change
sadly, that commit cannot be reverted :-( 12:17
well, automatically I guess 12:18
looks like the issue is in the pull-one 12:21
Geth rakudo/main: 16ce594e44 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Make sure the LAST phaser is fired in .map

when a `last` is done with a mapper that is being run through
  .pull-one, rather than through .push-all or .sink-all.
Fixes #5590
12:55
roast: 1346ec74cc | (Elizabeth Mattijsen)++ | S32-list/map.t
Add test for #5590
13:01
jdv what is the value judgement here. what's the percentage of rakudo users affected? 18:10
I only budget "1 release a month"'s worth of time so it has to be an emergency to do another. 18:11
or get someone else to do it - i don't care:) 18:13
lizmat patrickb can explain better 18:18
I think we can actually live with having patrickb make Window binaries off of the 2024.05.1 branch 18:19
nine If the fix is only needed on Windows, maybe we can just include it in the Windows packages? I have occasionally included backported fixes in the openSUSE packages
jdv that seems easier on everyone. i might be biased. 18:20
nine You're entitled to a bit of bias there :)
[Coke] works for me. 18:33
jdv sounds fun enough. thanks! 18:34
18:43 sena_kun joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/06/03/2024-23-sparkling/ 18:49
patrickb So I'll do the binaries 2024.05 for everything != win
and only win 2024.05.1
I think I can do so in a few hours. Thanks everyone! 18:52
lizmat ++patrickb
patrickb weekly correction: binary packages have not yet become available 18:54
lizmat updated
19:05 finanalyst left 20:47 AlexDaniel joined
AlexDaniel Hey! kiwiirc is not working (it has been broken for quite some time now), so the links to IRC are not helpful. You can replace it with web.libera.chat link I suppose 20:48
And then, this is how I see the docs: i.imgur.com/ht8JqMH.png
coleman AlexDaniel: I have opened github.com/Raku/doc-website/issues/396 if you could add your browser info that would help 21:07
docs team hangs here and in #raku-doc 21:08
AlexDaniel there's no need for browser info, you can reproduce it by just resizing your browser window 21:11
I left a comment 21:12
jdv not for me 21:25
ff 126 here
AlexDaniel jdv: have you opened the sidebar? Show a screenshot of the page with the same size and 100% zoom. 21:40
jdv oh, i thought you meant the sidebar was open on its own 21:44
yeah, same here - seems the sidebar assumes a desktop browser has a very wide viewport 21:45
maybe they focused on mobile and "wide" desktops. idk. 21:46
i'm not a huge fan of the new sidebar thing myself as i've mentioned before so i avoid using it:(
patrickb The binaries are done. \o/ 21:53
AlexDaniel I assume all bots are working fine? I don't check regularly anymore :) 21:59
if they ever don't, please file a ticket here: github.com/Raku/whateverable/issues/new 22:00
22:23 AlexDaniel left
Geth rakudo/main: ad0afb047e | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Don't set the FIRST flag always

But only if there are actually FIRST phasers involved.
This buglet was introduced in 5ecc8308fc , but did not have any adverse effects apart from a little overhead for those cases of
  .map where the block had *any* phaser in its body.
Found while developing ParaSeq.map, that wants only to execute any FIRST phaser while processing the first batch
22:33
23:04 sena_kun left
[Coke] AlexDaniel++ 23:07