🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
moon-child 'in block at translate-tables.pm6' 02:38
nameless block!
Geth rakudo: d6be10ed2a | (Jonathan Worthington)++ | t/09-moar/00-misc.t
Test cover a segfault after trying to clone a Lock
10:41
rakudo: ff6951f590 | (Jonathan Worthington)++ | 2 files
Fix deprecation warning in rakudo-[gdb|valgrind]-m
[Tux] Rakudo v2021.09-251-gff6951f59 (v6.d) on MoarVM 2021.09-633-g1f00f12ab
csv-ip5xs1.420 - 1.646
csv-ip5xs-2016.189 - 17.279
csv-parser5.064 - 5.650
csv-test-xs-200.381 - 0.381
test7.569 - 8.177
test-t1.754 - 1.948
test-t --race1.096 - 1.227
test-t-2026.204 - 27.351
test-t-20 --race9.877 - 9.970
11:26
Note to self: do not run timing while crossover tries to install MicroSoft updates and Teams is active in a video-meet 11:27
ggoebel compiling from source... Found /raku/bin/moar version 2021.09-607-ge28e06ded, which is too old. Wanted at least 2021.09-624-ge733aef88 12:14
just pulled latest MoarVM 12:15
did a make clean, make, make install... so not sure how I'm using a version which is too old
sorry... got that error while compiling nqp 12:16
timo you need to Configure.pl as well 12:17
ggoebel thanks 12:20
ggoebel getting an interesting error which appears to be related to Inline::Python and precompilation... No such method 'EXISTS-KEY' for invocant of type 'BOOTHash'. Did you 13:36
mean any of these: 'EXISTS-KEY', 'EXISTS-POS'?
happens when a module uses two modules which both use Inline::Python
simplest case I could golf it down to is...
[Foo.rakumod] 13:37
use v6;
use Bar;
use Baz;
[Bar.rakumod]
use v6;
use Inline::Python;
unit class Bar;
[Baz.rakumod]
use v6;
use Inline::Python;
unit class Baz;
lizmat ggoebel: perhaps a gist and an issue ? :-) 13:38
ggoebel $ raku -MFoo -I./lib -e 'say "ok"'
===SORRY!=== Error while compiling -e
===SORRY!=== Error while compiling /home/ggoebel/git/test/lib/Foo.rakumod (Foo)
===SORRY!=== Error while compiling /home/ggoebel/git/test/lib/Baz.rakumod (Baz)
No such method 'EXISTS-KEY' for invocant of type 'BOOTHash'. Did you
mean any of these: 'EXISTS-KEY', 'EXISTS-POS'?
at /home/ggoebel/git/test/lib/Baz.rakumod (Baz):2
at /home/ggoebel/git/test/lib/Foo.rakumod (Foo):3
at -e:1
lizmat a gist with --ll-exception might be helpful :-)
ggoebel ok will do. 13:40
if I change the order of use statements to use Baz before Bar... it prints ok 13:41
The first run produces 11 precomp files
after changing the order of the use statements it produces 14 13:42
will put it all in a gist and open an issue
timo you can set RAKUDO_MODULE_DEBUG=1 to get info about precompilation and such 13:43
ggoebel odd that it suggests using 'EXISTS-KEY' after stating that no such method exists 13:44
timo: will try that. I don't know enough about the internals to know whether it is specific to precomp.
lizmat not really: the error message handling probably HLLizes the native hash, and lists its methods 13:45
ugexe wasn't someone else getting that error this last week?
lizmat somewhere, a hash is not being HLLized
ugexe: yes, feels familiar
ugexe gist.github.com/whatnext/87c22a266...2b01b610d3 13:46
ggoebel no additional information is output when RAKUDO_MODULE_DEBUG=1
my bad... yes it does 13:47
ugexe my guess based on the gist above was one of the nqp::hash objects in CU::RR
lizmat the problem appears to be in INDIRECT_NAME_LOOKUP 13:49
feels like one of the stashes has a native hash as a value? 13:50
ugexe no idea... it doesnt seem like anything really changed around those areas but i havent taken a good look at the new-disp changes
ggoebel If I remove "use Inline::Python;" from either Baz or Bar... the error also goes away 13:59
something about the second time Inline::Python is being loaded
gist.github.com/ggoebel/7831a0b226...6c84e7e164 14:02
ggoebel github.com/rakudo/rakudo/issues/4557 14:10
lizmat ggoebel++
ggoebel: do you know perchance whether that issue exists with Inline::Python? Or with any other module? 14:11
ggoebel Let me substitute Inline::Perl5 and see :-) 14:14
seems to be specific to Inline::Python. If I switch it to Inline::Perl5... no error 14:16
lizmat aha.. ok, thanks!
nine Inline::Perl5 has supported precompilation since 2019, but Inline::Python has never gained similar support 15:07
lizmat m: sub a() {}; say a.^ver # weird 19:44
camelia 6.c
lizmat m: use v6.d; sub a() {}; say a.^ver # weirder
camelia Don't know setting RESTRICTED
at gen/moar/ModuleLoader.nqp:249 (/home/camelia/rakudo-m-inst-1/share/perl6/lib/Perl6/ModuleLoader.moarvm:previous_setting_name)
from gen/moar/ModuleLoader.nqp:254 (/home/camelia/rakudo-m-inst-1/share/perl6/lib/…
lizmat ah, a Camelia artefact
locally that also says "v6.c" 19:45
anyways, calling .^ver on a sub feels to me that it should be an errior 19:46
*error rather :-)
moon-child isn't that calling ^ver on the value returned by the sub? 21:08
timo yeah 21:12
lizmat aahhh... yes, of course, and that's Nil 23:06
m: say Nil.^ver
camelia 6.c
timo and even if you did get the Sub, you'll get the version of Sub, not the version of a 23:07