03:10 kjp left, greppable6 left, unicodable6 left, bloatable6 left, sourceable6 left, tellable6 left, coverable6 left, lucs left 03:19 lucs joined 03:20 kjp joined 08:58 [TuxCM] joined
[TuxCM] Rakudo v2024.10-78-g0911eca22 (v6.d) on MoarVM 2024.10-45-gfd9da869d
csv-ip5xs0.261 - 0.264
csv-ip5xs-201.105 - 1.120
csv-parser1.519 - 1.525
csv-test-xs-200.142 - 0.143
test1.880 - 1.933
test-t0.401 - 0.404
test-t --race0.266 - 0.267
test-t-204.743 - 4.794
test-t-20 --race1.176 - 1.181
 08:58
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth nqp-configure/main: 5b782265a6 | (Patrick Böker)++ | lib/NQP/Macros.pm
Allow config keys with double colon in @if()@
 09:41
nqp-configure/main: 566ca58573 | (Patrick Böker)++ (committed using GitHub Web editor) | lib/NQP/Macros.pm
Merge pull request #29 from Raku/if-double-colon-config-key

Allow config keys with double colon in @if()@
09:51 nine left 09:52 nine joined 10:23 sena_kun joined 10:34 sena_kun left 10:44 sena_kun joined 10:46 sena_kun left
Geth rakudo/lizmat-ownup: 6902531090 | (Elizabeth Mattijsen)++ | 3 files
Add VM.ownup to produce backtraces of all threads and exit

This wraps Timo Paulssen's new "all-thread-bt" MoarVM syscall in a method on the VM class, and attempts to do the same on other backends.
That syscall generates a complete backtrace of *all* running threads ... (9 more lines)		 11:40
rakudo: lizmat++ created pull request #5719:
Add VM.ownup to produce backtraces of all threads and exit
nqp/main: 7de34898a7 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get Timo++ "is-debugserver-running" syscall
 11:52
rakudo/main: 998fccfb49 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get Timo++ "is-debugserver-running" syscall
 12:06
rakudo/main: 4a93b41368 | (Elizabeth Mattijsen)++ | src/core.c/VM.rakumod
Add VM.remote-debugging method

On MoarVM, this may return: 0 - no remote debugging possible 1 - remote debugging is possible, but no remote debugger is watching 2 - remote debugger is watching
... (12 more lines)		 12:36
rakudo/lizmat-no-remote-debugging: 67aeb47bc8 | (Elizabeth Mattijsen)++ | 2 files
Add "no-remote-debugging" module

So that you can disable debugging easily from the command line (with
  -Mno-remote-debugging) or by adding that to the RAKUDO_OPT environment
variable.		 12:52
rakudo: lizmat++ created pull request #5720:
Add "no-remote-debugging" module
14:05 [TuxCM] left 14:09 donaldh left
Geth roast: 2346529e63 | (Elizabeth Mattijsen)++ | 6.c/MISC/bug-coverage-stress.t
Fix stress test that used .polymod

  github.com/rakudo/rakudo/commit/c8...636a8364b0
changed the semantics of .polymod for 1. This test was depending on that behaviour, but was just using the old behaviour to test a scoping issue, rather than the specific output of .polymod.
Fixed the test by adding a subroutine that mimicked the old behaviour and using that instead of the .polymod method call.		 14:24
¦ rakudo: lizmat self-assigned Use of lookbehind assertions in .trans hangs rakudo github.com/rakudo/rakudo/issues/5488 15:04
lizmat m: $/ := 42; "foo".trans(/ o / => "b") 15:19
camelia Cannot modify an immutable Int (42)
in block <unit> at <tmp> line 1
Geth rakudo/main: 097d668036 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Make .trans only assign to $/ if it's assignable

Found while looking into #5488		 15:44
rakudo/main: 59bfd7f6d3 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Check positional .trans args earlier

  - add candidate without positionals for the noop case
  - check candidates using new .are functions before doing anything
Found while looking into #5488		 16:09
lizmat m: say "foobar".trans("a..f" => "x") TIL 16:19
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> say "foobar".trans("a..f" => "x")<HERE> TIL
expecting any of:
infix
infix stopper
postfix
statement end
stat…
lizmat m: say "foobar".trans("a..f" => "x") # TIL
camelia xooxxr
lizmat I don't see any documentation for that 16:25
ab5tract An Easter Egg for Christmas! 16:26
m: multi sub add(Int(Str) $a, Int(Str) $b) { say "coercing Str to Int"; dd :$a, :$b }; multi sub add(Int(Num) $a, Int(Num) $b) { say "coercing Num to Int"; dd :$a, :$b }; add("4","1"); add(4.4e0, 2.3e0) 16:27
camelia coercing Str to Int
:a(4)
coercing Num to Int
:b(1)
:a(4)
:b(2)
ab5tract I’m curious why the output is out of order here
I would expect :b(1) to land after :a(4)
lizmat STDOUT vs STDERR output ? 16:28
ab5tract It’s no Easter Egg, though :)
lizmat m: multi sub add(Int(Str) $a, Int(Str) $b) { note "coercing Str to Int"; dd :$a, :$b }; multi sub add(Int(Num) $a, Int(Num) $b) { note "coercing Num to Int"; dd :$a, :$b }; add("4","1"); add(4.4e0, 2.3e0) 16:29
camelia coercing Str to Int
:a(4)
:b(1)
coercing Num to Int
:a(4)
:b(2)
ab5tract I guess I hadn’t ever clocked that dd was sent over $*ERR
Or if I had, I managed to forget it
Thanks lizmat 16:31
lizmat yw :-) 16:32
17:02 ggoebel joined
[Coke] blin run about 1/2 way done. 17:11
Might need to double up my
VM stats next release.
17:25 nine left, nine joined
[Coke] guessing we could improve the speed of Blin run if we kept track of known failures. (because if the new version fails, we test the old version - if it also fails, it's not a regression, but if we kept track of "old", there'd be less work to do. 17:37
crap. I was running with the wrong "new". 18:10
jdv, restarting Blin run right now. :| 18:12
Geth rakudo/main: de79080dcd | (Elizabeth Mattijsen)++ | 2 files
Some minor .trans optimizations

Re-imagined the Rakudo::Internals.EXPAND-LITERAL-RANGE method into a lexical sub inside the Str class, and removed the method.
Makes .trans up to 10% faster
Done while looking into #5488		 18:21
jdv wut? 18:26
doesnt it default to HEAD? 18:27
[Coke] yes, and I'm not using the defaults. 18:33
because I was rerunning so often last time, I didn't want to be changing what "new" meant each time. 18:34
how can I tell what whateverable has available to run? 59bfd7f6d isn't baked yet
linkable6 (2024-12-06) github.com/rakudo/rakudo/commit/59bfd7f6d3 Check positional .trans args earlier
jdv it'll work when its available?:) 18:41
[Coke] working my way back from HEAD, first few are 'not found' 18:42
jdv c: 59bfd7f6d say "foo" 18:44
committable6 jdv, ¦59bfd7f: «Cannot find this revision (did you mean “69dd7d6”?)»
[Coke] ah, that's a faster check than "running blin"
c: 998fccfb4 say 3
committable6 [Coke], ¦998fccf: «Cannot find this revision (did you mean “8bfb2c4”?)»
[Coke] c: 0911eca22 say 3 18:45
committable6 [Coke], ¦0911eca: «3␤»
[Coke] so maybe a day turnaround?
jdv++
there we go, restarted with correctish endpoints 18:48
18:49 ggoebel left
Geth ¦ rakudo: lizmat self-assigned [RakuDoc] Incomplete parsing of three markup codes github.com/rakudo/rakudo/issues/5721 18:49
¦ rakudo: lizmat self-assigned [RakuDoc] Line numbers in AST github.com/rakudo/rakudo/issues/5707 18:50
¦ rakudo: lizmat self-assigned [RakuDoc] Cannot recover `E<>` contents from AST with Deparse github.com/rakudo/rakudo/issues/5689
jdv its not a day. i think its relatively quick. at least it used to be. 18:52
ab5tract Would it make sense to keep a composable record of blin results, either in situ via json in the repo or else in a dedicated database? 18:54
I just can’t help feeling like the real value of any given “average” blin run is in spotting regressions. You only need to know what didn’t work last time for that, right? 18:56
[Coke] need to run everything against new - you could avoid running 'old' if you already knew those results. 19:00
... but we'd have to be careful as I imagine "old 19:01
" is typically a release while "new" is typically a commit a few days before the next tag
tha'ts easy to work with, just have to rmemeber.
ab5tract Indeed 19:02
But if we could somehow figure out how to keep the resource usage manageable we could theoretically run it weekly or something 19:03
jdv old can be bisect targets too. an "old cache" could be cool.
ab5tract Hmm
Sounds like a reasonable use of S3 :)
jdv well, not "old" but whatever
we only have hetzner resources afaik 19:04
ab5tract You mean in terms of “provided by The Foundation”? 19:06
[Coke] data storage is the cheap part compared to the cpu cost of doing the runs. 19:08
19:08 sena_kun joined
jdv yeah and yeah:) 19:10
since blin relies on the "mothership" for builds, maybe it makes sense to build that into the mothership?... 19:11
[Coke] (hetzner, aws) I'm running in azure right now (must remember to shut off the VM when done!)
jdv but that's currently hosted by alexdaniel
i left a crazy beefy aws vm running once and it cost way too much by accident 19:12
(that i used to use for blin runs)
[Coke] yah, I left mine running for a moth and doing nothing was about 200USD. 19:13
*month
m: 92/2248.say 19:15
camelia WARNINGS for <tmp>:
2248
Useless use of "/" in expression "92/2248.say" in sink context (line 1)
[Coke] m: say 92/2248
camelia 0.040925
19:24 sena_kun left, sena_kun joined
[Coke] m: say 133/2248 20:00
camelia 0.059164
[Coke] :sigh:
jdv that seems a bit slow
23:23 sena_kun left
[Coke] m: say 296 /2248 23:26
camelia 0.131673
[Coke] Yes, we knew it was slow. let me dig up the specs again.
8 vCPUs, 32 GiB RAM 23:27
running ubuntu 24.04
I'm using 5/32 G of memory, and only half the CPUs 23:32
load average: 3.71
.... I should run with a higher nproc. 23:34
... restarting 23:35
(I had it pinned at nproc=3 based on an earlier run with a less beefy VM) 23:36
load average up to 8+ on an 8 CPU 23:46
memory up slightly to 7.8 23:47
so hopefully about 2.5* faster this run 23:48

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!