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