|
00:26
arkiuat left
00:35
arkiuat joined
00:44
arkiuat left
00:55
arkiuat joined
01:00
arkiuat left
01:09
arkiuat joined
02:52
lizmat_ joined
02:55
lizmat left
03:38
disbot8 left,
disbot9 joined
06:45
arkiuat_ joined
06:48
arkiuat left
06:56
disbot10 joined
06:57
disbot9 left
|
|||
| disbot10 | <librasteve> arkuiat++ | 10:18 | |
| Geth | doc/main: 4 commits pushed by (Eric Forste)++, librasteve++ | 10:22 | |
| disbot10 | <librasteve> my practice is to review and merge at the same time if the review is good - maybe a bit shortcutty but I want to help maintain a fast pace of change - lemme know if that's an issue | 10:23 | |
|
10:25
lizmat_ left,
lizmat joined
|
|||
| [Coke] | I tend to prefer squashing the doc PRs in general. (usually a lot of "trying to fix whitespace" - this one looks fine just based on these 3 commits) | 14:21 | |
| stackoverflow.com/questions/798612...d-features | 14:42 | ||
| I think we can re-word that warning. The original dream of multiple compilers isn't here, and so I would tend to treat rakudo design decisions with more weight that when that line was written | 14:43 | ||
| I think we can keep the "design is separate from implementation" line, but soften the wording so it is less risk. | |||
| Also: anywhere in the docs where a concern like this is mentioned, I would add a link to another page, and write the warning *once*. | 14:53 | ||
| like: "See <notes> about specification vs. implementation" | |||
| And/or we should push for moving anything questionable INTO the specification | 14:54 | ||
| (would love to have the problem of a commercial compiler wanting to be called Raku and we had to deal with it. :) | 14:57 | ||
|
16:01
librasteve_ left
16:45
arkiuat_ left
17:02
arkiuat joined
17:18
arkiuat left
|
|||
| disbot10 | <librasteve> I am 100% cool with softenig and centralising. In practice, I guess there is a question whether we should "lift" the current MOP implementation to the status of specified by writing a bunch of MOP tests for ROAST ... I hesitate to propose this because (i) it feels to me that MOP and Mu and implementation are very interconnected so that this could overly constrain other compiler efforts (I say this based on having, once, a long time ago, | 17:30 | |
| trying to make a "Mu" and in general that's a very intricate thing) and (ii) we have other fish to fry (aka laziness is a virtue). I feel that the answer I gave was in line with these points and tbh if the lack of tightly specified MOP with promise of cross compiler interop in the far distant future, then I am not sure that Raku is the best choice for them, or more generally what the drivers are for this kind of concern. | |||
| <librasteve> PS. please can you review the latest raku.org PR as Camelia is still in Santa guise? | 17:32 | ||
|
17:51
arkiuat joined
17:56
arkiuat left
|
|||
| disbot10 | <librasteve> [Coke]: ^^ | 17:57 | |
|
17:57
librasteve_ joined
17:59
wayland76 joined,
wayland left
18:11
arkiuat joined
18:24
arkiuat left
18:31
arkiuat joined
18:41
arkiuat left
18:51
arkiuat joined
|
|||
| [Coke] | Done... but only with source. Let me know if I should review the UI also. | 20:40 | |
| disbot10 | <librasteve> tx! ... I'll keep an eye that all deploys as intended | 20:59 | |
|
21:57
wayland76 left
22:06
disbot10 left
22:07
disbot11 joined
22:55
arkiuat left
23:05
arkiuat joined
|
|||