Yes, Sam. I don't think anyone is happy with the status quo. Perhaps the tradeoffs have changed since last time a careful investigation happened.
Robby On Saturday, April 5, 2014, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > 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 > <ro...@eecs.northwestern.edu> wrote: > > raco make x.rkt && racket x.rkt > > > > Robby > > > > > > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson <eric.n.dob...@gmail.com> > > 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 <mfl...@cs.utah.edu> > 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? >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
