🦋 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.
03:19 |Tux| left 04:27 lizmat left 04:31 |Tux| joined 04:44 vrurg joined 04:46 vrurg_ left
nine Well I'm not sure what to do here. The new behaviour is not wrong. Quite the opposite, detecting an error at compile time is always better than leaving it for runtime. 06:57
08:12 sena_kun joined
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
08:31 finanalyst joined 08:40 camelia left, nine left 08:47 camelia joined 08:49 finanalyst left 08:51 nine joined 09:00 camelia left 09:01 nine left 09:02 nine joined 09:03 camelia joined 09:05 lizmat joined 09:06 sena_kun left, sena_kun joined, nine left, camelia left 09:07 nine joined 09:14 camelia joined
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
19:14 finanalyst joined 20:39 finanalyst left
Geth rakudo/main: c0f0ad3c6d | (Stefan Seifert)++ | 3 files
RakuAST: check whether sub calls work at compile time
 20:45
rakudo/main: 151236e83a | (Stefan Seifert)++ | 2 files
RakuAST: detect more coercive parameter types
nine 1051 which is quite unexpected :)
Apparently we have quite a few tests that rely on compile time sub call signature checks 20:46
20:47 finanalyst joined 20:51 vrurg_ joined, vrurg left 21:52 sena_kun left 21:53 sena_kun joined
ab5tract Nice! 22:04
22:19 |Tux| left
lizmat nine: cool! but it appears we lost t/02-rakudo/03-corekeys.t 22:21
22:29 finanalyst left 22:31 |Tux| joined 23:00 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!