JJMerelo Hi, 07:13
I'm kind of lost with regex adverbs
I can't find where they are defined.
Previously they were defined in grammar Actions.
Now they're all over the place, and nowhere 07:14
Did they move to NQP or something like that?
JJMerelo I can't even find where they're tested in roast, at least all together... 07:18
JJMerelo OK, I found it github.com/rakudo/rakudo/blob/mast...ctions.nqp It's only that GitHub search sucks 07:26
JJMerelo I'm trying to document this " Refined accepted arguments in regex operator adverbs (e.g. :in(…))" 08:03
But I can't find either the commit that did that, or where arguments for regex adverbs are actually defined.
also, in is not really an adverb
The question is, what arguments are accepted now? 08:13
Geth ¦ rakudo: lizmat self-unassigned DateTime string parsed incorrectly github.com/rakudo/rakudo/issues/3717 11:09
¦ problem-solving: Prince213 assigned to jnthn Issue Calling vararg functions from NativeCall github.com/Raku/problem-solving/issues/201 11:21
Geth ¦ rakudo: lizmat self-unassigned `my @foo is List` doesn't work and is reassignable github.com/rakudo/rakudo/issues/2060 11:41
[Tux] Rakudo version 2020.05.1-206-g986f8ab6b - MoarVM version 2020.05-15-g644533ad1
csv-ip5xs0.800 - 0.850
csv-ip5xs-208.068 - 8.194
csv-parser26.281 - 26.290
csv-test-xs-200.379 - 0.402
test7.556 - 8.688
test-t1.845 - 1.949
test-t --race0.839 - 0.925
test-t-2030.980 - 33.652
test-t-20 --race8.565 - 9.334
11:43
Geth ¦ rakudo: lizmat self-unassigned Baggy cross operators github.com/rakudo/rakudo/issues/1726 11:44
¦ rakudo: lizmat self-unassigned BUILDPLAN sharing optimization appears to have broken ancestor attribute initialization github.com/rakudo/rakudo/issues/1679
¦ rakudo: lizmat self-unassigned my %*FOO is Set = <a b c> dies github.com/rakudo/rakudo/issues/2360 11:46
Geth ¦ rakudo: lizmat self-unassigned Code review wanted: &THE_END with custom exception handlers github.com/rakudo/rakudo/issues/2150 11:46
¦ rakudo: lizmat self-unassigned Signatures does not shows Coercion types when gisted. github.com/rakudo/rakudo/issues/2416 11:47
¦ rakudo: lizmat self-unassigned Custom .new method is not reflected in standard .perl github.com/rakudo/rakudo/issues/2448 11:48
¦ rakudo: lizmat self-unassigned Exceptions getting lost when a Thread ends github.com/rakudo/rakudo/issues/2462
¦ rakudo: lizmat self-unassigned Would be nice to have a |Z operator github.com/rakudo/rakudo/issues/2465 11:49
¦ rakudo: lizmat self-unassigned Are Duration operators tested? github.com/rakudo/rakudo/issues/2473
¦ rakudo: lizmat self-unassigned Custom multi infix:<~> not working as expected github.com/rakudo/rakudo/issues/2548
¦ rakudo: lizmat self-unassigned (1 .. -Inf).reverse is wrong github.com/rakudo/rakudo/issues/3595 11:50
¦ rakudo: lizmat self-unassigned (Inf ^.. Inf).reverse is wrong github.com/rakudo/rakudo/issues/3597
tbrowder question please: is there any way to read a compiler option inside Raku *.pm6 source code? 13:22
i suspect not without illegal hacking or reading an env var. 13:23
i'll assume 'not'. 13:24
nine what for? in the setting or in user level code? 13:26
jnthn See in either TOP or comp_unit in Grammar.nqp, I think we do a dyn lookup for %*COMPILING and then there's a %?OPTIONS key on it. 13:27
m: dd %*COMPILING<%?OPTIONS> 13:28
camelia Hash element = {:encoding("utf8"), :setting("RESTRICTED"), :transcode("ascii iso-8859-1")}
jnthn heh, and there they are. This is...uh...so not official.
MasterDuke heh, that's the one nine mentioned only has that key
nine I'm actually pondering changing the thing. Because %*COMPILING only has that single key anyway. OTOH I just try to add another one...
jnthn :) 13:29
Is there a good reason to make these available? They aren't just command line options, is the thing. Heck, they may not be all of those too.
ShimmerFairy btw tbrowder, I'm starting to think about Pod again, in particular how to make user-defined blocks and M<> formatting codes be useful (there's always been an annoying question of "who's in charge of rendering this?") 13:30
nine jnthn: that's why I asked tbrowder about the use case 13:32
tbrowder i’ve found all the pieces of the decl blocks and the only thing i can’t yet solve is how to affect the leading and trailing pieces in pm6. but i just figured it out so i don’t think i will need to go there.,thnx 13:35
tbrowder ShimmerFairy: i did some crude hacking on pod but i believe one way to help the situation is to form most of the pod classes in nqp before serializing them. so many of the little pieces get put together too soon imho. 13:41
e.g. defn, :numbered, # config 13:42
jnthn I think when the Pod impl was done, we didn't have the nice serialization of arbitrary objects at compile time yet.
So it'd not surprise me if there's nicer ways to do things now. 13:43
tbrowder jnthn you have def improved it since i started: kebab case and return 13:44
!~~
ShimmerFairy I don't know what problems are plaguing Rakudo's pod implementation at the moment, but writing some Pod again, I've again noticed the custom blocks/codes handling being fuzzy, as well as wondering how L<doc:> works/should work. 13:45
doc: is pretty simple for modules with Pod documentation, but what about pure-Pod files? Could that be handled with just a "unit module Doc::Topic;" right before all the pod, and then installing that as a "module"? 13:48
nine It's what I'd do 13:49
ShimmerFairy It would work well enough, so long as it doesn't feel too hacky. 13:50
nine Aw crap...apparently there are cases of nested compilation where we don't want to add compiled frames to the precompilation's byte code: stubs executed at compile time, i.e. BEGIN blocks 14:03
Though I'm not sure why it hurts to do so
Oh it's more of an issue with frame sharing in general. MAST::Frame has a $!writer property which will still point to the inner compilation's writer when we try to write it to the outer's bytecode later. Need to update it. 14:05
jnthn Maybe missing fixups of them?
Ahh... 14:06
Should it have a writer properly, or maybe be passed it?
nine Why do I make the same OO design mistakes that I point out in others? "Is this writer thingy a property of a frame? No? Then it has no business being an attribute, so pass it to the methods". But it's so convenient...
moritz because software is hard, and we have to beat our brains into shape to deal with it 14:08
timotimo is that where the headaches come from ... 14:09
moritz aye
nine Trouble all the way down.... looks like collecting all frames from different comp units into the same bytes code violates the assumption that the very first frame in the list is the unit's outer 16:09
jnthn Makes a change from turtles I guess...
nine We already explicitly identify the main_frame, load_frame and deserialize_frame, just not the unit 16:11
Changing that will need adaptions in MoarVM first however...
jnthn Is it MoarVM that assumes that outer relationships? 16:13
nine Well compunitmainline is really just GET_REG(cur_op, 0).o = cu->body.coderefs[0] 16:14
jnthn I thought it was the QAST -> MAST step
It is, but I think the only reason we have that op rather than just pulling out ref 0 is because we needed a different abstraction on different backends (namely Parrot, I believe), but if the others look like MoarVM too... 16:15
nine We already have that main_frame field in the bytecode header. What is that usually set to? 16:40
jnthn iirc, it's the thing we should run if the bytecode file is the entry point. 16:41
nine Why is that different from mainline? 16:42
jnthn So only really important at the moment for NQP, where we do compile scripts.
Oh, that isn't the mainline?
Hmm.
nine No, apparently we generate another block called <entry> that fetches the command line args from the VM and calls the mainline with these args 16:45
I wonder if I can still re-use the same main_frame field by setting it to mainline unless it's used for that <entry> block. I could imagine that we don't care about mainline when we have a main_frame anyway. 16:48
Certainly worth a try. Extending the mbc header to add the additional mainline field sounds like a major headache :/ 16:53
MasterDuke role B { say "HI!" }; class C { method ^compose($) { say "composed" } }; my $c = C.new; $c = $c but B; # heh 18:59
evalable6 (signal SIGSEGV) composed
MasterDuke there are a wide range of errors when you override meta-methods, e.g., segv, `===SORRY!=== Cannot iterate object with P6opaque representation (Bool)`, `Too few positionals passed; expected 2 arguments but got 1`, `Died with X::TypeCheck::Binding::Parameter` 19:15
the segv probably shouldn't happen, but are the rest entirely DIHWIDT or should there be some more consistency in the errors? 19:17
[Coke] I feel like we should probably disallow methods that start with ^ 19:20
(since if you want to get at the ^ method, you can get the meta object and do it directly)
nine That....is allowed? 19:25
MasterDuke greppable6: method \^
greppable6 MasterDuke, 4 lines, 3 modules: gist.github.com/5205b91c6f9a562650...41a1aa064a
MasterDuke m: role B { say "HI!" }; class C { method ^compose($) { say "composed"; nextsame } }; my $c = C.new; $c = $c but B; 19:27
camelia composed
HI!
MasterDuke added in either 2009-08 or 2015.03 (changelog for both says added there) 19:40
timotimo [Coke]:actually defining a ^ method will put it in your metaobject, which is super cool and useful 20:26
nine So...repurposing main_frame works for compiling the NQP compiler....but breaks running NQP scripts. I guess you just can't have everything 20:31
At least it shows that fixing nqp::compunitmainline will give me a working compiler 20:34
Geth roast: e283a5a4e8 | (Tom Browder)++ (committed using GitHub Web editor) | S26-documentation/block-leading-user-format.t
clean up comments, remove extra blank line
21:48