🦋 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:03 reportable6 joined 01:13 japhb left 01:34 japhb joined 01:42 melezhik joined 01:51 melezhik left 02:23 melezhik joined 02:26 melezhik left 04:29 linkable6 left, evalable6 left 04:30 evalable6 joined 04:31 linkable6 joined 06:00 reportable6 left 06:03 reportable6 joined 07:03 bloatable6 left, notable6 left, sourceable6 left, greppable6 left, committable6 left, benchable6 left, bisectable6 left, shareable6 left, unicodable6 left, squashable6 left, quotable6 left, coverable6 left, reportable6 left, releasable6 left, nativecallable6 left, statisfiable6 left, evalable6 left, tellable6 left, linkable6 left, coverable6 joined, evalable6 joined, sourceable6 joined 07:04 statisfiable6 joined, releasable6 joined, reportable6 joined, tellable6 joined, notable6 joined, bisectable6 joined, nativecallable6 joined, committable6 joined, linkable6 joined, benchable6 joined 07:05 greppable6 joined, shareable6 joined, unicodable6 joined, quotable6 joined 07:06 bloatable6 joined, squashable6 joined 07:38 sena_kun joined 08:25 djinni` left 08:40 djinni` joined
Nemokosch I'm still thinking if I'm making some obvious mistake 08:56
but it seems that Callable isn't fully available at the time it would be needed for a &var 08:57
unlike Hash and Array - although part of the story is that those are classes while Callable is a role 08:59
this happens when I try to parameterize Callable: "Cannot find method 'parameterize' on object of type NQPClassHOW" 09:05
the old compiler basically performed a core lookup in World.nqp, as much as I understand 09:06
How to go about it these days?
nine Look at ImplicitLookups 09:08
Nemokosch 👍 09:10
I don't know... it seems that everything tries to look up itself, and then automagically knows what position of the lookup will be sufficient... 09:25
this seems to be the underlying magic in the Routine node: > RakuAST::Type::Setting.new(RakuAST::Name.from-identifier('Callable')) 09:27
may I just call this directly to obtain Callable?
ooor... should this be added to the get-implicit-lookups of the suitable variable declaration node? 09:29
nine It needs to be added to the list of implicit lookups. IMPL-CHECK will then resolve it. 09:31
RakuAST::Type::Setting.new(RakuAST::Name.from-identifier('Callable')) by itself just means "I'm interested in the Callable symbol from the setting", but that alone doesn't give you the actual object. 09:32
09:37 ab5tract joined
ab5tract I know I've been asking a lot of questions but this exercise of adding subsets has struck a cord in my hyperfocus matrix. Thank you all for your patience and your help! 10:27
nine Thanks for taking this on :) 10:28
ab5tract I'd be much obliged if someone could point out any fatal differences between the QAST for base and for my branch: gist.github.com/ab5tract/144c33cb3...638f66a6a5
nine: For the most part, it has been my pleasure :)
10:30 sena_kun left
ab5tract or, alternatively, what could be preventing nearly identical QAST from having the same effect between base and rakuast? 11:00
lizmat to my knowledge, nothing ? 11:02
at QAST level there is no difference between base and RakuAST ?
Nemokosch I used to think QAST is more complex than it really is 11:03
apparently the runtime relies a lot on the metamodel 11:04
ab5tract lizmat: functionally, yes. The only difference is a named lexical binding instead of '$_' 11:05
if you have any tuits for it, its all in that gist I linked
nine lizmat: he's talking about gist.github.com/ab5tract/144c33cb3...638f66a6a5 specifically 11:09
lizmat yeah, I got that :-)
nine ab5tract: could be that your expectations are actually wrong there: 11:14
m: my $a = * && "yes"; dd $a
camelia Str $a = "yes"
nine So * && ... does not curry, i.e. you don't get a WhateverCode 11:15
You also see that in the base qast. It literally translates to nqp::if(Whatever, 5)
Nemokosch what does the order of items in PRODUCE-IMPLICIT-LOOKUPS determine? 11:17
nine It's the same order you get these things out of get-implicit-lookups
ab5tract nine: Oh, strange.. * ~~ 5 does generate a WhateverCode in my branch 11:18
nine ~~ is not && 11:19
ab5tract And still doesn't work is not a constraint
Nemokosch I mean, if I add a new item, I'm probably breaking the "interface" of it, right?
ab5tract I see the code where '&&' is optimized into a direct nqp op 11:20
nine Maybe you're just picking the hardest examples all the time :D I'd not try ~~ as that's smartmatch and that's a lot of black magic
lizmat Nemokosch if you add at the end, there shouldn't be any problem 11:21
ab5tract Okay, then I guess subset is "done"
nine Nemokosch: appending is ok
tellable6 nine, I'll pass your message to Nemokosch
nine Can someone teach this bot to not pass messages to people who are right here?
lizmat they're not, as far as the bot is concerned... and I'm not sure where tellable lives 11:22
ab5tract nine: I was using '&&' specifically because it wasn't a smartmatch, btw :)
lizmat: presumably it could get learn how to connect to discord from 'discord-raku-bot' 11:23
That doesn't answer the question of where the thing actually is, of course :)
lizmat I think it's simpler than that: if the nick is <discord-raku-bot>, then look for the <real-nick> at the start of the line 11:24
ab5tract True, there's no point queueing IRC messages for discord nicks
Nemokosch so essentially scan the messages, then?
anyway, back to implicit lookups 11:25
my worry is that what it gives it not fixed-length
so if I append, well, counting from backwards can help if that's available?
feels awkward
lizmat implicit lookups just sets up info for the get-implicit-lookups to fetch... it's all up to you what it means 11:27
Nemokosch Yeah well, that's exactly my worry. If anything is modified, potentially all occasions of get-implicit-lookups need to be also modified 11:29
lizmat nope, only the one from that class
generally the implicit-lookups / get-implicit-lookups only work *within* a certain class, or maybe its subclasses 11:30
Nemokosch I mean that. It's going to be a third entry within that class.
and it's also getting variadic (which seems kinda like premature optimization to me?) 11:31
variadic my ass, variant, that's the important thing
depending on certain conditions, the entries may mean different things
AND their overall number can also differ 11:32
lizmat I'm not sure what you're getting at, it feels to me you're overcomplicating things
Nemokosch this isn't even what I wrote
lizmat it's just a tool to work around one of the bootstrapping issues of RakuAST
Nemokosch github.com/rakudo/rakudo/blob/156f...kumod#L423 11:33
nine IMHO the concerns are actually well founded. It just may still turn out to be worth the hassle.
Nemokosch so as it stands, it can have 1 entry or 2, and the first entry can be the package or the type 11:34
lizmat ah, in *that* particular case
nine One does have to be careful to get the conditions right.
lizmat well, I think that can be easily fixed by using fixed indices ?
instead of @lookups.push(foo) do @lookups[0] := foo ? 11:35
Nemokosch yes, the question would be: couldn't the whole thing just be a good-old fixed-sized array basically?
rather than something link-y
list*
lizmat well, in nqp there's no notion of lists, only arrays 11:36
there's also no assigning, only binding
Nemokosch yeah no I mean, this shouldn't have list semantics in the first place imo 11:37
just plain old static array/buffer semantics 11:38
"first position: either filled with the package or empty"
"second position: either filled with the type or empty"
etc.
which sounds like more or less the same thing you said, for what it's worth 11:39
nine These could as well be just properties on the node object. has RakuAST::Type::Setting $!Callable; The reason we have lists there at all is that the resolver goes through the list and resolves each item. But that list may then just be [$!Callable] 11:41
Nemokosch I don't know what the takeaway of this is. 11:47
How do I get Callable resolved, without relying on the positions in this implicit lookups list? 11:48
nine By doing just that: add a has RakuAST::Type::Setting $!Callable; to the node, initialize it in the node's constructor to the RakuAST::Type::Setting object with the proper name, then append $!Callable to the list in PRODUCE-IMPLICIT-LOOKUPS. Then, where you need Callable, access $!Callable.resolved.compile-time-value 11:54
ab5tract nine: If '* && 5' is not curried in the original, I guess I'm confused as to why ApplyInfix is the way it is 11:58
Nemokosch oh okay... so the list itself is returned but more importantly cached 11:59
12:00 reportable6 left, reportable6 joined
lizmat hmmm... looks like "resolve-implicit-lookups-with 12:09
doesn't like holes in the list 12:10
which would explain the approach taken
nine ab5tract: the answer is always: no test has shown the current ApplyInfix wrong. Same as at the time, no test had shown my original implementation (which looked like the current one in ApplyPostfix) wrong. 12:11
I actually tried to figure out from reading Perl6/Actions.nqp whether && is supposed to curry and I've failed so far. According to my reading it should, but it clearly doesn't. Which goes to show that the old code is just very complicated and it's easy to miss things. 12:12
lizmat m: dd (* && 1).^name # doesn't that say it all 12:13
camelia "Int"
Nemokosch the situation is worse than I thought
lizmat m: dd (* || 1).^name # that seems to curry
camelia "Whatever"
nine Huh....that's unexpected 12:14
lizmat ah, not, that's Whatever, not WhateverCoce
so that doesn't curry either
nine oh, right!
Nemokosch the class that needs to know Callable, RakuAST::ContainerCreator, doesn't inherit or mixin anything
can I just inherit from RakuAST::ImplicitLookups? 12:15
lizmat yes, just add "is RakuAST::ImplicitLookups"
Nemokosch okay, thanks 12:16
www.youtube.com/watch?v=ci1o288RB04 mood
lizmat note: it only *looks* like Raku code, but it is in fact code that feeds a pre-processor that produces NQP bootstrap code
ab5tract Even though it's a Whatever instead of a WhateverCode, its confusing why one is an Int and one is a Whatever 12:17
nine Oh...that's...bad. I have actually added array to the bootstrap because I needed it in ContainerCreator and as you've discovered, it's really bothersome to make it available there
lizmat m: dd * 12:18
camelia *
lizmat m: dd *.DEFINITE
camelia Bool::True
nine ab5tract: no, it's not confusing because Whatever is trueish. So * && 1 is like True & 1 which is 1 while * || 1 is True || 1 which is True 12:19
lizmat indeed
nine err which is Whatever
ab5tract ah, got it
Nemokosch nine: do you think it can be added with ImplicitLookups or will that create some paradoxical situation?
ab5tract so IIUC, I should change the behavior of ApplyInfix to *not* curry 12:20
nine ab5tract: not ApplyInfix, but Infix::IMPL-CURRIES needs to give a more accurate answer
Compare with the start of method whatever_curry in Perl6/Actions.nqp. That contains a lot of obscure logic 12:21
ab5tract ok, thanks! 12:23
omg... 12:27
that seems to have been the fix this whole time :O 12:28
Nemokosch well done 💪 12:29
ab5tract Thanks 12:30
Though it reproduces this bug now, lol
m: subset F where * && 5; my F $f = True
camelia Type check failed in assignment to $f; expected F but got Bool (Bool::True)
in block <unit> at <tmp> line 1
Nemokosch > Could not build C3 linearization: ambiguous hierarchy 12:31
I guess that answers my question about inheriting from ImplicitLookups...
ab5tract Nemokosch: There's the answer of whether you can actually descend from it or not
tellable6 ab5tract, I'll pass your message to Nemokosch
ab5tract m: subset F where * || False; my F $f = True
camelia ( no output )
ab5tract m: subset F where * || False; my F $f = False 12:32
camelia ( no output )
nine Nemokosch, you need to remove that inheritance from the classes that inherit from ContainerCreator. But then you're still left with the issue of combining their lists of names to resolve with your list
lizmat nine: maybe reform this from a list to a hash format ? 12:33
this probably won't be the last time this will occur...
nine I would still try to avoid that for performance reasons. In this particular case I'd introduce a callback to ContainerCreator which the inheriting classes can call in their PRODUCE-IMPLICIT-LOOKUPS 12:34
lizmat if we're talking performance, why all the WRAP / UNWRAP stuff then ?
Nemokosch so they wouldn't inherit from ImplicitLookups again, just override the method in a way that takes ContainerCreator into account? 12:35
nine I think the hope there is that we can optimize them away
yes
Nemokosch okay, that sounds fairly doable
lizmat nine: I get that, but why are they there in the first place?
as they'r only called inside nqp ?
or are they not ? 12:36
nine Not if it's Raku code creating the ASTs
and manipulating ASTs
lizmat ah, and they wouldn't get auto-hllized 12:37
gotcha
Nemokosch so the only thing to watch out for is the offset of the list of implicit lookups; the first position will be occupied by the inherited lookup 12:38
ab5tract damnit, I celebrated too soon :( 12:39
Nemokosch by the way - is ContainerCreator not a kind of abstract class? 12:48
nine No, it's a role 12:49
Nemokosch hm, anyway, where I'm getting at is that it might not even need to implement PRODUCE-IMPLICIT-LOOKUPS for anything but documentational purposes 12:52
or well, providing a default
nine true
Nemokosch first occasion in a long time that the generated bootstrapping code was syntactically correct 😄 12:57
what is the language of these bootstrapped rakumod files? Is this what "desugar'd Raku" looks like? 12:59
nine No, the routine bodies are just plain old NQP 13:00
Nemokosch or is this a syntactic skeleton over NQP? or are these the same thing? 🙂
lizmat I guess you could have a look at gen/moar/ast.nqp and tools/build/raku-ast-compiler.nqp 13:02
Nemokosch just out of curiousity, where it fits the bigger picture 13:03
like, is this a language written specifically for this purpose?
or is this just NQP with a rakumod extension? 13:04
I can't believe my eyes 🥹 13:05
cdn.discordapp.com/attachments/633.../image.png
lizmat it makes it easier to write the Raku bootstrap, which is what we otherwise we would have to do manually to get gen/moar/ast.nqp
Nemokosch is the number of passing tests and spectests tracked somewhere? 13:09
el gatito (** advocate) no one commented on my issue lmao
for 2 hours
Nemokosch 🤣 I mean, I get your point... 13:10
I have issues that have no comments after months
again, not saying that it's perfectly okay
but for the time being, I can't see the situation change radically 13:11
what you can do is to adopt the mindset that "this issue might wait for several months until somebody picks it up"
so 1. don't put heaps of effort into writing an issue 2. on the other hand, be concise and clear, otherwise the whole issue will go down in the garbage collector of time 13:12
should have run the test with and without separately 13:15
anyway, I'm gonna save the output with, and then revert and see without 13:16
nine el gatito (** advocate): see rootprompt.at for commercial options. I'm sure we could come up with a contract that guarantees response times. 13:24
lizmat :-)
14:34 ab5tract left
Nemokosch um... something seemed off with the tests... 14:37
14:37 epony left
anyway, now I'm gonna run the same thing without, to see if the testing is off or the results simply got ruined 14:37
14:44 epony joined
Geth rakudo/main: db7ca2dd03 | (Elizabeth Mattijsen)++ | 9 files
Add Unicode class to 6.c

Providing:
  - .version: the Unicode version supported
  - .NFG: Bool whether NFG supported
Removes the $?UNICODE-VERSION, which is now accessible as Unicode.version		 14:50
rakudo/main: e3b9c66363 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
Make undefined variables complain properly

Also attempt to auto-declare variables when "no strict" is active. But that sadly still fails. More research needed.		 15:51
lizmat which brings us to 670 / 1355 :-) 15:53
nine: could you explain why RakuAST::VarDeclaration::Simple.new(scope => 'our', name => $name).resolve-with($*R)
would error out with: Cannot find method 'resolve-with' on object of type NQPMu 15:54
and not with: Cannot find method 'new' on object of type NQPMu
ah. of course, it instantiated NQPMu.new first 15:55
Nemokosch I'm jealous of the tests actually working :c 16:11
17:22 codesections joined 17:42 melezhik joined 17:43 melezhik left 18:00 reportable6 left 18:01 reportable6 joined
okay... it doesn't actually compile! that explains a lot 18:32
worked from the REPL, lol
18:36 sena_kun joined
> This element has not been resolved. Type: RakuAST::Type::Setting 18:44
18:48 ab5tract joined
I'm back to clueless 😞 I can't see how it's different from how RakuAST::TraitTarget::Variable works 18:48
lizmat yeah, bootstrapping is hard :-( 18:52
Nemokosch and somehow it did the right thing in the REPL 18:55
so something must be with the compilation step 18:56
lizmat are you sure the Raku grammar was used in the REPL ? 18:57
Nemokosch yes - the funny thing is, I wasn't going for the current stable behavior so it gives it away quickly 18:59
my Int &foo would be Callable now and I made it become Callable[Int]
(the previous RakuAST behavior was simply a $-like Scalar, hence Int) 19:00
lizmat ack
Nemokosch say, I implement PRODUCE-IMPLICIT-LOOKUPS for a class that descends from ImplicitLookups. What performs the actual resolution? 19:02
lizmat the resolver 19:15
dinner&
20:17 bisectable6 left, bloatable6 left, notable6 left, nativecallable6 left, committable6 left, statisfiable6 left, tellable6 left, sourceable6 left, shareable6 left, unicodable6 left, releasable6 left, benchable6 left, greppable6 left, reportable6 left, evalable6 left, squashable6 left, coverable6 left, linkable6 left 20:18 squashable6 joined, sourceable6 joined, greppable6 joined, reportable6 joined, bisectable6 joined, evalable6 joined, releasable6 joined, bloatable6 joined 20:19 benchable6 joined, unicodable6 joined, coverable6 joined, notable6 joined, shareable6 joined, linkable6 joined, tellable6 joined, committable6 joined 20:20 nativecallable6 joined, statisfiable6 joined
Nemokosch yes, makes sense... however, I haven't seen the involvement of the resolver, like where does it kick in? 20:24
nine Look at src/Raku/ast/base.rakumod 21:15
IMPL-CHECK
22:09 sena_kun left
Nemokosch is there something that can give a stack trace for compile-time errors? 22:17
it feels hopeless without that 22:40
no idea what changed but all of a sudden, tests started passing 23:13
some tests, at least...
but previously it looked like it was all graveyard
it would be good to see a list of passing and failing tests 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!