[racket-dev] Compile cache being incorrect

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 <samth at 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
> <robby at 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.dobson at 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 <mflatt at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20140405/aa60a73e/attachment-0001.html>