That worked.<br><br><div class="gmail_quote">On Mon, Jul 26, 2010 at 8:44 AM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes, it's the ".ss"->".rkt' conversion yet again.<br>
<br>
I've pushed a repair. To speed things up, maybe you can try changing<br>
the definition of `get-source-sha1' in "collects/compiler/cm.rkt" to<br>
<br>
(define (get-source-sha1 p)<br>
(with-handlers ([exn:fail:filesystem?<br>
(lambda (exn)<br>
(and (regexp-match? #rx#"[.]rkt$" (path->bytes p))<br>
(get-source-sha1 (path-replace-suffix p #".ss"))))])<br>
(call-with-input-file* p sha1)))<br>
<br>
and check whether that fixes the problem.<br>
<br>
Thanks for your patience!<br>
<div><div></div><div class="h5"><br>
At Mon, 26 Jul 2010 08:02:25 -0600, Doug Williams wrote:<br>
> With last night's build, the error message is now:<br>
><br>
> cm: no SHA-1 for dependency: #"C:\\Documents and Settings\\williamsm\\My<br>
> Documents\\Development\\madness\\madness.rkt"<br>
><br>
> I am using a development link (using PLaneT) to reference the madness (which<br>
> is an acronym for Multi-Agent Dynamic Network Simulation System - MADNeSS,<br>
> not a reference to my mental state) development folder. But, the files in it<br>
> are actually .ss files - as are all of the files involved. So, I'm guessing<br>
> that somewhere along the line the development link to (planet<br>
> williams/madness/madness) didn't 'remember' it was to a .ss file instead of<br>
> a .rkt file.<br>
><br>
> Doug<br>
><br>
> On Sun, Jul 25, 2010 at 2:49 PM, Doug Williams <<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a><br>
> > wrote:<br>
><br>
> > Sam appears to be corrects.<br>
> ><br>
> > If "No Debugging or profiling" is selected, I get the backtrace. If<br>
> > "Debugging" is selected, I only get the error message. And, most<br>
> > interestingly, if "Debugging and profiling" is selected, it runs correctly.<br>
> ><br>
> > Also, Robby's suspicion that it would run correctly if "Populate compiled/<br>
> > directories (for faster loading)" is unchecked, seems to be true. It does<br>
> > run when it is unchecked.<br>
> ><br>
> > Doug<br>
> ><br>
> ><br>
> > On Sun, Jul 25, 2010 at 9:22 AM, Sam Tobin-Hochstadt<br>
> <<a href="mailto:samth@ccs.neu.edu">samth@ccs.neu.edu</a>>wrote:<br>
> ><br>
> >> On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>><br>
> >> wrote:<br>
> >> ><br>
> >> > It's worrying, though, that you're getting a DrRacket backtrace that<br>
> >> > covers "cm.rkt". Files in the main installation normally should not be<br>
> >> > instrumented for backtraces. Does your installation have any "drracket"<br>
> >> > subdirectories of any "compiled" directories?<br>
> >><br>
> >> It's easy to get such a backtrace if "Debugging" (meaning Errortrace<br>
> >> Debugging) is off. This is particularly likely to be what happened<br>
> >> here, since every backtrace frame is a function definition, which<br>
> >> rarely happens with errortrace, but always happens with the internal<br>
> >> Racket backtraces.<br>
> >> --<br>
> >> sam th<br>
> >> <a href="mailto:samth@ccs.neu.edu">samth@ccs.neu.edu</a><br>
> >><br>
> ><br>
> ><br>
</div></div></blockquote></div><br>