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
|