MasterDuke timo: any reason not to merge the runc pr? 00:02
timo it's proooobably OK to merge? maybe a spectest / stresstest with SPESH NODELAY and BLOCKING first though ... 00:05
> 00:06
Too young, only 3 of 5 days old
only a matter of time
MasterDuke what about the todo for when the number of elems is known-but-not-0? 00:11
timo someone can do that at some point 00:12
MasterDuke tons of failed spectests with `MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1` at head of main moarvm/nqp/rakudo 00:17
timo welp, that's not great
MasterDuke gist.github.com/MasterDuke17/f7931...159de837c7 00:20
hm...wait... 00:21
that might not be correct 00:22
afk for a while, but will re-run that during 00:23
timo today while napping i was dreaming of a much shinied up spec test runner
i'm also wondering how much time we could save if we prefork an instance that has already run through at least a little cross-section of the parser, compiler, optimizer 00:25
and of course it has to give better details than "non-zero exit status" when something goes south 00:26
00:31 rypervenche left
[Coke] timo: like the JVM runner? 00:38
but for moarvm?
00:58 ab5tract left 01:01 ab5tract joined
MasterDuke huh. those results seem correct 01:52
[dan@alexandria rakudo]$ ./rakudo-m -I lib t/spec/S05-modifier/exhaustive.t 01:53
1..104
Iteration past end of grapheme iterator
  in block <unit> at t/spec/S05-modifier/exhaustive.t line 29
# You planned 104 tests, but ran 0
does that fail when run completely unmodified for anybody else?
m: my $str = "abrAcadAbbra"; say $str ~~ m:i:exhaustive/ a .+ a / 01:56
camelia (｢abrAcadAbbra｣ ｢abrAcadA｣ ｢abrAca｣ ｢abrA｣ ｢AcadAbbra｣ ｢AcadA｣ ｢Aca｣ ｢adAbbra｣ ｢adA｣ ｢Abbra｣)
MasterDuke huh. locally i get `Iteration past end of grapheme iterator`
i double checked i'm on main and rebuilt everything, but i must have some bad precomp file from when i was working on my remove-repetitions-from-MVMString branch 01:57
hm. remove all .precomp directories and still same thing 02:00
just rebuilt all three and still the same 02:06
ugh. a clean checkout of rakudo built with `--gen-nqp --gen-moar` works fine. so some(where|how) rebuilding my normal setup isn't overwriting something 02:18
only one fail in the clean checkout for `MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 make m-spectest` 02:58
t/spec/S09-typed-arrays/native-shape1-num.rakudo.moar       (Wstat: 256 (exited 1) Tests: 333 Failed: 1)
  Failed test:  237
  Non-zero exit status: 1
07:37 [Tux] left 07:41 [Tux] joined
timo under some circumstances, when a moar/nqp/rakudo is still running, it can prevent "make install" from overwriting the binary 10:33
lizmat notable6__: weekly 11:59
notable6__ lizmat, 3 notes: gist.github.com/eee7548a8ae7dcde1d...22c40316e5
lizmat notable6__: weekly reset 12:14
notable6__ lizmat, Moved existing notes to “weekly_2024-09-10T12:14:44Z”
14:08 MasterDuke left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/09/10/2024-...hlighting/ 15:55
16:24 finanalyst joined
Geth ¦ rakudo: lizmat self-assigned [rakuast-highlighter] Formating different uses of '{' github.com/rakudo/rakudo/issues/5640 16:26
timo lizmat: "a CVE for minilua that potentially affected MoarVM" i would downgrade the severity of that statement by a few notches tbh 16:52
lizmat how would you phrase it then 16:53
timo "a CVE in minilua that is unlikely to affect MoarVM" maybe? 17:00
lizmat so done 17:01
Geth rakudo/main: 7ddaf755f8 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod
RakuAST: partial fix for postcircumfix:<{ }> highlighting

  ::SemiList has its own deparsing logic. It is a subclass of ::StatementList.
The Highlight module injects its own handling for ::StatementList, shadowing the handling of ::SemiList.
Fix by adding a Highlight candidate for ::SemiList, that just does what it is supposed to do.		 17:23
21:44 tellable6 left, tellable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!