🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
lizmat Files=1349, Tests=117874, 312 wallclock secs (35.42 usr 9.44 sys + 4347.30 cusr 353.23 csys = 4745.39 CPU) 09:20
patrickb o/ 10:37
jdv: All the binary release stuff will be taken care of. :-)
jdv: There are quite some people involved. El_Che builds the rakudo_pkg packages, niner builds for OpenSUSE, I do the binary files on rakudo.org. There might be others that tightly follow the release that I'm unaware of. 10:40
Geth rakudo: 57adbb1ef0 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Add "ceiling" as a suggestion for "ceil"
12:54
[Tux] Rakudo v2021.10-144-g57adbb1ef (v6.d) on MoarVM 2021.10-126-g83c53580a
csv-ip5xs0.865 - 0.880
csv-ip5xs-205.172 - 6.427
csv-parser4.123 - 4.165
csv-test-xs-200.403 - 0.412
test6.920 - 6.923
test-t1.640 - 1.649
test-t --race0.924 - 0.926
test-t-2023.863 - 23.933
test-t-20 --race7.259 - 7.367
14:30
ab5tract [Tux] do you still maintain a graph of those values over time? I'm curious as to where we are at these days 15:50
(relative to the past) 15:51
MasterDuke ab5tract: tux.nl/Talks/CSV6/speed4.html
ab5tract MasterDuke: Thanks! What happened in November when the graph dips down to almost zero? 15:53
MasterDuke the bottom of that graph isn't 0, it's something like 1.5
there were some improvements right around then, but [Tux] upgraded their OS the next day or so, which might explain the jump back up 15:55
Geth rakudo: 106769efa1 | (Justin DeVuyst)++ (committed using GitHub Web editor) | docs/release_guide.pod
Update next release date again
16:23
lizmat jdv++
Geth rakudo: c7e456d356 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 5 files
Reduce number of nqp::cpucores calls (#4659)

The internal method Kernel.cpu-cores-but-one uses a cached value for `nqp::cpucores`. This also makes sure all calls in the core are now using this method, to prevent issues on MacOS Monterey.
17:26
[Coke] with c7e456d356, is Monterey working now? 19:38
(or is it just that specific bug fixed) 19:39
lizmat it's my understanding that it was already fixed before that with f029ac83309f3 19:46
c7e456d356 is a refinement
[Coke] lizmat++ 20:28
what a weird bug. 20:29
lizmat yeah... it is probably really a libuv issue... and this is just a workaround
ugexe its probably an apple issue 21:14
japhb Sadly, that phrasing is not particularly actionable. :-P 21:15
ugexe yeah i've been trying to think of how to phrase an actual bug report but i keep coming up short
gist.github.com/ugexe/8c34b26c5edb...cf377ae334 thread #4 shows the before and after... the difference starting at the call to dlopen 21:16
ugexe afterwards it seemingly is doing an mdns query 21:16
or at least thats what i guess 'si_module_static_mdns' does 21:17
tonyo which version is monterey? 21:22
japhb tonyo: It's in the gist filenames 21:23
tonyo iirc they switched from mdns around 10.10
japhb: oh monterey is version monterey?
japhb Yeah, new-monterey.out and old-bigsur.out 21:24
tonyo monterey isn't a version number 21:25
japhb OH! You're asking what the OS version claims to be. I thought you were asking, which of ugexe's two gisted files is which. 21:26
12.x, says Wikipedia 21:27
tonyo weird, they flip flopped the mdns lib a few times in v10 but monterey should've been fleshed out for bugs, v12
ah gotcha
Geth nqp: dfef465e0e | (Vadim Belman)++ | 3 files
More universal fix for dumping QAST nodes with attached data

Get rid of occasional "cannot stringify" error message. This fix adds `stringify_value` method on `QAST::Node` which makes sure any value is stringified correctly. The common rule is now:
  - produce '(TypeName)' for type objects
... (6 more lines)
22:26