jdv if soneome else could try to do a blin run that'd be cool. I've failed 2x to get a full run in yet and i'm short on time this week. looks like something ate all the mem on this box. i had 24G. 03:06
ab5tract Jeepers creepers 08:04
lizmat it's probably github.com/rakudo/rakudo/issues/5665 :-( 08:40
I'll look at that today
Geth rakudo/main: 4b53990c2b | (Elizabeth Mattijsen)++ | 2 files
Revert "Don't create unnecessary Failures on numeric infix operators"

This reverts commit 0f5d54d2387c712e242910cb04d6312be2504bcc.
To allow the 2024.10 release to go through		 08:51
08:53 sena_kun joined
Geth rakudo/main: 4d6458989a | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Additional test for #5391

  raiph++ for the nudge		 08:56
timo github.com/rakudo/rakudo/issues/5189 - what did we close this for? 09:22
Geth rakudo/main: 6f8d314c2a | (Elizabeth Mattijsen)++ | 2 files
Don't create unnecessary Failures on numeric infix operators

This time without a stupid typo that made infix %% go infinilooping upon itself and eating all RAM (at 4GB/sec that was quite a feat :-)
timo hrm. i feel like i haven't accomplished anything for this release, or the previous one :| 09:29
lizmat timo: you have, although it's all in the background! 09:33
well, maybe not all :-)
in any case, it is appreciated! 09:34
Geth rakudo/main: b50d986a21 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #5599
 09:46
rakudo/main: 91e46d2952 | (Elizabeth Mattijsen)++ | src/core.c/Exception.rakumod
Also show file/line on ambiguous dispatch

As suggested by wayland++ in #5655		 10:44
releasable6 Next release in ā‰ˆ3 days and ā‰ˆ7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
Geth rakudo/main: 5e9d63dafa | (Elizabeth Mattijsen)++ | 2 files
Make Seq.sort in line with sort(Seq)

Also make sure that Type.sort does the right thing.
Fixes #5662		 11:30
roast: a82e731dd4 | (Elizabeth Mattijsen)++ | S32-list/seq.t
Add test for #5662
 11:33
lizmat jdv: pretty sure github.com/rakudo/rakudo/commit/6f8d314c2a makes it ok to run a Blin again 11:36
Geth rakudo/main: 302241feba | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #1616
 11:58
rakudo/main: 5e95151b74 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #1691
 12:02
rakudo/main: efb42ea700 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #1768
 12:14
rakudo/main: a1ccc7d31c | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #1871
 12:18
rakudo/main: 45a6cdd885 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add tests for #1965
 12:32
[Coke] the debian stuff is super important! 13:15
lizmat timo ^^ 13:18
timo i'll drink to that 13:19
Geth rakudo/main: c0ad99eafd | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #5249
 13:28
rakudo/main: 314eb11437 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #5119
 13:33
jdv lizmat: i think i can try again tonight. thanks. 13:37
lizmat ab5tract: got open tests down to 715, then re-opened almost all of the Fixed in rakuAST with tests so that the issues are more easily discoverable 14:01
now at 778
so that's 63 issue that should be closable when 6.e is released :-) 14:02
[Coke] Nice. 14:27
Saw there were a few that were docs-only at this point. I'll try to get any of those converted to raku/doc tickets.
lizmat thanks!
[Coke] I'd also like to have a doc run before the 6.e release to get us in a good position, will definitely need some volunteers. :) 14:28
timo i wish someoneā„¢ could find the time to hook up some kind of "run code from your browser" thing to the docs website, or at least something cheeky that turns a block of code into a `rakudo -e` commandline with here docs or something that reliably makes spaces and quotes and whatnot work properly 14:29
for the debian stuff i'm currently waiting for Dominique to do things 14:32
japhb timo: What's "the debian stuff"? 14:34
lizmat making Rakudo available in the Debian distro 14:35
timo after Dominique stepped down from debian maintenance of the raku packages, raku was briefly in peril of being removed from debian
with some help from [Coke]++ I was able to step in and learn how to do many of the things, and Dominique agreed to sponsor my uploads and such (since a proper DD Debian Developer has to do those) 14:36
in between, we had a Non-Maintainer-Upload by someone eager to make rakudo available on LoongArch64 which caused trouble with drifting precompilation files, since rakudo is currently not building reproducible results for the different .moar files that come out of it, like the core setting 14:37
so now a bunch of packages, when a rebuild is attempted, will explode violently with a "missing or wrong version of dependency: v6c.bootstrap" or something 14:38
lizmat timo: could you give github.com/MoarVM/MoarVM/pull/1847 a bit of a description? (for the weekly readers)
and possibly a more descriptive title? :-) 14:39
timo working on it
[Coke] (help from Coke) I assure you I basically did nothing. :) 14:41
timo how's that?
[Coke]: you were there to listen to my concerns, which i felt was a big help 14:42
Geth rakudo/main: 9f41d2c61a | (Christian BartolomƤus)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/RolePunning.nqp
[JVM] Unbreak module loading

For some reason the check for nqp::null doesn't work and the method returns NQPMu. Maybe TWEAK didn't run correctly?
I didn't want to undo all (or more changes) of efeb9d7742. Hopefully the bandaid can be removed at one point.
rakudo/main: ff50e3297e | (Christian BartolomƤus)++ (committed using GitHub Web editor) | src/core.c/Rakudo/Iterator.rakumod
[JVM] Flatten without overflow/underflow issues

If I'm not mistaken, the code relies on a $level parameter of -1 being coerced to a big positive number (due to the usage of uint). This doesn't work for the JVM backend.
Since the commit that introduced the uint parameter,
  github.com/rakudo/rakudo/commit/74cfe8e373, mentioned some
confusion for the expression JIT on Intel, I didn't dare to change the code for MoarVM.		 14:44
[Coke] timo++ # doing all the hard work while I listen to things and drink caffiene. 14:48
Geth rakudo/main: d964ec93a9 | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod
Make "repl" not shell out with rlwrap

Because then it loses its context, and will exit the program when done in the REPL		 14:51
Ā¦ rakudo: lizmat self-assigned $*USER and $*GROUP are Any on windows. github.com/rakudo/rakudo/issues/5066 15:42
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/10/21/2024-...ent-alert/ 16:55
ab5tract returning somewhat to the discussion of which modules should be available by default: we need to incorporate JSON::Fast or (ideall) a faster JSON parser in core 19:46
*ideally 19:47
a fast JSON serializer seems like something we should expect at the VM level 19:48
coleman I like the idea of pushing more things into an out-of-the-box installation, but is there an intermediate step that we can champion 19:49
does zef have a concept of "meta-libraries" such that we can rally around a collection of versions installable by zef 19:50
and then from there implement lower-level optimizations
[Coke] ab5tract: you know Rakudo has builtin JSON support, yes? 19:52
ab5tract you mean the one that's been deprecated for over half a decade? 19:53
I'm talking about something that can operate at native speeds
[Coke] sorry, deprecated? 19:54
but sure, if the goal is "faster", excellent. just trying to be clear. 19:55
(deprecated) ah, yes, the REPL doesn't complain about that until you exit. ;) 19:56
ab5tract the idea is that JSON::Fast is as fast as NQP gets
Java has faster deserializers at hand
so does C
we don't expose VM hashes to the HLL
this is something that caused JSON::SIMD to be unable to achieve much of a performance differential 19:57
leaving JSON support to an after-market module in 2024 is ... a choice 20:01
jdv perl does, no? 20:02
ugexe or java :) 20:05
but Go got the standard library right
ab5tract yeah, neither of those are good examples
perl got bitten by too many internalized modules (which I understand) 20:06
Java is dumbfoundingly useless by itself
it still ships with a CSV parser, iirc
(perl)
which is a rough equivalent of JSON, era to era 20:07
Anyway, the whole utility of the idea is that nothing in third-party space can fill a VM hash.. therefore leaving it to a third-party module necessarily leaves performance optimization opportunities on the table 20:09
this isn't the case for Perl, or Java
ugexe yeah, although it sort of gets into the "well what about the jvm backend" 20:13
although i guess jvm could just use some module like we already do for other stuff 20:14
some java module
it would complicate things a bit though since the "on jvm do this on moar do that" would presumably need to be applied to a *module* i.e. something in lib/ and not actually in the core 20:15
anyways im sure that problem can be solved so its probably not worth thinking too hard about 20:16
jdv isnt that just doing xs all over again? 20:25
ab5tract in JVM land I would introduce Kotlin and its builtin serialization 20:26
jdv: no, it's really not. it's recognizing that some things deserve to be closer to the VM than NativeCall allows, and those things likewise deserve being in core 20:27
ugexe: I'm not sure I understand, exactly. Any VM would ultimately expose JSON serialization as nqp routines. So the core `JSON` library would look the same from the perspective of the HLL 20:28
21:18 coleman left 21:21 coleman joined
|Tux| Rakudo v2024.09-138-gd964ec93a (v6.d) on MoarVM 2024.09-10-g939e64dc8
csv-ip5xs0.261 - 0.262
csv-ip5xs-201.095 - 1.099
csv-parser1.491 - 1.519
csv-test-xs-200.142 - 0.144
test1.859 - 1.877
test-t0.396 - 0.403
test-t --race0.269 - 0.273
test-t-204.723 - 4.813
test-t-20 --race1.163 - 1.179
 21:48
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
22:41 sena_kun left

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!