🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
04:08 [Coke] left 04:15 [Coke] joined 04:41 dogbert11 left
ab5tract_ this test file is failing for me in `main`: `t/spec/6.c/S32-io/file-tests.t` 07:32
is this affecting anyone else?
(`RAKUDO_RAKUAST=1`) 07:33
nine: I don't know about that. the thingies I'm unsinking seem to have been sunk already. Otherwise my unsinking would get re-sunk, no? 07:35
anyway, here's the approach I took: github.com/rakudo/rakudo/pull/5409...5625a9ba4d 07:37
but something's wrong there 08:06
08:45 sena_kun joined 09:44 sena_kun left
Geth File-Find/2colours-CI-patch: 8b767353f2 | (Márton Polgár)++ (committed using GitHub Web editor) | .github/workflows/windows-spec.yml
More useful CI for Windows
09:49
File-Find: 2colours++ created pull request #46:
More useful CI for Windows
File-Find/2colours-CI-patch: 6afeda46c1 | (Márton Polgár)++ (committed using GitHub Web editor) | .github/workflows/macos.yml
More useful CI for Mac
09:51
File-Find/2colours-CI-patch: 035a2f9708 | (Márton Polgár)++ (committed using GitHub Web editor) | .github/workflows/linux.yml
More usful CI for Ubuntu
File-Find/main: 4 commits pushed by (Márton Polgár)++ 09:52
rakudo/main: dd24f978be | (Elizabeth Mattijsen)++ | 3 files
RakuAST: unbreak POST phaser

This was borked in 934f806358b5233f
10:01
rakudo/main: a5d947d90e | (Elizabeth Mattijsen)++ | 3 files
RakuAST: colonpairs in postfix ops no .raku|DEPARSE ok

This required allowing :colonpairs to be specified on several postfixy ops to allow for a single statement .raku representation.
10:37
rakudo/main: 5 commits pushed by (Elizabeth Mattijsen)++ 10:47
[Tux] Rakudo v2023.09-82-g934f80635 (v6.d) on MoarVM 2023.09-1-g7abf85f94
csv-ip5xs0.838 - 0.861
csv-ip5xs-205.530 - 6.378
csv-parser3.715 - 4.004
csv-test-xs-200.356 - 0.384
test6.395 - 7.584
test-t1.446 - 1.635
test-t --race0.842 - 0.917
test-t-2020.075 - 20.868
test-t-20 --race7.119 - 7.585
Geth rakudo/main: aa5f512ba2 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: deparse colonpairs only once

Each postfix op is responsible for its colonpairs, so don't also do this when applying one
11:02
11:38 ilogger2 joined
Geth Benchmark/main: a62fce1d7d | (Márton Polgár)++ (committed using GitHub Web editor) | .github/workflows/test.yml
CI shouldn't fail fast

Updating here as well because I often take this workflow as a reference...
13:31
13:44 Nemokosch joined 13:50 Nemokosch left, Nemokosch joined 14:12 Nemokosch left
nemokosch ugexe: do you have an idea about this failure? github.com/2colours/Term-TablePrin...7606871883 14:36
succeeds with Mac+latest Rakudo, fails with Mac+august Rakudo
with fail-fast: false 14:37
ugexe github.com/rakudo/rakudo/issues/5357 14:39
that latest version of zef works around that issue, so you'd have to update zef in that CI or not test on that version of rakudo (which comes with the older zef)
nemokosch gotcha 14:40
ab5tract_ nine: sooo.... it looks like we are going to have to fudge a bit for DEPARSE and AST to round trip `FIRST` blocks 15:27
I suppose its probably not for the first time 15:53
lizmat ab5tract_: it isn't, see the POST phaser 15:58
16:52 RakuIRCLogger joined 16:57 RakuIRCLogger left, RakuIRCLogger joined 16:58 Geth left, Geth joined
Geth rakudo/main: dacdebeb6d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix several aspects of colonpairs handling
17:00
rakudo/main: 1e5de1231d | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod
RakuAST: make adverbs on array indices work

Apparently, these were simply forgotten to be added
lizmat 968 +7 !! 17:01
17:29 Geth left, Geth joined
Geth rakudo/main: 0c5f5ddb2c | (Elizabeth Mattijsen)++ | t/12-rakuast/postfix.rakutest
RakuAST: add tests for postfixes with colonpairs
17:41
ab5tract_ lizmat++ 18:03
nice one!
18:17 bartolin left 18:22 bartolin joined
ab5tract_ ok, the `FIRST` PR now has tests, doesn't use intrusive approaches to (not) sinking, and has working `FIRST` wherever state variables are sold 18:39
oh, and `my $uid = FIRST unique-id` is working too 18:40
Geth roast: usev6++ created pull request #844:
Add test for issue 4700 in old issue tracker
20:06
bartolin I'd like to hear some opinions about the topic "PR vs. committing directly". Being influenced by $day-job (and maybe/hopefully also due to becoming a bit wiser) I lean towards creating a PR for nearly everything. But then resources are scarce and creating pull requests just to watch them getting of age doesn't help much. (No offense meant.) 20:37
Probably the question is too generic, so the most sensible answer is "it depends"? 20:38
But to take some examples: The above PR, github.com/rakudo/rakudo/pull/5379 or github.com/Raku/nqp/pull/809: Would you be fine with me committing such things directly or do you prefer pull requests? (Related: Do you do a kind of "post review" for commits to main anyway, so that really bad patches would be caught?) 20:44
codesections I'd like others to weigh in too, but bartolin imo PRs for non-trivial changes are a good idea **but** merging your own PR after a few days of non-objection is fine too 20:51
iirc lizmat changed from mostly commiting directly to mostly (always?) opening a PR 20:52
bartolin Thanks for the first feedback. Sounds reasonable to me. Let's see if there are other opinions. 21:12
lizmat I most definitely only make PRs for something I think might be controversial 21:25
I get that wrong sometimes
22:14 Geth left, Geth joined 22:18 Geth left, Geth joined
ugexe i like PRs because they show you if your code works via the CI. i don't even run the spec tests locally anymore cause the CI runs one 22:48