🦋 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.
ab5tract ugexe: thanks for taking a look! 00:01
00:03 guifa joined
timo should i kick the job to run again or something? 00:03
ab5tract Any opinion on whether the changes to `X::Multi::NoMatch` should be left in place?
timo: no worries, I think I ought to rebase at least, if not outright change a few bits and bobs 00:06
timo ` use variables :_; ` it has a different kind of smiley in it :D 00:08
patrickb: do you prefer if i put highlighting issues i see on the github issue in raku/doc-website, or is it fine to ping you here on irc? 00:10
00:14 finanalyst left
timo well, i wrote it all up now :) 00:37
github.com/Raku/doc-website/issues...2571454164 it has screenshots!
docs.raku.org/language/variables#T...ialization has the output line-breaked (presumably by hand in the source code) so the second half of the error is highlighted as if it were code. not an issue with Rainbow, but something needing a one-line fix in the source that i'm too lazy to do myself right now 00:39
[Coke] checking 00:57
fixed 01:01
timo dope 01:37
when do we build something that transforms the rendered doc page into an editor with the click of a button without even a page reload :D 01:38
SmokeMachine My 3 distros are on raku.land now! It seems it was just a delay… thank you all 01:48
timo good! 02:05
07:51 lizmat joined 08:27 sena_kun joined
patrickb timo: As long as you ensure I actually notice it, it doesn't matter much. 08:33
timo: Are you aware you could also send an email to ~patrickb/Rainbow@todo.sr.ht ? (Only hastle: It has to be a plain text email.) 08:37
timo: Thanks for persistently reporting those! 08:38
09:22 lizmat left
timo no problem :) 10:08
10:18 finanalyst joined
[Tux] Rakudo v2024.12-33-ge7f9223c5 (v6.d) on MoarVM 2024.12-11-gfa5bfd926
csv-ip5xs0.262 - 0.263
csv-ip5xs-201.110 - 1.121
csv-parser1.491 - 1.504
csv-test-xs-200.144 - 0.146
test1.875 - 1.893
test-t0.414 - 0.424
test-t --race0.262 - 0.274
test-t-205.031 - 5.302
test-t-20 --race1.243 - 1.264
 11:31
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
timo ugexe: thanks for getting started on the "use 64bits in decoder" work. i think your suspicion that there's more places that need changes is correct. i've marked up some places where i could see that we're mixing 32bit and 64bit where it's likely trouble, but i make no claim to have found everything 14:35
we might actually be able to get away with doing a different change, however
we have these MVMDecodeStreamBytes and MVMDecodeStreamChars structs that have 32bit size fields. Maybe when we encounter something that's too big, we simply split it into as many parts as needed 14:36
then not so much code has to change, I think
however, there's some places that still use 32bit ints to represent "position in the total data", or at least from a first glance it looks like they are. maybe those are actually all refering to inside a single DecodeStream*s and it's fine to keep them at 32? 14:37
hmm. 14:38
maybe the "minimum necessary change" in your first comment is closer to "the right solution" after all
14:46 guifa left, guifa joined
timo so bytes_head_pos and chars_head_pos as well as the length members of the MVMDecodeStream*s could probably stay 32bit without too much trouble 14:47
15:19 sena_kun left 15:21 sena_kun joined
ugexe github.com/MoarVM/MoarVM/pull/1879...cL255-R255 16:00
thats the other thing that might be sus
the (MVMint32)chars when chars in the function signature is typed as MVMin64 16:01
16:53 sena_kun left, sena_kun joined 16:56 sena_kun left 16:57 sena_kun joined 17:24 lizmat joined 18:31 lizmat left 18:45 lizmat joined 18:47 finanalyst left 19:56 finanalyst joined
Geth marketing: bduggan++ created pull request #27:
Change all-your-cores flyer from Perl 6 to Raku		 20:08
[Coke] added a comment there about the hyper version being slower these days (and that we should bump up the timings to 1millionth instead) 20:59
21:35 sena_kun left
timo added my cents 23:13
23:36 sivoais_ left 23:38 sivoais joined 23:40 sivoais left, sivoais joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!