Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
nine And up to 377 01:11
nine Looks like auto-generated protos are the next facet for the timing deliberations. 11:48
Given just: multi sub foo() is export { }, this obviously needs to auto-generate a proto and this proto's meta object must be available to the export-trait, as this really means "export my proto". 11:50
lizmat fwiw, I wouldn't be against removing auto-generate protos
they're really just too much magic imo 11:51
nine That would break so much code out there. I mean, who is manually creating protos if they don't have to? So I don't see how that would be feasible. 11:52
lizmat I know... still, I can voice an opinion, no ? 12:04
:-)
nine You just did, so obviously you can :P 12:15
jnthnwrthngtn nine: Yup, there's multiple unresolved design questions in the area of multis in RakuAST, I'm afraid. 12:21
nine Actually, that comment is not totally off. There is the question of whether auto-generating protos is actually a task for the AST, or if it belongs in the parser. I.e. do people who create synthetic ASTs need to create those protos as well?
jnthnwrthngtn AST. 12:29
RakuAST is abstracted from some amount of syntactic detail, but not to that degree. 12:30
It's probably some kind of begin-time effect, much like package creation 12:32
Although it may be that we need to tease "begin time" apart a little bit
OK, two tiny fixes from me today in a spare moment. afk for a while :) 13:06
nine jnthnwrthngtn: why are RakuAST::Parameter::Slurpy::Capture no RakuAST::Parameters? 14:15
Ah, stupid question....because they just aren't. They're markers on the actual parameter objects 14:16
I'm really noticing that lack of sleep now. 14:18
nine Oh boy...how would I prevent a routine from getting added to the lexpad (i.e. a multi dispatchee)? 16:00
MasterDuke huh, look like github.com/MoarVM/MoarVM/commit/e7...44daa39e52 is already supposed to detect a working stdatomic.h 20:03
ah, but that only uses the probe to check for whether we can use mimalloc 20:05
Geth MoarVM: MasterDuke17++ created pull request #1699:
Take stdatomic.h probe into account in decision whether or not to use c11 atomics 		20:25
Geth MoarVM: d7dee3a282 | (Daniel Green)++ | Configure.pl
Use stdatomic probe in using c11 atomics decision

Had to move the probe earlier, and then also copy the minimal ldlib setup code.		 21:57
MoarVM: 794e1d589b | MasterDuke17++ (committed using GitHub Web editor) | Configure.pl
Merge pull request #1699 from MasterDuke17/use_stdatomic_probe_to_decide_whether_to_use_c11_atomics

Powered by Cro and the Raku® Programming Language.

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

Thank you!