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
re dogfooding: that page is written in Rakudoc :-)
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:31
lizmat meh, that's the wrong URL 18:33
htmlpreview.github.io/?https://git...oc_v2.html 18:35
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:40
lizmat weird that that link doesn't work for you, it does for me even in incognito mode ? 18:42
disbot4 <shimmerfairy> It just gives me an SSL record too long error. 18:43
[Coke] DDG fails to load it 18:48
as do chrome and ff
lizmat meh, Safari has no problem :-( 18:52
.tell finanalyst what is the best URL to read the latest RakuDoc spec? 18:53
meh