00:00 reportable6 left 00:02 reportable6 joined 06:00 reportable6 left 07:17 lizmat joined 07:21 lizmat_ left
Geth rakudo/main: 0eb99b8a94 | (Stefan Seifert)++ | src/core.c/Exception.rakumod
Fix reporting of X::Role::Initialization errors

The $.role attribute was passed to the constructor and used for creating the error message but was not actually declared as an attribute.
07:22
07:41 finanalyst joined 08:37 finanalyst left
Geth rakudo/main: a219c9bc47 | (Stefan Seifert)++ | 2 files
RakuAST: fix mixin creation with constructor argument

In 69 but Foo(1) the argument has to be passed to the &infix:<but> function as :value(1). It will then be passed on to the role constructor.
08:53
nine 1053
ab5tract climbing! 10:12
nine: so it's definitely this "memmem32" code that is breaking things (re: R#5550) 10:15
linkable6 R#5550 [open]: github.com/rakudo/rakudo/issues/5550 [Fixed in RakuAST] Simple literal-only regex fails
10:15 linkable6_ left
ab5tract a while back you asked if we knew what this `:rxtype<scan>` thing was actually doing.. it looks like for `:rxtype<literal>` we enable a pre-search scan that does a quick `index_s`, presumably to fail faster 10:17
that `index_s` calls `MVM_string_memmem_grapheme32`, which in turn calls `memmem_uint32`, which does the modulus based scan 10:20
replacing `MVM_string_memmem_grapheme32` with its previous contents fixes the issue. but the commit message of `e71ba738` references a 4x-15x speedup. 10:22
so I'm feeling a bit stuck about resolution options 10:25
I don't even know what test corpus samcv used when they measured that speedup 10:29
nine If in doubt correctness trumps speed. Of course would be nice to fix the actual bug and get both :) 10:39
ab5tract indeed... I guess I should have mentioned that I'm at the end of my skillset when it comes to the relevant C code :) 10:43
I've only used to debugging styles: printing swear words at opportune locations and comfy IDE integrations 10:44
let's add a third :) 10:51
nine I'm still at printing swear words :D 10:53
Well that and poking at stuff in gdb
ab5tract nine: are you using the `rakudo-gdb-m` wrapper? because it (and `rakudo-lldb-m`) both still reference `perl6.moarvm` ... gist.github.com/ab5tract/9030eb229...079e546cfe 10:59
though changing it to `rakudo.moarvm` or `rakudo-debug.moarvm` just gives a `ModuleLoader.moarvm not found` error 11:02
It looks like --libpath="\@nfp(\@nqp::libdir@)@" in tools/templates/moar/Makefile-runner_opts.in doesn't return anything (anymore) 11:20
nine Nah, I just use gdb --args ./rakudo-m ...
ab5tract TIL 11:21
nine Ever since rakudo-m became a proper binary, the wrapper kinda lost its purpose
ab5tract I guess that's why it's a bit of a rotten carcass
probably better to rewrite them than fix them, if we are going to keep them 11:24
11:25 sena_kun joined 12:10 sena_kun left 12:12 sena_kun joined
Geth nqp/main: 97217442cf | ab5tract++ | tools/lib/NQP/Config/NQP.pm
Allow --moar-option='--no-optimize' to actually work
12:42
ab5tract I'll be honest, I'm a bit brain boggled about how `Configure.pl` in rakudo.git depends on a Perl module in `nqp.git` :) 12:43
ah, we have `./tools/lib/NQP/Config/Rakudo.pm`, missed that somehow 12:45
but I fixed my issue with rakudo's Configure.pl by editing the module in nqp .. so ... 🤷 12:47
unfortunately I've used just about all of my brain juice just getting to this point where the debu 13:03
*the debugging process is available
13:43 MasterDuke joined
MasterDuke ab5tract: some of the comments here reviews.freebsd.org/D2601 seem relevant 13:44
tellable6 2024-04-18T06:52:56Z #moarvm <nine> MasterDuke: still doubt that would bring any measurable benefit. Mind that I could also just be wrong.
hey MasterDuke, you have a message: gist.github.com/11f155971e1c30cfbb...77115c8a97
MasterDuke they mention a bug that was fixed. maybe you could compare that implementation with ours? 13:45
ab5tract MasterDuke++
unfortunately this bug fix predates the implementation of memmem_uint32, but I'll still check this for viability 13:48
maybe something was lost in translation
MasterDuke and there might be newer bug fixes/reports, that's just the first one i found 13:49
ab5tract Yup, looking at reviews.freebsd.org/source/src/his...g/memmem.c 13:54
At least one
but part of the issue is... *none* of this references a `memmem_uint32` 13:55
It's hard for me to grok how much of the memmem32 patch was simple porting and how much as adapted 13:56
MasterDuke have you been able to construct an nqp::index_s call that exhibits the bug? 13:58
afk for probably a while & 13:59
ab5tract it's actually a MAST:Op
I haven't tried to create a "tiny" version, but that's a good idea 14:00
14:58 kjp left
ab5tract I wonder why we use 32-bits for our graphemes? wasn't UTF-16 already mostly abandoned as "more bits than necessary"? 15:42
even more curious.. the haystack string is stored as MVM_STRING_GRAPHEME_32 but the needle is stored as MVM_STRING_GRAPHEME_8 16:31
nine UTF-16 was the worst of both worlds. It wasted a lot of space on real-world strings that would fit in just 1 byte while it still was a variable length encoding, because 16 bits is just not enough. UTF-32 is a decent internal representation as each unit really represents a code point 16:48
MasterDuke aren't the graphemes 32-bits to support synthetics? 17:03
i wouldn't mind if the string-related code in moarvm was overhauled (probably to have more size-specific code paths for speed), but it's a decently sized undertaking 17:06
this was a poc of the type of thing i'm thinking of github.com/MoarVM/MoarVM/compare/m...g?expand=1 17:13
ab5tract nine: thanks for the clarification
MasterDuke: that's a link to open a PR, rather than a PR proper 17:14
MasterDuke yeah, i never created a PR
ab5tract ack. I will check the branch on your repo then 17:15
MasterDuke it's just that one commit
ab5tract regarding the FreeBSD memmem, it's definitely worth updating 3rdparty/memmem.c to the latest and greatest 17:18
but the meat of memmem32.c is apparently samcv's own adaptation 17:19
now to find the bug and squash it >:) 17:20
MasterDuke irclogs.raku.org/moarvm/2023-02-20.html has some chat about that branch, why i tried it, and the results 17:23
ab5tract will dig into it, thanks! 17:34
Is assigning -1 to a uint32_t just a run of the mill way to get a variable holding the max value of a uint32_t? 17:35
MasterDuke that's what i would assume 17:36
17:46 finanalyst joined
ab5tract I guess it just feels like an odd pattern, so I was wondering how common it is 17:50
lizmat m: my uint64 $a = -1; say $a
camelia 18446744073709551615
lizmat it is :-)
it beats typing:
m: my uint64 $a = 0xffffffffffffffff; say $a 17:51
camelia 18446744073709551615
lizmat :-)
ugexe anyone tried pasting memmem32.c into a llm and asking it to find the hidden bug? :) 18:03
ab5tract If that actually works… 18:09
I’ll become a believer
18:38 MasterDuke left
ab5tract as usual, I'm extremely underwhelmed by AI: gist.github.com/ab5tract/0ec39f79f...5155f185d4 18:38
lizmat well, the fix is clear: 18:39
To resolve this bug, the two-way string matching algorithm could be modified to handle cases where the maximal suffix of the needle string is not unique. Another possible approach is to use a different string search algorithm altogether.
:-)
ab5tract but that's not the actual problem
m: "Xabddcabacab" ~~ /abacab/ ==> so() ==> say() 18:40
camelia True
lizmat "Another possible approach is to use a different string search algorithm altogether."
18:42 notna joined
ab5tract heh 18:42
releasable6 Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
releasable6_ Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft
Geth rakudo/main: 35cc0d6aa1 | (Stefan Seifert)++ | 6 files
RakuAST: Prohibit re-binding of parameters (unless rw or copy)
19:50
20:08 notna left
Geth rakudo/main: 171307e928 | (Stefan Seifert)++ | 2 files
RakuAST: Prohibit rebinding of variables declared in bound signatures

my ($a, ) := (1, ); $a := 2; # now fails correctly
20:21
20:55 finanalyst left
Geth rakudo/main: 5f8c7bbeb0 | (Stefan Seifert)++ | src/Raku/ast/term.rakumod
RakuAST: throw targeted exception when trying to re-bind term
21:08
22:08 kjp joined 22:43 bloatable6_ left, coverable6_ left, shareable6_ left, committable6_ left, unicodable6_ left, releasable6_ left, bisectable6_ left, evalable6_ left, greppable6_ left, statisfiable6 left, tellable6_ left, quotable6_ left, sourceable6_ left, notable6_ left, nativecallable6_ left, squashable6 left, benchable6_ left, greppable6_ joined, nativecallable6_ joined, coverable6_ joined, notable6_ joined, squashable6 joined 22:44 bloatable6_ joined, reportable6 joined, bloatable6_ left, nativecallable6_ left, greppable6_ left, squashable6 left, reportable6 left, notable6_ left, coverable6_ left 22:45 quotable6_ joined, linkable6_ joined, coverable6_ joined, notable6_ joined, bisectable6_ joined 22:46 benchable6_ joined, nativecallable6_ joined, statisfiable6 joined, sourceable6_ joined, bloatable6_ joined, unicodable6_ joined, evalable6_ joined, releasable6_ joined, shareable6_ joined 22:47 greppable6_ joined, tellable6_ joined, reportable6 joined, committable6_ joined, squashable6 joined 23:48 shareable6_ left, tellable6_ left, reportable6 left, notable6_ left, benchable6_ left, committable6_ left, nativecallable6_ left, linkable6_ left, quotable6_ left, coverable6_ left, squashable6 left, unicodable6_ left, statisfiable6 left, releasable6_ left, sourceable6_ left, bisectable6_ left, bloatable6_ left, evalable6_ left, greppable6_ left 23:49 greppable6_ joined, releasable6_ joined 23:50 statisfiable6 joined, quotable6_ joined, reportable6 joined, shareable6_ joined, coverable6_ joined 23:51 linkable6_ joined, sourceable6_ joined, squashable6 joined, committable6_ joined, notable6_ joined, benchable6_ joined, nativecallable6_ joined, bloatable6_ joined, evalable6_ joined 23:52 tellable6_ joined, bisectable6_ joined, unicodable6_ joined 23:55 sena_kun left