[08:43] *** lizmat left
[08:44] *** lizmat joined
[16:56] <[Coke]> https://docs.raku.org/language/using-modules/code#fnret1 we can probably remove the "this was changed in 2016" footnote.

[17:21] <lizmat> yeah... I also saw some reference to 2018 recently

[17:22] <lizmat> Type/Match: This feature works only from Raku release 2018.02

[17:22] <lizmat> I would say, anything before 6.d can be removed from the docs ?

[17:23] <lizmat> Type/Supply:

[17:23] <lizmat> 947:B<Note:> L<Rakudo|/language/glossary#Rakudo> versions up to 2018.05

[17:23] <lizmat> 952:versions except 2018.04, 2018.04.1 and 2018.05, where the intended

[17:23] <lizmat> 954:issues are resolved in Rakudo releases after 2018.05.

[17:24] <lizmat> several mentions in Type/IO/Handle

[17:24] <lizmat> Language/numerics

[17:24] <lizmat> Language/nativecall

[17:25] <lizmat> Language/lost

[17:39] <[Coke]> whoops, xmas was 2015, not 2016

[17:40] <lizmat> I'd say any mention before release of 6.d, as in 2018.11 ?

[17:47] <[Coke]> Eh. i'll defer until we have rakudoc v2.

[17:47] <[Coke]> then we can more clearly mark what's available when.

[17:48] <[Coke]> (and we can decide criteria like "in release x" or "language version y", etc.

[17:48] <[Coke]> that 2016 one should, e.g. be a 2016.xx release, if we keep it

[17:52] <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:58] <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.

[17:58] <patrickb> (Or do I wrongly recall the situation?)

[17:59] <lizmat> it's more 2.3 that's cast in stone atm  :-)

[18:08] <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:22] <lizmat> I suggest you first read through the current spec: https://raku.github.io/rakudoc

[18:23] <lizmat> if you haven't already :-)

[18:23] <lizmat> re dogfooding: that page is written in Rakudoc  :-)

[18:31] <disbot4> <shimmerfairy> Yeah, I definitely need to read through that again, to brush up on my impressions. I recall liking much of what I saw.

[18:33] <lizmat> meh, that's the wrong URL

[18:35] <lizmat> https://htmlpreview.github.io/?https://github.com/Raku/RakuDoc-GAMMA/blob/main/rakudoc_v2.html

[18:40] <disbot4> <shimmerfairy> That link doesn't work for me, but I was able to follow it to the original rakudoc version. I see the web version I've been looking at is out-of-date (2.11 vs 2.20)

[18:42] <lizmat> weird that that link doesn't work for you, it does for me even in incognito mode ?

[18:43] <disbot4> <shimmerfairy> It just gives me an SSL record too long error.

[18:48] <[Coke]> DDG fails to load it

[18:48] <[Coke]> as do chrome and ff

[18:52] <lizmat> meh, Safari has no problem :-(

[18:53] <lizmat> .tell finanalyst what is the best URL to read the latest RakuDoc spec?

[18:53] <lizmat> meh