00:13 hungrydonkey joined 00:22 hungrydonkey left 01:49 Altai-man_ joined 01:52 sena_kun left 03:04 benlittle left 03:08 leont left 03:50 sena_kun joined 03:52 Altai-man_ left 04:52 releasable6 left, bisectable6 left, shareable6 left, quotable6 left, notable6 left, greppable6 left, benchable6 left, bloatable6 left, sourceable6 left, reportable6 left, squashable6 left, evalable6 left, tellable6 left, committable6 left, coverable6 left, statisfiable6 left, linkable6 left, nativecallable6 left, unicodable6 left 04:53 notable6 joined, quotable6 joined, shareable6 joined, nativecallable6 joined, evalable6 joined, benchable6 joined, squashable6 joined 04:54 coverable6 joined, committable6 joined, bisectable6 joined, greppable6 joined, unicodable6 joined 04:55 tellable6 joined, reportable6 joined, linkable6 joined, sourceable6 joined, statisfiable6 joined 04:56 releasable6 joined, bloatable6 joined 05:28 ZzZombo_ joined 05:31 ZzZombo left, ZzZombo_ is now known as ZzZombo 05:50 Altai-man_ joined 05:52 sena_kun left 06:06 epony left 07:51 sena_kun joined
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
07:52 Altai-man_ left 09:50 Altai-man_ joined 09:53 sena_kun left
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
11:24 ufobat joined 11:47 Kaiepi joined 11:51 sena_kun joined 11:53 Altai-man_ left 12:03 Kaiepi left 12:09 Kaiepi joined
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
13:26 leont joined 13:50 Altai-man_ joined 13:53 sena_kun left 14:58 lucasb joined 15:51 sena_kun joined 15:53 Altai-man_ left 16:39 benlittle joined 16:59 Xliff left 17:14 ufobat left 17:50 Altai-man_ joined 17:53 sena_kun left 18:14 domidumont joined 19:07 sena_kun joined 19:09 Altai-man_ left 19:14 domidumont left
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
19:44 ufobat joined, Ven`` joined
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
19:48 cognominal joined
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.
19:51 cognomin_ left
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
20:23 travis-ci joined
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
20:23 travis-ci left 21:06 Altai-man_ joined 21:08 sena_kun left 22:52 sena_kun joined, Ven`` left 22:53 Altai-man_ left 23:57 lucasb left