00:16 Voldenet left 00:18 Voldenet joined 01:06 Voldenet left 01:09 Voldenet joined
[Coke] jdv: you do anything with the long running hanging tests? 02:06
I have 4 .t's that are showing times of nearly 2h 02:07
jdv investigate and kill 02:24
normally its just 1 or 2 02:25
[Coke] ⏳ 2233 out of 2249 modules processed 02:44
jdv so close 02:55
[Coke] gist.github.com/coke/0a5f70703ba4f...ailures-md - finally got a run that completed. 03:09
jdv cool 03:10
you had no fails? 03:11
[Coke] | Flapper | 1 | InstallableButUntested | 7 | ZefFailure | 12 | UnhandledException | 16 | CyclicDependency | 17 | MissingDependency | 21 | AlwaysFail | 736 | OK | 1439 03:12
jdv but there is no "Fail" count so that's normally "no regressions" 03:14
iirc
[Coke] ... weird; I should have gotten the same results you did 03:15
jdv race conditions?
its normal for stuff to fail under blin and be fine outside so that's my best guess 03:16
super odd though that we were that different
04:31 japhb joined 06:00 japhb left 07:29 sena_kun joined 07:38 sena_kun left 11:52 sena_kun joined
lizmat bisectable6: old=2024.10 my int @a = ^10; dd @a[5..*] 11:53
bisectable6 lizmat, On both starting points (old=2024.10 new=0911eca) the exit code is 0, exit signal is 1 (SIGHUP) and the output is identical as well 11:54
lizmat, Output on both points: ««timed out after 10 seconds»»
Geth rakudo/main: 65ec7f303c | (Elizabeth Mattijsen)++ | 3 files
Fix issues with slices with N..* ranges

Commit a4b87c9 throws earlier than before, and this caused some ecosystem fallout. This was because any unbounded ranges would simply stop on encounter with the first element that didn't exist.
This commit fixes that by adding an implementation-detail method ... (13 more lines)		 13:13
lizmat bisectable6: old=2024.10 dd 1400.polymod(256 xx 7).reverse 13:19
bisectable6 lizmat, Bisecting by output (old=2024.10 new=0911eca) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/593ba0249852a94a92...d830789690
lizmat, (2024-10-25) github.com/rakudo/rakudo/commit/c8...636a8364b0
Geth rakudo/main: c6872fb036 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.rakumod
Fix issue with .polymod and fixed number of divisors

Commit c81d9cf changed the behaviour of .polymod with regards to handling values if 0 was encountered: it would *always* stop producing values, rather than continuing until there were no more divisors. Which caused the problems shown in #5726.
... (6 more lines)		 14:06
[Coke] getting that heap corruption error in the REPL daily 14:50
lizmat [Coke]: using Terminal::LineEditor ? 14:53
[Coke] the REPL doesn't tell me what it's using when it launches. 14:55
that is installed, though
lizmat are you on HEAD or on 2024.10 ? 14:56
[Coke] Terminal::LineEditor:ver<0.0.17>:auth<zef:japhb>
2024.10
lizmat ok, then I suggest uninstalling Terminal::LineEditor and installing Linenoise until 2024.12
[Coke] ok. 14:58
just wanted to raise the flag in case it was a raku thing. Thanks
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
timo did we already get a new release of Terminal::MakeRaw with the fix in it? 15:01
[Coke] jdv - I'll try to run a subset of the blin run to see if I can figure out why the ones you're showing as errors aren't showing as errors here.
lizmat timo: no, patrickb wanted a proper fix 15:09
since the issue is on MacOS only, and then only with Terminal::LineEditor, it felt ok to me to get patrickb to make a proper fix 15:10
patrickb I'll do a last T::MR release. It's obviously annoying people. Which dependent module are most needed? Only T::LE? 15:11
lizmat yes, afaik
patrickb (T::Printer is the other one) 15:12
timo i would call it more than just "annoying" though? 15:14
it crashes :)
Geth rakudo/main: a01021a945 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.rakumod
Fix stupid typo
 15:17
15:24 japhb joined
jdv lizmat: thanks 16:24
[Coke]: ok, cool
lizmat sadly, polymod issue not fixed yet :-(
but close to it
jdv i guess if abstract can't fix that one we'll revert
ah
lizmat m: dd 12.polymod(14) 16:29
camelia (12, 0).Seq
lizmat m: dd 12.polymod(lazy 14,)
camelia (12, 0).Seq
lizmat that should be (12,).Seq 16:30
jdv: fwiw, this is an edge case, the modules affected in blin should be fixed 16:31
jdv the repl thing? 16:32
lizmat no, the modules affected by polymod changes 16:33
the repl thing only affects: MacOS && Terminal::LineEditor
any other OS or other module providing editor functions, and you're ok
jdv no, that's what Jupyter::Chatbook tripped over in the blin run 16:34
lizmat ah?
ah, then that may also use the underlying ::TerninalRaw module somehow
patrickb said he was going to do an update of that 16:35
jdv anyway, you're saying Digest, Digest::HMAC, EC, PBKDF2 all need to change?
lizmat nope, they should be ok now
fwiw, I only checked Digest, but that was a dependency of the other 3
jdv didn't you just say the polymod affected modules should be fixed? now i'm confused. 16:36
lizmat Digest cs were the ones affected by polymod
jdv ok 16:37
lizmat re polymod issue: fixed it in a local script, but fails again when in core setting 16:38
so now I'm debugging that, which is much slower due to 1+ minute compilation cycle
jdv faster than my box 16:39
lizmat ok, looks like the iterator on "lazy 14," somehow becomes non-lazy :-( 16:47
jdv if someone could help me "somehow become non-lazy" i'd appreciate it:) 16:48
lizmat hehe 16:49
.oO( don't be too eager :-)
 16:50
grrr found the cause in List::Todo: 16:52
method is-lazy() { $!todo.DEFINITE && $!todo.is-lazy }
I think that's another issue: I'm going to alter the failing test for now 16:55
patrickb @ [Coke], lizmat, whoever: Can someone give git.sr.ht/~patrickb/Terminal-MakeRaw a quick try on MacOS? 17:14
I'd like to be sure it's working before I make a release. 17:15
Geth rakudo/main: 818a543a4e | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.rakumod
Fix remaining issue with polymod

Commit c6872fb036 fixed several modules, but broke one polymod test
   12.polymod(lazy 14,)
which should produce (12,).Seq because of the lazy iterator. ... (10 more lines)		 17:18
roast: cc990cb369 | (Elizabeth Mattijsen)++ | S32-num/polymod.t
Fix polymod test

In light of github.com/rakudo/rakudo/commit/818a543a4e		 17:19
[Coke] [Terminal-MakeRaw] Dynamic variable $*DISTO not found
(running zef test . from git) 17:20
with that fix, 'zef test .' is OK 17:21
... but there's not of a lot of test - is there a sample or something I can run to see the desired behavior? 17:22
README should probably say "In contrast" instead of "I contrast" 17:23
patrickb: ^^
patrickb you'll have to run the repl and try to make it fail while -I ing that module 17:36
[Coke] that seems complicated. :) 17:37
my previous failures were not reproducable, just common 17:38
perhaps we go with "tests pass" once that typo is fixed.
Geth rakudo/main: 7e5e210fe8 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Revert "Fix issue introduced with 8365a5deb4"

This reverts commit 4082d2c707cebcf496b0b974204b238436bcaa35.
Revert this commit for the 2024.12 release. It will return later as a part of a more extensive rework of .trans after 2024.12 release		 18:03
patrickb Do the tests fail without the commit implementing MacOS support? 18:04
lizmat jdv: looking at Format::Lisp one now 18:23
jdv thanks 18:24
Geth App-MoarVM-Debug/main: 5 commits pushed by slid1amo2n3e4++
Format-Lisp/main: 6ca5a013d0 | (Elizabeth Mattijsen)++ | 82 files
CI test for a 0.0.3 release
 18:32
[Coke] no, the tests pass at both HEAD and HEAD^1 18:34
(with the typo fix at HEAD)
looks like the tests are only really checking compilation and that a method can be called (not that it does a thing) 18:35
lizmat bisectable6: old=2024.10 my $a = "foo"; $a.substr-rw(*-2,0) = "zip" 18:38
bisectable6 lizmat, Bisecting by exit code (old=2024.10 new=0911eca). Old exit code: 0
lizmat, bisect log: gist.github.com/8d35ccfb0ba7cec119...4da45fff84
lizmat, (2024-10-26) github.com/rakudo/rakudo/commit/61...6ffc4fe13c
18:50 japhb left
Geth Format-Lisp/main: f1069ae220 | (Elizabeth Mattijsen)++ | 2 files
0.0.3
 18:53
rakudo/main: 0ceb4be2e1 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Fix support for .substr-rw(Callable, x)

Apparently that case was forgotten in 6182ed5, as was spotted in #5726. This commit adds that support again		 19:04
lizmat jdv: only blocker is Jupyter::Chatbook now, with the cause already known, right? 19:06
jdv more or less. anton is gonna look at it soon. 19:08
later today iirc
lizmat ack so I won't be spending any time on that now
jdv yup, thanks 19:09
Geth roast: 043f39d850 | (Elizabeth Mattijsen)++ | S32-str/substr-rw.t
Add test for .substr-rw(Callable, x)

As spotted in github.com/rakudo/rakudo/commit/0ceb4be2e1		 19:13
21:03 vrurg left
bartolin lizmat: I saw that you worked on polymod. In case you didn't notice, maybe you could give github.com/rakudo/rakudo/pull/5712 a quick look? It has a conflict now, but I wonder if I should propose the change for the JVM backend only. 21:09
21:28 vrurg joined
[Coke] github.com/Raku/Blin/blob/master/l...kumod#L476 - where does the $CONFIG here come from?? 21:44
ah, whateverable::config 21:46
jdv: what commit of blin are you on? 21:47
22:38 sena_kun left
jdv maybe 84790935b9e4 23:27
linkable6 (2024-01-21) github.com/Raku/Blin/commit/84790935b9 Various updates
jdv there's no .git in the container. but my wc is at that commit so that's my best guess. 23:28
[Coke]: ^ 23:29
afk though

Powered by Cro and the Raku® Programming Language.

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

Thank you!