|
08:43
lizmat left
08:44
lizmat joined
|
|||
| [Coke] | docs.raku.org/language/using-modul...ode#fnret1 we can probably remove the "this was changed in 2016" footnote. | 16:56 | |
| lizmat | yeah... I also saw some reference to 2018 recently | 17:21 | |
| Type/Match: This feature works only from Raku release 2018.02 | 17:22 | ||
| I would say, anything before 6.d can be removed from the docs ? | |||
| Type/Supply: | 17:23 | ||
| 947:B<Note:> L<Rakudo|/language/glossary#Rakudo> versions up to 2018.05 | |||
| 952:versions except 2018.04, 2018.04.1 and 2018.05, where the intended | |||
| 954:issues are resolved in Rakudo releases after 2018.05. | |||
| several mentions in Type/IO/Handle | 17:24 | ||
| Language/numerics | |||
| Language/nativecall | |||
| Language/lost | 17:25 | ||
| [Coke] | whoops, xmas was 2015, not 2016 | 17:39 | |
| lizmat | I'd say any mention before release of 6.d, as in 2018.11 ? | 17:40 | |
| [Coke] | Eh. i'll defer until we have rakudoc v2. | 17:47 | |
| then we can more clearly mark what's available when. | |||
| (and we can decide criteria like "in release x" or "language version y", etc. | 17:48 | ||
| that 2016 one should, e.g. be a 2016.xx release, if we keep it | |||
| disbot4 | <shimmerfairy> How set-in-stone is rakudoc v2, btw? When I came across it a while back, there were a couple things I didn't like about it (along the lines of things being "too magical"), but I do mostly like it as-is. If there's interest, I could refresh my memory and dredge up my old notes on how I was thinking of redesigning rakudoc. (To be clear, if it is set in stone, I'd be fine with it.) | 17:52 | |
| lizmat | it's pretty much well dried up concrete at the moment... but I guess finanalyst and Damian will always welcome feedback :-) | 17:58 | |
| patrickb | shimmerfairy: afaik v2 is pretty much done. But work is already underway on a v3. Given the implementation currently depends on the not-yet-released RakuAST, there is a lot of room for changes. | ||
| (Or do I wrongly recall the situation?) | |||
| lizmat | it's more 2.3 that's cast in stone atm :-) | 17:59 | |
| disbot4 | <shimmerfairy> If there's interest in hearing them, I can find the time to organize my thoughts on what the ideal rakudoc system ought to be. To put it very shortly: my interest in the past has been in ensuring that modules extending rakudoc have all the same abilities as standard stuff. For example, =defn treats its first source line of text special; how does a custom =MyDefn get the same functionality? | 18:08 | |
| lizmat | I suggest you first read through the current spec: raku.github.io/rakudoc | 18:22 | |
| if you haven't already :-) | 18:23 | ||