[00:00] *** reportable6 left
[00:01] *** lucasb left
[00:02] *** reportable6 joined
[00:13] *** Kaiepi left
[00:52] *** pamplemousse joined
[01:54] *** pamplemousse left
[02:43] *** pamplemousse joined
[02:47] *** Kaiepi joined
[03:24] *** pamplemousse left
[06:00] *** reportable6 left
[06:02] *** reportable6 joined
[06:54] *** MasterDuke joined
[07:48] *** lizmat joined
[07:59] *** Ven`` joined
[08:31] *** chloekek joined
[09:13] <nine> timotimo: a use statement can change the language by its implicit BEGINness, so there's just no way to continue parsing until the statement is processed fully. OTOH you're trying to improve a rare situation anyway. The loaded modules should be precompiled already after all.

[09:14] <nine> Unless! You might say, we're talking about a developer working on some base module of his distro, where running the tests means precompiling a large number of modules that depend on the changed base module.

[09:16] <nine> It seems easier to optimize for this situation, because there are more things that work to our advantage. For example we probably know the full set of modules that may need re-compilation from a META6.json. And we can have the developer run some service in the background or include that in some test setup code.

[09:17] <nine> This service could watch files and run the compiler for all modules in the distro (in parallel of course - possibly even with a job server).

[09:18] <nine> And if you're thinking about a job server and dependencies and running compilers, you may as well use something that's already doing this well, like make.

[09:20] <nine> So all we need is something that records the dependency graph of a distro, writes it out into a Makefile, watches files for changes and starts make -j when appropriate.

[09:21] <lizmat> FWIW, I know from experience that currently in such a situation, with running tests in parallel, modules are precompiled more than once

[09:21] <lizmat> so maybe we need some locking at the file level making sure only one process is precomping something at a time

[09:28] <nine> lizmat: yes, I've noticed that, too. CompUnit::PrecompilationRepository::Default.precompile already uses a file lock so precomp processes don't step on each other's toes. I think the check if it still needs to precompile after it gained the lock may be broken.

[09:33] <lizmat> perhaps we need some in memory semaphore, if supported :-)

[09:33] <lizmat> I seem to recall implementing that as one of the Perl 5 functions

[09:44] *** lizmat left
[09:46] *** Ven`` left
[10:06] <nine> Ah, I think I understand. It's the logic in try-load: load the precompiled file or precompile with :force(did we fail to load because the precompiled file outdated?). There's just no code for the case when the precomp file was outdated but another process may have precompiled while we were waiting for the lock.

[10:06] <nine> Without the :force flag, we take whatever's there after gaining the lock.

[10:09] <nine> I'm not sure if the current control flow can somehow be extended with checks if the precomp file has become up-to-date while waiting or if it needs general restructuring

[10:16] *** chloekek left
[11:07] *** pamplemousse joined
[11:19] *** lizmat joined
[11:59] *** lizmat left
[12:00] *** reportable6 left
[12:04] *** reportable6 joined
[12:06] *** lizmat joined
[12:18] *** lizmat left
[12:19] *** lizmat joined
[13:16] *** rba joined
[13:27] *** lizmat left
[13:43] *** pamplemousse_ joined
[13:47] *** pamplemousse left
[13:58] *** chloekek joined
[14:05] *** Ven`` joined
[14:13] *** pamplemousse_ left
[14:34] *** lucasb joined
[14:48] *** Ven`` left
[16:15] *** pamplemousse joined
[16:20] *** pamplemousse left
[16:53] *** chloekek left
[17:42] *** chloekek joined
[17:54] *** Kaiepi left
[17:56] *** Kaiepi joined
[18:00] *** reportable6 left
[18:05] *** reportable6 joined
[18:17] *** zakharyas joined
[19:01] *** zakharyas left
[20:36] *** lizmat joined
[20:44] *** zakharyas joined
[20:51] *** lizmat left
[21:27] <Geth> ¦ MoarVM: cygx++ created pull request #1159: add MVM_vm_run_bytecode() as alternative to  MVM_vm_run_file()

[21:27] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1159

[21:42] *** AlexDaniel left
[22:03] *** AlexDaniel joined
[22:03] *** AlexDaniel left
[22:03] *** AlexDaniel joined
[22:04] *** zakharyas left
[22:15] *** Kaiepi left
[22:15] *** Kaiepi joined
[22:39] *** Kaiepi left
[22:40] *** Kaiepi joined
[23:00] *** Kaiepi left
[23:01] *** Kaiepi joined
[23:03] *** lucasb left
[23:44] *** chloekek left
