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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!