| 31 Jul 2026 | |||
| lizmat | and then, who knows what's out there on DarkPan | 17:27 | |
| ugexe | I will write up my thoughts on why it’s wrong when I get back. If we follow this pattern then the core is going to get bloated with not well thought out syntax | 17:28 | |
| lizmat | fair enough meantime I'm going to keep looking in fixing the module for RakuAST, so at least we won't need people to change their code | 17:33 | |
| Geth | rakudo/main: d9166ef4cf | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/Actions.nqp RakuAST: streamline module loading action a bit DRYer and hopefully better readable |
17:34 | |
| rakudo/lizmat-27: 86bb5fdfad | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp RakuAST: make sure all expressions are handled By using the magic RakuAST::BeginTime.IMPL-BEGIN-TIME-EVALUATE method. Which should probably need to be abstracted into a method "execute" on RakuAST::Node. |
18:40 | ||
| 1 Aug 2026 | |||
| rakudo/lizmat-28: c5f9b1695e | (Elizabeth Mattijsen)++ | 2 files RakuAST: use RakuDoc instead of Pod when appropriate |
07:59 | ||
| rakudo: lizmat++ created pull request #6499: RakuAST: use RakuDoc instead of Pod when appropriate |
|||
| rakudo/main: 4 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ | 08:03 | ||
| rakudo/lizmat-29: dffe95ecbd | (Elizabeth Mattijsen)++ | 2 files Refactor error X::Syntax::InfixInTermPosition This error is most often called if there is an error in Pod/RakuDoc syntax. So make those types of cases much more elaborate, and mention the fact that a term was expected as a last option. So a "=begin FOO" without "=end FOO" will now (in RakUAST) be reported as: ... (7 more lines) |
10:17 | ||
| rakudo: lizmat++ created pull request #6500: Refactor error X::Syntax::InfixInTermPosition |
10:18 | ||
| timo | I feel like we should be able to give a POD parsing related error instead of backtracking all the way back out of the POD parser and then saying "oh you seem to have an equals sign here that is actually an assignment operator that just went in a spot it wasn't allowed to go" | 14:56 | |
| I've wondered about this a few times already, but never spent enough brain time to come up with an actual proposal | 14:57 | ||
| we only ever enter the part of the pod parser that is "problematic" in this way when we're at the start of a line, right? that's the only time you can put a "=begin whatever" or a "=foobar"? | 14:58 | ||
| but of course, if a custom prefix:<=> operator or a term or so is defined, that would need to take precedence as well | 15:02 | ||
| thankfully you cannot define a `sub prefix:<=>` before using it in the grammar anyway :) | 15:08 | ||
| m: say "gimme a newline please" | 15:11 | ||
| camelia | gimme a newline please | ||
| timo | m: sub term:<=begin>() { say "begun" }; say=begin; | 15:12 | |
| camelia | ===SORRY!=== Error while compiling <tmp> =begin must be followed by an identifier; (did you mean "=begin pod"?) at <tmp>:2 ------> =begin<HERE><EOL> |
||
| timo | m: sub term:<=begin>() { say "begun" }; sub infix:<comment>($a, $b) { say "comment passed $a and $b" }; say=begin comment"haha" | 15:13 | |
| camelia | begun comment passed True and haha True |
||
| timo | but then | ||
| m: sub term:<=begin>() { say "begun" }; sub infix:<comment>($a, $b) { say "comment passed $a and $b" }; say=begin comment"haha"=end comment"this is just a normal call to sub say"; | 15:14 | ||
| camelia | this is just a normal call to sub say | ||
| timo | that's somewhere between DIHWIDT and "kinda funky behaviour" | ||
| github.com/raku-community-modules/...L/pull/113 do we know why this isn't running its checks? | 16:05 | ||
| I reviewed and merged that pull request, upgraded the module's dependency on JSON::Fast, and put the changes in the Changes document | 16:19 | ||
| but I don't think I have the login details for zef:raku-community-modules, so I think someone else has to actually run the release process; lizmat? :) | 16:20 | ||
| actually I have another change that could maybe go in | 16:28 | ||
| but it's not critical, I guess | 16:34 | ||
| probably something that really wants many people to test it before we put it into the ecosystem | |||
| lizmat | timo: "when we're at the start of a line", nope, you can have any amount of whitespace from the start of the line | 17:23 | |
| timo | oh, that does make sense. not just when you're already inside pod | ||
| lizmat | as far as code parsing is concerned: pod is considered whitespace | 17:25 | |
| OpenSSL 0.2.8 on its way to the ecosystem | 17:30 | ||
| timo | lizmat++ thanks! | 17:32 | |
| 2 Aug 2026 | |||
| Geth | rakudo/main: 0036539579 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files Refactor error X::Syntax::InfixInTermPosition This error is most often called if there is an error in Pod/RakuDoc syntax. So make those types of cases much more elaborate, and mention the fact that a term was expected as a last option. So a "=begin FOO" without "=end FOO" will now (in RakUAST) be reported as: ... (7 more lines) |
07:18 | |
rakudo/lizmat-28: 6 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++
|
07:21 | ||