Rob Browning wrote: > In the past I'd noticed that guile appeared to be running stale code, > and I finally got a chance to track it down with help from Dale Smith. > > The cause is that filesystems have finite (and sometimes quite coarse) > timestamp "granularity", and guile currently treats equal timestamps > between a .scm file and .go file as meaning that the .go file is up to > date, i.e. represents the compilation of the code in the .scm > file. Right now that is not always true, and can produce undesiarable > results: > > For example, if you do this: > > echo '(display "something bad\n")' > test.scm > guile test.scm > echo '(display "the (broken) fix)' > test.scm > guile test.scm
This is an artificial example. In what situation did you encounter this issue? I am wondering if it is easier to fix that situation instead of submitting this patch. > The final guile invocation may actually succeed while printing > "something bad" if the test.go generated by the first guile invocation > ends up with the same timestamp as the one with the fix. It's not even > relevant that the fix is actually itself broken (invalid syntax) because > guile never attempts to compile it --- it just runs the "bad" test.go. > > To fix this, we can change compiled_is_fresh in load.c to require the > .go to be strictly newer than the corresponding .scm, i.e. change the <= > to < here: If you do that, you will break a lot of Guile Autotools projects whose object files currently have >= timestamps to sources. See for example <https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00125.html>, which explains an Automake hack to establish object timestamp >= source timestamp. To obtain a strict inequality, a sleep command would further need to be used (as discussed there), but currently autotools projects do not do this and will break with your patch. Regards, Nikolaos Chatzikonstantinou
