|
🦋 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. |
|||
|
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
|
|||