🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku Set by ChanServ on 14 October 2019. |
|||
00:00
peteretep joined
00:01
spycrab0 joined,
kawaii joined
00:08
samebchase- left
00:09
kawaii left,
brass left,
samebchase- joined,
skaji_ left,
brass_ joined,
skaji_ joined
00:12
kawaii joined
00:13
peteretep left
00:14
spycrab0 left
00:16
spycrab0 joined
00:18
cpan-raku left
00:19
cpan-raku joined,
cpan-raku left,
cpan-raku joined,
peteretep joined
00:26
aborazmeh left
00:51
Altai-man joined
00:52
dogbert17 joined
00:54
sena_kun left
00:55
dogbert11 left
00:57
dogbert11 joined
01:00
dogbert17 left,
dogbert12 joined
01:01
dogbert11 left
01:18
dogbert17 joined
01:19
dogbert12 left
01:22
dominix joined
|
|||
dominix | I have a Windows10 m&chine to setup for some dev. | 01:25 | |
I am surprised to see rakudostar to be only at 2019.01 version | |||
how do you folks install a current raku on a windows 10 machine ? | 01:26 | ||
other question do you know about a team that work on raku for windows10 ? | 01:27 | ||
01:31
wintre37 joined
|
|||
[Coke] | there's a more recent installer for windows than 2019.01. one sec | 01:38 | |
I build from source on win10, but I am probably weird. | 01:39 | ||
rakudo.org/downloads - has 2020.07 | |||
01:40
wintre37 left,
molaf left
|
|||
dominix | I will ask for a package update on chocolatey | 01:52 | |
01:53
molaf joined
02:05
Manifest0 left,
Manifest0 joined
02:18
stoned75 left
02:19
stoned75 joined
02:28
brass_ left,
brass joined
02:31
Cabanossi left
02:32
Cabanossi joined
02:55
dogbert17 left,
dogbert17 joined
02:57
dominix left
03:20
hungryd40 joined
03:21
hungrydonkey left
03:28
squashable6 left,
squashable6 joined
03:31
xinming_ left
03:34
xinming_ joined
03:45
Mawile left
03:47
gnufr33dom joined
03:48
hungryd40 left
03:49
hungrydonkey joined
04:03
dogbert11 joined
04:05
dogbert17 left
04:08
Kaiepi left,
hungrydonkey left,
Kaiepi joined
04:10
hungrydonkey joined
04:13
dogbert17 joined
04:17
dogbert11 left
04:21
xinming_ left
04:22
xinming_ joined
04:33
dogbert11 joined
04:34
dogbert11 left,
dogbert11 joined
04:37
dogbert17 left
04:41
xinming_ left
04:42
xinming_ joined
04:52
sena_kun joined
04:53
Altai-man left
05:00
dogbert17 joined,
ponbiki joined
05:02
dogbert11 left
05:04
ponbiki left
05:08
dogbert17 left,
dogbert17 joined
05:15
dogbert11 joined
05:17
dogbert11 left
05:19
dogbert11 joined,
dogbert17 left
05:20
dogbert11 left,
dogbert11 joined
05:21
xinming_ left
05:22
xinming_ joined
05:24
dogbert17 joined
05:26
dogbert11 left
05:40
bocaneri joined
05:41
camelCaser joined
05:43
rindolf joined,
dogbert11 joined
05:47
dogbert11 left,
dogbert17 left
05:48
dogbert11 joined
06:02
dogbert11 left,
dogbert11 joined
06:08
dogbert17 joined
06:10
dogbert11 left
06:12
dogbert11 joined
06:13
dogbert11 left,
dogbert11 joined
06:15
dogbert12 joined,
dogbert17 left
06:20
dogbert11 left
06:25
dogbert12 left
06:26
dogbert12 joined
06:38
dogbert17 joined
06:40
guifa left
06:41
dogbert12 left
06:43
AlexDaniel joined,
HarmtH joined,
Celelibi joined,
gfldex joined,
agentzh joined,
telex joined,
veesh joined,
m_athias joined,
Util joined,
erdic joined,
stux|RC-only joined
06:44
dogbert11 joined
06:45
dogbert11 left,
Sgeo left
06:46
dogbert11 joined
06:49
dogbert17 left
06:51
dogbert11 left,
dogbert11 joined
06:55
leont joined
06:58
Archenoth joined
07:05
stoned75 left
|
|||
El_Che | [Coke]: do you follow specific instructions to build on Windows? | 07:12 | |
07:13
dogbert17 joined
07:15
dogbert11 left,
dogbert12 joined
07:18
dogbert11 joined,
dogbert17 left
07:19
leont left
07:20
hungryd67 joined
07:21
dogbert12 left
07:22
hungrydonkey left,
dogbert17 joined
07:25
dogbert11 left
07:30
wamba joined
07:32
dogbert11 joined
07:35
dogbert17 left
|
|||
Geth | advent: 9dae2750a8 | (JJ Merelo)++ | raku-advent-2020/authors.md Revising advent RFC |
07:35 | |
timotimo | that's the difference between rakudo star and rakudo isn't it? | 07:46 | |
oh, that conversation was a few hours ago | |||
07:49
molaf left
07:50
bocaneri left,
Kaiepi left,
samebchase- left
07:53
bocaneri joined
08:00
dogbert17 joined
08:03
dogbert11 left,
dogbert11 joined
08:04
redhands joined
08:06
dogbert17 left
08:22
Kaiepi joined,
samebchase- joined,
raydiak joined,
[ptc] joined,
Bucciarati joined,
KotH joined
08:27
hungryd67 left
08:33
BHANU joined
08:36
BHANU left
08:45
ChoppedBacon joined
08:47
stoned75 joined
08:50
gnufr33dom left
08:51
Altai-man joined
08:52
finanalyst joined
08:53
sena_kun left
09:17
Kaiepi left
09:19
dogbert17 joined
09:20
Kaiepi joined
09:23
dogbert11 left
09:26
Kaiepi left,
Kaeipi joined
09:34
rindolf left
|
|||
Geth | doc/typo: 438575b385 | (Stoned Elipot)++ | doc/Type/List.pod6 typo |
09:45 | |
doc: stoned++ created pull request #3573: typo |
|||
doc: 5826022f24 | stoned++ (committed using GitHub Web editor) | doc/Type/List.pod6 typo (#3573) |
09:49 | ||
linkable6 | Link: docs.raku.org/type/List | ||
DOC#3573 [closed]: github.com/Raku/doc/pull/3573 typo | |||
09:51
dogbert11 joined
09:55
dogbert17 left
09:58
Black_Ribbon left
10:10
Cabanossi left
10:24
Cabanossi joined
10:36
dogbert17 joined
10:41
dogbert11 left
10:43
Kaeipi left
10:44
Kaiepi joined
10:49
Kaiepi left
10:51
molaf joined
10:56
redhands left
11:08
hungrydonkey joined
11:09
dogbert11 joined
11:12
dogbert17 left
|
|||
Geth | doc/ref-ops: f904d64a48 | (Stoned Elipot)++ | doc/Type/List.pod6 xref operators |
11:21 | |
doc: stoned++ created pull request #3574: xref operators |
|||
11:25
dogbert11 left
11:26
dogbert11 joined
11:27
rindolf joined
|
|||
codesections | m: class A { method f() {} }; say A.^lookup('f').signature | 11:32 | |
camelia | (A: *%_) | ||
codesections | When you create a method, it seems to implicitly get a signature of (Self: *%_). I understand why it gets `Self:` – that's what makes it a method. But why does it get *%_ (allowing it to be called with arbitrary named arguments)? | ||
lizmat | codesections: that's been a source of debate and a source of frustration for yours truly | 11:33 | |
there's a nice name for this behaviour, which I forget right now, (traumatic?) | 11:34 | ||
but it's to allow nextsame and friends to have access to *any* named parameters that have been passed, to be passed along without any additional boilerplate | 11:35 | ||
stoned75 | "automatic signature" ? | ||
hum no | 11:37 | ||
lizmat | no, that'd be more for something like: | 11:41 | |
m: dd ({ $^a + $^b }).signature | |||
camelia | :($a, $b) | ||
Geth | doc/list-eg-output: 6bf9432527 | (Stoned Elipot)++ | doc/Type/List.pod6 Fix examples' output if there is a , don't break the line :) |
11:49 | |
doc: stoned++ created pull request #3575: Fix examples' output |
11:50 | ||
codesections | lizmat: Thanks. So, related set of questions: Is that feature documented anywhere? If not, should it be? And why do *none* of the method signatures in the docs show that parameter? | ||
Are all they docs wrong? :D (Or, rather, would it be worth adding that to all method docs?) | 11:51 | ||
11:52
dogbert17 joined
11:55
dogbert11 left
|
|||
codesections | «Methods will ignore extra named arguments where other types of Routine will throw at runtime. Extra arguments will be forwarded by nextsame and friends.» 192.168.0.235:3000/type/Method | 11:55 | |
er, docs.raku.org/type/Method | 11:56 | ||
So, I guess it's _kind of_ documented | |||
lizmat | I guess the term I was looking for was "interface consistency" | ||
yeah, but I would definitely *not* go documenting that for every method :-) | 11:57 | ||
stoned75 | like roast/S12-class/interface-consistency.t ? | ||
and similar | |||
lizmat | yup :-) | 11:58 | |
a lemma about "interface consistency" would be nice | |||
codesections | lizmat: Makes sense. I'll open a docs issue. I guess that would live in the /type/Method docs? | 12:02 | |
12:05
zacts joined
12:14
dogbert11 joined
|
|||
Geth | doc: codesections self-assigned expand documentation of implicit *%_ parameter/interface consistency for Methods github.com/Raku/doc/issues/3576 6bf9432527 | (Stoned Elipot)++ | doc/Type/List.pod6 if there is a , don't break the line :) |
12:16 | |
12:17
dogbert17 left
12:19
dogbert17 joined
12:23
dogbert11 left
|
|||
doc: 1a607959db | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | doc/Type/List.pod6 Merge pull request #3575 from Raku/list-eg-output Fix examples' output |
|||
linkable6 | Link: docs.raku.org/type/List | ||
12:34
zacts left
|
|||
kawaii | Can the values stored in a hash be type restrained? i.e. `my Rat %results = ...`, so that it can only store whatever you want to cast? | 12:40 | |
tellable6 | hey kawaii, you have a message: gist.github.com/b395d1ea6ec3cd6580...680f50aa95 | ||
12:41
andrzejku joined
|
|||
tobs | kawaii: I don't understand what you mean by "cast". What exactly is wrong with `my Rat %results`? | 12:44 | |
stoned75 | kawaii: yes they can. see docs.raku.org/language/hashmap#Con...alue_types | 12:45 | |
kawaii | tobs: I didn't test that what I wrote is actually valid, but am I right in thinking it would give me a hash capable of storing only Rat's? :) | ||
stoned75: thanks! :D | |||
Geth | doc: f904d64a48 | (Stoned Elipot)++ | doc/Type/List.pod6 xref operators |
12:48 | |
doc: 53588f5199 | stoned++ (committed using GitHub Web editor) | doc/Type/List.pod6 Merge pull request #3574 from Raku/ref-ops xref operators |
|||
linkable6 | Link: docs.raku.org/type/List | ||
12:52
sena_kun joined
12:53
Altai-man left
12:57
sena_kun left,
sena_kun joined
13:04
skids joined
13:15
aborazmeh joined,
aborazmeh left,
aborazmeh joined,
hungrydonkey left
13:17
hungrydonkey joined,
wamba left
13:18
hungryd86 joined
|
|||
[Coke] | El_Che: to build on windows? I use the x64 native tools command prompt, have perl 5 installed (can dig up which version if you need), git, and I think it just works. | 13:20 | |
looks like strawberry perl 5 | 13:21 | ||
13:21
hungrydonkey left
|
|||
[Coke] | and I have visual studio 2017, but didn't do any particular config that I recall to make it work. | 13:21 | |
13:22
cpan-raku left
|
|||
Geth | ¦ doc: codesections self-assigned List.pick with Callable and .pick/pickpairs/grab/grabpairs for Baggy and Setty with Callable are not documented github.com/Raku/doc/issues/3564 | 13:22 | |
13:23
cpan-raku joined,
cpan-raku left,
cpan-raku joined
13:24
wamba joined
13:26
wamba left
|
|||
xinming_ | m: multi a (:$a where "a") { "a".say; }; multi a (:$b where "b") { "b".say; }; a(:a<a>); | 13:33 | |
camelia | a | ||
xinming_ | Is there a shorter version of :$a where "a" in multi signatures? | ||
Something like, multi a (:$a<a>) { }; | 13:34 | ||
Something like, multi a (:$a where <a>) { }; | |||
tadzik | m: multi foo(:a("a")) { say "OK" }; foo("a") | ||
camelia | 5===SORRY!5=== Error while compiling <tmp> Missing block at <tmp>:1 ------> 3multi foo(:a(7⏏5"a")) { say "OK" }; foo("a") |
||
tadzik | that' | ||
...not the errorr I thought I'd see, hmm | |||
oh pfft | 13:35 | ||
m: multi foo(:$a("a")) { say "OK" }; foo(a => "a") | |||
camelia | 5===SORRY!5=== Error while compiling <tmp> Shape declaration with () is reserved; please use whitespace if you meant a subsignature for unpacking, or use the :() form if you meant to add signature info to the function's type at <tmp>:1… |
||
13:36
gnufr33dom joined
13:38
wamba joined
13:42
wamba left
13:43
wamba joined
13:45
dogbert11 joined
13:48
dogbert17 left
13:56
dogbert17 joined,
dogbert17 left
13:57
dogbert17 joined
14:00
dogbert11 left
14:02
aborazmeh left
14:15
wamba left
|
|||
jdv79 | but why shoudln't the actual signature of all methods be documented that way? | 14:21 | |
14:21
andrzejku left
|
|||
jdv79 | (including the *%_ i mean | 14:21 | |
codesections | jdv79: it *would* just be a simple s/// to do so :) | 14:22 | |
14:23
andrzejku joined
|
|||
jdv79 | yeah. i'm just curious why some think omitting it from docs is a better idea. | 14:23 | |
lizmat | jdv79: should we document that each method automatically has a `self` defined that contains a deconted version of the invocant ? | 14:25 | |
with each method documentation? | |||
or should we do that somewhere more general? | 14:26 | ||
docs.raku.org/language/objects#index-entry-self # current state | |||
14:27
ponbiki joined,
ponbiki left
|
|||
codesections | Well, the docs already have signatures like «multi method lc(Str:D: --> Str:D)». That `Str:D:` shows what the invocant is (but I maybe I'm misunderstanding what you mean, lizmat?) | 14:28 | |
lizmat | sub a { self } | ||
m: sub a { self } | |||
camelia | 5===SORRY!5=== Error while compiling <tmp> 'self' used where no object is available at <tmp>:1 ------> 3sub a {7⏏5 self } expecting any of: term |
||
lizmat | m: method a { self } | ||
camelia | Potential difficulties: Useless declaration of a has-scoped method in mainline (did you mean 'my method a'?) at <tmp>:1 ------> 3method7⏏5 a { self } |
||
lizmat | so, "self" is defined inside *each* method | 14:29 | |
do we document that with each method? I think not, nor should they be | |||
in my opinion, the same goes for %_: it is added to the signature of *each* method unless it has an explicit slurpy hash | 14:30 | ||
codesections | Oh, yeah, I agree *that* doesn't need to be called out on each method. It's something that's generally true of all methods. And, analogously, I think we don't need to say anything about the method taking *%_ in the _discription_ of the method | ||
I guess I'm less sure of that when it comes to the _signature_ | 14:31 | ||
jdv79 | what does this have to do with self? that's not in the sig. the sig is what is featured on every method doc. | ||
[Coke] | things that are common like that (self) should be in overall OO documentation, we could have 'method' definition link to >something<. shouldn't be part of each individual method, though | ||
codesections | imo, there's an argument that the documented signature should be the same as the .signature Signature | ||
lizmat | jdv79: ok, I got the impression you wanted it documented with each method, but this is just about being mentioned in the sig | 14:32 | |
I'm fine with just showing it in the sig | |||
14:32
wamba joined
|
|||
jdv79 | well, the use case i'm thinking of is a new user looking at hte docs for a method and seeing the sig and thinking that's *exactly* what it is | 14:32 | |
lizmat | sorry for the misunderstanding :-) | ||
jdv79: gotcha | 14:33 | ||
[Coke] | we could add an xt/ to docs saying that if it's a method declaration, it has to have a parameter that ends with a : | ||
xkcd.com/2347/ reminds of a few projects. :| | 14:35 | ||
jdv79 | oof | 14:36 | |
lizmat | Ahhh... ImageMagick, my old friend :-) | ||
14:37
wamba left
|
|||
[Coke] | sort of project that you'd hope some company would support the person/team and have a plan to provide backup. | 14:38 | |
14:38
wamba joined
14:43
dogbert11 joined
14:46
dogbert17 left
14:52
wamba left
15:00
raku-bridge joined
|
|||
SmokeMachine | m: my method a { self } | 15:10 | |
camelia | ( no output ) | ||
15:10
andrzejku left
15:12
dogbert17 joined
15:15
dogbert12 joined
15:16
dogbert11 left
15:17
dogbert17 left
15:19
dogbert17 joined
15:20
dogbert12 left
|
|||
codesections | I created a docs issue that I'd appreciate people's input on: github.com/Raku/doc/issues/3577 | 15:29 | |
15:30
patrickb joined
|
|||
codesections | It's about deciding which methods should be documented in the /type/* docs | 15:30 | |
(apologies for the length) | |||
15:39
patrickb left
15:41
gnufr33dom left
15:49
dogbert11 joined
15:51
dogbert17 left,
patrickb joined
15:54
stoned75 left
15:56
stoned75 joined
16:00
Geth joined
16:08
patrickb left
16:09
patrickb joined
16:22
dogbert17 joined
16:25
dogbert11 left
|
|||
xinming_ | SmokeMachine: termbin.com/zapo <-- Should this example work in Red? :-) | 16:28 | |
SmokeMachine: I added my $*RED-FALLBACK = True for that example, doesn't work either | 16:30 | ||
It's kind of database table inheritance | |||
with Red | |||
termbin.com/f42so <--- This is the updated version which expose the real problem. :-) | 16:33 | ||
16:39
patrickz joined
16:40
patrickb left
|
|||
rypervenche | Does anyone know what I'm doing wrong with my grammar here? It's able to match a single line, but it doesn't match the <eol> (tried it with Grammar::Debugger, fails to match <eol>): repl.it/@rypervenche/Asterisk-file#main.raku | 16:42 | |
I should say, when I try to run it against the whole file, it doesn't match the \n at the end of each line. | 16:43 | ||
16:43
zacts joined
16:48
dogbert11 joined
16:51
Altai-man joined
16:52
dogbert17 left
16:53
sena_kun left
17:01
dogbert17 joined
17:04
dogbert12 joined
17:05
zxcvz left
17:06
dogbert11 left
17:08
dogbert17 left
17:23
patrickb joined
17:26
patrickz left
17:28
zacts left
17:37
dogbert17 joined
17:41
dogbert12 left
17:58
stoned75 left
18:05
greppable6 joined
18:06
reportable6 joined
18:07
tellable6 joined,
shareable6 joined,
vrurg_ left
18:08
dogbert11 joined
18:09
vrurg joined
18:10
dogbert17 left
18:11
vrurg left
18:12
vrurg joined
18:16
patrickz joined
18:18
patrickb left
|
|||
Geth | ¦ doc: codesections self-assigned Add *%_ to method signature documentation github.com/Raku/doc/issues/3578 | 18:19 | |
18:21
patrickz left
|
|||
codesections | Hmm, does Rakudo not put any limits on its own memory consumption? I just triggered a bug that causes an infinite hang, an the REPL is now at > 10 GiB of mem, with no sign of stopping yet. | 18:31 | |
(I'll kill the process soon, but I was just interested in seeing it go for a bit) | 18:32 | ||
moritz | no | 18:33 | |
you can use something on the outside like ulimit to that effect | |||
codesections | Interesting/surprising | ||
and good to know | 18:34 | ||
(it made it to 15 GiB before I got bored. Pretty big, for one-line) | 18:35 | ||
18:39
patrickb joined
18:41
zacts joined,
dogbert17 joined
|
|||
codesections | m: class A is Setty {}; A.grab | 18:42 | |
camelia | Cannot resolve caller grab(A:U); Routine does not have any candidates. Is only the proto defined? in block <unit> at <tmp> line 1 |
||
codesections | What's the point of having Setty define a `grab` method, but just declare the proto? | 18:43 | |
Is it saying «if your class `does` Setty, it *might* want a `grab` method, but I won't insist on it» | |||
18:43
dogbert12 joined
|
|||
codesections | or is there some other point I'm missing? | 18:43 | |
18:44
dogbert11 left
18:47
dogbert17 left
18:49
dogbert17 joined
18:51
dogbert12 left
18:56
dogbert11 joined
18:58
andinus joined
|
|||
rypervenche | Gah! I figured out my issue. The space at the end of a rule matters. | 19:00 | |
19:00
dogbert17 left,
dogbert17 joined
19:01
finanalyst left
19:03
dogbert11 left
19:06
tigerpaws joined
19:08
natrys joined
19:11
dogbert17 left,
dogbert17 joined
19:13
finanalyst joined
19:17
dogbert11 joined
19:20
stoned75 joined
19:21
dogbert17 left
19:24
stoned75 left
19:26
leont joined
19:29
Mawile joined
19:32
ChoppedBacon left,
Archenoth left,
pecastro joined,
bocaneri left
19:34
tellable6_ joined,
ChoppedBacon joined,
tellable6 left,
vrurg left
19:35
vrurg joined,
skaji__ joined
|
|||
[Coke] | you can put some strictures about what it has to look like with the proto, I think. | 19:37 | |
19:38
brass_ joined,
reportable6_ joined,
brass_ left,
brass_ joined,
brass_ left
|
|||
[Coke] | m: dd Setty.can("grab")[0] | 19:38 | |
camelia | Method grab = proto method grab (Setty: |) {*} | ||
[Coke] | ... not that that does. | ||
codesections | [Coke]: but the source doesn't. I'ts just `proto method grab(|) {*}` | 19:39 | |
well, *that* was faster than checking the source code :D | |||
[Coke] | there used to be a multi method grab in that file. | 19:40 | |
19:40
pecastro left
|
|||
[Coke] | see if you can find out which commit removed the multi itself, maybe there's a clue there. Might have accidentally been left in. | 19:40 | |
(ah. the old version did this: | 19:41 | ||
X::Immutable.new( method => 'grab', typename => self.^name ).throw | |||
codesections | the multi got moved to things that `does` (things that do?) Setty | ||
? | |||
[Coke] | why bother throwing that error when you now get a very similar one "for free" | ||
19:42
brass_ joined,
skaji_ left,
reportable6 left,
hungryd86 left,
brass left,
camelCaser left,
skaji__ is now known as skaji_,
brass_ left,
ccamel joined
|
|||
codesections | m: Set.new.grab | 19:42 | |
camelia | Cannot call 'grab' on an immutable 'Set' in block <unit> at <tmp> line 1 |
||
[Coke] | (I think lizmat is the one that knows all about the various container types, I'd defer to her.) | 19:43 | |
codesections | Oh, it's not really "for free": that exact X::Imut... line is now in Set | 19:44 | |
19:46
edk_ joined,
bocaneri joined
|
|||
codesections | This is exactly the sort of thing that makes me conflicted about the "document all public methods" approach for that GitHub issue I opened. `grab` is now a public method on `Set` (that does nothing but error) when it used to be a public method on `Setty` | 19:48 | |
Is that a change that should be/should have been reflected in the docs? | |||
It *really* feels like a Rakudo implementation detail | |||
but documenting it falls out of the «document all public methods» rule | |||
19:50
dogbert17 joined
|
|||
moritz | rules are meant to be broken sometimes | 19:52 | |
19:53
dogbert11 left
19:54
Sgeo joined,
dogbert2 joined
|
|||
codesections | moritz: And I'm fine with that :) But I want *these* rules to be tool-enforced, so if they're going to be broken, I want them to be broken in ways I can explain to the tools! | 19:54 | |
19:57
dogbert17 left
|
|||
[Coke] | codesections: rakudo isn't the source of truth there. it's a convenient place to pull the method list, but it's not the source of truth (as you noted in your list of options) | 20:05 | |
I would treat the work like an exercise ending up with everything either being in roast or tagged as implementation detail. | 20:06 | ||
codesections | But what _is_ the source of truth about _where_ methods are implemented? | ||
Roast is intentionally agnostic about that | |||
[Coke] | but I wouldn't expect it to be right as is. | ||
codesections: If roast doesn't care, why do you? | |||
Roast says where you can call them from - that's the part that's spec. | |||
unless there are specific tests, doesn't matter if it's done in a parent class or a role. | 20:07 | ||
codesections | Ok, so how do we decide where to put the documentation? | ||
[Coke] | so part of the doc effort can be "this method on this role, 8 classes inherit it, but we only test that you can call it on 3 of them" | ||
s/inherit/use/ | 20:09 | ||
codesections | So, where should `SetHash.kv` be documented? It's currently doc'ed in `Setty` but implemented (in Rakudo) in `SetHash` (and also in `Set`) | ||
Since Roast doesn't care, we shouldn't either? | 20:10 | ||
[Coke] | It's a good question. I'm saying there's no right answer today. | 20:11 | |
aren't we setup so that methods available from outside our class are displayed on the class? | 20:12 | ||
but it sounds like right now it's not matching roast nor rakudo | |||
codesections | Yeah, on the SetHash docs, `kv` shows up under the heading «Routines supplied by class Setty» | 20:14 | |
so the docs *do* display | |||
it's just a question of if we care that the info doesn't match the Rakudo implementation (and, relatedly, how we detect missing docs if we don't follow Rakudo – e.g., SetHash would *also* inherit the `kv` method from Any, but that's not the correct implementation, so just saying "does this method show up on the page" isn't enough | 20:16 | ||
) | |||
20:18
dogbert2 left
20:20
dogbert2 joined
|
|||
[Coke] | we've said since day one that rakudo is *an* implementation, not *the* implementation. So that should inform this question on the docs site. | 20:27 | |
(we can have rakudo specific stuff in there, and do, but we try to call it out, like for 'dd', which is not spec.) | |||
(day one) of the project, not the doc site. | |||
codesections | Yeah, I get that and support it 100% | ||
I'm just kind of lost on how to apply it here | 20:28 | ||
Like, we organize the Type docs by listing which methods are supplied by each Class/Role | 20:29 | ||
and that's fundementally something Roast doesn't have an opinion on | |||
20:29
Black_Ribbon joined
|
|||
[Coke] | I'd treat it as incremental progress. let's get the docs in the site as a first approximation, and we can true up the location as we go. | 20:29 | |
i don't think we need to finalize everything about step 2 before completing step 1. (but I get wanting to settle it as much as possible to reduce moves later) | 20:30 | ||
codesections sighs | |||
You're probably right... | |||
[Coke] | Sorry. also: I'm just me. I'm sure JJ has a strong opinion, you can do what he says. :) | ||
codesections | Well, you have me mostly convinced. But it pretty much means I need to give up on the goal of having all our docs checked against a tool that introspects Raku code | 20:32 | |
and that the work I did on the list-missing-methods script to get it to be that tool was ... well, I'll say a Good Learning Experience rather than "a waste" | 20:33 | ||
20:33
natrys left
|
|||
[Coke] | I think it's a reasonable start, and everything in rakudo should be documented. you can still use that part of the tool. | 20:44 | |
and it may be used to highlight those differences between rakudo & roast and allow us to true things up, in either direction. | |||
20:47
rindolf left,
zacts left
|
|||
codesections | Coke: Yeah, all fair points :). Just to clarify, in your view should `Mixy` even be documented? It's not in Roast and is arguably an implementation detail, right? | 20:48 | |
[Coke] | we can have additionally a mapping config that says "rakudo defines this here, and in docs, we've intentionally put it here.". | ||
if it's not in Roast, I wouldn't bother, no. | |||
assuming all documentation time is fungible, don't document the things that aren't spec. | |||
(it's not, and people will work on what they want) | |||
codesections | Well, taken literally, that would mean *large* changes | 20:49 | |
Mixy isn't in Roast, Setty and Baggy are in ~2 tests, but that looks like an more of an accident than an intentional decision to include them | 20:51 | ||
20:52
sena_kun joined
|
|||
codesections | Dateish isn't either | 20:52 | |
rypervenche | Question: Is it possible to get the output of a Match object with the tree that it creates, but without the text that it matched against at the very top? | ||
20:54
Altai-man left
|
|||
rypervenche | Ahh, looks like it's .caps, although it doesn't do the indenting. Ok, I can make a method to do that, similar to the Match gist. | 20:56 | |
[Coke] | codesections: I am sure there are large gaps in the docs, yes. | ||
only way to keep it up to date (and get it there in the first place) is testing. | |||
so codesections++ for pursuing this and all the work on the rakudo introspector | 20:57 | ||
codesections | :D "large gaps" is a whole different thing from "many pages that shouldn't exist because we're following the implemention too closely" | ||
It's a false-positive instead of a false negative | 20:58 | ||
[Coke] | add a failing xt test and just keep making it pass more. :) | 20:59 | |
"just" | |||
codesections | :D | 21:00 | |
[Coke] | that's what we did with examples compilation, spellcheck... | 21:01 | |
there was a huge pile, we wrote a test so we'd know when we were done, and just hacked away | |||
codesections | Sounds like a plan. Or at least a plan-to-have-a-plan | 21:02 | |
But I guess we still need to reach consensus on this | |||
21:15
hungrydonkey joined,
MasterDuke joined
21:25
dogbert11 joined
21:28
dogbert2 left
21:32
chloekek joined
|
|||
chloekek | . | 21:35 | |
21:40
patrickb left
21:41
pecastro joined
21:48
dogbert17 joined,
wamba joined
21:49
dogbert2 joined
21:51
dogbert11 left
21:52
dogbert17 left
22:01
dogbert2 left
22:03
dogbert2 joined
22:08
Manifest0 left
22:09
edk_ is now known as e
22:10
Cabanossi left
22:17
Cabanossi joined
22:21
dogbert11 joined
22:22
dogbert2 left
|
|||
SmokeMachine | xinming_: yes it should (if add the column c) | 22:26 | |
22:31
dogbert17 joined
22:34
dogbert11 left
|
|||
lizmat | codesections: perhaps Set.grab should be marked as "implementation detail " ? | 22:35 | |
and similar candidates that are just there to provide better error messages ? | |||
22:43
dogbert17 left
22:45
dogbert17 joined
22:53
wamba left
22:54
lucasb joined
23:03
oneeggeach joined
23:07
molaf left
23:10
japhb left
23:11
japhb joined
23:13
dogbert2 joined
23:15
dogbert17 left
23:21
leont left
23:22
dogbert11 joined
23:23
dogbert17 joined
23:24
dogbert2 left
23:25
dogbert2 joined
23:26
dogbert12 joined
23:27
dogbert11 left
23:28
dogbert17 left
23:29
dogbert2 left
23:30
aborazmeh joined,
aborazmeh left,
aborazmeh joined
23:37
oneeggeach left
23:42
dogbert17 joined
23:45
dogbert12 left
23:46
dogbert2 joined
23:47
chloekek left
23:50
dogbert17 left
23:52
rir joined
23:53
dogbert11 joined
23:54
maggotbrain joined
23:55
dogbert2 left
|