00:28 sena_kun joined 00:30 Altai-man_ left 00:57 squashable6 left 01:01 squashable6 joined 01:28 klapperl_ joined 01:30 klapperl left 02:27 Altai-man_ joined 02:30 sena_kun left 02:35 guifa2 joined 03:04 squashable6 left 03:06 squashable6 joined 03:51 guifa2 left 04:28 sena_kun joined 04:29 Altai-man_ left 06:23 Kaiepi left 06:26 Kaiepi joined 06:27 Altai-man_ joined 06:29 sena_kun left 06:50 JJMerelo joined 06:52 domidumont joined
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?
07:16 Kaiepi left
JJMerelo I can't even find where they're tested in roast, at least all together... 07:18
07:21 Kaiepi joined
JJMerelo OK, I found it github.com/rakudo/rakudo/blob/mast...ctions.nqp It's only that GitHub search sucks 07:26
07:46 MasterDuke joined 07:50 patrickb joined
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
08:28 sena_kun joined 08:29 Altai-man_ left 08:52 JJMerelo left 09:45 Prince213 joined 09:47 Prince213 left 09:48 Prince213 joined 09:49 Prince213 left, Prince213 joined 09:50 Prince213 left, Prince213 joined, Prince213 left 09:56 JJMerelo joined 10:09 MasterDuke left 10:17 Prince213 joined 10:27 Altai-man_ joined, Prince213 left 10:29 sena_kun left 10:33 Prince213 joined 10:47 Prince213 left 10:57 JJMerelo left
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
11:23 [Tux] left, [Tux] joined 11:31 [Tux] left, [Tux] joined, [Tux] left 11:32 Kaiepi left 11:33 Kaiepi joined 11:34 [Tux] joined 11:38 [Tux] left, [Tux] joined
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
11:46 JJMerelo joined
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
12:27 sena_kun joined 12:29 Altai-man_ left 12:48 JJMerelo left 13:13 MasterDuke joined
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
13:35 squashable6 left
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
13:37 squashable6 joined
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
14:27 Altai-man_ joined 14:29 JJMerelo joined, sena_kun left 14:48 patrickb left
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
16:28 sena_kun joined 16:29 Altai-man_ left
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
16:55 chansen_ left 17:00 chansen_ joined 17:03 wildtrees joined, wildtrees left 18:27 Altai-man_ joined 18:29 sena_kun left 18:32 JJMerelo left 18:38 guifa2 joined 18:47 guifa2 left 18:50 guifa2 joined 18:51 Xliff joined
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
19:18 domidumont left
[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)
19:23 Xliff left
nine That....is allowed? 19:25
MasterDuke greppable6: method \^
greppable6 MasterDuke, 4 lines, 3 modules: gist.github.com/5205b91c6f9a562650...41a1aa064a
19:27 lucasb joined
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
20:28 sena_kun joined 20:29 Altai-man_ left
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
20:35 cognomin_ left 20:45 nebuchadnezzar left 21:17 guifa2 left
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
21:56 nebuchadnezzar joined 22:27 Altai-man_ joined 22:30 sena_kun left 22:41 maggotbrain joined 23:04 Altai-man_ 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!