But if you mean that if 10 files need to be compiled, then 1 fails, then all 10 have to be compiled again, then that's correct. There are compiler passes that need to run on all modules, such as undefined function warnings, so we can't save intermediate files without introducing reasonably complex checkpoints.
On Mon, Jun 21, 2021 at 5:06 PM José Valim <jose.va...@dashbit.co> wrote: > I can't reproduce it. I introduced a syntax error: > > ~/ML/livebook[jv-eval-compile]$ mix test > Compiling 1 file (.ex) > > == Compilation error in file lib/livebook_cli.ex == > ** (ArithmeticError) bad argument in arithmetic expression > lib/livebook_cli.ex:1: (module) > (stdlib 3.15) erl_eval.erl:685: :erl_eval.do_apply/6 > > Then I fixed it: > > ~/ML/livebook[jv-eval-compile *]$ mix test > Compiling 1 file (.ex) > > ................................................................................................................................................. > > On Mon, Jun 21, 2021 at 5:03 PM Zach Daniel <zachary.s.dan...@gmail.com> > wrote: > >> This question may be tangentially related, but I'll bring it up here: >> It seems that, even if it is just the last module that has to compile >> that fails, nothing is cached/saved, and on subsequent compilations, the >> entire application will need to be recompiled. I'm unsure if there are >> technical limitations that cause that to be true, though. >> >> On Monday, June 21, 2021 at 10:01:56 AM UTC-4 Allen Madsen wrote: >> >>> +1 >>> >>> I've noticed mtime changes in some scenarios related to CI and docker, >>> that causes things to be recompiled again even though there's no other >>> change to the files. >>> >>> Allen Madsen >>> http://www.allenmadsen.com >>> >>> >>> On Mon, Jun 21, 2021 at 3:29 AM Marc-André Lafortune < >>> marc-...@marc-andre.ca> wrote: >>> >>>> >>>> >>>> On Mon, Jun 21, 2021 at 2:54 AM José Valim <jose....@dashbit.co> wrote: >>>> >>>>> Hi Marc-André! >>>>> >>>>> There is no particular reason, this is a functionality that could be >>>>> added. In particular we can continue checking the mtime and file size but >>>>> compare the contents if the mtime changed but the file size is the same. >>>>> >>>> >>>> Yep 👍 >>>> >>>> >>>>> I also think we should update the mtime anyway, even if the hash is >>>>> the same. WDYT? >>>>> >>>> >>>> Yes, otherwise we might keep re-hashing the file over and over again. >>>> >>>> >>>>> Feel free to open up an issue or, if you want to tackle it, even send >>>>> a PR! >>>>> >>>> >>>> Awesome. I'll check if I can come up with a PR in the next few days, >>>> and if not I'll create an issue. >>>> >>>> Thanks. It's so awesome to get such quick feedback 💛 >>>> >>>> >>>>> >>>>> Thanks! >>>>> >>>>> On Mon, Jun 21, 2021 at 8:20 AM Marc-André Lafortune < >>>>> marc-...@marc-andre.ca> wrote: >>>>> >>>>>> I'm a newbie, sorry if this has been asked before but I couldn't find >>>>>> anything. >>>>>> >>>>>> Currently, elixir uses last modification dates to determine files >>>>>> that need to be recompiled. >>>>>> >>>>>> ``` >>>>>> $ mix compile >>>>>> # ... >>>>>> $ touch lib/some/file.ex >>>>>> $ mix compile >>>>>> Compiling <n> files (.ex) >>>>>> ``` >>>>>> >>>>>> Could Elixir not verify that in addition to a modification time >>>>>> change, that the actual text content has changed by comparing a hash of >>>>>> it? >>>>>> In the example above, the file `lib/some/file.ex` would be hashed a >>>>>> second >>>>>> time, but no recompilation would occur. >>>>>> >>>>>> Currently, many operations may change the last modification date even >>>>>> if no content at all has changed: >>>>>> * switch to a different branch, switch back >>>>>> * do an interactive rebase: >>>>>> - to rewrite a commit message, >>>>>> - to reorder some commits >>>>>> - to squash some commits together >>>>>> - etc. >>>>>> >>>>>> While the content of the files does not change (at all) in these >>>>>> examples, some very long recompilations may occur because elixir only >>>>>> relies only on modification times and not on file hashes. >>>>>> Hashing a file is orders of magnitude faster than compiling it, and >>>>>> realizing that the potentially large number of compile-time dependencies >>>>>> of >>>>>> a given file do not need to be recompiled is infinitely faster than >>>>>> recompiling them all for nothing. >>>>>> >>>>>> I am presuming that hash collisions are deemed so incredible unlikely >>>>>> to be acceptable, but if not, then I'd ask the same question but with >>>>>> using >>>>>> the complete content of the source file instead of a hash of it. Copying >>>>>> a >>>>>> source file is again an order of magnitude faster than the time it takes >>>>>> to >>>>>> recompile it. >>>>>> >>>>>> -- >>>>>> 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-co...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "elixir-lang-core" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/elixir-lang-core/8-30JVn_8M0/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> elixir-lang-co...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.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-co...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CADwvmaWP%2BccDF9QRdDfL8_B8fXuFXeFSL-fV0vLgOVqFH8LiHw%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CADwvmaWP%2BccDF9QRdDfL8_B8fXuFXeFSL-fV0vLgOVqFH8LiHw%40mail.gmail.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/93dc87b6-6d61-43b9-81aa-5b740a525f15n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/93dc87b6-6d61-43b9-81aa-5b740a525f15n%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%2BX6YGaQRT2_by3YKcOq_QjySn2EKf96p%3D4Op-ozbKg3A%40mail.gmail.com.
