🦋 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
Nemokosch t/spec/S09-multidim/XX-POS-on-dimensioned.t 00:36
the special relevance of this test file is that apparently this is the one test that passed after my butchering of containers 00:37
this is the one win
it would be a bit longer to list the tests that broke, though
but even this seems like a test that failed on the TAP somehow, and otherwise it would already work 00:42
01:24 epony joined 03:36 linkable6 left, evalable6 left, evalable6 joined 03:38 linkable6 joined 06:00 reportable6 left 06:01 reportable6 joined
Geth rakudo/main: 67ba2dfcc8 | (Christian Bartolomäus)++ | tools/templates/jvm/Makefile.in
[JVM] Set Xmx4G for building Rakudo

As explained in github.com/rakudo/rakudo/issues/5186 the compilation of blib/Perl6/BOOTSTRAP/v6c.jar failed with
   java.lang.OutOfMemoryError: Java heap space
otherwise. Hopefully we'll find a way to reduce the memory usage for that step, because 4 GB is quite an amount of memory. (And for instance, I could imagine, that we won't have that much memory for the CI builds.)		 06:20
09:07 epony left
Nemokosch eventually, I got back to getting errors... but this time it's an error actually related to the modification at least 🥺 09:37
cannot do resolution on NQPMu 09:38
09:39 codesections left
lizmat that indicates something is not getting initialized :-) 09:44
Nemokosch so does that imply that the element exists at least? or could be that it's just downright missing? 09:46
what I changed here is that I prepended an element for lookup, and consequently changed the indices by one 09:47
lizmat ah, so the array of things to resolve may have had a "hole" 09:48
?
if so, then that's what it's choking on, it currently doesn't support holes
Nemokosch hmm, I don't know how if would have a hole. Everything is either pushed or not pushed 09:50
so that's the one form of index mess-ups that shouldn't happen 🙂
actually I'm gonna push this and make a draft PR so that it's easier to talk about it 09:51
lizmat €oki 09:53
*oki
09:55 ab5tract joined
Geth rakudo: 2colours++ created pull request #5196:
Make & sigil defaults and types correct		 10:04
Nemokosch so yes, the state of, khm khm, "art"
10:18 ab5tract left
> is (42)[*/2], 42, 'Indexing half way into one element list'; 10:31
by the way, I don't like this test case
it doesn't (only) test what it says
(42) is not a "one element list", is it
10:31 sena_kun joined 10:32 sena_kun joined
so it implicitly tests whether it successfully turns into one 10:32
lizmat agree 10:36
test probably preceded the GLR
there was a time in Raku where (42) *was* a list
I guess about 15+ years ago :-)
10:37 sena_kun left
Nemokosch what is really crippling about the problem is that I can just keep running tests without modifying anything about Rakudo itself - and the output changes 10:39
lizmat ? 10:41
Nemokosch I'm running tests with the modifications I made 10:42
and I can't even purposefully get the same output with the same executable on the same script that I got 30 minutes ago
deleted .precomp folders, doesn't even seem to change anything 10:43
the same thing works now, previously it didn't for the exact same amount of time
lizmat hmmm.. yeah, there's still some gremlins with precomp and dependency checking atm
I routinely do a "make clean" before rebuilding 10:44
and when I go back to a previous compilation-id, I make sure I run 'cleanup-precomp' first
nine Nemokosch, RakuAST::VarDeclaration::Simple is not the only ContainerCreator 10:46
Oh, but Signature doesn't do any lookups. 10:47
Nemokosch That's a good point regardless 10:49
At this point I'm happy for any idea that doesn't involve chasing a heisenbug
11:11 ab5tract joined
ab5tract nine: nope, it doesn't seem to be related to the $whatevercode_arg being a contvar 11:19
this is so ... annoying in a way that catches my attention lol 11:20
12:00 reportable6 left 12:03 reportable6 joined
Geth rakudo/main: e67941e9f1 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
Lose an unneeded level of indentation

No functional changes, just something found while checking out stuff		 12:03
rakudo/main: d8d34a12dc | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
Remove some dead code

And rearrange some other to make it more DRY		 12:12
12:46 ab5tract left 14:27 ab5tract joined
ab5tract nine: when you have some tuits, I'd really appreciate your eyes on this QAST again: gist.github.com/ab5tract/144c33cb3...638f66a6a5 14:33
Other than 'contvar' versus 'var', I can't tell any difference. Though we've established that I'm not the most qualified one to make that claim ;) 14:35
nine If the generated code is ok, then the difference is likely in the meta object 14:44
Nemokosch the hard lesson 14:45
QAST is still indeed "abstract", the semantics seems to come from the metamodel quite often 14:46
used to think QAST was "everything"
14:51 ab5tract left
Geth rakudo/main: d20bea564b | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix using curried expressions as where clauses on parameters

Curried expressions are not Code objects but they actually code-gen to blocks, so there's no need to wrap them in blocks again.
  ab5tract++ for discovering		 15:03
nine ab5tract: ^^^ will be useful in your tests 15:04
tellable6 nine, I'll pass your message to ab5tract
15:05 ab5tract joined
lizmat QAST *could* be everything, but that's simply not very practical 15:08
Geth rakudo/main: 46fc663eed | (Elizabeth Mattijsen)++ | 2 files
Properly initialize our variables without initialization

Transfer all of the complicated logic for this to a new Stash.VIVIFY-KEY implementation-detail method.
lizmat sadly, no new tests passing 15:09
nine My commit fixed 2 tests. Did you notice that more than half of the spectests now pass? :) 15:10
[Coke] woot 15:14
japhb \o/ 15:15
15:15 ab5tract left
nine Oh wait...half is at 677, we're at 672. But I guess it's just one more weekend. 15:36
Nemokosch I can't wait for the weekend to begin 🎶 15:49
shmup i just learned about en.wikipedia.org/wiki/POETS_day 15:56
16:01 ab5tract joined
ab5tract I guess I don't understand how the problem could be "in the metaobject" .. to which I assume is meant "in SubsetHOW" 16:13
tellable6 2023-02-10T15:04:13Z #raku-dev <nine> ab5tract: ^^^ will be useful in your tests
lizmat nine: the order in which declarations are codegenned seems wrong 16:16
causing $?PACKAGE not to be set until *after* it is needed to initialize any "our" variables
so it's taking the wrong one in the case of:
our $a; package M { our $a } # <-- still referring to the outer one
ab5tract lizmat: Interesting. I wonder if this is also the cause of my issue with 'my' scoped subsets still being visible outside of the module they are declared in 16:26
though it's kind of the reverse of your problem 16:30
lizmat well, I can't seem to find where the declarations of a block are being codegenned 16:31
ab5tract maybe via signature.rakumod? 16:51
well, that's where some of the block's declarations come from at least 16:52
[Coke] Any thoughts on github's new "merge queue" functionality? github.blog/changelog/2023-02-08-p...blic-beta/ 17:04
lizmat sounds pretty interesting 17:19
17:33 melezhik joined 17:42 melezhik left 18:00 reportable6 left 18:01 reportable6 joined 18:11 sena_kun joined
lizmat just realized that all $?PACKAGE lookups should be run-time, rather than compile time 19:10
*especially* if the RakuAST is built by hand
[Coke] is it true that $*W is going away once AST is complete? 19:24
lizmat yes
[Coke] ok. Updating github.com/Raku/doc/issues/3050
lizmat $*W is the Perl6::World object, and there is no Raku::World 19:25
19:35 epony joined
nine [Coke]: I don't think our repo is busy enough to warrant that feature 20:42
[Coke]: $*W was never meant to be a public API. Documenting it would have been a disservice 20:43
ab5tract: don't you mean $!where.IMPL-CURRIED.meta-object? 20:50
in line 542
Nemokosch the world is going away... 20:52
🙀
nine I am SO gonna play The Day The World Went Away when we remove the old compiler frontend 21:05
Nemokosch I'd rather stay away from this Supply semantics issue on GH, but the question seems appropriate... 21:07
so, what happens if it turns out that roast was basically wrong?
it sounded kinda like there was a test for an implementation detail and therefore something that should be just okay is a "breaking change" all of a sudden 21:08
ab5tract nine: That does seem to make the guard work! 21:11
Unfortunately, now there's breakage for all of the clauses that _do_ get wrapped 21:12
I gues because ApplyPostfix *also* curries
nine Nemokosch, roast has been wrong often before. We fix the bug in the test and that's that. Probably add a ChangeLog entry. After all the official branch for current 6.d is 6.d-errata 21:14
ab5tract: but that shouldn't matter? If it's curried, we need that block and will get it from IMPL-CURRIED. 21:15
It should probably be $!where.IMPL-CURRIED ?? $!where.IMPL-CURRIED.meta-object !! $!where.compile-time-value 21:16
Otherwise you'll get a "unknown method meta-object on object of type Bool"
ab5tract yeah, was getting that but understood it for the wrong reason 21:24
nine: well, that last change is it! 21:25
everything is passing except for 'module M { my subset F where 5 }; my M::F $f = 5'
^ that one still succeeds, where it should fail 21:26
tried all I could thin of over the week to fix it but couldn't find a fix so far 21:29
nine Before you think of fixes, why does it even fail?
or unexpectedly succeed in this case
ab5tract IIUC, it fails because the grammar calls resolve-name to determine if a type is defined. that somehow finds F, even though that F is my scoped 21:31
[Coke] nine: the only documentation I was considering was marking it as an implementation detail somewhere. Probably on the rakudo wiki, not the raku/docs
nine But why does it find it?
ab5tract *my scoped inside of a module
[Coke] but maybe add to raku/docs something more explicit about implementation details and why you should check to see if something's official if you're not sure. 21:32
ab5tract because it is installed lexically inside the module? 21:33
nine Btw. keep in mind that for subset the timing of the BEGIN handler will be different than for packages which you share that declaration code with
If it's installed lexically inside the module, the resolver won't find it outside the module. There are few things you can rely on, but that the resolver keeps the boundaries of lexical scopes is one of them. 21:34
If it's visible outside that scope, it's because it's declared outside that scope.
ab5tract hmmm... in the QAST output I see that for the default 'our' scoped subset in a module, the lexical declaration is only inside that module. 21:36
but the output looks the same to me vs a 'my' subset 21:39
(this is in the QAST from the old frontend) 21:40
Honestly, I have no idea why it finds it. As you say, it shouldn't be found given that the resolver shouldn't find it from outside the module 21:46
21:47 sena_kun left
nine Probably useful to know: there are 2 different declarations made for lexicals. One is via the resolver's declare-lexical method, this is just to let the compiler know about this lexical. The other is the RakuAST::Declaration node, this is responsible for generating the QAST. 21:50
nqp::gethllsym('nqp', 'note')($resolver.current-scope.HOW.name($resolver.current-scope.dump); in IMPL-INSTALL-SUBSET might shine a light on what's going on 21:53
Err... nqp::gethllsym('nqp', 'note')($resolver.current-scope.dump); 21:54
ab5tract ah... so should I also be saving the current scope at attach time?
let me actually run what you've suggested 21:55
'lang-call cannot invoke object of type 'VMNull' belonging to no language' 21:58
nine Have you not added nqp::bindhllsym('nqp', 'note', &note); to nqp/src/core/IO.nqp? 21:59
ab5tract I just did, but somethings is still wrong. I did a 'make clean' in between but that change still wasn't picked up. What's the difference between this nqp note and nqp say? 22:06
the Raku ones only differ in whether the output goes to STDOUT vs STDERR 22:07
nine The differerence is that in bootstrap NQP's setting is not available and this thing is the most reliable way I've found to just print a darn thing regardless of where I'm adding it 22:08
ab5tract with nqp::say($resolver.current-scope.dump) I get 'Block\n\tBlockoid\n\t\tStatmentList'
I wish I couild say that this cleared it up for me but ... 22:09
that could be any Block 22:11
including the one in the module M where the QAST of my lexical declaration lives
nine There aren't that many blocks in that program when you look at the --target=ast output. Actually I think it's the module's body block. Why is it empty though you might ask. The answer would be $package.replace-body: $body; in method package_def, i.e. we first assemble the whole body and then replace the default empty body on a package. 22:13
An equally good answer would be that that block doesn't actually contain anything yet because your example program would only add that subset and the BEGIN handler is called before we attach that Subset node to the StatementList 22:16
In any case, sprinkling everything with tons of debug output is my usual approach for this :D 22:18
ab5tract lol
been there earlier in the week
nine entering package scope for M
RakuAST::Block Block
So yes, we should be inside the package
ab5tract I mean, everything looks gravy to me. The QAST output resembles the old frontend output 22:20
The old frontend QAST looks exactly the same whether you do a 'my' or an 'our' subset
nine I think the QAST is fine. It's the resolver that's got wrong information
ab5tract which was what made me suspect s bug in the resolver
nine Not a but in the resolver. Nine's debugging lemma #1: the bug is always in your own code
Oh, wait a minute. my M::F $f = 5, that's not a lexical lookup, it's looking in the package 22:22
ab5tract m: module M { my subset F where 5 }; my M::F $f = 5 22:23
camelia ===SORRY!===
Type 'M::F' is not declared
at <tmp>:1
------> odule M { my subset F where 5 }; my M::F⏏ $f = 5
Malformed my
at <tmp>:1
------> module M { my subset F where 5 }; my M::⏏F $f = 5
ab5tract nine: Right, I should have answered your original question differently.. It looks through the package and finds the subset in the package stash 22:24
where I don't see how it does any distinction of whether what the resolver finds something that should actually be "visible" to the scope or not 22:26
nine The subset shouldn't _be_ in the package stash in the first place. After all it's lexically scoped
ab5tract erm, that sentence is a bit broken, please let me know if you'd like clarification
but it is package-like 22:28
it has to steal the .WHO of a stubbed package
nine We enter the if $scope eq 'our' at the end of IMPL-INSTALL-SUBSET!
Err....I don't think the actions ever tell the subset how it's scoped, so it'll fall back to the default which is our 22:30
ab5tract now that is an excellent point 22:32
is that always available in $*SCOPE? 22:34
nine Actually I think it is told, but that's too late for your BEGIN handler 22:37
Yes, $*SCOPE should be it
Ah, no it's not told. Blocks have special handling for that and packages. You're gonna need that, too 22:38
ab5tract ... I can't believe that that was it, the whole time 22:50
All my test cases are currently passing. 22:51
Time to run against spectest and see if I solved anything there. what count are we at,currently?
from the regular tests, I made exactly one subtest pass.. hooray! 22:52
The exception doesn't 100% match. My output now doesn't mention "Type M::F is not declared", it just jumps straight to 'malformed my 22:58
'but other than that one discrepancy, we seem to eqiual the base behavior \o/ 22:59
anyway, my run says 696 passing spectest files 23:05
sleep& 23:08
nine++ for helping me through the last two hurdles. 23:10
much less complicated than I was making them in my investigations

Powered by Cro and the Raku® Programming Language.

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

Thank you!