🦋 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.
releasable6 Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
07:58 sena_kun joined 08:09 MasterDuke left 08:35 sena_kun left 11:21 lizmat_ joined 11:24 lizmat left 11:25 lizmat_ left, lizmat joined
lizmat `ok, finally able to look at github.com/lizmat/App-Rak/issues/6...2303793077 11:32
the stack trace is *really* weird, as the only hash involved in the .^find_method call, is the *%_ in the signature of Perl6::Metamodel::MROBasedMethodDispatch.find_method 11:34
so is *%_ or %_ somehow global? nine any idea? 11:35
guess I'll need to look at the signature binder to find out
and the NQP one 11:38
nine certainly not 11:41
11:41 lizmat_ joined 11:42 lizmat_ left, lizmat_ joined 11:44 lizmat left, lizmat_ left, lizmat joined 13:09 finanalyst joined
ab5tract lizmat: is it locally reproducible? I wonder if this could be a spesh issue.. 13:12
lizmat no reproduction so far
timo there are barely any uses of MVM_str_hash_fetch_nocheck in moar 13:15
MVM_sc_find_by_handle uses it 13:18
oh, ok, MVM_str_hash_fetch calls into MVM_str_hash_nocheck
that probably explains it then
14:07 finanalyst left
ab5tract So a race condition then? 14:59
lizmat yes, but a weird one: it's complaining about hash accesses, but the only hash I see there is *%_ in the signature 15:00
ab5tract Isn’t there a hash underneath the match object? 15:04
lizmat hmmmm 15:05
actually, there can be many hmmm good point 15:06
Geth rakudo/main: fd9cd0a5c8 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix .rak / deparsing issue with "is type"
 15:49
rakudo/main: c1520df7cd | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod
RakuAST: make highlighting more resilient

Basically, look at any error seen, and attempt to work around that by adapting the source, ASTing that, and then remove the additional AST objects before deparsing again. Handled are:
  - undefined variables (by prefixing "no strict")
  - undefined types / classes (by prefixing "my class foo { }")
  - undefined subroutines (by prefixing "sub foo (|) { }")		 16:06
timo a c-level backtrace might be interesting for the oops in question 16:07
hey i wonder how much work it is to get libunwind into your program ...
now how do i oops moar most easily ... 16:36
[Coke] heh. similar tricks to the "does this code compile" script in raku/doc 16:46
we hardcoded a bunch of preambles for code - if we could adapt the dynamic retries you're doing here, could reduce a lot of misc crap from raku/doc 16:50
lizmat [Coke]: where should I look ? 17:15
timo gist.github.com/timo/34e8671452273...19d792eeeb this is what it could look like 17:25
lizmat looks nice 17:29
17:35 sena_kun joined
lizmat [Coke]: xt/examples-compilation.rakutest I presume 17:40
?
[Coke] sorry, had stepped away, yes. 17:47
lizmat ok I looked at that... I don't immediately see cases that I could cover in the same manner 17:48
e.g. this thing about WHAT ?
and why multi sub should be a problem? 17:49
[Coke] Sorry, wasn't suggesting it was stuff you could adapt, I'm saying I can adapt what you just did there to make my code less verbose. 17:50
was basically just saying "Neat!". :)
lizmat ah, ok... :-)
it should make finanalyst's work easier 17:51
Geth ¦ rakudo: lizmat self-assigned [Rakuast highlighting] Post comments fail, pre comments highlight github.com/rakudo/rakudo/issues/5629 17:52
¦ rakudo: lizmat self-assigned [Rakuast-highlighting] Highlighting of undeclared sub github.com/rakudo/rakudo/issues/5628
lizmat bisectable6: /./; "no worries; if False \{\nclass :: \{\n;\n/a b/\n\n}}".EVAL; 18:06
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/ac180c677c9cdd526a...a53bf287cd 18:07
lizmat, Bisecting by output (old=2018.12 new=2019.03.1) because on both starting points the exit code is 0
[Coke] heh, was just about to do that. :)
bisectable6 lizmat, bisect log: gist.github.com/95e518c72abb5948de...69b32ee9fc 18:08
lizmat, (2019-01-14) github.com/rakudo/rakudo/commit/1c...fba874a8cd
lizmat, Output on all releases and bisected commits: gist.github.com/768419cc92632d1d11...96e00c6daa
lizmat looks like it got fixed -)
[Coke] Nice. I'll close the ticket.
lizmat++ nine++ 18:09
Geth rakudo/main: 5c532a3e20 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod
RakuAST: fix various issues with highlighting

  - fix comment highlighting #5629		 18:31
18:44 librasteve_ joined
timo got libunwind hooked up to also understand how to unwind a moar jit frame (same gist was updated) 19:07
[Tux] Rakudo v2024.07-211-g5c532a3e2 (v6.d) on MoarVM 2024.07-13-g5e52422f4
csv-ip5xs0.257 - 0.257
csv-ip5xs-201.117 - 1.161
csv-parser1.517 - 1.528
csv-test-xs-200.142 - 0.143
test1.851 - 1.864
test-t0.403 - 0.417
test-t --race0.273 - 0.276
test-t-204.946 - 4.974
test-t-20 --race1.178 - 1.232
 19:42
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
timo updated the libunwind gist: oops and panic now show a bit of bytecode around the current instruction on the topmost stack frame if it's not a jit frame 20:51
21:23 sena_kun left 22:54 librasteve_ left
releasable6 Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
23:43 MasterDuke joined
MasterDuke timo: i really like that libunwind output. could we easily add it as a debug option to moarvm? 23:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!