16 Apr 2024
nine I guess I can just change the test to no longer supply a literal ala my $n = 9; my G $g = $n 08:20
ab5tract nine: ahh, it was late and I wasn’t reading clearly. The only difference is compile time versus run time, right? Could the test maybe changed to an eval style one? It should fail for both compile time and runtime in equal measure 10:33
*should then 10:34
Geth rakudo/main: cee25a7c08 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: Fix $*RAKU.version in v6.e.PREVIEW

The PREVIEW modifier should not be included in $*RAKU.version. This is ensured by the call to set_language_revision which replaces the previously set language_version.
10:53
lizmat for the record: 2 days of REA harvester run without crash 10:56
nine takes note
lizmat also I haven't seen any flappers in make spectest anymore, but that may be too soon to tell 10:57
nine: looking at the strings heap in c setting: any idea where the 21K+ numeric strings come from? 11:00
feels like something is being stringified in the compilation process that shouldn't
fg 11:02
oops
Geth roast: ea4e74b76e | (Stefan Seifert)++ | S12-subset/type-subset.t
Fix invalid test failure when error is detected at compile time.
11:03
lizmat I guess that's a +1 again :-)
nine Yeah, it's 1042 now
I'd guess that any number that we parse out of the source will still be in string representation 11:04
lizmat yeah, but I don't see the numbers 0..21000+ in the source, is what I'm saying
not all of them, I mean :-) 11:05
walking the c setting string heap in Raku is .02 seconds 11:08
but yeah, in C it's probably 1000x faster, so 0.00002 seconds, ok :-) 11:09
Looks like the numbers are coming from compilation unit names ??? 12:39
ab5tract lizmat: are you poking at R#5550? 12:51
linkable6 R#5550 [open]: github.com/rakudo/rakudo/issues/5550 [Fixed in RakuAST] Simple literal-only regex fails
ab5tract FWIW I think the fixed in RakuAST tag may be a misnomer here, as the logic in the base compiler is to add a rxtype <scan> to any rxtype<literal> 12:54
lizmat nope, poking at bytecode introspectability atm
ab5tract ack
lizmat if you think the label is premature, you can remove it 12:55
ab5tract The label isn’t inaccurate, so I’ll leave it. I’m more trying to initiate a conversation around whether this difference in behavior is intentional and/or desirable. I know very little about the regex stack 12:59
nine Any idea on what scan actually does? 13:02
ab5tract I didn’t actually manage to find that bit out yet :) 13:03
Maybe poking into the Java implementation will prove more comprehensible
My money is that the culprit is the switch to `memmem32` in e71ba7381 13:06
(MoarVM).
"The only caveat is the table uses a modulus so it can only jump to the next codepoint of the same modulus" 13:07
I'll report back with any findings regarding what `:rxtype<scan>` actually, you know, does :) 13:08
(re: e71ba7381 -- best guess so far is that the modulus-based string indexing could explain why this bug is triggered by a specific pattern) 13:09
nine indeed 13:10
lizmat nine: any idea why the cuuid of a frame is stored as a string, and not just as a number ?? 13:37
because *that*s what is filling up the string heap in the core settings: having 21K+ cuuids stored as strings 13:38
nine Well it _is_ a string. We just use an incrementing counter to generate them because it's convenient. 14:01
lizmat why is it a string? 14:02
| Compilation unit unique ID |
| 32-bit string heap index |
those 32bits could also be considered a cuuid by themselves, without having a string heap entry 14:03
I'm just wondering... that's all :-)
nine don't know 14:06
lizmat I'll ask the architect when I have the chance :-)
ab5tract unsurprisingly, the base MorVM Rakudo compiler and the NQP MoarVM interpreter both go through the `scan` method in `QAST::MASTRegexCompiler` -- gist.github.com/ab5tract/a4dbd249c...5e96b9ce27 16:54
unsurprising because that's what the QAST says its going to do.. surprising in that one works and the other does not