| Geth | rakudo: ugexe++ created pull request #6321: RakuAST: Treat :$foo in a use/import/no argument as an import selector |
02:42 | |
| releasable6 | Next release in ≈1 day and ≈15 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 03:00 | |
| Geth | rakudo: ugexe++ created pull request #6322: RakuAST: Add the leading package of a qualified lookup to the SC |
03:29 | |
| JSON-Collector/main: b9b1c4f6e4 | (Elizabeth Mattijsen)++ | Changes A dummy push to test webhooks |
08:40 | ||
| lizmat | that's... interesting | ||
| sorry for the noise... misconfig in webhook | 08:41 | ||
| fwiw, this proved that codeberg JSON webhook is compatible with Github's JSON | 08:43 | ||
| or did it ? hmmm | 08:44 | ||
| timo | but the review url would need to be changed to take into account that it's not github? | 09:57 | |
| lizmat | probably, yes | 10:38 | |
|
12:38
donaldh left
12:40
donaldh joined
13:22
donaldh left
14:07
hurufu joined
14:28
finanalyst_ left
14:33
finanalyst_ joined
|
|||
| timo | anyone got a clue why inside of Perl6/Grammar.nqp a couple of the regexes/rules/tokens end up multiple times in the compilation result? and at least the one i'm looking at right now, which is `babble`, isn't the same in its two incarnations | 14:53 | |
| it's inside of role STD, but I wouldn't expect that to cause the result I'm seeing? | 14:54 | ||
| ugexe | m: role R { token foo { <.ws> } }; grammar A does R {}; grammar B does R {}; say A.^lookup("foo") === B.^lookup("foo") | 15:26 | |
| camelia | False | ||
| ugexe | its compiled against the grammar it lands in, and babble calls <.ws> which resolves to a different consumer in Perl6::Grammar.nqp and Perl6::RegexGrammar. so each composed copy of babble binds <.ws> to a different token | 15:30 | |
|
15:31
donaldh joined
15:48
finanalyst_ left
16:24
finanalyst joined
|
|||
| timo | working on making MATCH faster | 16:35 | |
|
17:32
hurufu left
17:41
guifa_ joined
18:22
librasteve_ left
18:53
disbot4 left
18:54
disbot1 joined
18:58
guifa_ left
20:22
guifa_ joined
20:46
guifa_ left
|
|||
| timo | that was very tedious and is now not working :) | 20:57 | |
| lizmat | yeah, It's been a while since I looked at that, and it's definitely hard to further optimize | 20:58 | |
| I think the greatest gains can be had when it is possible to prevent MATCH object creation | |||
| which is why .contains(/ foo /) exists | |||
| timo | we won't be able to make "stage parse" much faster with just that :D | 20:59 | |
| I should have committed when I had the first thing that did something and didn't break instead of pressing on | |||
| my first step was to take a bunch of the getattrs from inside MATCH out to where calls to MATCH are generated, and having a MATCH_with_attrvals where they are passed as arguments | 21:00 | ||
| I was thinking that should allow more work from the specializer, since the types there are almost fixed per method | 21:01 | ||
| next step was to try to leverage the fact that the CAPS are not just per method but also known at compile time already | |||
| I've now taken out the preparation of the hash and list objects from being dynamically done by the Caps class and generating code instead | 21:03 | ||
| it looks like prepare-hash is actually responsible for 1.1% of time in stage parse | 21:12 | ||
|
21:18
MasterDuke joined
|
|||
| MasterDuke | timo: very exciting! what do you have in mind for MATCH? | 21:20 | |
|
21:21
guifa_ joined
|
|||
| timo | basically code-gen stuff in the regex subs themselves that do a big chunk of the work that MATCH currently does with less dynamicism | 21:22 | |
| MasterDuke | huh, nice | 21:23 | |
| timo | one spot where we create a call to MATCH is for method-like regexes at the end after we check if there's a corresponding action method in the action class | 21:26 | |
| another spot is where-ever we have code blocks embedded in regexes, like { } or <?{ }> or <!!{ }> or <{ }> | |||
| and probably also for ** { ... } | 21:27 | ||
| MasterDuke | hm. we have sp_boolify_iter_arr, which gets jitted, but that doesn't appear to get called when running that example i was using | 21:41 | |
| looks like they were removed from moarvm in 4a88986ef105b71af26b5eac5626457943b9269e | 21:45 | ||
| timo | yeah that's what i meant by "the optimization got lost" | ||
| MasterDuke | seems to be in prep for new-disp, and i guess they just never made it back in | ||
| timo | the information whether an iterator is an array_X or hash iterator is also not being propagated any more. i was thinking maybe we should have one type per iteration mode | 21:49 | |
| MasterDuke | github.com/MoarVM/MoarVM/commit/4a...dL987-L997 isn't a huge amount of code | 21:51 | |
| dinner in a couple minutes, but maybe i can try to resurrect this over the weekend | 21:52 | ||
| timo | i don't think that's all you need. by the time spesh gets to it, you'll now have the results of the dispatcher which will be a runcfunc or something that does the coercion, and the dispatcher will have decided up front which function is the right one | 21:57 | |
| MasterDuke | yeah, i assume i'll have to follow however other truthy ops got converted to new-disp | 21:58 | |
| Geth | rakudo: ugexe++ created pull request #6323: RakuAST: Support anon subset declarations |
22:02 | |
| rakudo: ugexe++ created pull request #6325: RakuAST: Give a non-constant lexical its BEGIN value in a constant |
|||
| rakudo: ugexe++ created pull request #6326: RakuAST: Hyper the postfixes the legacy frontend hypers |
22:03 | ||
| rakudo: ugexe++ created pull request #6327: RakuAST: Resolve forward references in a role body before composing it |
|||
|
22:08
MasterDuke left
22:14
guifa_ left
22:48
guifa_ joined
22:52
guifa_ left
|
|||
| releasable6 | Next release in ≈19 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 23:00 | |