<div dir="ltr">Altho if someone wanted to improve this somehow (make macro expansion faster? Find better ways to exploit parallel hardware?) then that would be really awesome.<br><br>Robby<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Apr 5, 2014 at 10:38 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That sounds difficult. <div class="HOEnZb"><div class="h5"><span></span><br><br>On Saturday, April 5, 2014, Eric Dobson <<a href="mailto:eric.n.dobson@gmail.com" target="_blank">eric.n.dobson@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also this is a poor solution for me because `raco make` compiles all<br>
the dependencies serially. I have also tried doing 'raco setup -D' for<br>
the packages I am dependent on but that has the issue of compiling<br>
everything in those packages which is over kill (and thus slower than<br>
needed).<br>
<br>
My end goal is a very fast edit/test loop (~100ms), which may be<br>
impossible but I want to be aggressive.<br>
<br>
<br>
On Sat, Apr 5, 2014 at 8:14 AM, Robby Findler<br>
<<a>robby@eecs.northwestern.edu</a>> wrote:<br>
> Yes, Sam. I don't think anyone is happy with the status quo.<br>
><br>
> Perhaps the tradeoffs have changed since last time a careful investigation<br>
> happened.<br>
><br>
> Robby<br>
><br>
><br>
> On Saturday, April 5, 2014, Sam Tobin-Hochstadt <<a>samth@cs.indiana.edu</a>><br>
> wrote:<br>
>><br>
>> I don't think this is a good answer for Racket.  Certainly the docs<br>
>> don't say that you need to always do this if you want your program to<br>
>> work right. If Racket doesn't work right in the presence of stale<br>
>> compiled filed, then it should just error in those cases, rather than<br>
>> doing the wrong thing. Of course it would be better to work correctly<br>
>> in that case, but this is a hard problem, and it's reasonable to not<br>
>> have a solution. But having the system act like it works when it<br>
>> doesn't is worse.<br>
>><br>
>> Sam<br>
>><br>
>> On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler<br>
>> <<a>robby@eecs.northwestern.edu</a>> wrote:<br>
>> > raco make x.rkt && racket x.rkt<br>
>> ><br>
>> > Robby<br>
>> ><br>
>> ><br>
>> > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson <<a>eric.n.dobson@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Great that explains it and with that information I was able to<br>
>> >> simplify my test case to<br>
>> >><br>
>> >> tmp.rkt<br>
>> >> #lang racket<br>
>> >><br>
>> >> (require "tmp2.rkt")<br>
>> >><br>
>> >> (define-syntax (go stx)<br>
>> >>   (foo))<br>
>> >><br>
>> >> (go)<br>
>> >><br>
>> >> tmp2.rkt<br>
>> >> #lang racket<br>
>> >><br>
>> >> (provide (for-syntax foo))<br>
>> >><br>
>> >> (begin-for-syntax<br>
>> >>   (define (foo) #'3))<br>
>> >><br>
>> >> So now the question is how do I run my code so as to not be bit by<br>
>> >> this? I want a command to run my program that is both fast to run and<br>
>> >> correct with regards to my source. My previous assumption was that the<br>
>> >> zo file's logic was safe if I wasn't trying to break it but I now know<br>
>> >> better. Is my only option to either always compile or never compile?<br>
>> >><br>
>> >><br>
>> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt <<a>mflatt@cs.utah.edu</a>><br>
>> >> wrote:<br>
>> >> > If I understand the question:<br>
>> >> ><br>
>> >> >  * With 34c3eed615, "pr12644.rkt" can compile and run.<br>
>> >> ><br>
>> >> >  * With d29df205f7, "pr12644.rkt" fails to compile.<br>
>> >> ><br>
>> >> >  * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can<br>
>> >> > still<br>
>> >> >    run in d29df205f7, because run-time support for "pr12644.rkt"<br>
>> >> > didn't<br>
>> >> >    change.<br>
>> >> ><br>
>> >> >  * When you tell `racket` to run "pr12644.rkt", it will use a ".zo"<br>
>> >> > for<br>
>> >> >    each of "pr12644.rkt" and its dependencies as long each individual<br>
>> >> >    ".zo" file has a newer timestamp than its ".rkt" file. That is,<br>
>> >> > the<br>
>> >> >    only timestamp comparisons are on individual ".rkt" and ".zo"<br>
>> >> > pairs.<br>
>> >> ><br>
>> >> >  * When you tell `raco make` to build "pr12644.rkt", it checks<br>
>> >> >    dependencies (via ".dep" file) and compares a ".rkt" file's<br>
>> >> >    timestamp against the times of all of its dependencies, instead of<br>
>> >> >    just checking individual ".rkt" and ".zo" pairs. That's why a<</blockquote>
</div></div></blockquote></div><br></div>