releasable6 Next release in ≈6 days and ≈15 hours. 2 blockers. Please log your changes in the ChangeLog: 03:00
03:20 evalable6 left, linkable6 left 03:22 linkable6 joined 03:23 evalable6 joined 04:17 maggotbrain joined 06:32 frost-lab joined 07:53 evalable6 left, linkable6 left 07:55 linkable6 joined 07:56 evalable6 joined 08:08 Altai-man joined
Geth roast: 44685318d2 | (Christian Bartolomäus)++ | S10-packages/precompilation.t
[JVM] Skip test that started to fail recently
rakudo: usev6++ created pull request #4110:
[JVM] Make optional coercive parameter work again
08:53 stoned75 joined 09:09 sena_kun joined 09:10 Altai-man left
Geth rakudo: 1c43c46efb | (Elizabeth Mattijsen)++ | 7 files
Remove return Sig from .elems methods

We can be pretty sure that these will either return an Int or a Failure. So there's no real need to check here. This appears to have a positive effect, typically on multi-dimensional shaped array accesses, hence the reason for doing this (typically from 15% of total to 15% of total effort).
13:08 Altai-man joined 13:10 sena_kun left
Geth nqp: f7be5c5932 | (Nicholas Clark)++ | t/nqp/019-file-ops.t
floating point atime should be compared with integer atime, not mtime.

Similarly ctime with ctime, not mtime.
This appears to be a copy-paste thinko that dates back to when the test was originally added in 2016 by commit 37862cd52d63eb61:
   Add subsecond file time ops stat_time and lstat_time
nqp: a083615656 | (Jonathan Worthington)++ (committed using GitHub Web editor) | t/nqp/019-file-ops.t
Merge pull request #688 from Raku/atime-with-atime

floating point atime should be compared with integer atime, not mtime.
13:51 MasterDuke left, lucasb joined 14:20 MasterDuke joined 14:40 sxmx left 14:44 sxmx joined
Geth roast: 9c443ac27d | (Christian Bartolomäus)++ | S17-supply/syntax.t
[JVM] Unfudge tests (no UnwindException anymore)

It's not clear what made the UnwindException go away, but the tests seem to run fine now.
16:49 stoned75 left 17:09 sena_kun joined 17:10 Altai-man left 17:35 leont joined
Geth rakudo: nwc10++ created pull request #4111:
Use `exec` instead of `system` and then exiting with the return code.
nwc10 that totally doesn't fit the PR template :-)
or :-(
Geth rakudo: 856dfb2d2e | (Christian Bartolomäus)++ | src/vm/jvm/runtime/org/raku/rakudo/
[JVM] Make optional coercive parameter work again

Fixes for the JVM backend. Inspired by
rakudo: 5e791d7995 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | src/vm/jvm/runtime/org/raku/rakudo/
Merge pull request #4110 from usev6/jvm_coercive_optional

  [JVM] Make optional coercive parameter work again
nqp: b12517b062 | (Christian Bartolomäus)++ | src/vm/jvm/QAST/Compiler.nqp
[JVM] Make gather work with last/next/redo in loop

This helps with a long standing bug on the JVM backend:
If last/next/redo were called within an extra block (marked as
  'immediate' or 'immediate_static'), that call was translated to
... (8 more lines)
19:45 Xliff joined
Xliff Oh my.... 19:45
IRC looks brilliant on my new 86" TV 19:46
An actual on-topic question: Has anyone run into a "too many open files" error when precompiling nested modules? 19:47
In my larger work, I am trying to run a script, go 7 extra levels down (modules requiring other modules...) and can trigger this error. 19:48
If not, will try to golf and reproduce.
Bumping ulimit fixed it. Is raku leaking file handles? 19:50
MasterDuke that's not a tv, that's a small wall 20:28
lizmat Xliff: possibly 20:33
Xliff MasterDuke: :)
lizmat: I've been looking at my system. I think it MIGHT not be rakudo 20:34
My browsers are memory and file hungry beasts.
If I see the problem again, I will golf and bug. 20:35
MasterDuke Xliff: maybe check lsof close to the end of your precompilation? see if raku/moar have a lot of files open 20:38
Xliff That's pretty much what I did. Except I counted files without raku running. 20:43
Previous ulimit was 1024 files
Now it's 2048.
Browsers had close to 1000 files open! 20:44
MasterDuke ha
Xliff Exactly! 20:45
20:50 stoned75 joined
stoned75 Hi 20:52
I'm looking
and I'm wondering if the final comma is a typo or if it serves a specific purpose ?
MasterDuke looks like a typo 20:57
Xliff Yeah. A typo that stumbles into the right behavior because the value is sunk? 21:00
21:08 Altai-man joined
Xliff Noticing a definite slide in rakudo compile times over the last 4 weeks 21:08
21:11 sena_kun left
lizmat stoned75: yup, a harmless typo 21:11
Geth rakudo: 6843f80330 | (Elizabeth Mattijsen)++ | src/core.c/Signature.pm6
Fix harmless typo

Spotted by stoned75++
Xliff 21:13
Note the 2 timings tabs
lizmat Xliff: sadly not visible for the Google login impaired
stoned75 lizmat: yeah, I had to recompile rakudo a few times to convince myself it was harmless, ... as I've been mislead by's caveat wrt to its count parameter's type :-} 21:14
Xliff lizmat: I'll see what I can do.
lismat: Does this work? 21:15
lizmat ^^ 21:19
lizmat yup 21:20
Xliff: O and P ? 21:21
Xliff lizmat: where? 21:22
lizmat looking at I'm not sure what to look for ?
ah, wrong tab 21:23
Xliff Yah. tabs ending in "timings"
Even with GIO and ATK removed from 11/16 numbers that still would be the fastest timing in 4 weeks 21:25
Geth rakudo: e1f09cfaf8 | (Elizabeth Mattijsen)++ | src/core.c/Parameter.pm6
Fix copy-pasto, also spotted by stoned75++
lizmat Xliff: you *are* saying that compilation is taking *longer*, right ? 21:31
stoned75 lizmat: I wonder if I should ask you to describe Parameter.usage-name in one sentence or if I go on trying to double check my understanding of it and spot other typos and pastos ;-) 21:37
lizmat m: sub a(:a(:$b)) { }; dd &a.signature.params.head.usage-name 21:41
camelia "b"
lizmat so I guess it's the name of the parameter inside the scope? Without its sigil 21:43
Xliff lizmat: Yes.
m: sub a(:$a) { }; dd &a.signature.params.head.usage-name 21:44
camelia "a"
Xliff m: sub a($b, :$a, :xliff(:$c)) { }; dd & *.usage-name)
camelia ("b", "a", "c").Seq
lizmat stoned75: looks like it really is an implementation detail 21:45
Xliff lizmat: Ah! Cool.
lizmat Xliff: not sure where that was an answer to 21:46
Xliff <lizmat> Xliff: you *are* saying that compilation is taking *longer*, right ?
lizmat well... it taking longer I wouldn't describe as "Cool" :-( 21:47
Xliff lizmat: Oh. No. The "Cool" was for .usage-name 21:48
lizmat ah, right, ok :-)
stoned75 lizmat: ok. but it's only used once in rakudo's sources, and btw it was added by you ;-)
lizmat could well be 21:49
hmmm... my git blame says Ben Davies ? 21:50
lizmat ah, ok, :-) almost 5 years ago :) 21:51
21:51 patrickb joined
lizmat ok, in that light, for people wanting to generate their own USAGE message, it's probably wise to document this as user-facing 21:53
stoned75 that's what I'm doing. but I wanted to understand its implementation and well... I got carried away :-} 21:54
as now I'm wondering how a parameter could have a * or ! or . twigil 21:58
22:02 maggotbrain left
lizmat m: sub a(*@a) { dd @a }; a 1,2,3, <a b c> 22:07
camelia Array element = [1, 2, 3, "a", "b", "c"]
lizmat m: sub a($*FOO) { dd $*FOO }; a 42
camelia 42
stoned75 m: say => '$^a').usage-name 22:17
camelia ^a
stoned75 hum so now this seems wrong
lizmat yup that's wrong
m: otoh, I don't think you can actually create such a parameter in plain Raku code 22:18
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3ly create such a parameter in plain Raku7⏏5 code
expecting any of:
infix stopper
statement en…
lizmat m: my $b = { $^a }; dd $b.signature.params.head.usage-name
camelia "a"
lizmat { $^a } is syntactic sugar for -> $a { $a } 22:20
stoned75 sure 22:21
Xliff lizmat: Did you ever get a chance to comment on: 22:22
lizmat I think I said a PR would be nice? "Any thoughts? If you'd rather this be a PR, I'll have to work more on it." 22:23
Xliff Ah. OK. 22:24
I need to finish writing the tests for it, anyway.
lizmat ++Xliff 22:25
22:41 Altai-man left 22:42 patrickb left
releasable6 Next release in ≈5 days and ≈19 hours. 2 blockers. Please log your changes in the ChangeLog: 23:00