🦋 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.
ab5tract nine: you mentioned earlier that we should be adding "fixed in RakuAST" tests. I definitely agree, but it's totally unclear how to actually do that 00:23
afaict there's no solid way (outside of errata) to add version or (even more usefully) release specific tests 00:24
FWIW, I would be adding way more test cases if the above were possible 00:47
nine ab5tract: sounds like it'd just require beefing up the fudger a bit 07:01
lizmat wouldn't just marking them as "todo "fixed in RakuAST'" be sufficient ? 07:32
nine Passing todos count as failures in the harness 07:33
lizmat I thought only unexpectedly passing todos were reported ? 07:34
Geth ¦ rakudo: lizmat self-assigned Inconsistent interface among .substr/.substr-eq/.substr-rw github.com/rakudo/rakudo/issues/1720 08:15
[Tux] Rakudo v2024.04-106-gcf87ccf95 (v6.d) on MoarVM 2024.04-7-gfe2080ac3
csv-ip5xs0.262 - 0.269
csv-ip5xs-201.146 - 1.165
csv-parser1.416 - 1.525
csv-test-xs-200.142 - 0.142
test1.962 - 2.023
test-t0.432 - 0.433
test-t --race0.278 - 0.281
test-t-205.275 - 5.304
test-t-20 --race1.252 - 1.327
 08:39
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
08:44 sena_kun joined 08:49 finanalyst joined
Geth rakudo/r1705: 88628f59eb | ab5tract++ | src/core.c/metaops.rakumod
foo
 10:35
ab5tract oops, didn't save the amended commit message 10:36
Geth rakudo/r1705: f0aa962a79 | ab5tract++ | src/core.c/metaops.rakumod
Give META_REDUCE_RIGHT behavior for 1-arg case

This aligns the behavior of `META_REDUCE_RIGHT` to that of
  `META_REDUCE_LEFT` when handling 1-arg cases:
   > sub infix:<@> ($a, $b) is assoc<left> { [$a, $b] }
   > say [@] 10
... (7 more lines)
lizmat ab5tract: op.count can be Inf
ab5tract ah, so that would blow up the iseq_i check 10:38
Geth rakudo/r1705: 9459057eb5 | ab5tract++ | src/core.c/metaops.rakumod
Give META_REDUCE_RIGHT behavior for 1-arg case

This aligns the behavior of `META_REDUCE_RIGHT` to that of
  `META_REDUCE_LEFT` when handling 1-arg cases:
   > sub infix:<@> ($a, $b) is assoc<left> { [$a, $b] }
   > say [@] 10
... (7 more lines)
ab5tract note that I'm not 100% convinced that this is the right direction for a fix: github.com/rakudo/rakudo/issues/17...2122279730
also not quite sure how an infix with infinite arguments is supposed to be called, grammatically speaking, but then again an infix with 1 or 0 args doesn't make much sense to me either (I'm running slow today) 10:43
am I missing something or is the Inf case not handled at all in the base code either? 10:51
lizmat could very well be... it's just that I recently worked with .count in ParaSeq and got bitten by Inf :-)
ab5tract ah, gotcha :)
nine ab5tract: I'd be a bit more cautious with the "fixed in RakuAST" label. It can just be that the mis-behaving optimization hasn't been implemented yet in RakuAST. 11:19
ab5tract Ah, fair.
lizmat maybe change the naming of the label to: "probably fixed in RakuAST" ?
ab5tract Well, some things we know for sure are fixed 11:20
So maybe a new label instead
lizmat works for me 11:21
nine We only know for sure if there is a spectest covering it. Otherwise the high code churn may lead to regressions for these issues.
ab5tract That’s different than “maybe fixed” though 11:23
I’ll pause my Issue Quest to work on the required harness changes
Unfortunately I anticipate pushback on versioned tests, as it implies tighter coupling between the test suite to Rakudo 11:33
patrickb nine: Can you have another look at github.com/Raku/problem-solving/is...1984532814 please? 11:40
11:46 vrurg left
lizmat ab5tract: indeed, the only versioning in roast should be language level 12:02
ab5tract then it should never be expected to pass on anything but HEAD of rakudo 12:03
you really can't have it both ways
lizmat current roast passes the tests on HEAD indeed, and once that becomes 6.e, then roast will be frozen in that state 12:04
like it has with 6.d 12:05
ab5tract so there's no problem with adding a test which won't pass on, say, 2024.04?
(but does pass on HEAD) 12:06
lizmat sure
github.com/Raku/roast/tags # 6.c and 6.d tests
ab5tract I guess I misunderstood the decoupling then
well, that makes things easier :) 12:07
lizmat when 6.e is released, the then state of roast will be tagged with 6.e
and we take it from there again :-)
meanwhile there's a 6.d-errata branch, which corrects errors found in roast tagged with 6.d 12:08
Geth roast: 3434882538 | ab5tract++ | S12-construction/construction.t
Test that all parents' attributes are set with .new

This addresses the remaining piece of R#1679.		 12:11
linkable6 R#1679 [open]: github.com/rakudo/rakudo/issues/1679 [tests needed][regression] BUILDPLAN sharing optimization appears to have broken ancestor attribute initialization
Geth roast: 92262facef | ab5tract++ | S06-other/main.t
Remove erroneous todo fudging
 12:15
13:10 finanalyst left 13:16 vrurg joined
ab5tract so is using the Q | |.AST.EVAL form appropriate for RakuAST tests? if so, I don't think the fudger needs modification after all 13:37
13:37 finanalyst joined
Geth roast: 4b9624630e | ab5tract++ | S03-sequence/misc.t
Add test for R#5520
 13:39
linkable6 R#5520 [open]: github.com/rakudo/rakudo/issues/5520 [tests needed][Fixed in RakuAST] Chained sequence and `for`
ab5tract like so ^^
lizmat why use is_run? 13:43
if you use a push to an array instead of .say
you could use ann is-deeply
my @result; Q| @result.push($_) for 1...5...3 |.AST.EVAL; is-deeply @result, [1,2,3,4,5,4,3] 13:45
ab5tract ^^
ab5tract m: @result.push($_) for 1...5...3; dd @result 13:46
camelia ===SORRY!=== Error while compiling <tmp>
Variable '@result' is not declared. Perhaps you forgot a 'sub' if this
was intended to be part of a signature?
at <tmp>:1
------> <BOL>⏏@result.push($_) for 1...5...3; dd @resu
ab5tract m: my @result; @result.push($_) for 1...5...3; dd @result
camelia [1, 2, 3, 4, 5]
ab5tract Ah, I tried reproducing the bug using `[~]` and there wasn't an issue with base 13:47
lizmat m: use Test; my @result; Q| @result.push($_) for 1...5...3 |.AST.EVAL; is-deeply @result, [1,2,3,4,5,4,3]
camelia ok 1 -
ab5tract yes, looks good. but what's the problem with is_run? just to understand 13:48
[Coke] does is_run use a new process? 13:49
ab5tract as I'm going through all of these tickets, I'd prefer not to have to spend significant time reproducing alternative versions of the provided cases
lizmat yes 13:53
it runs a new process
nine Was .AST meant as a public API? I thought it was more a helper for during RakuAST development. 13:54
Geth roast: 83905d26ef | ab5tract++ | S03-sequence/misc.t
Prefer version without is_run
ab5tract nine: good question. unfortunately the test doesn't appear to work when providing `use experimental :rakuast;` in the block scope 13:57
nine A very simple solution would be to add these new tests to rakudo itself and migrate them to roast after RakuAST has become the default 13:59
lizmat nine: how about using .AST as place holder in roast, to be removed by the time 6.e is default ?
ab5tract nine: I had considered putting them in rakudo... if we go that route, is it alright for them to land in a single file? 14:10
nine The important part is to have them in the first place :)
ab5tract sure, but I have to ask these things because clearly there's a lot of things to be concerned about, and I'm not wise enough to see them in advance :) 14:11
Geth roast: 27317e54d8 | ab5tract++ | S03-sequence/misc.t
Keep .AST out of roast
 14:17
lizmat that... works?? 14:18
m: say "foo"; { use v6.*; }
camelia ===SORRY!=== Error while compiling <tmp>
Too late to switch language version. Must be used as the very first statement.
at <tmp>:1
------> say "foo"; { use v6.*⏏; }
Geth roast: 4da1bb7969 | ab5tract++ | S03-sequence/misc.t
Fix plan
 14:19
lizmat also: "use experimental :rakuast" **only** makes the RakuAST classes available
ab5tract damnit
lizmat it does *not* change the grammar
ab5tract that's a very important distinction, thank you for clarifying 14:20
it wasn't what I intended to push :(
lizmat again: why not a todo 'fixed in RakuAST' ?
ab5tract I feel like I'm getting some conflicting information here... 14:22
lizmat I mean: there are *many* todos in roast
ab5tract IIUC, the todo would just be cosmetic?
if roast is onlyt 14:23
lizmat ok, the question is really: do we mean to check the RakuAST implementation doesn't regress ?
ab5tract if roast is only caring about HEAD, then what's the point of a todo?
lizmat or do we mean to check that it will be fixed in 6.e ?
ab5tract the first one
lizmat a todo would cover the latter, so ok: todo is out 14:24
ok, then I suggest we add a t/12-rakuast/fixes.rakutest file 14:25
and put all of these types of tests there
sorry for the confusion and thanks for the perseverance and nudging :-)
ab5tract lizmat++ 14:32
m: use Test; lives-ok { Q| use trace; my %a{Str} |.AST.EVAL }, "trace pragma works with hash shapes"
camelia 2 (EVAL_0 line 1)
my %a{Str}
ok 1 - trace pragma works with hash shapes
ab5tract any easy way to divert the trace output to /dev/null? or should I not bother being so picky 14:33
lizmat github.com/lizmat/Trap/blob/main/l...ap.rakumod :-) 14:34
nine Tracing is implemented by generating nqp::getstderr().write_fh(...) calls, so I doubt Trap would catch that 14:38
lizmat ah, good point!
so I guess any trace tests *would* benefit from using is_run :-) 14:39
ab5tract which is is-run in Rakudo and is_run in roast :) 14:40
with different syntaxes too.. maybe we can port is-run over directly at some point 14:44
Geth rakudo/main: 22a7a89742 | ab5tract++ | t/12-rakuast/fixed-in-rakuast.rakutest
Add the first 'Fixed in RakuAST' tests

In order to prevent regressions, we will be accumulating test cases for issues that remain open but which have been confirmed working with RakuAST.
First up: R#5520 (#5520) and R#5546 (#5546).		 14:51
linkable6 R#5520 [open]: github.com/rakudo/rakudo/issues/5520 [tests committed][Fixed in RakuAST] Chained sequence and `for`
R#5546 [open]: github.com/rakudo/rakudo/issues/5546 [tests committed][Fixed in RakuAST] Interaction of `use trace` with hash shapes
ab5tract lizmat: does R#5536 need a test? 14:59
linkable6 R#5536 [open]: github.com/rakudo/rakudo/issues/5536 [Fixed in RakuAST] discrepancy in --doc output between standard/RAKUAST
lizmat I think that's covered in the doc tests
there's a special RakuAST version of that I seem to remember 15:00
ab5tract glad to hear it, because I have no idea how to write a test for that :) 15:12
this one is also a bit tricky.. R#5396
linkable6 R#5396 [open]: github.com/rakudo/rakudo/issues/5396 [Fixed in RakuAST] Using a FIRST block in while loop causes unexpected behaviour
lizmat is there a test in roast for this maybe marked as todo or skip ? 15:13
ab5tract m: Q| my &a = *.uc ~ *.lc ~ (*.uc ~ *.lc); my &b = *.lc ~ *.lc ~ (*.lc ~ *.lc); &a eqv &b |.AST.EVAL ==> say() 15:18
camelia True
ab5tract boo 15:19
ahh, that's probably fixed in nine++'s branch
lizmat: not sure about that. maybe [Coke] knows?
nine ab5tract: doesn't look like it's fixed there 15:33
ab5tract bummer :/
iiuc, this would have been working prior to the move away from using deparse in the .raku representation 15:35
nine So we're getting the wrong source code location for infix expressions? 15:41
ab5tract I haven't looked into it closely but I did notice .raku breaking for more complex WhateverCodes earlier 15:52
m: Q| my &b = *.lc ~ *.lc ~ (*.lc ~ *.lc); dd &b |.AST.EVAL
camelia Callable &b = ~
ab5tract m: Q| my &b = *.lc ~ *.lc ~ (*.lc ~ *.lc); say &b.raku |.AST.EVAL 15:53
camelia ~
ab5tract but which `~` ? :)
m: Block+{Callable[Int:D]} ~~ Block; 15:56
camelia Use of uninitialized value of type Block in numeric context
in block <unit> at <tmp> line 1
Cannot resolve caller Numeric(Block:D: ); none of these signatures matches:
(Mu:U \v: *%_)
in block <unit> at <tmp> line 1
ab5tract how does one hold this kind of type object, I wonder?
gfldex You need to bind it to a symbol. There is no user interface to create _this_ typeobject, other then going through .^mixin . 15:59
It's kind of an instance of a type-object type-object.
ab5tract gfldex: this is for a test case, so the question is a bit of a chicken and egg situation. can't really bind it to a symbol if the grammar chokes when parsing it, right? 16:12
gfldex m: dd Block but Callable[Int:D]; 16:15
camelia Int:D = Block+{Callable[Int:D]}
gfldex m: dd (Block but Callable[Int:D]) === (Block but Callable[Int:D]);
camelia Bool::True
gfldex This could be seen as a caching artifact. 16:16
nine Probably interning, not just caching 16:20
Geth rakudo/rakuast-phase-cleanup: b42721bec2 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: fix infix expressions origins only covering the operator itself

This led to the WhateverCode generated for *.lc eqv *.uc only getting
  "eqv" as its $!original-expression		 16:22
nine ab5tract: ^^^ 16:23
This was a pretty easy fix for once
ab5tract \o/
gfldex: ah, thatt's clear, thanks 16:30
Geth rakudo/main: ddde58bec1 | ab5tract++ | t/12-rakuast/fixed-in-rakuast.rakutest
Add most of the remaining 'Fixed in RakuAST' test cases

A select few of them are a bit more complex, so I'm leaving them as a challenge for a different day.		 17:08
rakudo/main: 2c3602de28 | ab5tract++ | tools/templates/Makefile.in
Provide test harness support to .rakutest files in t/
 17:14
rakudo/main: 5a122c60ab | ab5tract++ | t/12-rakuast/fixed-in-rakuast.rakutest
Un-todo a working test
 17:23
lizmat ab5tract: why reduce the test count? was it wrong?
ab5tract yes :) 17:31
lizmat m: subset Even of Int where * %% 2; .say for (^10).grep(Even) 18:38
camelia 0
2
4
6
8
lizmat m: subset Even of Int where * %% 2; .say for (^10).hyper.grep(Even)
camelia A worker in a parallel iteration (hyper or race) initiated here:
in block <unit> at <tmp> line 1

Died at:
Type check failed in binding; expected Callable but got Even (Even)
lizmat didn't even know that that's not a thing 18:39
ParaSeq fixes that :-)
ab5tract nice! 18:43
Geth rakudo/rakudoc-comment: d961a05154 | (Will Coleda)++ | lib/Pod/To/Text.rakumod
Z<> is a comment - do not render it as text.

Fixes #5574		 20:13
rakudo: coke++ created pull request #5575:
Z<> is a comment - do not render it as text.
[Coke] I feel like this needs a test! 20:14
"This is Z<not> OK" now renders as "This is OK"
Geth rakudo/main: c1cc007f96 | (Will Coleda)++ (committed using GitHub Web editor) | lib/Pod/To/Text.rakumod
Z<> is a comment - do not render it as text.

Fixes #5574		 20:16
lizmat looks good to me!
[Coke] WOOT
Geth rakudo/main: 22932c27a8 | ab5tract++ | t/12-rakuast/fixed-in-rakuast.rakutest
Un-fudge the regex code param tests

The tests were previously broken due to a syntax error, not because of any regression.		 20:21
22:18 sena_kun left 22:29 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!