Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
That worked. On Mon, Jul 26, 2010 at 8:44 AM, Matthew Flatt wrote: > 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 > > 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] Can't Find a Workaround for Bug 11017 in DrRacket
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 > 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 > 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] Can't Find a Workaround for Bug 11017 in DrRacket
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 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 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] 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] 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]
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
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]]) (and l (let ([p (open-output-string)] [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))) l)]) ;; sort by sha1s so that order doesn't matter (write (sort l stringmain-collects-relative deps) (map (lambda (x) (cons 'ext (path->main-collects-relative x)))
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
That version is after I improved error message, but before the repair. It looks like the nightly build failed last night, which is why the repair wasn't in the build. We're working on that problem. At Fri, 23 Jul 2010 16:11:37 -0600, Doug Williams wrote: > I downloaded the latest nightly build (version > 5.0.1.1--2010-07-21(ca106a41343233e3e2e1d6393b97ff6de67e01c4/a) [3m]). Now I > get the following error message: > > cm: no SHA-1 for dependency: (collects #"scheme" #"base" #"lang" > #"reader.rkt") > > Doug > > On Thu, Jul 22, 2010 at 5:47 PM, Matthew Flatt wrote: > > > At Wed, 21 Jul 2010 17:09:03 -0600, Matthew Flatt wrote: > > > I've pushed a change to the git repo that I don't think will fix the > > > problem, but I think it will give us better information when you get a > > > chance to try it. > > > > The new error message provoked a bug report that led to a repair. So, > > please try the latest and let me know if the problem is fixed. > > > > _ 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
I downloaded the latest nightly build (version 5.0.1.1--2010-07-21(ca106a41343233e3e2e1d6393b97ff6de67e01c4/a) [3m]). Now I get the following error message: cm: no SHA-1 for dependency: (collects #"scheme" #"base" #"lang" #"reader.rkt") Doug On Thu, Jul 22, 2010 at 5:47 PM, Matthew Flatt wrote: > At Wed, 21 Jul 2010 17:09:03 -0600, Matthew Flatt wrote: > > I've pushed a change to the git repo that I don't think will fix the > > problem, but I think it will give us better information when you get a > > chance to try it. > > The new error message provoked a bug report that led to a repair. So, > please try the latest and let me know if the problem is fixed. > > _ 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 Wed, 21 Jul 2010 17:09:03 -0600, Matthew Flatt wrote: > I've pushed a change to the git repo that I don't think will fix the > problem, but I think it will give us better information when you get a > chance to try it. The new error message provoked a bug report that led to a repair. So, please try the latest and let me know if the problem is fixed. _ 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
I've pushed a change to the git repo that I don't think will fix the problem, but I think it will give us better information when you get a chance to try it. _ 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
Sorry-- I should have been more clear: this looks like a bug and we'll try to get it fixed. Robby On Tue, Jul 20, 2010 at 3:12 PM, Doug Williams wrote: > Since it is autogenerated code, most of the time it is just run once (via a > shell call) and discarded - it's the results that are important and send > back to the knowledge base. So, I don't need to keep the .zo files up to > date. In fact, the only reason I ever execute the autogenerated code under > DrRacket is when I'm debugging the code generator itself. > > However, we're now looking at using the generated models themselves in some > more advanced parametric analysis. That's why I split the Monte Carlo code > out separately and ran into the bug. The production system is still under > V4.2.5 and doesn't have the problem - and it is strictly in the > run-once-and-forget mode. I only ran into the problem on my laptop, which > I'd rather not drop back to pre-V5. > > I'll see if disabling the automatic compilation also solves the problem. > > Doug > > On Tue, Jul 20, 2010 at 1:45 PM, Robby Findler > wrote: >> >> Did you try disabling the automatic compilation (in the details >> portion of the language dialog)? My guess is that that will make the >> problem go away. (If so, you can also then start running "raco make >> " in the shell to keep the .zo files up to date and save >> on load times.) >> >> Robby >> >> On Tue, Jul 20, 2010 at 2:24 PM, Doug Williams >> wrote: >> > Okay, some more information. >> > >> > If I execute DrRacket with the Monte Carlo file, make sure Debugging is >> > checked (in the Language dialog with Show Details), and hit Run, I get >> > the >> > error: >> > >> > string as 1st argument, given: #f; other >> > arguments >> > were: >> > >> > "0fe14e326dff1551df22271bdae03080a46dff5a9cd41e2f58a86ac8158ca605f292b20a02896479" >> > >> > with no backtrace available. >> > >> > If I then select No debugging or profiling and hit Run, I get the error: >> > >> > ..\..\..\..\..\..\..\..\..\Program >> > Files\Racket\collects\racket\private\sort.rkt:85:19: string> > type >> > as 1st argument, given: #f; other arguments were: >> > >> > "082577093f20c187869d70b940a5b298cd5572084c12d02f2de08868342b8264c39b7fe111a38bf5" >> > >> > with a backtrace. >> > >> > If I then select Debugging and profiling and hit Run, it actually runs >> > (although more slowly) and produces a profile. >> > >> > Interestingly, I can then go and check either Debugging or No debugging >> > or >> > profiling and it runs. But, if I exit and restart DrRacket it goes back >> > to >> > not working. >> > >> > Weird, huh? >> > >> > Doug >> > >> > On Tue, Jul 20, 2010 at 11:18 AM, Doug Williams >> > wrote: >> >> >> >> I seem have hit the same (or related) bug that Laurent Orseau submitted >> >> as >> >> bug 11017 (but in a completely different context that might help track >> >> it >> >> down) and I haven't been able to find a workaround. The actual error >> >> message >> >> I get is: >> >> >> >> string as 1st argument, given: #f; other >> >> arguments were: >> >> >> >> >> >> "c29a751537a750b825f72c9ee37eea737a0f3a8b9cd41e2f58a86ac8158ca605f292b20a02896479" >> >> >> >> coming from somewhere in the bowels of DrRacket. I don't get the error >> >> when using Racket (i.e., MzScheme). I'm not sure if this machine was >> >> running >> >> the stock V5.0 or a post-V5.0 nightly build that fixed a PLaneT problem >> >> I >> >> was having. But, the pre-release 5.0.1 build gives the same error. I >> >> reloaded V4.2.5 and the code runs fine there. >> >> >> >> I was hoping that the string in the error message itself might give >> >> someone in the know some idea of the problem. >> >> >> >> Unfortunately, this happens in a rather large autogenerated agent-based >> >> simulation that isn't easily posted - although I can send the code and >> >> the >> >> development packages it uses to someone if they need it. >> >> >> >> A short extract of the 'main' program that runs: >> >> >> >> #lang scheme >> >> ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation >> >> (an SAIC Company) >> >> ;;; Autogenerated PLT Scheme source code >> >> invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss >> >> ;;; Generated Monday, July 19th, 2010 12:33:42pm >> >> >> >> (require (planet williams/madness/madness) >> >> >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-arguments.ss" >> >> >> >> >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-argument-values.ss" >> >> >> >> >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-data-collection.ss") >> >> >> >> ... >> >> >> >> ;;; >> >> ;;; Monte Carlo loop >> >> INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES >> >> ;;; >> >> (define (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES n) >> >> (with-new-simulation-environment >> >> (let ((aggregate-instance-index (make-hasheq))) >> >> (for ((i (in-range n))) >> >> (INVEST-IN-PA-YANGI-YANGI-TUCKER i aggregate-instance-index)) >
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
Since it is autogenerated code, most of the time it is just run once (via a shell call) and discarded - it's the results that are important and send back to the knowledge base. So, I don't need to keep the .zo files up to date. In fact, the only reason I ever execute the autogenerated code under DrRacket is when I'm debugging the code generator itself. However, we're now looking at using the generated models themselves in some more advanced parametric analysis. That's why I split the Monte Carlo code out separately and ran into the bug. The production system is still under V4.2.5 and doesn't have the problem - and it is strictly in the run-once-and-forget mode. I only ran into the problem on my laptop, which I'd rather not drop back to pre-V5. I'll see if disabling the automatic compilation also solves the problem. Doug On Tue, Jul 20, 2010 at 1:45 PM, Robby Findler wrote: > Did you try disabling the automatic compilation (in the details > portion of the language dialog)? My guess is that that will make the > problem go away. (If so, you can also then start running "raco make > " in the shell to keep the .zo files up to date and save > on load times.) > > Robby > > On Tue, Jul 20, 2010 at 2:24 PM, Doug Williams > wrote: > > Okay, some more information. > > > > If I execute DrRacket with the Monte Carlo file, make sure Debugging is > > checked (in the Language dialog with Show Details), and hit Run, I get > the > > error: > > > > string as 1st argument, given: #f; other > arguments > > were: > > > "0fe14e326dff1551df22271bdae03080a46dff5a9cd41e2f58a86ac8158ca605f292b20a02896479" > > > > with no backtrace available. > > > > If I then select No debugging or profiling and hit Run, I get the error: > > > > ..\..\..\..\..\..\..\..\..\Program > > Files\Racket\collects\racket\private\sort.rkt:85:19: string type > > as 1st argument, given: #f; other arguments were: > > > "082577093f20c187869d70b940a5b298cd5572084c12d02f2de08868342b8264c39b7fe111a38bf5" > > > > with a backtrace. > > > > If I then select Debugging and profiling and hit Run, it actually runs > > (although more slowly) and produces a profile. > > > > Interestingly, I can then go and check either Debugging or No debugging > or > > profiling and it runs. But, if I exit and restart DrRacket it goes back > to > > not working. > > > > Weird, huh? > > > > Doug > > > > On Tue, Jul 20, 2010 at 11:18 AM, Doug Williams > > wrote: > >> > >> I seem have hit the same (or related) bug that Laurent Orseau submitted > as > >> bug 11017 (but in a completely different context that might help track > it > >> down) and I haven't been able to find a workaround. The actual error > message > >> I get is: > >> > >> string as 1st argument, given: #f; other > >> arguments were: > >> > >> > > "c29a751537a750b825f72c9ee37eea737a0f3a8b9cd41e2f58a86ac8158ca605f292b20a02896479" > >> > >> coming from somewhere in the bowels of DrRacket. I don't get the error > >> when using Racket (i.e., MzScheme). I'm not sure if this machine was > running > >> the stock V5.0 or a post-V5.0 nightly build that fixed a PLaneT problem > I > >> was having. But, the pre-release 5.0.1 build gives the same error. I > >> reloaded V4.2.5 and the code runs fine there. > >> > >> I was hoping that the string in the error message itself might give > >> someone in the know some idea of the problem. > >> > >> Unfortunately, this happens in a rather large autogenerated agent-based > >> simulation that isn't easily posted - although I can send the code and > the > >> development packages it uses to someone if they need it. > >> > >> A short extract of the 'main' program that runs: > >> > >> #lang scheme > >> ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation > >> (an SAIC Company) > >> ;;; Autogenerated PLT Scheme source code > >> invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss > >> ;;; Generated Monday, July 19th, 2010 12:33:42pm > >> > >> (require (planet williams/madness/madness) > >> > >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-arguments.ss" > >> > >> > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-argument-values.ss" > >> > >> > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-data-collection.ss") > >> > >> ... > >> > >> ;;; > >> ;;; Monte Carlo loop > INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES > >> ;;; > >> (define (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES n) > >> (with-new-simulation-environment > >> (let ((aggregate-instance-index (make-hasheq))) > >> (for ((i (in-range n))) > >> (INVEST-IN-PA-YANGI-YANGI-TUCKER i aggregate-instance-index)) > >> (print-statistics aggregate-instance-index) > >> (generate-exhibit-files aggregate-instance-index) > >> (generate-results-XML aggregate-instance-index n > >> > >> ;;; > >> ;;; Execute Monte Carlo > >> ;;; > >> > >> (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) > >> > >> ;;; > >> ;;; Module Contracts > >> ;
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
Did you try disabling the automatic compilation (in the details portion of the language dialog)? My guess is that that will make the problem go away. (If so, you can also then start running "raco make " in the shell to keep the .zo files up to date and save on load times.) Robby On Tue, Jul 20, 2010 at 2:24 PM, Doug Williams wrote: > Okay, some more information. > > If I execute DrRacket with the Monte Carlo file, make sure Debugging is > checked (in the Language dialog with Show Details), and hit Run, I get the > error: > > string as 1st argument, given: #f; other arguments > were: > "0fe14e326dff1551df22271bdae03080a46dff5a9cd41e2f58a86ac8158ca605f292b20a02896479" > > with no backtrace available. > > If I then select No debugging or profiling and hit Run, I get the error: > > ..\..\..\..\..\..\..\..\..\Program > Files\Racket\collects\racket\private\sort.rkt:85:19: string as 1st argument, given: #f; other arguments were: > "082577093f20c187869d70b940a5b298cd5572084c12d02f2de08868342b8264c39b7fe111a38bf5" > > with a backtrace. > > If I then select Debugging and profiling and hit Run, it actually runs > (although more slowly) and produces a profile. > > Interestingly, I can then go and check either Debugging or No debugging or > profiling and it runs. But, if I exit and restart DrRacket it goes back to > not working. > > Weird, huh? > > Doug > > On Tue, Jul 20, 2010 at 11:18 AM, Doug Williams > wrote: >> >> I seem have hit the same (or related) bug that Laurent Orseau submitted as >> bug 11017 (but in a completely different context that might help track it >> down) and I haven't been able to find a workaround. The actual error message >> I get is: >> >> string as 1st argument, given: #f; other >> arguments were: >> >> "c29a751537a750b825f72c9ee37eea737a0f3a8b9cd41e2f58a86ac8158ca605f292b20a02896479" >> >> coming from somewhere in the bowels of DrRacket. I don't get the error >> when using Racket (i.e., MzScheme). I'm not sure if this machine was running >> the stock V5.0 or a post-V5.0 nightly build that fixed a PLaneT problem I >> was having. But, the pre-release 5.0.1 build gives the same error. I >> reloaded V4.2.5 and the code runs fine there. >> >> I was hoping that the string in the error message itself might give >> someone in the know some idea of the problem. >> >> Unfortunately, this happens in a rather large autogenerated agent-based >> simulation that isn't easily posted - although I can send the code and the >> development packages it uses to someone if they need it. >> >> A short extract of the 'main' program that runs: >> >> #lang scheme >> ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation >> (an SAIC Company) >> ;;; Autogenerated PLT Scheme source code >> invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss >> ;;; Generated Monday, July 19th, 2010 12:33:42pm >> >> (require (planet williams/madness/madness) >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-arguments.ss" >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-argument-values.ss" >> >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-data-collection.ss") >> >> ... >> >> ;;; >> ;;; Monte Carlo loop INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES >> ;;; >> (define (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES n) >> (with-new-simulation-environment >> (let ((aggregate-instance-index (make-hasheq))) >> (for ((i (in-range n))) >> (INVEST-IN-PA-YANGI-YANGI-TUCKER i aggregate-instance-index)) >> (print-statistics aggregate-instance-index) >> (generate-exhibit-files aggregate-instance-index) >> (generate-results-XML aggregate-instance-index n >> >> ;;; >> ;;; Execute Monte Carlo >> ;;; >> >> (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) >> >> ;;; >> ;;; Module Contracts >> ;;; >> >> (provide (all-defined-out)) >> >> If I simply remove the call to >> (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) and move it to >> it's own package: >> >> #lang scheme >> ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation >> (an SAIC Company) >> ;;; Autogenerated PLT Scheme source code >> invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-monte-carlo.ss >> ;;; Generated Monday, July 19th, 2010 12:33:43pm >> >> (require >> "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss") >> >> >> ;;; >> ;;; Execute Monte Carlo >> ;;; >> >> (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) >> >> I get the error above. [Again, it runs under Racket (i.e., MzScheme).] >> >> Please let me know if there are some switches I can set or otherwise >> provide additional information. >> >> Ah, I just ran it with "No debugging or profiling" checked and got some >> additional information - seems interesting that I got more information with >> no debugging. But anyway the error printed is now >> >> ..\..\..\..\..\..\..\..\..\Program >> Files\Racket\collects\racket\private\sort.rkt:85:19:
Re: [racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
Okay, some more information. If I execute DrRacket with the Monte Carlo file, make sure Debugging is checked (in the Language dialog with Show Details), and hit Run, I get the error: string as 1st argument, given: #f; other arguments were: "0fe14e326dff1551df22271bdae03080a46dff5a9cd41e2f58a86ac8158ca605f292b20a02896479" with no backtrace available. If I then select No debugging or profiling and hit Run, I get the error: ..\..\..\..\..\..\..\..\..\Program Files\Racket\collects\racket\private\sort.rkt:85:19: string as 1st argument, given: #f; other arguments were: "082577093f20c187869d70b940a5b298cd5572084c12d02f2de08868342b8264c39b7fe111a38bf5" with a backtrace. If I then select Debugging and profiling and hit Run, it actually runs (although more slowly) and produces a profile. Interestingly, I can then go and check either Debugging or No debugging or profiling and it runs. But, if I exit and restart DrRacket it goes back to not working. Weird, huh? Doug On Tue, Jul 20, 2010 at 11:18 AM, Doug Williams < m.douglas.willi...@gmail.com> wrote: > I seem have hit the same (or related) bug that Laurent Orseau submitted as > bug 11017 (but in a completely different context that might help track it > down) and I haven't been able to find a workaround. The actual error message > I get is: > > string as 1st argument, given: #f; other arguments > were: > > > "c29a751537a750b825f72c9ee37eea737a0f3a8b9cd41e2f58a86ac8158ca605f292b20a02896479" > > coming from somewhere in the bowels of DrRacket. I don't get the error when > using Racket (i.e., MzScheme). I'm not sure if this machine was running the > stock V5.0 or a post-V5.0 nightly build that fixed a PLaneT problem I was > having. But, the pre-release 5.0.1 build gives the same error. I reloaded > V4.2.5 and the code runs fine there. > > I was hoping that the string in the error message itself might give someone > in the know some idea of the problem. > > Unfortunately, this happens in a rather large autogenerated agent-based > simulation that isn't easily posted - although I can send the code and the > development packages it uses to someone if they need it. > > A short extract of the 'main' program that runs: > > #lang scheme > ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation (an > SAIC Company) > ;;; Autogenerated PLT Scheme source code > invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss > ;;; Generated Monday, July 19th, 2010 12:33:42pm > > (require (planet williams/madness/madness) > > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-arguments.ss" > > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-argument-values.ss" > > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-data-collection.ss") > > ... > > ;;; > ;;; Monte Carlo loop INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES > ;;; > (define (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES n) > (with-new-simulation-environment > (let ((aggregate-instance-index (make-hasheq))) > (for ((i (in-range n))) > (INVEST-IN-PA-YANGI-YANGI-TUCKER i aggregate-instance-index)) > (print-statistics aggregate-instance-index) > (generate-exhibit-files aggregate-instance-index) > (generate-results-XML aggregate-instance-index n > > ;;; > ;;; Execute Monte Carlo > ;;; > > (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) > > ;;; > ;;; Module Contracts > ;;; > > (provide (all-defined-out)) > > If I simply remove the call to > (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) and move it to > it's own package: > > #lang scheme > ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation (an > SAIC Company) > ;;; Autogenerated PLT Scheme source code > invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-monte-carlo.ss > ;;; Generated Monday, July 19th, 2010 12:33:43pm > > (require > "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss") > > > ;;; > ;;; Execute Monte Carlo > ;;; > > (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) > > I get the error above. [Again, it runs under Racket (i.e., MzScheme).] > > Please let me know if there are some switches I can set or otherwise > provide additional information. > > Ah, I just ran it with "No debugging or profiling" checked and got some > additional information - seems interesting that I got more information with > no debugging. But anyway the error printed is now > > ..\..\..\..\..\..\..\..\..\Program > Files\Racket\collects\racket\private\sort.rkt:85:19: string as 1st argument, given: #f; other arguments were: > "146047b7b2121bf8f7b15d7c2ef396b710f394474c12d02f2de08868342b8264c39b7fe111a38bf5" > > It also gave a backtrace that I copied and pasted into the attached file. > [Was a better way to do that?] > > Doug > > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Can't Find a Workaround for Bug 11017 in DrRacket
I seem have hit the same (or related) bug that Laurent Orseau submitted as bug 11017 (but in a completely different context that might help track it down) and I haven't been able to find a workaround. The actual error message I get is: string as 1st argument, given: #f; other arguments were: "c29a751537a750b825f72c9ee37eea737a0f3a8b9cd41e2f58a86ac8158ca605f292b20a02896479" coming from somewhere in the bowels of DrRacket. I don't get the error when using Racket (i.e., MzScheme). I'm not sure if this machine was running the stock V5.0 or a post-V5.0 nightly build that fixed a PLaneT problem I was having. But, the pre-release 5.0.1 build gives the same error. I reloaded V4.2.5 and the code runs fine there. I was hoping that the string in the error message itself might give someone in the know some idea of the problem. Unfortunately, this happens in a rather large autogenerated agent-based simulation that isn't easily posted - although I can send the code and the development packages it uses to someone if they need it. A short extract of the 'main' program that runs: #lang scheme ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation (an SAIC Company) ;;; Autogenerated PLT Scheme source code invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss ;;; Generated Monday, July 19th, 2010 12:33:42pm (require (planet williams/madness/madness) "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-arguments.ss" "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-argument-values.ss" "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-data-collection.ss") ... ;;; ;;; Monte Carlo loop INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES ;;; (define (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES n) (with-new-simulation-environment (let ((aggregate-instance-index (make-hasheq))) (for ((i (in-range n))) (INVEST-IN-PA-YANGI-YANGI-TUCKER i aggregate-instance-index)) (print-statistics aggregate-instance-index) (generate-exhibit-files aggregate-instance-index) (generate-results-XML aggregate-instance-index n ;;; ;;; Execute Monte Carlo ;;; (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) ;;; ;;; Module Contracts ;;; (provide (all-defined-out)) If I simply remove the call to (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) and move it to it's own package: #lang scheme ;;; Agent Generation from Templates - PRIME (AGenT') by SET Corporation (an SAIC Company) ;;; Autogenerated PLT Scheme source code invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-monte-carlo.ss ;;; Generated Monday, July 19th, 2010 12:33:43pm (require "invest-in-pa-yangi-yangi-tucker---plausible-outcomes-212-main.ss") ;;; ;;; Execute Monte Carlo ;;; (INVEST-IN-PA-YANGI-YANGI-TUCKER---PLAUSIBLE-OUTCOMES 10) I get the error above. [Again, it runs under Racket (i.e., MzScheme).] Please let me know if there are some switches I can set or otherwise provide additional information. Ah, I just ran it with "No debugging or profiling" checked and got some additional information - seems interesting that I got more information with no debugging. But anyway the error printed is now ..\..\..\..\..\..\..\..\..\Program Files\Racket\collects\racket\private\sort.rkt:85:19: string as 1st argument, given: #f; other arguments were: "146047b7b2121bf8f7b15d7c2ef396b710f394474c12d02f2de08868342b8264c39b7fe111a38bf5" It also gave a backtrace that I copied and pasted into the attached file. [Was a better way to do that?] Doug string as 1st argument, given: #f; other arguments were: "146047b7b2121bf8f7b15d7c2ef396b710f394474c12d02f2de08868342b8264c39b7fe111a38bf5" C:\Program Files\Racket\collects\racket\private\sort.rkt: 85:19 (let jloop ([j (i+ Blo i)]) (let ([ref-j-1 (ref (i- j 1))]) (if (and (i< Blo j) ( 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 by
