Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
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 wrote: > On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt 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
Re: [racket-dev] proposal: `data' collection
I've pushed the splice-at-file-level change so we can try it out. There are many uses of `collection-path' that should change to `collection-file-path'. Most would be easy to change, but as expected, that's not always the case. For a while, I think file-level splicing will work well only for collections where that's expected, such as the possible "data" collection. At Fri, 9 Jul 2010 13:10:26 -0600, Matthew Flatt wrote: > At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote: > > Back to `data', the problem is that you cannot have two toplevel > > `data' collections -- which means that you cannot have separate > > distributions of `data/foo' and `data/bar' since they must both appear > > in your plt installation or in your user directory -- not in both. > > The more I think about it, the more I'm convinced that it's ok to > splice collections at the file level instead of the directory level: > > * Splicing at the file level doesn't create any issues for resolving >module names: There's already a search path to find the directory >for a collection, and the filename is known at that point, so the >filename could be used as part of the search. > > * The `collection-path' function would have to be deprecated, and we'd >add a `collection-file-path' function that splices at the file >level. > >Most uses of `collection-path' could be easily replaced with >`collection-file-path'. > >Some other uses of `collection-path' don't particularly need >splicing (e.g., locating a file used by a test suite). > >A Planet package (or some other code outside the main development >repository) might use `collection-path' in a way that would break if >a collection is spliced at the file level. If the package is useful >enough, I imagine there will be plenty of time to fix it before >file-level splicing becomes common. > > Does anyone see a problem that I've overlooked? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
At Sun, 25 Jul 2010 11:22:19 -0400, Sam Tobin-Hochstadt wrote: > On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt 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. Oh, I see. Thanks! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt 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
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
The immediate bug is now fixed (to show up in a nightly build until tomorrow). 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? At Sat, 24 Jul 2010 19:41:04 -0600, Doug Williams wrote: > I downloaded the nightly build version > 5.0.1.1--2010-07-23(57d3dd7df753abacc8642809216a873962204d4f/a) [3m] and the > error message is now: > > ..\..\..\..\..\..\..\..\..\Program > Files\Racket\collects\compiler\cm.rkt:94:26: cdr: expects argument of type > ; given # > > and the backtrace is: > > cdr: expects argument of type ; given # > > C:\Program Files\Racket\collects\compiler\cm.rkt: 94:26 > (delay (get-compiled-file-sha1 (get-zo-path] > > C:\Program Files\Racket\collects\racket\private\promise.rkt: 103:10 > (lambda () > (let ([vs (call-with-values v list)]) (pset! promise vs) vs > > C:\Program Files\Racket\collects\racket\private\more-scheme.rkt: 274:2 > (define (call-with-exception-handler exnh thunk) > ;; The `begin0' ensures that we don't overwrite an enclosing > ;; exception handler. > (begin0 > (with-continuation-mark > exception-handler-key > exnh >(thunk)) > (void))) > > C:\Program Files\Racket\collects\racket\private\promise.rkt: 95:0 > (define (force/generic promise) > (reify-result >(let ([v (pref promise)]) > (if (procedure? v) >(begin > (pset! promise (make-running (object-name v))) > (call-with-exception-handler > (lambda (e) (pset! promise (make-reraise e)) e) > (lambda () > (let ([vs (call-with-values v list)]) (pset! promise vs) vs >v > > C:\Program Files\Racket\collects\compiler\cm.rkt: 212:23 > [l (map (lambda (v) > (let ([sha1 (force (car v))] >[dep (cdr v)]) >(unless sha1 > (error 'cm "no SHA-1 for dependency: ~s" dep)) >(cons sha1 dep))) > > C:\Program Files\Racket\collects\racket\private\map.rkt: 23:17 >(let loop ([l l]) >(cond > [(null? l) null] > [else (cons (f (car l)) (loop (cdr l)))])) > > C:\Program Files\Racket\collects\racket\private\map.rkt: 18:11 > (case-lambda > [(f l) > (if (and (procedure? f) > (procedure-arity-includes? f 1) > (list? l)) > (let loop ([l l]) >(cond > [(null? l) null] > [else (cons (f (car l)) (loop (cdr l)))])) > (map f l))] > [(f l1 l2) > (if (and (procedure? f) > (procedure-arity-includes? f 2) > (list? l1) > (list? l2) > (= (length l1) (length l2))) > (let loop ([l1 l1][l2 l2]) >(cond > [(null? l1) null] > [else (cons (f (car l1) (car l2)) > (loop (cdr l1) (cdr l2)))])) > (map f l1 l2))] > [(f . args) (apply map f args)])]) > > C:\Program Files\Racket\collects\compiler\cm.rkt: 187:0 > (define (get-dep-sha1s deps up-to-date read-src-syntax mode must-exist?) > (let ([l (for/fold ([l null]) ([dep (in-list deps)]) > (and l > ;; (cons 'ext rel-path) => a non-module file, check source > ;; rel-path => a module file name, check cache > (let* ([ext? (and (pair? dep) (eq? 'ext (car dep)))] > [p (main-collects-relative->path (if ext? (cdr dep) > dep))]) > (cond > [ext? (let ([v (get-source-sha1 p)]) > (cond > [v (cons (cons (delay v) dep) l)] > [must-exist? (error 'cm "cannot find > external-dependency file: ~v" p)] > [else #f]))] > [(or (hash-ref up-to-date (simple-form-path p) #f) > ;; Use `compiler-root' with `sha1-only?' as #t: > (compile-root mode p up-to-date read-src-syntax > #t)) > => (lambda (sh) >(cons (cons (cdr sh) dep) l))] > [must-exist? > ;; apparently, we're forced to use the source of the > module, > ;; so compute a sha1 from it instead of the bytecode > (cons (cons (get-source-sha1 p) dep) l)] > [else #f]
