ShimmerFairy My probably bad suggestion would be to allow method foo(@args):D { } so you don't have to worry about method foo:D(@args) { } (or even method:D foo(@args) { } as another option) 00:59
timotimo and methods without argument signatures would be "method foo:D { ... }" then? 01:00
ShimmerFairy Yeah, I was thinking more "another location to put adverbs", so attaching it to the name would still be OK. 01:01
timotimo OK 01:02
to me, if it's after the signature, and outside, it kind of reads a little like "related to return type", kinda like "is rw"
ShimmerFairy Actually, attaching it to the keyword would make sense for things that could be see as affecting what kind of sub/method/etc. you're making, e.g. "This isn't just any method, but a 6.c only method"
01:03 lucasb left
ShimmerFairy method:LANG<6.c> foo() { ... }; method:LANG<6.d> foo() { ... }; 01:03
timotimo metho:D and meth:U:d 01:04
ShimmerFairy Also, I'm fine with the idea of reserving uppercase adverb names, but there had better be a clear line between adverbs and ordinary colonpairs. sub bar:CUSTOM-NOT-OK<...>(:$CUSTOM-OK) { } 01:07
Ooh! Attaching adverbs to the keyword means anonymous subs can be modified too! pass-a-func($arg, sub:LANG<6.c> { ... }) 01:10
02:48 linkable6 left, evalable6 left 02:50 linkable6 joined 02:51 evalable6 joined 05:14 Xliff left 06:50 domidumont joined
moritz eeks! 07:02
nine But, but, why not just `multi method foo ($b) is LANG<6.e+> { ... }`? With a simple `sub trait_mod:<is>(Method $m, Version(Str) :$LANG!) { }` that already parses today and just needs the trait to set some field on the multi candidate that the dispatcher checks 07:09
We don't need such a mechanism for subs as we can just override lexically in the new language version's setting.
07:31 MasterDuke joined
ShimmerFairy I was just working in the confines of "how can we do this adverbly?" 07:33
And besides, putting aside LANG specifically, the question of how to deal with sub foo:adv($function, $args) { } may well come up someday. 07:36
07:54 JJMerelo joined
JJMerelo m: rule r { (\w+ '.')* \w+ }; say "a.b" ~~ r 07:55
camelia 5===SORRY!5===
Undeclared routine:
r used at line 1

Other potential difficulties:
Useless declaration of a has-scoped method in mainline (did you mean 'my rule r'?)
at <tmp>:1
------> 3rule 7⏏5r { (\w+ '.')* \w+…
JJMerelo m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ r 07:56
camelia Too few positionals passed; expected 1 argument but got 0
in regex r at <tmp> line 1
in block <unit> at <tmp> line 1
JJMerelo m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r
camelia 「a.b」
0 => 「a.」
JJMerelo m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r
camelia 「a.b」
0 => 「a.」
JJMerelo m: my token r { (\w+ '.')* \w+ }; say "a.b" ~~ &r
camelia 「a.b」
0 => 「a.」
JJMerelo commit: releases my token r { (\w+ '.')* \w+ }; say "a.b" ~~ &r 07:58
committable6 JJMerelo, ¦releases (43 commits): «「a.b」␤ 0 => 「a.」␤»
JJMerelo commit: releases my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r
committable6 JJMerelo, ¦releases (43 commits): «「a.b」␤ 0 => 「a.」␤» 07:59
JJMerelo So rules behave exactly the same as tokens. There's no :sigspace difference
m: my token r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r 08:00
camelia Nil
JJMerelo m: my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r
camelia 「a.b.c」
JJMerelo commit: releases my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r
committable6 JJMerelo, ¦releases (43 commits): «「a.b.c」␤» 08:01
JJMerelo I am checking this stackoverflow.com/questions/620517...and-a-rule and it seems as if all it's in the documentation is wrong
tokens ratchet, rules don't. They both have non-significant whitespace. There does not seem to be a difference between a regex and a rule, then. 08:02
ShimmerFairy default <.ws> does not require whitespace except between two word characters 08:04
JJMerelo ShimmerFairy far as I can tell, that's not what the documentation says. But what about ratcheting? 08:12
ShimmerFairy rule should absolutely be ratcheting, and if it isn't that's a bug.
But the default <ws> has always been / <!ww> \s* /
JJMerelo commit: releases my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r 08:14
committable6 JJMerelo, ¦releases (43 commits): «「a.b.c」␤»
JJMerelo commit: releases my token r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r
committable6 JJMerelo, ¦releases (43 commits): «Nil␤» 08:15
JJMerelo ShimmerFairy if it does, then it's a long standing bug...
The commit that changed that part of the documentation is 5 years old github.com/Raku/doc/commit/3c20a9f...7d5e2583bb
Sorry, afk now...
ShimmerFairy m: my token r { a+ a }; say "aaaaa" ~~ &r 08:17
camelia Nil
ShimmerFairy m: my rule r {a+a}; say "aaaaa" ~~ &r
camelia Nil
ShimmerFairy m: my rule r { a+ a }; say "aaaaa" ~~ &r
camelia Nil
ShimmerFairy m: my regex r { a+ a }; say "aaaaa" ~~ &r
camelia 「aaaaa」
08:20 JJMerelo left
jnthn I'm guessing this is a mis-compile in some situation, but I didn't yet figure out exactly what are the ingredients. 09:20
It's losing a ratchet somewhere
(None in any of those cut-down cases, though..)
*Not
09:44 Altai-man_ joined 09:54 JJMerelo joined
JJMerelo jnthn is that bug posted somewhere? 09:55
jnthn and does that happen always, or only in some situations?
jnthn JJMerelo: It's the first time I can recall seeing it. And I think the above evaluations show "only sometimes" 10:00
Maybe only if there's a quantified group
JJMerelo jnthn++
jnthn JJMerelo: If you've a moment, please do make an issue. If nobody beats me to it, I'll have a big in the regex compiler, but my brain is full of dispatcher stuff at the moment. 10:06
JJMerelo jnthn by all means. 10:07
jnthn s/big/dig :)
.oO( I'm big in the regex compiler )
Altai-man_ .oO ( maybe not da biggezt, but da strongezt for sure ) 10:10
nine jnthn: isn't grammar matching just a special case of dispatch? :P
ShimmerFairy
.oO(Non-deterministic Finite Dispatcher)
10:11
jnthn Actually, the design dispatch programs at polymoorphic sites basically does look just like a finite automata, just over arguments instead of chars :P 10:14
*design of
10:28 sena_kun joined 10:30 Altai-man_ left
Geth problem-solving: JJ++ created pull request #202:
Solution for issue #72: spin off module publishing tutorial in the documentation.
10:36
10:42 squashable6 left
ShimmerFairy nqp: say(nqp::sprintf("%08.e", [1])); say(nqp::sprintf("%-8.e", [1])); say(nqp::sprintf("%-08.e", [1])); 10:44
camelia 0001e+00
1e+00
001e+000
10:44 squashable6 joined
ShimmerFairy The handling of the '-' and '0' flags in %e seems broken to me, or is adding one of the zeros in the exponent intentional? 10:45
10:51 JJMerelo left 11:07 MasterDuke left
lizmat ShimmerFairy: it is not 11:08
ShimmerFairy That's what I figured. I would expect - to override 0 and put spaces on the right, like in other directives.
11:12 finsternis joined 12:27 Altai-man_ joined 12:30 sena_kun left 13:04 MasterDuke joined
Kaiepi i was taking a bit of a break from things for a couple weeks, i'll get all those open prs rebased later today 13:06
13:39 MasterDuke left 13:57 MasterDuke joined 14:28 sena_kun joined 14:29 Altai-man_ left 14:38 MasterDuke left
[Tux] Rakudo version 2020.05.1-206-g986f8ab6b - MoarVM version 2020.05-15-g644533ad1
csv-ip5xs0.823 - 0.839
csv-ip5xs-207.899 - 8.396
csv-parser26.650 - 27.086
csv-test-xs-200.394 - 0.419
test7.748 - 7.990
test-t1.870 - 1.939
test-t --race0.932 - 0.933
test-t-2031.992 - 33.099
test-t-20 --race8.695 - 8.867
14:48
nine So, my <unit-outer> seems to be missing it's outer, which is why symbols from the setting are just not available at runtime. It's missing already in the mbc file. That's odd however as I clearly give it an outer using nqp::forceouterctx (which I just documented as well) as evidenced by the debug output: forceouterctx(0x6e39d30, 0x5d22830), replacing sf 0x4b03538 <unit-outer>(nested) 91 outer (nil) with 15:35
0x4107d28
15:38 Xliff joined
nine Oooh! Of course nqp::forceouterctx only affects the MVMCode and MVMStaticFrame, i.e. runtime representation, but not the compiled code they came from. 15:47
So what does setting outer_ctx in the compiler adverbs actually do?
jnthn nine: I think it's used by the compiler to find symbols at compile time also 15:49
15:58 domidumont left
nine Though a typical <unit-outer> also doesn't seem to have an outer in the bytecode. So how does it acquire one at runtime? I guess...it's that forceouterctx generated by Perl6::World::load_setting 16:00
jnthn Yes
Or at least,that's my recollection of how it works
I suspect this stuff will change a bit in RakuAST...I've noticed that a startup cost is iterating the whole core.setting symbols and building a QAST::Block with lexicals for them all 16:01
When it'd be better to just do lookups into the context when we need to
nine Darn...I can't just set the MAST::Frame's outer during compilation as that frame hasn't even been compiled at that point. 16:10
16:16 Geth left
timotimo oof 16:19
gotta fake the outers up or something? uuuggghhhh
nine I figure it'd be best to generate the same load_setting call as with non-nested compilations. After all a raku block in a Perl 5 module doesn't have an outer scope other than the setting. Except for nested blocks of course. But I'll figure out something for them once I have the simpler case up and running 16:23
Kinda funny. A year ago it wasn't even possible to precompile modules when they used Perl 5 modules. Now that capability looks like the bare minimum and I'd be quite unhappy if we couldn't precompile those raku blocks into the user :) 16:26
Btw. jnthn next up on my list is definitely going to be non-Raku-module dependencies for precomp files. It gets tedious having to modify the user module on every change to the Raku code in the Perl 5 module ;) 16:27
16:27 Altai-man_ joined 16:28 Geth joined
[Coke] nine++ nine++ ... (let's assume I did that nine times.) 16:29
16:29 sena_kun left
nine Ok, for that load_setting call to work, it won't do to have 2 dependencies+deserialize frames in the comp unit... 16:32
16:48 MasterDuke joined
jnthn nine: ooh, that'd be good for multiple things, not least badger... :) 16:56
(The "write SQL, get Raku subs" thingy) 16:57
nine But first, I've got to get out of this rabbit hole... 17:03
17:18 domidumont joined
Xliff jnthn: I thought badger emitted Go 18:12
jnthn Xliff: Wrong badger. :) 18:25
18:25 hankache joined 18:28 sena_kun joined 18:30 Altai-man_ left
Geth rakudo/set_equality: 701f4cfb40 | (Elizabeth Mattijsen)++ | 11 files
Implement set equality operators

  - (==) returns whether operands are the same using QuantHash semantics
  - ≡ unicode version of (==)
  - ≢ returns whether operrands are *NOT* the same using QuantHash semantics
Although "a (==) b" can be considered short for "a.Set (==) b.Set", it will ... (16 more lines)
18:34
rakudo: lizmat++ created pull request #3727:
Implement set equality operators
roast/set_equality: 715fb79b93 | (Elizabeth Mattijsen)++ | 2 files
Tests for Rakudo PR #3727
18:35
roast: lizmat++ created pull request #646:
Tests for Rakudo PR #3727
18:36
18:51 hankache left, lucasb joined 19:25 domidumont left
timotimo ^- so <a a a b b c> (==) <a b c> will give True or False? QuantHash/Bag or Set? 19:28
i guess arrays/lists become Set, and if one is a Bag or Mix, that's what the others become 19:36
nine Now to get my load_setting call running I need to share dependencies+deserialize between outer and nested compiler. To get that running I need to remove my workaround in compile_in_context where I explicitly did not share the CompUnit's data. 19:53
The intruiging thing about those failures are that they are of the kind "Cannot invoke this object (REPR: Null; VMNull)" which occurs when I share the frames list between compilations. 19:54
But...why? If anything sharing should fix missing frames, not cause them.
After all how can having access to all frames of all concurrent compilations cause us to lose some? 19:55
timotimo is it a missing frame, or is it something just not having the frame assigned to it, or the invocation protocol is not set up, or whatever else? 20:03
do you have a VM by now that you can use rr in?
nine I can use rr 20:04
New observations: lots and lots of nested compilations happen successfully before the failing one. And the failing one also just adds frames to @!frames, though curiously one of them is rethrow 20:21
20:21 sena_kun left, sena_kun joined 20:27 Altai-man_ joined 20:29 sena_kun left 22:28 sena_kun joined 22:29 Altai-man_ left 22:53 sena_kun left
lizmat timotimo: <a a a b b c> (==) <a b c> is the same as <a a a b b c>.Set (==) <a b c>.Set so True 23:25
timotimo OK 23:27
23:40 lucasb left