|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
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
|
|||
| 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:13 | |
| 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:14 | ||
| 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:16 | ||
| 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:17 | ||
| 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:18 | ||
| 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:20 | ||
| 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 | |
| so maybe we need some locking at the file level making sure only one process is precomping something at a time | |||
| 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:28 | |
| lizmat | perhaps we need some in memory semaphore, if supported :-) | 09:33 | |
| I seem to recall implementing that as one of the Perl 5 functions | |||
|
09:44
lizmat left
09:46
Ven`` left
|
|||
| 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 | |
| Without the :force flag, we take whatever's there after gaining the lock. | |||
| 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:09 | ||
|
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
|
|||
| Geth | MoarVM: cygx++ created pull request #1159: add MVM_vm_run_bytecode() as alternative to MVM_vm_run_file() |
21:27 | |
|
21:42
AlexDaniel left
22:03
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
22:04
zakharyas left
22:15
Kaiepi left,
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
|
|||