|
00:47
arkiuat left
00:48
arkiuat joined
00:53
arkiuat left
01:20
arkiuat joined
01:25
arkiuat left
01:46
arkiuat joined
01:51
arkiuat left
02:04
arkiuat joined
02:09
arkiuat left
02:21
arkiuat joined
02:26
arkiuat left
02:44
arkiuat joined
02:49
arkiuat left
03:19
arkiuat joined
03:24
arkiuat left
03:29
arkiuat joined
03:34
arkiuat left
03:46
arkiuat joined
03:50
arkiuat left
04:18
arkiuat joined
04:23
arkiuat left
04:46
arkiuat joined
04:52
arkiuat left
05:19
arkiuat joined
05:24
arkiuat left
05:46
arkiuat joined
05:55
arkiuat left
06:23
arkiuat joined
06:28
arkiuat left
06:31
arkiuat joined
06:37
arkiuat left
07:05
arkiuat joined
07:10
arkiuat left
07:32
arkiuat joined
07:37
arkiuat left
07:55
arkiuat joined
08:06
arkiuat left
08:15
arkiuat joined
08:21
arkiuat left
08:36
arkiuat joined
08:41
arkiuat left
09:12
arkiuat joined
09:17
arkiuat left
09:30
arkiuat joined
09:38
arkiuat left
09:52
librasteve_ joined
09:55
arkiuat joined
09:59
arkiuat left
10:22
arkiuat joined
10:27
arkiuat left
10:30
arkiuat joined
10:40
arkiuat left
10:41
arkiuat joined
10:47
arkiuat left
11:03
arkiuat joined
|
|||
| lizmat | feels like roast's CONTRIBUTING.md could use a makeover | 11:15 | |
| arkiuat | it seems to me that the failed space-after-comma test on PR 4714 is spurious, because I'm discussing the comma operator and marking it up as such. I couldn't find any "real" commas without spaces after them. | 11:16 | |
| however, I'm not sure I got all the new links right | |||
| good morning lizmat :) | 11:18 | ||
| lizmat | morning arkiuat | ||
|
12:26
ds7832 joined
12:38
ds7832 left
13:08
arkiuat left
13:20
arkiuat joined
13:25
arkiuat left
13:32
arkiuat joined
13:38
wayland joined,
wayland76 left
14:22
librasteve_ left
15:04
arkiuat left
15:32
arkiuat joined
15:39
arkiuat left
15:57
arkiuat joined
17:12
Guest7020 joined,
Guest7020 left,
Guest7020 joined
17:57
Guest7020 is now known as ds7832
|
|||
| lizmat | reading through docs.raku.org/language/operators I wonder why the description of the operators is mixed in with the precedence of the operators | 20:03 | |
| in my experience, the precedence of an operator is generally of lesser importance | |||
| am I the only one ? | 20:32 | ||
| ds7832 | personally I've so far only consulted this document when some other document linked to a subsection on a specific operator, and then I've only read that exact subsection or and maybe parts of the overarching section. Thus it has always been very rare that I encountered any of the text about precedence. *But* I actually like knowing that it's in there, to be read when I want to read up on it; and more importantly, I think it makes sense: When one wants to learn | 21:22 | |
| the order of operator precedence, I think it helps significantly to have the list of all concrete operators right there, ready to construct examples from. | |||
| in other words: for understanding precedence, it helps to have the operators there; for understanding individual operators, it is at least no disadvantage to have a few sections on precedence at the very top. | 21:23 | ||
| But, in fairness, I may have a bias for the status quo on this | 21:24 | ||
| arkiuat | I have to agree with lizmat on this one. I've always thought that precedence was a weird choice to use for ordering the operator docs. I'd rather see operator precedence discussed in an article dedicated to only that topic. | 21:43 | |
| But on the other hand, I don't have a ready candidate for how else to order the operator docs (alphabetical doesn't make any sense here, really), and frankly, there's no particular rhyme or reason to the ordering of the methods in each documented type/class. | 21:44 | ||
| +either | |||
|
22:10
wayland left
22:27
[Coke] left
|
|||
| ds7832 | If it's about the ordering of the various sections, there might be better ordering principles than precedence. (Incidentally, I briefly became aware of this just yesterday.) One option, is of course to try to group most of them by the action they perform (e.g. or *return a specific type* like a Bool, Array, Numeric, Block,... or *return type dependent on input* like `//`, `andthen` & friends, and the Reduction operators,... or those that *assign* a RHS to a LSH | 22:34 | |
| or ). One will probably make some exceptions e.g. to keep all the regex operators together despite them performing different "actions". Also, one may want to put (non-meta) Z, X, x, xx and perhaps ... and ^ (as in 1...5 and ^5) into the same section, even though they don't all produce the same type; that section should then probably be located right above the Metaoperators section, since many of them have a Metaoperator variant. | |||
| Geth | doc/schultzdavid-patch-10: 93aba54f43 | (David Schultz)++ | doc/Type/Str.rakudoc update signatures of `method contains` and explain handling of Cool params If $needle and/or $pos is of type Cool, this is no longer directly handled by a multi of Str.contains, but by a multi of Cool.contains. Hence, remove such signatures from here and instead add an explanation and a link to Cool.contains . Also, order the signatures in a way that's better to digest. |
23:27 | |
| doc/schultzdavid-patch-10: ac2a6bf3a9 | (David Schultz)++ | doc/Type/Str.rakudoc fix invocant marker & formatting |
|||
| doc: schultzdavid++ created pull request #4717: fix invocant marker & formatting |
23:31 | ||
| doc/main: ac2a6bf3a9 | (David Schultz)++ | doc/Type/Str.rakudoc fix invocant marker & formatting |
23:34 | ||
| doc/main: 4663a23b89 | schultzdavid++ (committed using GitHub Web editor) | doc/Type/Str.rakudoc fix invocant marker & whitespace in Str.rakudoc, |
|||