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