Oh, just now I understand your previous point: we could simply order the files by their last modified time. The most recently modified is likely the one we should try first anyway. This seems like a very trivial change to make, I am on it.
On Tue, Jun 22, 2021 at 7:26 PM José Valim <jose.va...@dashbit.co> wrote: > > Still, is it not true that when recompiling <n> files, any compilation > error occurring at any point in the process will insure that all the <n> > files will have to be recompiled next time, for any kind of interdependence > of these <n> files? > > Correct. All I am saying is that the notion of Z being last is not > necessarily the case. In practice we likely have several files completing > about the same time. :) > > We spawn one process per file, correct, and the number of processes is > based on the number of cores. Indeed we could prioritize the file that > failed first, this seems considerably simpler than any kind of > checkpointing. It is mostly a matter of where to store this information? We > likely don't want to touch the manifest in case of failures. > > On Tue, Jun 22, 2021 at 7:18 PM Marc-André Lafortune < > marc-an...@marc-andre.ca> wrote: > >> I probably gave an overly simplified scenario. >> >> Still, is it not true that when recompiling <n> files, any compilation >> error occurring at any point in the process will insure that all the <n> >> files will have to be recompiled next time, for any kind of interdependence >> of these <n> files? >> >> Xavier Noria: thanks for your post. Do I read correctly that the number >> of processes involved depends on the number of cores? That sounds more >> tricky to implement than having one process per file to compile. If that's >> the case, files within a process could be prioritized (e.g. if they failed >> last time and/or by modification date), no? >> >> On Tuesday, 22 June 2021 at 12:31:30 UTC-4 José Valim wrote: >> >>> I mean, even the impression of ordering is wrong. The compiler is >>> running in parallel, so it may be that all of them are being compiled at >>> the same time and none of them actually completes. :) >>> >>> On Tue, Jun 22, 2021 at 6:27 PM Marc-André Lafortune < >>> marc-...@marc-andre.ca> wrote: >>> >>>> It is a separate topic, but I find that very frustrating also. >>>> >>>> Typical scenario: >>>> A is a compile-time dependency of a lot of files B to Z, which >>>> themselves are not dependencies of anything. >>>> 1) Change A >>>> 2) `mix compile` => compiles A, B, C, ... Y, and then produces an error >>>> in Z. >>>> 3) Fix Z >>>> 4) `mix compile` => recompiles A, B, C, ...Y and finally Z. If there is >>>> still an error, goto 3. A-Y should already be compiled. I haven't doubled >>>> checked, but it is my impression that the compiler doesn't prioritize >>>> latest modified file either? >>>> >>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/c42b3501-34f2-4eee-8d9b-70ac12a3a3e2n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/c42b3501-34f2-4eee-8d9b-70ac12a3a3e2n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BvURfu4wo61SM7CLE6u_8j06%2BNJGH-5GtgfvgerNoxFg%40mail.gmail.com.
