🦋 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, reportable6 joined
Geth rakudo/main: 0d1444d267 | (Elizabeth Mattijsen)++ | src/Raku/ast/resolver.rakumod
Fix spelling error and formatting in comment
 00:11
rakudo/main: 14923ccb43 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
Make sure the RakuAST::Pragma class is known

  "no strict".AST would fail before this
02:25 jjatria left 02:36 jjatria joined 03:15 coverable6 left, djinni` left, japhb left 03:27 coverable6 joined, djinni` joined, japhb joined 06:00 reportable6 left 06:03 reportable6 joined
nine Nemokosch, you aware of --ll-exception? 07:17
Nemokosch I heard the name but perhaps not consciously aware 08:27
nine Just wanted to mention: I just had an introduction call with a new colleague and told him about my involvement with Raku and he said that our website looks very nice and he really liked Camelia :) 08:28
Nemokosch, just run rakudo with that and get the full backtrace on any exceptions thrown during compilation and later :)
Nemokosch That sounds cool 💪 thank you 08:29
Geth nqp/main: d19ece2409 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP to get MoarVM optimizations
 09:18
rakudo/main: 250b43347a | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MoarVM optimizations
 09:38
lizmat bare startup of raku from 0.12 to 0.11 on the M1Mini of yours truly
nine: looking at gist.github.com/lizmat/a61f90d5699...e1-txt-L23 09:52
do you see a thinko in the approach on getting "no strict" to work ?
the idea is to simply replace a Var::Lexical by a VarDeclaration::Simple 09:53
m: use MONKEY; EVAL Q|sub a() is raw { our $x }; a() = 42; say OUR::<$x>|.AST 09:56
camelia 42
lizmat so, the VarDeclaration::Simple does return a container
ab5tract In a statement list, if QAST bind mentions a lexical variable before a QAST::Var has declared that lexical variable, does it just silently fail to bind? 10:00
or does it somehow still bind to the lexical even if the lexical definition comes afterwards? 10:02
nine lizmat: except for that final $declaration.resolve-with($*R); it may just work 10:04
lizmat you mean it doesn't need to be resolved? 10:05
lizmat tries 10:06
nine ab5tract: I think that's fine. The list of lexicals is a property of the frame, so there is no connection to the place in the QAST where it's declared (other than in which scope)
ab5tract ok, great to know thanks
nine It can't be resolved as RakuAST::VarDeclaration::Simple is no RakuAST::Lookup
lizmat aha! ok 10:07
nine lizmat: but you may need a call to $*R.declare-lexical so the compiler knows that lexical from then on 10:09
lizmat: the actions for variable_declarator does that call, but you are in variable access 10:10
lizmat calling it with the $declaration just made, right ? 10:14
nine yes 10:15
lizmat no strict; $x = 42 now dies with Died with X::Assignment::RO 10:17
no strict; $x; say OUR::<$x>:exists # False, in base gives True 10:18
evalable6 WARNINGS for /tmp/jnyhZiWEe_:
True
Useless use of $x in sink context (line 1)
lizmat I guess it doesn't actually create the container in OUR:: now, because there's no place where the QAST for that is generated now 10:25
nine: so I guess the declaration needs to be hooked up into QAST generation somehwo 10:26
nine: updated the gist gist.github.com/lizmat/a61f90d5699...692f1390c3 10:53
basically, added a "set-declaration" method to Var::Lexical
that will produce the QAST of the declaration just before producing the QAST of the access 10:54
verified that the declaration.IMPL-QAST-DECL is being run, yet still no go :-(
nine I wouldn't muddy the waters any further. There are already a few things that are declaration and access in one and things get quite complicated there. 10:58
lizmat agree... it was more a prove of concept :-)
nine I'd still try to get your original approach of replacing the access with the declaration going.
lizmat I think that works, *but* it still needs the QAST generated for the variable somehow 10:59
nine Have you looked at the variable_declarator action? 11:00
Maybe there's something else that does. Oh and I think your original patch didn't actually contain the attach call
lizmat it looks like it is missing a self.attach: $/, $decl; in the actions 11:17
so how would I add that?
11:18 sena_kun joined
lizmat m: use MONKEY; EVAL Q|our $x; say OUR::.keys|.AST 11:31
camelia ()
lizmat looks like "our $x" itself is still with problems
m: our $x; say OUR::.keys
camelia ($x)
11:38 epony left, epony joined
lizmat looks like the QAST differs 11:38
RakUAST: - QAST::WVal(GLOBALish) QAST::SVal($x) 11:39
base: - QAST::Var(lexical $?PACKAGE) - QAST::WVal(Str)
nine That doesn't necessarily indicate a problem. $?PACKAGE will contain GLOBALish and the new frontend just doesn't box the string but I don't think that will matter 11:49
12:00 reportable6 left
lizmat m: use MONKEY; EVAL Q|our $x; say $x; dd OUR::.keys|.AST # looks like it's going wrong if there's no initializer 12:00
camelia (Any)
().Seq
lizmat m: use MONKEY; EVAL Q|our $x = 42; say $x; dd OUR::.keys|.AST
camelia 42
("\$x",).Seq
12:01 reportable6 joined
ab5tract lizmat: I hit a wall with that in one of my many diversionary approaches as well 12:02
nine I guess the old frontend always creates code to initialize our scoped variables? 12:06
lizmat m: use MONKEY; EVAL Q|our $x; say OUR::.keys; $x = 42; say OUR::.keys|.AST
camelia ()
($x)
nine Since our scoped variables are really just entries in the Stash, these entries must have some initial value after all 12:07
lizmat looks like it doesn't get vivified until assignment
I guess similar to: 12:09
m: my %h; my $x := %h<x>; say %h.keys; $x = 42; say %h.keys
camelia ()
(x)
nine I don't see any significant difference to the QAST of the old frontend though. Maybe the compiler does the vivification instead? 12:11
Yes, $*W.install_lexical_container will call install_package_symbol_unchecked which does an assignment 12:15
lizmat ok, will check an mimicry 12:16
*and 12:17
Geth rakudo/main: 1acb74d875 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.pm6
Add :run named arg to .AST

Mostly to allow quicker testing, e.g. with camelia online		 12:32
lizmat m: Q|our &foo; dd OUR::<&foo>|.AST(:run) 13:21
camelia Any element{'&foo'} = Any
lizmat m: our &foo; dd OUR::<&foo>
camelia Callable &foo = Callable
Nemokosch If there is a fresh state of test outputs, could you please make an "official" (valid) list of passing and failing test cases from it? 13:23
lizmat I guess we also need to fix that :-)
nine Nemo, what for? 13:24
Nemokosch To see the state of things. To be honest, I'm not at all confident when I look at a test output I produced; for example, I got like 21 "ok"s on a main branch checkout, after make && make install 13:42
nine should be a 100 more
Nemokosch you say fairly different numbers. And also, it would be good to know what's behind those numbers.
btw that "21" is 42 when I recompile with my change, so absolute chaos 13:43
nine what failures do you see?
ab5tract Nemokosch: you might want to re-run the Configure.pl script, maybe do a make realclean first 13:47
tellable6 ab5tract, I'll pass your message to Nemokosch
ab5tract nine: I'm totally lost with trying to tweak IMPL-CURRIES. Any problem I solve just creates another problem. For example, adding "'&&', 0" makes the an expression like 'suibset F where * && 5; my F $f = False' fail, it makes '(* && 5)(False)' die 13:59
The first example is wanted behavior, the second example is unexpected 14:00
Ah, maybe that's still related to the broken ApplyPostfix code 14:03
Still, I feel like my brain is melting -_- 14:04
also, yesterday we were discussing whether things curry or not. 14:09
m: (* == 5).^name.say 14:13
camelia ( no output )
ab5tract m: (* == 5).WHAT.^name.say 14:14
camelia WhateverCode
ab5tract but in the QAST generated by this expression, I don't see a WhateverCode
gar, should have double checked. I guess I'm getting a bit lost in comparing the outputs of * &&, * ==, and * ~~ 14:15
Nemokosch ab5tract back to that - yes, it would be good if I had a better understanding of what needs to be run to get a clean state installed 14:22
but I'd say regardless it would be good (and quite effortless, probably) to have an updated list - a table or something like that - of what "should work now", on main at least 14:23
nine m: (* && 5)(False) 14:24
camelia No such method 'CALL-ME' for invocant of type 'Int'
in block <unit> at <tmp> line 1
nine So dieing there is perfectly fine!
Nemokosch if I get confident in what I'm actually running, I might as well make such a table or something
to connect the two things
ab5tract nine!! 14:25
Nemokosch oh right, && doesn't Whatever-curry
nine You won't see a WhateverCode for the same reason you don't see a Method or Sub. Those are meta objects. They are part of the serialized _data_, not the code. What you will see is a QAST::Block that matches your expression 14:26
Nemokosch I wonder if Whatever-currying could be cleaned up on design level
once the new frontend works
ab5tract nine: Usually there is a little clone op that comes with a WVal of 'WhateverCode' 14:28
Nemokosch Anyway: current plan: I do a rakubrew triple, run make test and make spectest, with RAKUDO_RAKUAST=1, save the outputs... and then I do something with my local branch, rebase it, something for building, and then test again
nine Ah, yes, for dd (* == 5) I do get a QAST::WVal(WhateverCode) 14:30
Nemokosch, a find . -name .precomp | xargs rm -rf can help sometimes 14:31
Nemokosch sounds like a good idea 😅 👍 14:32
also, good to know what xargs is good for 14:33
nine Well the safer and more correct version of the command is: find . -name .precomp -print0 | xargs -0 -r rm -rf
ab5tract The only difference I can find between these two gists (other than us wrapping the ApplyInfix in ApplyPostfixes) is that in my branch, '$whatevercode_arg_1' is a 'contvar' instead of a 'var': gist.github.com/ab5tract/144c33cb3...638f66a6a5 14:38
I've said it before and been very wrong, but what I see is functionally equivalent :( 14:39
nine In what way does the code you gisted still fail? 15:12
ab5tract The assignment succeeds even when the constraint should make it fail 15:16
Nemokosch > grep '. ok' test_without | wc -l 15:18
> 129
looks better...
ab5tract Nemokosch: much!
tellable6 ab5tract, I'll pass your message to Nemokosch 15:19
Nemokosch 693 for "spectest_without"
nine ab5tract: the differences in generated QAST are not just cosmetic. Base just is (5 == 6) -> False. Your's is -> $_ { (5 == 6).ACCEPTS($_) }.Bool 15:30
Note that the pointy block never actually gets called!
ab5tract But why doesn't it get called? It gets called with similar branch QAST with '(* == 5)(6)' 15:33
damnit, no, in that case it is not wrapped... 15:34
QAST featured in my dreams last night 15:35
Nemokosch how should I run ./Configure.pl so that I get an actually working Makefile?
"Can't compiler [sic] CORE.c yet" doesn't sound healthy... 15:36
ab5tract Nemokosch: perl Configure.pl --gen-moar --gen-nqp --backends=moar
tellable6 ab5tract, I'll pass your message to Nemokosch
Nemokosch thankies
re tellable - the funny thing is that it does convert my name into Discord mentions
so I am "notified" in extra on the Discord side as well 15:37
I mean the bridge does that, not tellable itself
ab5tract ah, right
Nemokosch --backends=moar is probably a good idea indeed 😄 15:38
nine Do NOT run Configure.pl or make with RAKUDO_RAKUAST=1
only RAKUDO_RAKUAST=1 make test
Nemokosch all these crazy interactions... 15:39
🤕
ab5tract nine: so when you say that the block never gets called... how do I make sure it is called? 15:41
presumably I need to add an QAST op of 'call' somewhere 15:42
Nemokosch okay, now it's back to "vast majority of test cases fail" 15:49
ab5tract :(
Nemokosch it's annoying how tests are not really reproducible
ab5tract I think its because you are fiddling deep in the innards 15:50
any precomp files can subtly mess things up
Nemokosch when this run finishes, I will take a look at some individual tests 15:51
nine Why is there so much wrapping in the first place? Apparently there's no need to call ACCEPTS for example and indeed the old frontend doesn't.
Nemokosch the same thing happened last time, when I accepted everything broke, I suddenly had a clean run with 600 ok's
nine All you want is that block with cuid(2). That's your where condition. Everything else should go 15:52
Nemokosch, in my experience it's more productive to figure out why exactly things fail instead of trying random things 15:53
ab5tract nine: It's there because you told me not to special case ApplyInfix in the wrapping code :) 15:56
Nemokosch I won't be able to figure that out unless I try something in the first place
if something doesn't work at first, or second, or third, that's fine and to be expected 15:59
but that the whole thing just breaks down and I'm running circles around something that really should just work, that's brutally exausting...
nine ab5tract: that doesn't mean that the wrapping code is correct as it is. It just means that conditioning on ApplyInfix is the wrong thing. E.g. thunked expressions in general probably don't need any wrapping 16:00
Nemokosch, you are trying fixes, not investigating the problem. Unless I have misunderstood your message about going to take a look at individual tests. That would have been the first thing I'd advise. 16:02
16:05 sena_kun left 16:06 codesections left 16:07 codesections joined
ab5tract thunked expressions should all match a guard of 'nqp::istype($!expr, RakuAST::Code)', right? 16:11
nine no
Thunks are a property of expressions. They don't wrap them or change their nature.
And yes, the terms are a bit misleading, e.g. the wrap-with-thunk method. What gets wrapped is the generated code, not the expression node. 16:12
ab5tract hmm.. so along those lines I tried a guard of '(nqp::can($!expr, 'IMPL-CURRIED') && $!expr.IMPL-CURRIED)' but that didn't take either 16:13
nine I'd probably try $!expr.IMPL-CURRIED first as that's already there and if it works, investigate whether that should be extended to "any thunk" via a new method on Expression 16:14
$!expr is already a RakuAST::Expression, isn't it? So you can assume that it supports IMPL-CURRIED
ab5tract oh, fair 16:15
still, didn't trigger. maybe I need to run this begins after the children are visited?
nine Is the expression not IMPL-CURRIED or is it not IMPL-CURRIED _yet_ when you check?
exactly!
Getting the timing right is arguably the hardest part in RakuAST 16:16
ab5tract make 16:17
I said, 'make', and I meant it! ^_^ 16:18
nine: Yeah, I'm starting to see what you mean by that
Nemokosch nine: how could I understand the problem without knowing the problem 16:22
TAP output is useless to an outstanding extent 16:23
ab5tract nine: no dice, still not hitting the guard :/ 16:24
nine ab5tract: I'd add debug output to IMPL-CURRY, probably including nqp::objectid(self) and then to the place that checks IMPL-CURRIED, also including nqp::objectid($!where) 16:26
That tells you if you're actually testing the object you're expecting and also the order of events
ab5tract nice!
nine It's amazing how the debug print is the simplest and also the most versatile debugging technique in existence. Even when debugging my C++ code it's sometimes easier to add a few std::cerr << ... to my code than to wade through it in gdb 16:29
tonyo nine++ been doing that since i was ten and still find it easier than anything else
nine Nemokosch, I meant, pick one of the failing tests and just run it individually with RAKUDO_RAKUAST=1 ./rakudo-m -Ilib t/foo/bar.t. That should give you a proper error message, i.e. a hint at what's wrong. 16:30
Nemokosch okay.... I ran a passing test on the "fixed version" - and guess what, it said 'ok' to everything 16:31
go figure, really...
nine What do you mean by "fixed version"? 16:32
Nemokosch the version built from my local branch 16:33
i.e the same version that only threw errors to spectest
nine Sorry, I don't undestand the situation. You ran a passing test and it said ok to everything. That's....good, isn't it?
Nemokosch it says ok if I run the tests individually 16:34
16:34 sena_kun joined
if I run RAKUDO_RAKUAST=1 make spectest, it's all "dubious, test returned 1" 16:35
the exact same tests
nine When you run it individually, what's the exit code?
echo $?
Nemokosch 0
RAKUDO_RAKUAST=1 raku t/spec/APPENDICES/A02-some-day-maybe/concreteness.t && echo "hooray!" # will hooray 🙂 16:36
my only idea is that something broke around the test harness itself 16:37
nine Does the test output contain anything besides the ok lines? 16:46
Nemokosch gist.github.com/2colours/bd4936ad9...30e2aa790c 16:47
nine That doesn't look too bad. What about RAKUDO_RAKUAST=1 make t/spec/APPENDICES/A02-some-day-maybe/concreteness.t 16:50
Nemokosch are you sure you meant make? 16:51
good old "no such target available" 16:52
16:53 donaldh joined
nine nine@sunshine:~/rakudo (main *>)> make t/spec/S02-lists/indexing.t 16:54
'/usr/bin/perl' -I'/home/nine/rakudo/tools/lib' -I'/home/nine/rakudo/3rdparty/nqp-configure/lib' t/harness5 --moar --fudge --keep-exit-code --verbosity=1 t/spec/S02-lists/indexing.t
Like this ^^^
Ah, that file is too deep in the directory hierarchy. The makefile only does t/*/*.t t/*.t t/*/*/*.t not t/*/*/*/*.t 16:56
Nemokosch I copied the line and running it, that was a successful test 16:59
> Files=1, Tests=4, 5 wallclock secs ( 0.02 usr 0.00 sys + 8.16 cusr 0.45 csys = 8.63 CPU) 17:00
Result: PASS and all that jazz
could be, then, that the Makefile is misgenerated?
nine I did have the same issue with the 2 cpp nativecall tests which the harness reported as not ok, despite them passing just fine when running individually. Eventually I concluded it must be a bug in the harness, misattributing failures to these files, as they only were listed as failed in runs where other files were failing. 17:03
Those 2 failures have gone away since though but I can't for the life of mine remember if it was due to a specific fix or just because the files they inherited those failures from were fixed 17:04
Nemokosch the strange thing is, "make test" doesn't fail it all
"make spectest", however, fails from the very start
nine Do all files in spectest fail? 17:05
Nemokosch now go figure... I just started another run and NOW there are passing spectests, and yes, I set RAKUDO_RAKUAST=1 17:06
actually, all of a sudden, there is a good amount of 'ok's
is the harness known to act differently when the output is piped? 17:07
that's one thing I could think of
nine I don't know. My standard command is: make && TEST_JOBS=20 RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | sort | tee $(git describe).pure.tests | wc -l 17:09
Nemokosch Whatever changed... this output seems testable, at least 17:14
actually comparable to the stable version
17:22 donaldh left
ab5tract ok, it's progress, I guess... So now unmet constraint values fail to assign. But so do valid, met constraint values ... 17:30
17:30 NemokoschKiwi joined
ab5tract could it be due to binding a decont'd parameter to a 'contvar' ? 17:32
at the QAST level
18:00 reportable6 left 18:01 reportable6 joined 18:15 ab5tract left 18:16 NemokoschKiwi left
nine I don't know. Could be 18:19
lizmat nine: I just found a difference in the QAST for "our $foo" 18:22
in base, the Op(bind) is *after* the QAST::Var(GLOBALish)
in RakuAST, it is before
also, the RakuAST version is missing a QAST::Var(lexical $a :decl(contvar)) :our_decl<?> 18:24
am I missing something if I say that "use fatai" is basically the same as adding a: POST 18:51
POST $_ ~~ Failure ?? .throw !! True 18:52
phaser to each block in which "use fatal" is active ?
m: sub a { use fatal; fail }; my $a = a 18:53
camelia Died
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a { POST $_ ~~ Failure ?? .throw !! True }; my $a = a
camelia ( no output )
lizmat m: sub a { POST $_ ~~ Failure ?? .throw !! True; fail }; my $a = a
camelia Failed
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a { POST $_ ~~ Failure ?? .Exception.throw !! True; fail }; my $a = a 18:54
camelia Failed
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat and also: wouldn't such a POST phaser be potentially generic, as in the same for each block that would need it?
nine doesn't understand fatal enough to comment 19:09
I also don't understand why our scoped things still get lexicals declared for them (in the old compiler) 19:10
lizmat because they are lexically scoped 19:13
m: { our $a = 42 }; say $a
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$a' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> { our $a = 42 }; say ⏏$a
lizmat m: { our $a = 42 }; say OUR::<$a>
camelia 42
nine Btw. the design and our docs contradict each other there. S04 says "our $foo" introduces a lexically scoped alias for a variable in the current package. 20:21
docs say: our variables work just like my variables, except that they also introduce an alias into the symbol table. 20:22
I think the S04 version makes sense. The lexical variable is an alias for the package variable, not the other way round. Otherwise why would the package variable still be available, when the variable it's an alias for goes out of scope? 20:23
Nemokosch so you mean: which one is the alias and which is the real thing? 20:24
nevermind, the other message pretty much clarified
fair point... 20:25
does "symbol table" only refer to package-scoped things? 20:26
21:00 NemokoschKiwi joined 21:01 NemokoschKiwi left
nine In that sentence at least. But yeah, that's another ambiguity in the docs. The design docs are more clear 21:11
Nemokosch yeah I was thinking how to rephrase it 21:22
nine I think S04 already spells it quite nicely :) 22:00
22:49 sena_kun left
Nemokosch okay cool, my fix lowered the number of passing spectests by around 85 xD 23:16
next step: figure out which ones. Tbh I doubt I will start with it "today" 23:17
nine: > As in Perl 5, "C<our $foo>" introduces a lexically scoped alias for a variable in the current package 23:18
is this what you meant?
(I guess "as in Perl 5" can go)
Geth rakudo/main: fff197957a | (Elizabeth Mattijsen)++ | 3 files
Make "use fatal" operational

Instead of wrapping each block in a check, use the "POST" phaser mechanism to insert a special POST phaser into a block when
  "use fatal" is active.
Adds a ".fatalize" implementation-detail method to Block for convenience.		 23:35
lizmat sadly, this does not bring us more passing test :-(
23:39 epony 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!