🦋 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.
Geth nqp: Kaiepi++ created pull request #776:
Make some enhancements to atomic integers
06:49
rakudo: Kaiepi++ created pull request #5000:
Make some enhancements to atomic integers
06:50
japhb Have been using idle time to work my way backwards on the Getopt::Long failure. Back as far as e7acf4930 it won't install. At 934f9895e, I get hangs trying to install an earlier module in my test list; I suspect fixing that was exactly was the e7acf4930 merge was *for*. 06:58
japhb Looks like 5a8aa66bc was the last commit before one that was later reverted; checking there next (despite it being a bit of a jump back) 07:00
Geth JSON-Unmarshal: CIAvash++ created pull request #3:
Fix is unmarshalled-by trait issue
07:45
japhb Well 5a8aa66bc got *much* further in building things, but it hung testing Cro::HTTP, so that's a fail for a new reason 07:55
japhb tries 6dc2f92c9 in between 07:58
SIGH
japhb It being after 1 AM, I think I'm going to sleep while that builds (or attempts to, at least). See y'all in a few hours. :-) 08:04
Kaiepi LAPTOP-7I9RCT0C% raku --ll-exception -e 'say Counter(IntStr.new: 0, "ayy") ~~ Cool' 09:25
True
nqp can manage a *little* more than Any
takes a bit of convincing to do CALL-ME, though
Kaiepi oh, i can spare CALL-ME if i let hllization do its thing 10:15
nvm, i need it 10:19
Geth rakudo: 3d3966b0c4 | (Elizabeth Mattijsen)++ | src/core.c/Main.pm6
Fix lone "-" in MAIN handling with :named-anywhere

This resulted in an execution error:
   my %*SUB-MAIN-OPTS = :named-anywhere; sub MAIN(|) { }; @*ARGS = "-"
Without :named-anywhere, the lone "-" was already considered a positional argument.
10:52
JSON-Unmarshal/main: 1778fb8e0c | (Siavash Askari Nasr)++ (committed using GitHub Web editor) | lib/JSON/Unmarshal.rakumod
Fix is unmarshalled-by trait issue (#3)

Fixes #2
It seems putting `use JSON::Name` after `unit module` causes the issue.
11:13
lizmat m: sub MAIN(|c) { dd c }; @*ARGS = "--=" # this feels like an odd thing to allow ? 11:43
camelia \("" => IntStr.new(0, ""))
lizmat m: sub MAIN(|c) { dd c }; @*ARGS = "--=22" # this feels like an odd thing to allow ?
camelia \("" => IntStr.new(22, "22"))
Geth rakudo: 31779f4701 | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6
Add ACCEPTS method for DateTime

Fixes #5001
13:12
Xliff P6-GLib suite timing statistics for Raku 2022.06.60.ga.7.e.9.b.1938 14:11
Total number of projects: 33 (483208 loc)
Total non-parallel compile times: 8905.310 (269.858 avg)
Total parallel compile times: 1505.717 (45.628 avg) 5.914x speedup
Still seeing an odd recompilation issue with one of my projects which is sucking an extra 100 seconds away from record timings. 14:12
japhb FINALLY: "Welcome to Rakudo™ v2022.06-33-g6dc2f92c9." 18:26
japhb inches forward to try 4fedb6f05 18:30
releasable6 Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
japhb Hmmm, that one also hung on Cro::HTTP. I wonder if that's just a flaky test, or whether this range of Rakudo commits has a hang bug. 19:21
japhb retries on same version
japhb Yep, retry worked 20:28
OK, time to split Vadim's branch I think. Trying b4a26fbe4. 20:30
Boom, Getopt::Long fail. Closing in! 20:53
Same failure at 4ab617201. Time to try the last one: 7774c331c 21:08
japhb Yup, that one fails too. 21:23
vrurg_: Looks like the Getopt::Long failures are caused by "7774c331c - Implement coercion via new-disp" (and not fixed by any later patches) 21:24
Don't know if that's a bug in the coercion changes or a fragility in Getopt::Long, but at least now you have a place to look .... 21:25
vrurg_ japhb: interesting as I use Getopt::Long pretty heavily in my work project. Any details? 21:35
japhb vrurg: gist.github.com/japhb/fc7aea8417fd...8b5806cfe5 21:40
vrurg Interesting, does it mean I didn't reinstall it since the new-disp implementation? :) 21:44
japhb *chuckle* 21:45
vrurg I don't get the idea behind the test. What happens there? I don't use that feature of Getopt::Long and can't grok what is being tested. 21:49
japhb shrugs -- I just threw spare compute and disk space at narrowing down the failure introduction. I haven't actually looked at Getopt::Long itself. :-) 21:50
vrurg But it looks like it's a bug in the test. Seemingly, the option must produce a Foo, but parameter's type is Signature(Str). 21:51
Or Foo is cached by new-disp somehow because guards told it so... 21:56
jdv i think there's a bunch related to coercion 22:20
trying to curate the blin report atm 22:21
vrurg If I'm right (and I seem to be) the problem is likely to affect many cases. Will work on it today. 22:22
jdv looks like about 4 failures 22:27
vrurg: github.com/rakudo/rakudo/issues/5002 22:32
lizmat: the 2 at the top of that blin report look like they are related to changes of yours 22:33
did we ever address the issue that broke the ORM last release?