Yes, Sam. I don't think anyone is happy with the status quo.<div> </div><div>Perhaps the tradeoffs have changed since last time a careful investigation happened. </div><div> </div><div>Robby On Saturday, April 5, 2014, Sam Tobin-Hochstadt <<a href="mailto:samth@cs.indiana.edu">samth@cs.indiana.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think this is a good answer for Racket. Certainly the docs don't say that you need to always do this if you want your program to work right. If Racket doesn't work right in the presence of stale compiled filed, then it should just error in those cases, rather than doing the wrong thing. Of course it would be better to work correctly in that case, but this is a hard problem, and it's reasonable to not have a solution. But having the system act like it works when it doesn't is worse. Sam On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler <<a>robby@eecs.northwestern.edu</a>> wrote: > raco make x.rkt && racket x.rkt > > Robby > > > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson <<a>eric.n.dobson@gmail.com</a>> > wrote: >> >> Great that explains it and with that information I was able to >> simplify my test case to >> >> tmp.rkt >> #lang racket >> >> (require "tmp2.rkt") >> >> (define-syntax (go stx) >> (foo)) >> >> (go) >> >> tmp2.rkt >> #lang racket >> >> (provide (for-syntax foo)) >> >> (begin-for-syntax >> (define (foo) #'3)) >> >> So now the question is how do I run my code so as to not be bit by >> this? I want a command to run my program that is both fast to run and >> correct with regards to my source. My previous assumption was that the >> zo file's logic was safe if I wasn't trying to break it but I now know >> better. Is my only option to either always compile or never compile? >> >> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt <<a>mflatt@cs.utah.edu</a>> wrote: >> > If I understand the question: >> > >> > * With 34c3eed615, "pr12644.rkt" can compile and run. >> > >> > * With d29df205f7, "pr12644.rkt" fails to compile. >> > >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can still >> > run in d29df205f7, because run-time support for "pr12644.rkt" didn't >> > change. >> > >> > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" for >> > each of "pr12644.rkt" and its dependencies as long each individual >> > ".zo" file has a newer timestamp than its ".rkt" file. That is, the >> > only timestamp comparisons are on individual ".rkt" and ".zo" pairs. >> > >> > * When you tell `raco make` to build "pr12644.rkt", it checks >> > dependencies (via ".dep" file) and compares a ".rkt" file's >> > timestamp against the times of all of its dependencies, instead of >> > just checking individual ".rkt" and ".zo" pairs. That's why a `raco >> > make` in d29df205f7 tries to recompile "pr12644.rkt". >> > >> > At Thu, 3 Apr 2014 09:41:19 -0700, Eric Dobson wrote: >> >> I have seen multiple times changes in TR not getting properly >> >> propogated to TR programs in my debugging, and I finally have found a >> >> repeatable example. >> >> >> >> I am under the impression that if I compile a file and then change a >> >> (transitive) dependency of it, then it should have to be recompiled, >> >> but I am not seeing that. >> >> >> >> Steps to reproduce: >> >> git checkout 34c3eed6155765a1e457f69194786575128a13a5 >> >> raco setup -D typed-racket typed >> >> raco make >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> >> >> The test should run successfully and output '(6 7 8 9) >> >> >> >> Now make the change (rolling forward one commit): >> >> git checkout d29df205f7bb8347f60c82206b74e3e167e2de24 >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> raco make >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> >> >> The test runs the first time successfully but fails if you try to >> >> compile it again. Can someone explain why this is not working like I >> >> expect? </blockquote></div>