🦋 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:02 reportable6 joined 02:26 squashable6 left 02:28 squashable6 joined 06:00 reportable6 left, reportable6 joined 07:04 squashable6 left 07:06 squashable6 joined 07:32 samcv left, samcv joined
nine ab5tract: Congratulations! See? A walk in the park.... is whatever feature you are gonna tackle next compared to this :D 07:45
696? That's 24 newly passing spectests 8) 07:48
08:38 japhb left
nine Can't wait to see that merged :) 08:48
09:10 japhb joined
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2022.12-19-g92aac35c6
csv-ip5xs0.875 - 0.926
csv-ip5xs-205.376 - 5.539
csv-parser3.564 - 3.570
csv-test-xs-200.416 - 0.450
test6.415 - 6.927
test-t1.517 - 1.540
test-t --race1.010 - 1.094
test-t-2020.646 - 20.692
test-t-20 --race7.104 - 7.110
 09:55
10:46 sena_kun joined
ab5tract lizmat: Can I take you up on that offer to write the tests/DEPARSE stuff? :D 10:58
lizmat sure :-)
just drop whatever testing code you had in a gist and I'll take It from there 10:59
ab5tract: does that mean your PR can be merged 11:06
?
nine Definitely not the 43 commit monster it's now. The PR also misses the last fix 11:07
lizmat want me to squash it ? 11:08
also wouldn't that new Github merge function be helpful to get the PR up-to-date ? 11:09
ab5tract It's not 100% ready yet
but yeah, definitely a squash :)
lizmat ok, lemme know when it is: I'll take that as the cue to start the Deparse and tests 11:10
ab5tract still cleaning things up. You can squash on merge in Github right? For sure you can do that with gitlab
lizmat++
nine ab5tract: please also make sure that all your changes are actually necessary. E.g. I don't know why you removed the IMPL-RESOLVE-NAME-IN-PACKAGES call from the resolver
lizmat yeah, can squash on merge :-)
ab5tract nine: yeah, I was going to start a dicusssion about that. I removed it because it seems redundant with the fact that 'resolve-name-constant' calls IMPL-RESOLVE-NAME-IN-PACKAGES 11:12
nine For a proper review I'd prefer the branch to be ready for merging as-is, e.g. the commits that will actually land on main with proper commit messages.
ab5tract and it was running twice in my code
lizmat nine: so no squashing: check 11:13
ab5tract nine: I'll try to be more concise next time around. But for this one, I don't see any option besides a squash. I really went all around the world with my commits. What are you proposing? 11:14
nine ab5tract: squash them locally and push the result for review 11:15
ab5tract ok
nine While resolve-name-constant also calls IMPL-RESOLVE-NAME-IN-PACKAGES, resolve-lexical doesn't 11:16
Geth rakudo/main: ad940dec89 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: properly handle @/%/& sigilled our variables

  - Remove unnecessary lookup of $?PACKAGE
  - Move "no initialization" code to always be used during binding
nine Speaking about commit messages. This one ^^^ doesn't really tell me why the new state is more correct 11:17
lizmat hmmm... ok: this fixes "our @x; @x = 1,2" and "our @x = 1,2" 11:18
left that as a comment 11:19
ab5tract nine: okay. putting that back in. thanks for the heads up 11:26
nine It's certainly not optimal, that we are searching packages twice. But that can be fixed in a separate effort 11:27
Meanwhile I'm pondering how to fix the problem with nested blocks of dynamically compiled code. I.e. role Foo { method foo() { } }; class Bar does Foo { }; # here foo will at runtime still use the fallback resolver as its outer scope is the comp unit created during BEGIN time compilation 11:28
I wonder if there is a downside to just perform the usual fixups for these nested blocks as well. 11:32
When we compile a code object, we first "stub" it, i.e. create the meta object (Sub, Method, Block, etc.) and assign a placeholder code to its $!do property. This placeholder when executed will then "dynamically" compile the actual body and replace itself on its code object. 11:33
This body could contain nested code objects like in the role example above (the role body itself is a Block that's executed when the role is composed into a class).
Since we're already compiling these nested code objects as part of their parent body, we take the opportunity of "fixing up" their code objects while we're at it, i.e. when Foo body is compiled, we also replace foo's $!do. 11:35
Normally when we load a comp unit, we fixup all routines, i.e. assign the compiled blocks to their owning objects $!do, thereby replacing all stubs. But if a stub was already replaced, that's not necessary, so we don't bother.
Except that there is this subtle difference between the dynamically compiled bodies and the normal ones: the dynamically compiled code belongs to a different comp unit (the one created for compiling that thing while the outer comp unit is still unfinished). And this outer comp unit doesn't contain all lexical symbols. 11:37
ab5tract ouch
nine The same situation exists on the old frontend as well, except for that very last bit: on the old frontend we create a wrapper frame containing all lexical symbols visible at the point of the routine's definition. This includes all symbols from the setting as well, so these frames are very large. 11:38
In the RakuAST frontend we instead use a newly introduced mechanism of the VM: fallback resolvers. I.e. when the VM can't find a lexical, it runs a callback which will then access the RakuAST::Resolver. 11:39
Since this fallback resolver is a property of the comp unit, the same thing actually happens at runtime. I.e. these dynamically compiled routines actually keep the resolver object alive and that in turn references a lot of AST nodes. So definitely not memory friendly. 11:40
Also not necessary, since at runtime we'll have a complete lexical environment there already.
I guess all that really sounds like "so just do the normal fixup at load time, even for dynamically compiled blocks!" Which is exactly what I tried, even before understanding the whole situation. And indeed that fixes 4 spec tests right away. But it also breaks one. 11:41
BEGIN { my $a = 42; END { say $a } } # this one prints (Any) instead of 42, but would succeed thanks to the fallback resolver. 11:42
evalable6 42
ab5tract nine: do you want me to remove *everything* tangential to the feature? things like using an already constructed variable instead of doing another method dispatch?
nine ab5tract: please put any incidental improvements into separate commits.
ab5tract ok
nine I'm quite suprised that "int $n" without the "my" actually compiles... 11:43
ab5tract right? 11:51
okay, I think it is ready for review
nine Is there any difference between IMPL-INSTALL-SUBSET and IMPl-INSTALL-PACKAGE? 11:59
12:00 reportable6 left
ab5tract yes, there's a few subtle differences 12:01
based on what we actually lexically declare
and not adding the generated lexical in case it shares the name of a stubbed package 12:02
12:03 reportable6 joined
nine There are also large parts that you took verbatim. And I'm not sure the differences are actually because subset is so different. Couldn't they apply to Package as well? Are you sure the if !$lexically-registered branch is still necessary? 12:05
ab5tract If I remove that, the QAST for the lexical definition won't exist inside of the packages 12:07
but it might not change behavior, let me check 12:08
this was added when I was striving for QAST equivalence 12:09
does the use of RakuAST::VarDeclaration::Implicit::Constant make sense, btw? 12:13
okay, all tests still pass with `$!lexically-registered` gone... are you suggesting I just use IMPL-INSTALL-PACKAGE directly? or do I create 12:21
a "parent" routine somewhere 12:22
another option is to merge as-is and then proceed to de-dupe it in a further commit 12:25
I'm imagining IMPL-INSTALL-PACKAGE becomeing IMPL-INSTALL-INTO-PACKAGE
nine IMPL-INSTALL-PACKAGE could go into a role that Subset and Package do 12:26
I was asking about if !$lexically-registered because there's also a $resolver.current-scope.merge-generated-lexical-declaration in the else branch
ab5tract that's for any new lexical package 12:27
not a new subset
nine But if I read it correctly for subset Foo::Bar where True; you'd create a lexical called Bar in addition to adding Bar to the Foo package. The old frontend doesn't do that. 12:29
The old frontend also only creates a lexical Foo holding that package into which Bar is installed
12:36 ab5tract left
Geth rakudo/main: af90aed750 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: stop "our \x" from being codegenned

It's a NYI in base, make it a NYI here as well, although it looks like it should be pretty easy to implement in RakuAST.
Will leave that for another day.		 12:51
lizmat nine: better commit message ? ^^ 12:52
also: there appears to be a subtle difference between base and RakuAST now:
base: ------> our \x⏏ = 42
RakuAST: ------> our \x = 42⏏<EOL> 12:53
nine Definitely better :) 12:57
I think to get that pointed at the old place, you'd have to throw the error from the grammar 12:58
lizmat hmmm.. in the base case, it was also thrown from Actions... but I'll check 12:59
13:04 ab5tract joined 13:08 ab5tract left
Geth rakudo/main: 419d371da9 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make error message for our \x identical with base

By throwing it from the grammar, rather than from Actions. nine++		 13:23
rakudo/try_to_fix_wrappers: ec452f3e8e | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: Fix dynamically compiled blocks keeping compiler alive

When we compile a code object, we first "stub" it, i.e. create the meta object
  (Sub, Method, Block, etc.) and assign a placeholder code to its $!do property.
This placeholder when executed will then "dynamically" compile the actual body and replace itself on its code object.
... (29 more lines)		 13:34
nine So BEGIN { my $a = 42; END { say $a } } doesn't work as expected because the END phaser finds a different container in that lexical 13:47
lizmat maybe because the scope of the BEGIN is lost by the time of the END ? 13:48
so the lookup fails?
I bet you can't assign to $a in END
nine If the lookup failed, it would throw an error. But the lookup succeeds. It only finds a different object there 13:49
lizmat hmmmm...
nine You'd lose that bet
lizmat ok :-)
then it *is* a container :-)
nine: Q related to "our constant $x = 42" 13:50
I've added the necessary code to VarDeclaration::Implicit::Constant I think
13:50 ab5tract joined
nine And yes, the lexical scope is lost. But the new one should contain the same container. Unless....oh....creating that container is probably done during QAST generation. And that runs twice, so 2 containers. 13:50
lizmat however, the IMPL::QAST::DECL is *not* being called at all in the scope eq 'our' case 13:51
it *is* being called for the "my" case
nine But...that constant is not implicit. It's about as explicit as it can be 13:53
lizmat ah, ok, so it's codegenning incorrectly... checking 13:55
hmmm.. there is no RakuAST::VarDeclaration::Constant class :-) 13:58
also, what would make it implicit? the use of the ? twigil ? 13:59
nine According to my interpretation of the comments, that it's declared as a side effect. E.g. creating a package will cause $?PACKAGE to be declared 14:01
lizmat so I guess we need a RakuAST::VarDeclaration::Constant 14:06
nine Yes. At least for deparse 14:09
lizmat why for deparse ?
nine How else would you know to actually generate any output? The implicit constants are not part of the source code 14:10
lizmat but deparse works on the AST, and it would still be in the AST ?
feels to me the almost the only thing wrong with RakuAST::VarDeclaration::Implicit::Constant 14:11
is the name
and that it could just be called RakuAST::VarDeclaration::Constant
ab5tract lizmat++ 14:21
nine: tried breaking the relevant class out into a "role" class. got this: "Class RakuAST::Type::Subset cannot inherit from RakuAST::PackageInstaller because the parent is not composed yet" 14:22
lizmat that means you need to shuffle the order in which the packages are defned around 14:23
ab5tract hmm
I see what you mean. thanks
lizmat a typical bootstrapping issue been there done that :-) 14:24
m: my constant $x = my $a; say $a 14:30
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
------> my constant $x = my $a; say ⏏$a
lizmat that feels ... counter-intuitive :-)
ab5tract nine, lizmat: Any preferences for where PackageInstaller should live? base.rakumod seems like maybe the least offensive landing place 14:32
lizmat no preference from me
nine scoping.rakumod 14:34
14:39 epony left
ab5tract damn, it's depressing to be back in broken code land :( 14:59
nine But now you have a working version to compare with 15:01
ab5tract okay, I think it's ready again 16:02
unfortunately I borked the grep when counting the passing spectests
"grep '\. ok' spectest.out | wc -l" -> 670 16:03
so a lot less than I had said before
I had forgotten the backslash before :( 16:05
Geth rakudo/watermarky-supply-zip: 470a46c6ed | (Jonathan Worthington)++ | src/core.c/Supply-coercers.pm6
Switch Supply.zip to a watermark approach

In github.com/Raku/problem-solving/issues/364 a proposed solution to a deadlock in supply setup is hindered by the failure of a spectest for Supply.zip.
Thus far we defined Supply.zip as having its reuslt Supply be `done` as ... (13 more lines)		 16:22
rakudo: jnthn++ created pull request #5200:
Switch Supply.zip to a watermark approach
ab5tract okay, this is frustrating. 2 spectests are failing in my branch that don't fail in the current main 16:28
nine That happens to me every time :) 16:32
ab5tract so what are my options? even finding the two different tests feels like a unique form of frustration
but: glad I'm not alone ;) 16:33
I just tried diff and that is not the answer 16:40
nine My standard command for spectesting is: make && TEST_JOBS=20 RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | sort | tee $(git describe).pure.tests | wc -l 16:49
Then I just vimdiff the resulting file with the one of the run on the previous commit
lizmat nine: so I created a RakuAST::VarDeclaration::Constant class according to the rules, afaics 16:51
gist.github.com/lizmat/8d78561ff23...26701e39c3 16:52
but it keeps complaining about RakuAST::Type not having a lexical-name method
and the stack trace doesn't make sense to me
nine Maybe the stack trace makes sense to me? 16:55
lizmat I hope, or otherwise the code
nine lizmat: your constructor is missing a return value :) 16:59
lizmat ggrrrr... thanks! 17:00
need to go afk now, will work on it tomorrow again& 17:04
Geth nqp/specialcase_genarate_dispatch_single_arg: 87a7099923 | (Timo Paulssen)++ | 3 files
use single-arg op generator for dispatch ops
 17:22
rakudo/specialcase_genarate_dispatch_single_arg: b0b9ba3cb1 | (Timo Paulssen)++ | src/vm/moar/Perl6/Ops.nqp
use single-arg op generator for dispatch ops
ab5tract okay, this is totally weird. The two tests that are failing seem to be so unrelated. 17:46
nine Your branch does make a few unrelated changes though. Maybe they do have an effect after all? 17:47
ab5tract gist.github.com/ab5tract/7ea3f45f5...834a009677 17:48
could be, let me try reverting those 17:49
nine and suddenly it's quite useful that these are separate commits already 17:50
ab5tract :)
17:58 Xliff joined
nine Oh darn....now I know why I get a different container in that END block when I run fixups for dynamically compiled blocks. Lexical variables are contvars and for such contvars, the VM actually clones the object the compiler gave it as value when vivifying the lexical on first access in a frame. 17:58
ab5tract uff 17:59
18:00 reportable6 left 18:01 reportable6 joined
ab5tract nine: nothing is really changing the results 18:06
nine But the main commit is? 18:07
ab5tract the tests pass on the main commit 18:11
nine now you lost me 18:12
ab5tract it's something in the new PackageInstaller code
something broke on the way to abstraction
nine Ah, yes, that fits the symptoms
18:32 Xliff left
nine m: my $a = 42; BEGIN { END { say $a } } 19:07
camelia (Any)
nine Gotcha! Not even the wrapper frame of the old frontend is fool proof 19:08
ab5tract nice find! 19:25
running the final verification steps for the branch, but so far it's looking good 19:26
okay, 672 passing spectests 19:43
which indicates that my subset test file is actually a good candidate for roast inclusion, as nothing else there seems to have covered my corner cases 19:44
nine Cool! So it's ready for review again? 19:47
19:52 sena_kun left, sena_kun joined
jdv just added curated blin results from a few days ago. the failures all seem to be the same on HEAD. 19:56
lizmat: ^ blin points mostly to your commits:(
vrurg: ^ blin pointed to one of your commits 19:57
20:06 epony joined
nine ab5tract: github.com/rakudo/rakudo/pull/5178...1d239c2cc8 seems to contain unrelated changes 20:08
ab5tract Are you referring to the modification of expressions? 20:09
Their presence got confused, they were added in the original commit. I remove them in this commit and then re-add them in the final commit 20:10
so that at least they ended up with their own explanation in git blame 20:11
nine They shouldn't be in the original commit 20:12
ab5tract alright, I'll clean it up
didn't think it would be a blocker issue, tbh 20:13
nine Well if we are doing it, we may as well do it right :)
ab5tract easy enough to fix, indeed 20:15
okay, I hope it is all impeccable now 20:18
wait, one more thing could be better 20:42
nine: whenever you have the tuits, it should be shiny 20:50
wait, what? 21:13
crap.. I'm starting to feel like the boy who cried wolf
ok, *phew* false alarm . the current state of the branch is pristine 21:40
vrurg jdv: I didn't see any reports of blin in my emails. 22:34
jdv: nevermind, found it. 22:37
22:38 guifa_ joined 22:41 guifa left 22:52 japhb left 22:58 japhb joined 23:09 Voldenet left 23:10 Voldenet joined 23:12 ab5tract 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!