🦋 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. |
|||
07:34
[Tux] left
07:38
[Tux] joined
07:40
sena_kun joined
09:20
sena_kun left
09:37
finanalyst joined
10:17
MasterDuke left
|
|||
Geth | rakudo/main: c158228515 | (Stefan Seifert)++ | 2 files RakuAST: check bind value types in initializers |
10:18 | |
rakudo/main: 830727e539 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod RakuAST: ensure symbols accessed by BEGIN time code are resolved Generating a compile-time-value may need some lookups to have been resolved. |
|||
nine | 1034 | 10:19 | |
lizmat | 150+ runs of REA harvester still clean, I declare the bug squashed! | 10:22 | |
nine | Yeah! | 10:29 | |
Geth | nqp/main: ec940c08c0 | (Elizabeth Mattijsen)++ | src/how/NQPClassHOW.nqp Remove snitch code The underlying issua has been fixed with github.com/MoarVM/MoarVM/commit/d5dafa9b47 |
10:30 | |
rakudo/main: 08b77e9431 | (Stefan Seifert)++ | 3 files RakuAST: support the sink statement-prefix |
10:48 | ||
nine | 1039! This was about one spec test file per minute :D | ||
lizmat | whee! | 10:49 | |
nine | > RAKUDO_RAKUAST=1 ./rakudo-m -e '"foo bar" ~~ m:s/foo bar/' | 10:55 | |
Potential difficulties: Space is not significant here; please use quotes or :s (:sigspace) | |||
lizmat: ^^^ | 10:56 | ||
lizmat | ? | 11:04 | |
nine | Looks like your commit fb53d50a8a3068399db4a24ba315ab3b9d71d8c8 is a bit incomplete | ||
linkable6 | (2023-03-21) github.com/rakudo/rakudo/commit/fb53d50a8a RakuAST: eradicate use of %*RX<s> in the grammar | ||
lizmat | could well be... it's been a while :-) | 11:05 | |
11:12
finanalyst left
|
|||
Geth | rakudo/main: 4adf939586 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod RakuAST: fix params with post constraints stumbling over junctions When passed a Junction, the result of an ACCEPTS call can again be a Junction. Before passing that on to paramtypecheck we have to ensure it's turned into a Boolean. |
11:58 | |
nine | 1040 | ||
lizmat updates the weekly draft | 11:59 | ||
Geth | rakudo/main: f43128bd8e | MasterDuke17++ (committed using GitHub Web editor) | 5 files Convert uses of `if nqp::getcomp('Raku').backend.name eq <...>` to `#?if <...>` So instead of a runtime decision it's done at compile time. |
12:13 | |
lizmat | notable6: weekly | 12:25 | |
notable6 | lizmat, 2 notes: 2024-04-11T19:48:46Z <gfldex>: weekly www.youtube.com/watch?v=pFKLHOygtqQ&t=945s ; 2024-04-14T22:09:43Z <antononcube>: rakuforprediction.wordpress.com/20...-exercism/ | ||
ab5tract | just saw #5550 ... that's a weird one | 12:44 | |
R#5550 | |||
linkable6 | R#5550 [open]: github.com/rakudo/rakudo/issues/5550 [Fixed in RakuAST] Simple literal-only regex fails | ||
ab5tract | I wonder if approaching it from the mysterious angle of the repl *not* failing would be the most fruitful path? | 12:50 | |
obviously grateful that RakuAST gets it right.. | |||
nine | The QAST generated by RakuAST is also different from that generated by the old frontend | 12:57 | |
ab5tract | nqp-moarvm: say("_20__32022320" ~~ /2022320/) | 13:01 | |
camelia | 2022320 | ||
ab5tract | m: use nqp; say(nqp::index("_20__32022320", "2022320")) | 13:03 | |
camelia | 6 | ||
ab5tract | I guess we don't do an nqp::index() check prior to switching to deeper levels of matching strategy? | ||
probably I'm thinking too small, but that feels like it would be an "obvious" optimization strategy... though it wouldn't be enough on its own to build a proper match object from | 13:06 | ||
nine: is there perhaps some way to dump QAST produced during a repl seession? | 13:16 | ||
maybe with a combination of the two working examples and the failing one, triangulation efforts would be reduced | |||
looks like this might be the answer to the question of why the repl works? | 13:29 | ||
m: say (Q| 'Xabddcabaacab' ~~ /abaacab/| ~ "\n").EVAL | |||
camelia | 「abaacab」 | ||
ab5tract | m: say qq|"Xabddcabaacab" ~~ /abaacab/;|.EVAL; say qq| "Xabddcabaacab" ~~ /abaacab/;\n|.EVAL | 13:35 | |
camelia | Nil 「abaacab」 |
||
ab5tract | it should be noted that the regex works on the JVM as well (though calling say with a Match argument barfs instead of coercing to Str) | 13:44 | |
(works without the newline modification, I mean) | 13:47 | ||
QAST for JVM vs MoarVM: gist.github.com/ab5tract/5ec0037e2...dec9e1a662 | 13:56 | ||
A major distinction is in the use of `QAST::Dispatch`by MoarVM | 13:58 | ||
just added RakuAST QAST, which is simpler than the JVM output but likewise does not use `QAST::Dispatch('raku-smartmatch', ...)` | 14:00 | ||
bisectable6: so("Xabddcabaacab" ~~ /abaacab/) ~~ True | 14:07 | ||
bisectable6 | ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
ab5tract, Output on all releases: gist.github.com/56c953ccb1fd5c3e0b...78d5d4771d | |||
ab5tract, Bisecting by output (old=2015.12 new=2016.01.1) because on both starting points the exit code is 0 | |||
ab5tract, bisect log: gist.github.com/75659ebda8bf5dd7f2...b80ec8d98a | |||
ab5tract, Output on all releases and bisected commits: gist.github.com/5346c8b98f749b58bc...6fb3750f17 | 14:08 | ||
ab5tract | bisectable6: (so "Xabddcabaacab" ~~ /abaacab/) == True | 14:09 | |
bisectable6 | ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
ab5tract, ¦6c (78 commits): «WARNINGS for /tmp/lCEhz5GToC:Useless use of "==" in expression "(so \"Xabddcabaacab\" ~~ /abaacab/) == True" in sink context (line 1)» | |||
ab5tract, Nothing to bisect! | |||
ab5tract | bisectable6: exit 1 - (so "Xabddcabaacab" ~~ /abaacab/) | 14:12 | |
bisectable6 | ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
ab5tract, Output on all releases: gist.github.com/31825a3cea3ab688ea...b97b09c207 | 14:13 | ||
ab5tract, Bisecting by exit code (old=2018.04.1 new=2018.05). Old exit code: 0 | |||
Geth | rakudo/main: 5211345d50 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Concretization.nqp Fix some thread-safety issues that were missed |
||
bisectable6 | ab5tract, bisect log: gist.github.com/57c92bdd982904c8d4...085d4789bf | ||
ab5tract, (2018-05-07) github.com/rakudo/rakudo/commit/6a...9ebfbc8a70 | |||
ab5tract, Output on all releases and bisected commits: gist.github.com/14195e9cee989bc9b2...fb9b048976 | |||
lizmat | ab5tract: re "an "obvious" optimization strategy... though it wouldn't be enough on its own to build a proper match object from", yes, having to create a Match object is stopping a lot of opts | 14:14 | |
ab5tract | probably something we can get some great wins from with a RakuAST-based optimizer :) | 14:15 | |
lizmat | having said that, I think in RakuAST we will be able to optimize a lot of very simple cases | ||
yes | |||
ab5tract | the fact that adding a newline to the problematic regex _after_ the semicolon makes it work is spooky as hell to me | 14:18 | |
is there some way to get at the QAST generated by the EVAL? | 14:20 | ||
also, even though `raku-smartmatch` is implicated in the differences between working and non-working QASTs, it seems kind of farfetched in that my understanding is that it is post-newdisp .. and this bug is far older | 14:23 | ||
lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/04/15/2024-...y-concise/ | 14:26 | |
ab5tract | lizmat++ | 14:27 | |
..but if the issue is lower level than this QAST::Dispatch, why do `nqp -e` and RakuAST work? | 14:50 | ||
Geth | rakudo/main: a15f9f41b8 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ConcretizationCache.nqp Streamline Metamodel::ConcretizationCache (Part 1/N) Mostly about making sure that the Capture type object is not used before its HOW is fully composed. |
14:52 | |
nine | RakuAST: | 14:53 | |
│ │ - QAST::Regex(:rxtype(concat) :subtype()) | |||
│ │ - QAST::Regex(:rxtype(scan) :subtype()) | |||
│ │ - QAST::Regex(:rxtype(concat) :subtype()) | |||
│ │ - QAST::Regex(:rxtype(literal) :subtype()) | |||
│ │ - 2022320 | |||
│ │ - QAST::Regex(:rxtype(pass) :subtype()) | |||
old: | |||
│ │ │ - QAST::Regex(:rxtype(concat) :subtype()) | |||
│ │ │ - QAST::Regex(:rxtype(scan) :subtype()) | |||
│ │ │ - 2022320 | |||
│ │ │ - QAST::Regex(:rxtype(concat) :subtype()) 2022320 | |||
│ │ │ - QAST::Regex(:rxtype(literal) :subtype()) 2 | |||
│ │ │ - 2022320 | |||
│ │ │ - QAST::Regex(:rxtype(pass) :subtype()) | |||
ab5tract | ah! great catch | 15:05 | |
however, NQP output also has :rxtype<scan> | 15:11 | ||
│ │ - QAST::Stmts | |||
│ │ - QAST::Regex+{QAST::RegexCursorType}(:rxtype(concat) :subtype() :cursor_type(NQPMatch)) | |||
│ │ - QAST::Regex(:rxtype(scan) :subtype()) | |||
│ │ - abaacab | |||
│ │ - QAST::Regex(:rxtype(concat) :subtype()) abaacab | |||
│ │ - QAST::Regex(:rxtype(literal) :subtype()) a | |||
│ │ - abaacab | |||
│ │ - QAST::Regex(:rxtype(pass) :subtype()) | |||
Geth | rakudo/main: 75e63ce615 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ConcretizationCache.nqp Streamline Metamodel::ConcretizationCache (Part 2/N) Make sure that adding to the cache is done in a threadsafe manner. Note that the same concretization technically can appear more than once in the cache. Not sure if this is really an often occurring situation warranting additional uniqueness checks. |
15:17 | |
ab5tract | ++(nine++) | 15:30 | |
it looks like it was the scan indeed. | |||
> ./rakudo-m -e '"Xabddcabaacab" ~~ /abaacab/ ==> so() ==> say()' | |||
True | |||
&afk | 15:38 | ||
So I guess that the issue is actually with the implementation of scan, as JVM and NQP QAST includes it | 15:58 | ||
Geth | rakudo/main: b1aaf338ff | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ConcretizationCache.nqp Streamline Metamodel::ConcretizationCache (Part 3/3) Make sure that fetching a concretization from the cache is done in a threadsafe manner. |
15:59 | |
ab5tract | Which makes sense with bisectable returning an NQP/MoarVM bump commit | 16:00 | |
Geth | rakudo/main: 4 commits pushed by (Stefan Seifert)++ | 18:02 | |
nine | Unfortunately while this gains us one spectest we also lose one: t/spec/S12-subset/type-subset.t fails one test because | 18:03 | |
m: subset F of Int where * %% 2; subset G of F where * %% 3; my G $g = 9 | |||
camelia | Type check failed in assignment to $g; expected G but got Int (9) in block <unit> at <tmp> line 1 |
||
nine | fails now at compile time with "Cannot assign a literal of type Int (9) to a variable of type G" | ||
18:22
sena_kun joined
21:15
sena_kun left
21:17
sena_kun joined
21:20
finanalyst joined
|
|||
ab5tract | nine: that sounds familiar.. I'll try to take a poke at it soon, but feel free to go after it if you have the inclination | 21:53 | |
22:26
sena_kun left
23:00
finanalyst left
|