| 5 Jan 2026 | |||
| tbrowder | status is: nothing to commit | 12:39 | |
| oh, i just pushed it and it showed previous commit was 589db5238 | 12:43 | ||
| what a dufus i am | 12:47 | ||
| anyhow, the code in the PR on raku/doc looks like my local code. checking again for ws locally | 13:01 | ||
| no trailing ws | 13:05 | ||
| the draft on raku/doc github looks like it's passing ws test | 13:09 | ||
| merge the draft? | 13:18 | ||
| [Coke]_ | Yes, it's fine to merge your PR. | 14:04 | |
| tbrowder | ok, will do | 14:13 | |
| here's fingers crossed... | |||
| Geth | doc/main: 14 commits pushed by (Tom Browder)++ review: github.com/Raku/doc/compare/2a2c0c...39ad1fb23f |
14:19 | |
| tbrowder | looks like it made it, whew, sorry about all the angst created | 14:20 | |
| [Coke] | no worries, just means the next one will be smoother | 14:28 | |
| tbrowder | well i hope so. i always forget that working on a PR for Raku and Rakudo are a bit more complicated than othe PRs. and i assume the failing test is because the current ver of Raku doesn't yet have the new name for the test. | 15:24 | |
| [Coke] | Yes, that's the remaining failure for the example compilation | 15:27 | |
| Oh. I wonder if it would be helpful to have a variant of the examples compilation test that can also use bisectable to see when it stopped/started working. | 15:35 | ||
| (then we could programmatically verify the surrounding "available in release xxx" | 15:36 | ||
| tbrowder | whoa, sounds cool by WAY over my head! | 18:23 | |
| *but | 18:24 | ||
| Geth | ¦ doc: arkiuat self-assigned language/regexes: Rewrite "Regex interpolation" section github.com/Raku/doc/issues/2230 | 20:10 | |
| arkiuat | I've been moving some of the still-open issues from milestone 2025Q4 to 2026Q1 on my own initiative: I hope that's okay | 21:02 | |
| if not, let me know, and I'll stop doing it! | 21:03 | ||
| [Coke] | Oh, yes, that's fine, thanks. | 21:40 | |
| 6 Jan 2026 | |||
| disbot10 | <librasteve> arkuiat++ | 10:18 | |
| Geth | doc/main: 4 commits pushed by (Eric Forste)++, librasteve++ | 10:22 | |
| disbot10 | <librasteve> my practice is to review and merge at the same time if the review is good - maybe a bit shortcutty but I want to help maintain a fast pace of change - lemme know if that's an issue | 10:23 | |
| [Coke] | I tend to prefer squashing the doc PRs in general. (usually a lot of "trying to fix whitespace" - this one looks fine just based on these 3 commits) | 14:21 | |
| stackoverflow.com/questions/798612...d-features | 14:42 | ||
| I think we can re-word that warning. The original dream of multiple compilers isn't here, and so I would tend to treat rakudo design decisions with more weight that when that line was written | 14:43 | ||
| I think we can keep the "design is separate from implementation" line, but soften the wording so it is less risk. | |||
| Also: anywhere in the docs where a concern like this is mentioned, I would add a link to another page, and write the warning *once*. | 14:53 | ||
| like: "See <notes> about specification vs. implementation" | |||
| And/or we should push for moving anything questionable INTO the specification | 14:54 | ||
| (would love to have the problem of a commercial compiler wanting to be called Raku and we had to deal with it. :) | 14:57 | ||
| disbot10 | <librasteve> I am 100% cool with softenig and centralising. In practice, I guess there is a question whether we should "lift" the current MOP implementation to the status of specified by writing a bunch of MOP tests for ROAST ... I hesitate to propose this because (i) it feels to me that MOP and Mu and implementation are very interconnected so that this could overly constrain other compiler efforts (I say this based on having, once, a long time ago, | 17:30 | |
| trying to make a "Mu" and in general that's a very intricate thing) and (ii) we have other fish to fry (aka laziness is a virtue). I feel that the answer I gave was in line with these points and tbh if the lack of tightly specified MOP with promise of cross compiler interop in the far distant future, then I am not sure that Raku is the best choice for them, or more generally what the drivers are for this kind of concern. | |||
| <librasteve> PS. please can you review the latest raku.org PR as Camelia is still in Santa guise? | 17:32 | ||
| <librasteve> [Coke]: ^^ | 17:57 | ||
| [Coke] | Done... but only with source. Let me know if I should review the UI also. | 20:40 | |
| disbot10 | <librasteve> tx! ... I'll keep an eye that all deploys as intended | 20:59 | |
| 7 Jan 2026 | |||
| patrickb | [Coke]: I've fixed up the tests for the two docs PRs of mine. | 10:48 | |
| [Coke] | ooh, thanks. | 14:17 | |
| huh. I didn't know a multiline attribute worked in pod6. nifty | 14:18 | ||
| Geth | doc/main: 622f40cdb2 | (Patrick Böker)++ (committed using GitHub Web editor) | doc/Type/Proc/Async.rakudoc NativeCall: Document the PTY functionality (#4754) |
14:20 | |
| 8 Jan 2026 | |||
| lizmat | dev.to/lizmat/raku-resolutions-17g7 | 13:19 | |