lizmat Files=1305, Tests=111213, 209 wallclock secs (28.59 usr 8.09 sys + 2935.00 cusr 268.24 csys = 3239.92 CPU) 07:52
rba hi 10:46
nine hi 10:53
rba patrickb: For the provided rakudo-moar-2020.02.1 binary builds is the gpg signature missing. 10:56
tellable6 rba, I'll pass your message to patrickb
bartolin hi #raku-dev. it looks like the jvm backend doesn't build anymore. this usage of nqp::null: github.com/rakudo/rakudo/commit/4e...c4395R4657 seems to cause in NullPointerException 12:17
lizmat vrurg ^^ 12:18
Geth rakudo: 40d41a3004 | (Vadim Belman)++ | src/Perl6/Actions.nqp
Fix JVM build

Don't use `nqp::null()` as a default for a symbol installed with
  `$*W.install_lexical_symbol()`.		 19:26
lizmat is surprised to see 10 calls to World.find_symbol_in_setting *every* time rakudo is started 19:36
one would think that after compiling the setting, these lookups would not be needed anymore ?
vrurg lizmat: I think it is mostly from locations where we must ensure that the symbol we get is really from the setting and is not overriden in user space. 19:39
lizmat but, if it is from the setting, we could look up the symbol at the end of setting compilation and Wval it ? 19:40
gist.github.com/lizmat/652ce95e720...21da974c20 # the symbols being looked up
vrurg First of all, I'm mistaken. find_symbol_in_setting is used when unit is not ready yet – and we can't just lookup lexicals. Second case is when symbol name is CORE::Something. 19:42
bartolin vrurg++ 19:46
bartolin is taking another attempt at providing a VMNull for the JVM backend 19:47
vrurg bartolin: though I should warn that JVM tests never pass on my macbook. If there're any other related problems I'm not even able to check them.
lizmat vrurg: but, when rakudo is started with raku -e '' , is the unit not already ready then ? 19:48
vrurg lizmat: '' is a compunit on it's own. One way or another, Grammar is parsing it. 19:49
lizmat ok, I get that... but the settings have already been loaded then... so we should know what "Mu" is then, no ? 19:50
vrurg lizmat: token comp_unit calls compunit_stage0/compunit_stage1 from World where it connects the setting and does a lot of other work. 19:51
lizmat: No, look at the end of comp_unit_stage1.
vrurg lizmat: Most correct would be to say that at the point Mu is requested cores are being connected already but the unit itself is still not ready. 19:53
lizmat: Don't have time to test it now, but looking into stage0/stage1, it looks like find_symbol can check not for $!unit_ready but for $!in_unit_parse. That's when settings should be fully available. 19:56
lizmat has to be afk for a few hours, will attempt to grok when I'm back 20:00
vrurg Ah, never mind. Setting is getting connected by lang-version token. So, $!in_unit_parse is too early.
lizmat: I have to leave for a couple of hours too. If you willing to test the difference, then you can try adding $!have_setting on World. Set it to 1 in comp_unit_stage1 after the `$/.unistart()` call. And check for $!have_setting in find_symbol. 20:05
lizmat: It did pass compilation for me. No time for more tests, unfortunately.
vrurg is afk too
travis-ci Rakudo build passed. Vadim Belman 'Fix JVM build 20:23
travis-ci.org/rakudo/rakudo/builds/659882652 github.com/rakudo/rakudo/compare/2...d41a30045d

Powered by Cro and the Raku® Programming Language.

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

Thank you!