🦋 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.
00:00 reportable6 left 00:01 reportable6 joined 00:30 samcv left, samcv joined 01:07 Kaiepi joined
vrurg greppable6: set_language_version 01:54
greppable6 vrurg, Found nothing!
vrurg greppable6: set_language_revision
greppable6 vrurg, Found nothing!
02:33 linkable6 left, evalable6 left 02:34 linkable6 joined 02:36 evalable6 joined 04:15 vrurg_ joined, vrurg left 06:00 reportable6 left 06:02 reportable6 joined 06:31 Kaiepi left 08:41 sena_kun joined
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 10:36
nine 92 make test files passing (+2) and 618 spectest files (+10)
10:56 Kaiepi joined
lizmat I count 620 ? 11:12
nine lizmat: that's my list:gist.github.com/niner/40bd639593c2...1d0eddd4cc 11:26
lizmat hmmm... looks like something is flapping 11:34
I was using:
RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | wc -l
and it produced 620 and 617 just now
running again
the 618 I got from: RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | sort 11:36
matches your list
nine t/spec/S12-construction/destruction.t is definitely a flapper and has been for a long time 11:37
lizmat yeah :-( 11:44
nine lizmat: good news! I think it's actually an error in the test itself and trivial to fix really. A dd @destructor_order; at the end of the test tells the story: 11:49
In perfect conditions, this prints: Array @destructor_order = ["Child", "Parent"] and that's what the test is looking for.
Most of the time however it takes 2 runs of the loop for the destructors to fire and we end up with: Array @destructor_order = ["Child", "Parent", "Child", "Parent"] 11:50
The test is still fine with that. But sometimes it's Array @destructor_order = ["Child", "Child", "Parent", "Parent"] instead. Which is still ok! Children destroy before their parents. But the test doesn't account for this order.
lizmat yeah, but with those texts, we don't know which child is before which parent ? 11:51
if there are multiple ones
how do we know that Child Parent Child Parent is ok?
ok, I get something *really* weird now 11:52
nine We could simply ad some id to the parent class
lizmat I've added a ";\n" to a string in RakuAST::Deparse
and now t/02-rakudo/03-cmp-ok.t reliably fails with: 11:53
setcodeobj needs a code ref
this is the diff: 11:54
gist.github.com/lizmat/e58cbfcd9a3...e0451203ff
ok, so I do a reconfigure and build, and the problem goes away... 12:00
weird
12:00 reportable6 left, reportable6 joined
Geth rakudo/main: 36638d2fd7 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Tweak deparsing of repeat { } xxx expr
 12:07
rakudo/main: e6cfc4c8f5 | (Elizabeth Mattijsen)++ | t/12-rakuast/statements.rakutest
Add extensive deparsing tests to statements
lizmat m: ... "this is the yada yada yada operator taking a string" 12:16
camelia this is the yada yada yada operator taking a string
in block <unit> at <tmp> line 1
lizmat TIL
Nemokosch lol 12:18
lizmat m: !!! "this is the yada yada yada dieing operator taking a string"
camelia this is the yada yada yada dieing operator taking a string
in block <unit> at <tmp> line 1
lizmat the things you learn writing deparsing tests 12:19
m: !!!("foo")
camelia foo
in block <unit> at <tmp> line 1
lizmat m: !!!
camelia Stub code executed
in block <unit> at <tmp> line 1
lizmat m: die
camelia Died
in block <unit> at <tmp> line 1
lizmat that's the difference, really 12:20
Nemokosch is it like a die with a default? 12:22
lizmat yeah, except its a grammar construct 12:23
m: dd ::("!!!")
camelia Failure.new(exception => X::NoSuchSymbol.new(symbol => "!!!"), backtrace => Backtrace.new)
lizmat m: dd ::("&!!!") # more correct spec 12:24
camelia Failure.new(exception => X::NoSuchSymbol.new(symbol => "\&!!!"), backtrace => Backtrace.new)
Nemokosch is it not &prefix:<!!!> or something? 12:27
lizmat nope... it's macro-ish in that sense 12:28
Geth roast: a87e5f1184 | (Stefan Seifert)++ | S12-construction/destruction.t
Fix flapping desturctor tests

In perfect conditions, @destructor_order is ["Child", "Parent"] and that was what the test was looking for. Most of the time however it takes 2 runs of the loop for the destructors to fire and we end up with: ["Child", "Parent",
  "Child", "Parent"]. The test is still fine with that. But sometimes it's
  ["Child", "Child", "Parent", "Parent"] instead. Which is still ok! Children
... (5 more lines)		 12:37
nine Finally :)
12:38 discord-raku-bot left, discord-raku-bot joined
lizmat nine++ 12:39
Nemokosch oh okay 12:45
12:56 discord-raku-bot left, discord-raku-bot joined
lizmat m: use experimental :rakuast; use MONKEY; dd EVAL(RakuAST::Stub::Warn.new) 13:11
camelia No such method 'resolve-with' for invocant of type
'RakuAST::Stub::Warn'
in any IMPL-CHECK at src/Raku/ast/base.rakumod line 88
in any at src/Raku/ast/base.rakumod line 120
in any visit-children at src/Raku/ast/statements.rakumod line 5…
lizmat nine: I guess that's a known issue, thoughts on me being able to fix that ? 13:12
added an empty "resolve-with" method, now fails with missing IMPL-EXPR-QAST, guess I'll be adding that now :-) 13:16
nine Looks to me like RakuAST::Stub shouldn't do RakuAST::Lookup, since it doesn't actually look up anything 13:17
lizmat even if the ArgList could be looking up ?
nine Ther arglist is its own node and has to take care of itself. But Stub needs a visit-children for that to happen 13:18
lizmat wouldn't it use the RakuAST::Call's visit-children ? 13:19
anyway, it would need a IMPL-EXPR-QAST, right ? 13:20
nine Yeah, may as well be on RakuAST::Call itself 13:21
lizmat the IMPL-EXPR-QAST or the visit-children? 13:22
nine However, I wonder if you're actually using it correctly. After all, this works just fine: RAKUDO_RAKUAST=1 ./rakudo-m -e '...'
Stub code executed
Hm...that doesn't even use any of these Stub nodes 13:24
lizmat ah, so maybe we just remove the stub nodes :-)
and their testing :-) 13:25
nine Yeah, stubs compile directly to calls to fail/warn/die 13:27
lizmat yeah, looks like
ok, so, change the actions to use the stubs, or remove the stub classes ?
nine However, one could argue that these deserve their own node types, at least for the purpose of deparsing. 13:28
lizmat yeah, since they're macroish anyway
so the actions'd become something like: 13:29
self.attach: $/, self.r('Stub', 'Fail').new(); 13:30
nine yep
lizmat ok, lemme see if I grok this enough to get this together :-) 13:31
its IMPL-EXPR-QAST I need to implement, right ? 13:32
nine Yes, like in RakuAST::Call::Name, only much less complicated 13:33
lizmat ack
14:22 Kaiepi left, Kaiepi joined
lizmat ok, almost there 14:31
but I now get "lang-call cannot invoke object of type 'VMNull' belonging to no language" when EVALling the AST
nine: suggestions?
gist.github.com/lizmat/18b0cc12644...d4faf55863 is what I got so far 14:32
nine no idea 14:38
lizmat but that implementation in the gist looks ok, right ? 14:39
is ... actually a Term, if it can take args ? 14:40
nine doesn't even know what a Term actually is 14:41
lizmat time now nano 14:42
15:50 linkable6 left, evalable6 left, linkable6 joined 15:52 evalable6 joined
nine lizmat: I think you introduced a bug here github.com/Raku/roast/blob/master/...nts.t#L160 in commit github.com/Raku/roast/commit/8120b...3f04d8dfcc 16:55
Or rather you enshrined a bug. Test description says "comments can't contain unspace" but the test is actually broken. It will complain about the undeclared variable $a and your commit made us test for that explicitly. Should probably be X::Syntax::Comment::Embedded 16:57
(and a my added to the test)
Nemokosch woah, that was a long time ago 17:02
Geth rakudo/main: c4080f9537 | (Stefan Seifert)++ | 2 files
RakuAST: fix crash with embedded comment at the start of the comp unit

lang_setup is run only after we parsed a possible language version declaration which in turn may be preceeded by a comment. This comment may need the literals builder, hence the crash.
Fix by setting up the literals builder in comp_unit_stage0 instead. Since it needs the resolver, but the resolver needs the language version, set the resolver on the literals builder once we have it.		 17:03
nine So, apparently many, many of the remaining fails are just because we don't throw the right kind of exception yet. 17:33
But then, there's also surprising finds like: class Foo { has $.i = 1; }; Foo.new.i returning Any 17:34
Because....we have no support whatsoever for build plans/BUILDALL
lizmat aha... ok... hmmmm 18:00
18:00 reportable6 left
lizmat but that can now be set up properly built using RakuAST:: classes 18:00
18:00 reportable6 joined
lizmat nine: so where would be set up the BUILDALL method 18:03
for a given class? also, when? 18:04
nine I think "when" is actually the most interesting question. And it will tell us where. 18:13
lizmat m: use MONKEY; EVAL Q/class A { has $.a }; dd A.^BUILDPLAN/.AST 18:16
camelia ((0, A, "\$!a", "a"), (1000, A, "\$!a"))
lizmat looks like the buildplan is made as expected in RakuAST already 18:17
at least that part of it :-)
nine Obviously we're gonna need all the attributes already declared, so BEGIN time is too early as for packages that's run right before we start parsing the block. Would doing it as part IMPL-EXPR-QAST be too late?
lizmat well, I'd say it would be needed as soon as the closing curly of the class has been processed ?
aka, the mythical COMPOSE phaser :-) 18:18
nine The BUILDPLAN is created by the MOP
IMPL-CHECK would be the right peg then 18:23
lizmat ok, so let me see if I can hang that on RakUAST::Package's peg then 18:24
hmmm.. there also appears to be a IMPL-INSTALL-PACKAGE method
feels it should be there maybe?
nine No, that's run at BEGIN time to put it into the right stash.
Actually we could add an IMPL-COMPOSE method that's called by Raku::Actions::package_def. The latter currently already calls meta-object to compose that. 18:25
IMPL-COMPOSE could take care of composing the meta object and adding that BUILDALL method 18:26
lizmat ok, will look at that 18:29
meanwhile, I'm going to give up at the stubs issue
I *think* I did the right thing
but if they're not codegenned as RakuAST::Call directly, but rather through RakuAST::Stub, the running of them fails 18:30
I've todoed the associated tests 18:31
it doesn't lose us any full files passing 18:43
so I will push what I have now
Geth rakudo/main: 57dd190186 | (Elizabeth Mattijsen)++ | 3 files
Rework how ... !!! ??? are codegenned

They were codegenned as calls to fail, die and warn respectively, rather than using the already existing RakuAST::Stub classes.
These will now be codegenned as RakuAST::Stub classes, which generate the QAST to call fail, die and warn respectively. However that appears ... (8 more lines)		 18:51
rakudo/main: b436566ee9 | (Elizabeth Mattijsen)++ | t/12-rakuast/stubs.rakutest
Add deparsing tests to stubs

And try to handle the current brokenness of stubs in a todo-like way		 18:58
19:02 ab5tract joined
Geth rakudo/main: 34efa23686 | (Elizabeth Mattijsen)++ | src/Raku/ast/base.rakumod
Allow calling .DEPARSE with a class

This allows for subclassing RakuAST::Deparse for customization.
   use experimental :rakuast;
   class A is RakuAST::Deparse { }
   say Q/say "foo"/.AST.DEPARSE(A); # say("foo")		 19:21
19:21 ab5tract left 19:25 ab5tract joined 19:29 Kaiepi left
Geth rakudo/main: 50fd019f3f | (Elizabeth Mattijsen)++ | 2 files
Put in IMPL-COMPOSE stub

For creating a class' BUILDALL from its BUILDPLAN		 19:37
nine lizmat: hint, hint, unfinished work is what branches are for ;) 19:43
lizmat noted: however at the current rate of changes, any branch would very quickly become unmergeable 19:45
and fixing conflicts would at least for me, with my current RakuAST internals knowledge, be pretty impossible, I'm afraid 19:48
19:49 ab5tract left 20:09 Kaiepi joined
Geth rakudo/main: b832f70db7 | (Elizabeth Mattijsen)++ | t/12-rakuast/package.rakutest
Added deparsing tests for RakuAST::Package
 20:16
rakudo/main: 677db9cc55 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: Finish implementation of RakuAST::Stubs

Just base it on RakuAST::Call::Name and let that do all the heavy lifting.		 20:17
nine lizmat: ^^^
lizmat nice!
eh, but will disallow deparsing :-( 20:18
ah, no, method name() is still there *phew* 20:19
Geth rakudo/main: f9b01f80a3 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
Make deparsing of empty set same as in old grammar
 20:30
lizmat nine: it did break deparsing, as there is now no difference between 20:31
...
and
... "Stub code executed"
from an AST standpoint 20:32
20:33 ab5tract joined
Geth rakudo/main: e8c23f84b3 | (Elizabeth Mattijsen)++ | t/12-rakuast/terms.rakutest
Add deparsing tests for terms
 20:34
20:43 ab5tract left
lizmat m: use experimental :rakuast; dd RakuAST::NumLiteral.new(1e5) 20:53
camelia 100000e0
lizmat I wonder whether deparsing num literals should keep the original specification or not
m: use experimental :rakuast; dd RakuAST::RatLiteral.new(.60) 20:54
camelia 0.6
lizmat I guess the same for all numeric literals... hmmm
nine No, hence the A in AST 20:55
lizmat I guess :-) 20:57
Geth rakudo/main: dfd2703803 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: keep a difference in the AST for stubs with and without args

While technically correct, we don't want a plain ... to deparse to
  ... 'Stub code executed'
So instead of adding default arguments to the AST, keep the default args ephemeral.
Nemokosch RakuAST meeting when? 👀 21:00
lizmat well, you're the first one to react to my proposal 21:08
21:10 ab5tract joined
lizmat nine: alas, it's the .args method that is used by deparsing to see if there are any args :-( 21:11
21:19 ab5tract left
nine Cheat... nqp::getattr ;) 21:34
Or add a helper method that does that for you 21:35
I'll be afk for a week. Will be back in action on the 18th 21:36
lizmat ok, have fun! 21:37
Geth rakudo/main: 6d837b38db | (Elizabeth Mattijsen)++ | 2 files
Fix deparsing of stubs and the anonymous state var
 21:51
rakudo/main: 212e5e6eb7 | (Elizabeth Mattijsen)++ | t/12-rakuast/var.rakutest
Add deparse test for variables of all sorts
lizmat and that concludes my hacking for today&
22:21 Xliff joined 22:58 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!