Re: [racket-dev] [plt] Push #23293: master branch updated
At Fri, 19 Aug 2011 08:36:30 -0400, mfl...@racket-lang.org wrote: 7eb2042 Matthew Flatt mfl...@racket-lang.org 2011-08-19 03:34 : | fix compiler handling of top-/module-level constants Sorry --- I know that DrRacket doesn't start after this commit. I'm working on it. (I ran extra test suites trying to make sure this commit is ok, but I forgot to try starting DrRacket until 30 seconds too late.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sporadic failure when building PLaneT docs
It looks like this is a problem with the sandbox or the use of the sandbox somehow. Here's the stacktrace for the error: - require: unknown module: 'program === context === /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:572:17: ns /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:583:20 /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:564:0: evaluate-program /Applications/Racket v5.1.3/collects/racket/private/more-scheme.rkt:151:2: call-with-break-parameterization /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:703:2: user-process - I'm not seeing anything when looking at your code that looks suspicious, but I'm not sure of the ins and outs of the sandbox protocols so I'm not sure who to blame here (well, probably the sandbox needs to be blamed since the error is not illuminating, but there may be other problems that that error is masking). One difference that I notice is that scribble's make-base-eval doesn't create the evaluator in the same way your code does; it uses a different argument to make-evaluator that puts the evaluator into a different mode somehow. That could be relevant. Maybe Eli can say more? Also, with the following program in tmp.rkt #lang racket/base (require (planet dyoo/closure-compile)) closure-compile then running racket -W info tmp.rkt is enough to reproduce the problem (assuming dyoo/closure-compile isn't installed). You don't need to actually install other packages. Hope that helps a little bit. Robby On Wed, Aug 17, 2011 at 3:44 PM, Danny Yoo d...@cs.wpi.edu wrote: I'm seeing the following error message when I'm compiling Whalesong: require: unknown module: 'program raco setup: error: during Building docs for /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/manual.scrbl Wait, that's odd! I thought that my closure-compile package compiled cleanly. I tested this! I removed the closure-compile.plt package, and then tried reinstalling that package directly. To my dismay: I couldn't reproduce the error: the transcript below shows that I don't get a error about unknown module: dyoo@kfisler-ra1:~$ planet install dyoo closure-compile.plt 1 2 downloading dyoo/closure-compile:1 from planet.racket-lang.org via HTTP = Installing closure-compile.plt on Wed, 17 Aug 2011 16:27:15 = raco setup: Unpacking archive from /home/dyoo/.racket/planet/300/packages/dyoo/closure-compile.plt/1/2/closure-compile.plt raco setup: unpacking COPYING in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking compiler.jar in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking info.rkt in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking main.rkt in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking manual.html in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking manual.scrbl in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: making directory planet-docs in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: making directory manual in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/ raco setup: unpacking index.html in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/manual/ raco setup: unpacking racket.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/manual/ raco setup: unpacking scribble-common.js in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/manual/ raco setup: unpacking scribble-style.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/manual/ raco setup: unpacking scribble.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./planet-docs/manual/ raco setup: unpacking racket.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking scribble-common.js in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking scribble-style.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: unpacking scribble.css in /home/dyoo/.racket/planet/300/5.1.3/cache/dyoo/closure-compile.plt/1/2/./ raco setup: version: 5.1.3 [3m] raco setup: variants: 3m raco setup: main collects: /home/dyoo/local/racket-5.1.3/collects raco setup: collects paths: raco setup: /home/dyoo/.racket/5.1.3/collects
Re: [racket-dev] Intermittent DrRacket crash
Commit d7a996ee0bf393 is relevant. Let me know if you see any change after updating to the latest. At Wed, 17 Aug 2011 10:22:32 -0500, Casey Klein wrote: DrRacket crashes pretty routinely when I'm editing a Scribble document and hitting the Scribble HTML button. I don't know precisely what triggers it, but here's the stack trace, in case it's useful. Process: DrRacket [30831] Path:/Users/clklein/git/plt/DrRacket.app/Contents/MacOS/DrRacket Identifier: org.racket-lang.DrRacket Version: 5.1.1.5 (5.1.1.5) Code Type: X86 (Native) Parent Process: launchd [219] Date/Time: 2011-08-17 10:19:36.742 -0500 OS Version: Mac OS X 10.6.8 (10K540) Report Version: 6 Interval Since Last Report: 2498843 sec Crashes Since Last Report: 5 Per-App Interval Since Last Report: 2225316 sec Per-App Crashes Since Last Report: 4 Anonymous UUID: 30D5FBB7-E93E-4AE6-B690-46E1E1D29CB8 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 Racket0x00222e14 scheme_do_close_managed + 308 1 Racket0x00224dfd do_close_managed + 29 2 Racket0x00224f0d check_scheduled_kills + 173 3 Racket0x00221593 scheme_thread_block + 195 4 Racket0x00224655 scheme_out_of_fuel + 37 5 Racket0x00173b12 scheme_get_byte_string_unless + 2546 6 Racket0x00174369 scheme_get_bytes + 89 7 Racket0x001aead3 read_inner_inner + 29027 8 Racket0x001b0c58 _internal_read + 1016 9 Racket0x001b1407 scheme_internal_read_k + 247 10 Racket0x0007a733 scheme_top_level_do_worker + 931 11 Racket0x0007b1b8 scheme_top_level_do + 40 12 Racket0x001b115e scheme_internal_read + 318 13 Racket0x00183538 do_read_f + 376 14 ??? 0x00380748 0 + 3671880 15 Racket0x0005c6aa scheme_do_eval + 10122 16 Racket0x0007017c do_dyn_wind + 44 17 Racket0x00076675 scheme_dynamic_wind + 805 18 Racket0x00076c9e dynamic_wind + 318 19 ??? 0x0037a9c9 0 + 3647945 20 ??? 0x00381854 0 + 3676244 21 Racket0x0005c6aa scheme_do_eval + 10122 22 Racket0x00077ca8 scheme_finish_apply_for_prompt + 696 23 Racket0x00077e60 scheme_apply_for_prompt + 112 24 Racket0x00083838 call_with_prompt + 1208 25 ??? 0x0037a9c9 0 + 3647945 26 ??? 0x00380270 0 + 3670640 27 ??? 0x15a21cd4 0 + 362945748 28 ??? 0x003809b4 0 + 3672500 29 Racket0x0005c6aa scheme_do_eval + 10122 30 Racket0x0005f2ec _scheme_apply_multi_from_native + 92 31 ??? 0x0037a962 0 + 3647842 32 Racket0x0005c6aa scheme_do_eval + 10122 33 Racket0x00078f62 call_with_values + 194 34 ??? 0x0037feb9 0 + 3669689 35 ??? 0x00398b90 0 + 3771280 36 Racket0x0005c6aa scheme_do_eval + 10122 37 Racket0x00079cda apply_k + 170 38 Racket0x0007a69f scheme_top_level_do_worker + 783 39 Racket0x0007b184 scheme_apply_thread_thunk + 116 40 Racket0x00221031 start_child + 993 41 Racket0x0022481b make_subprocess + 411 42 Racket0x00224a56 scheme_thread_w_details + 326 43 ??? 0xbfff3040 0 + 3221172288 44 ??? 0x1d72bb18 0 + 494058264 45 ??? 0x0030 0 + 48 Thread 1: 0 libSystem.B.dylib 0x94a6dafa mach_msg_trap + 10 1 libSystem.B.dylib 0x94a6e267 mach_msg + 68 2 Racket0x0024f042 exception_thread + 194 3 libSystem.B.dylib 0x94a9b259 _pthread_start + 345 4 libSystem.B.dylib 0x94a9b0de thread_start + 34 Thread 2: 0 libSystem.B.dylib 0x94ada7da __sigwait + 10 1 libSystem.B.dylib
Re: [racket-dev] Intermittent DrRacket crash
OK, I'll try it out. On Fri, Aug 19, 2011 at 3:08 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Commit d7a996ee0bf393 is relevant. Let me know if you see any change after updating to the latest. At Wed, 17 Aug 2011 10:22:32 -0500, Casey Klein wrote: DrRacket crashes pretty routinely when I'm editing a Scribble document and hitting the Scribble HTML button. I don't know precisely what triggers it, but here's the stack trace, in case it's useful. Process: DrRacket [30831] Path: /Users/clklein/git/plt/DrRacket.app/Contents/MacOS/DrRacket Identifier: org.racket-lang.DrRacket Version: 5.1.1.5 (5.1.1.5) Code Type: X86 (Native) Parent Process: launchd [219] Date/Time: 2011-08-17 10:19:36.742 -0500 OS Version: Mac OS X 10.6.8 (10K540) Report Version: 6 Interval Since Last Report: 2498843 sec Crashes Since Last Report: 5 Per-App Interval Since Last Report: 2225316 sec Per-App Crashes Since Last Report: 4 Anonymous UUID: 30D5FBB7-E93E-4AE6-B690-46E1E1D29CB8 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 Racket 0x00222e14 scheme_do_close_managed + 308 1 Racket 0x00224dfd do_close_managed + 29 2 Racket 0x00224f0d check_scheduled_kills + 173 3 Racket 0x00221593 scheme_thread_block + 195 4 Racket 0x00224655 scheme_out_of_fuel + 37 5 Racket 0x00173b12 scheme_get_byte_string_unless + 2546 6 Racket 0x00174369 scheme_get_bytes + 89 7 Racket 0x001aead3 read_inner_inner + 29027 8 Racket 0x001b0c58 _internal_read + 1016 9 Racket 0x001b1407 scheme_internal_read_k + 247 10 Racket 0x0007a733 scheme_top_level_do_worker + 931 11 Racket 0x0007b1b8 scheme_top_level_do + 40 12 Racket 0x001b115e scheme_internal_read + 318 13 Racket 0x00183538 do_read_f + 376 14 ??? 0x00380748 0 + 3671880 15 Racket 0x0005c6aa scheme_do_eval + 10122 16 Racket 0x0007017c do_dyn_wind + 44 17 Racket 0x00076675 scheme_dynamic_wind + 805 18 Racket 0x00076c9e dynamic_wind + 318 19 ??? 0x0037a9c9 0 + 3647945 20 ??? 0x00381854 0 + 3676244 21 Racket 0x0005c6aa scheme_do_eval + 10122 22 Racket 0x00077ca8 scheme_finish_apply_for_prompt + 696 23 Racket 0x00077e60 scheme_apply_for_prompt + 112 24 Racket 0x00083838 call_with_prompt + 1208 25 ??? 0x0037a9c9 0 + 3647945 26 ??? 0x00380270 0 + 3670640 27 ??? 0x15a21cd4 0 + 362945748 28 ??? 0x003809b4 0 + 3672500 29 Racket 0x0005c6aa scheme_do_eval + 10122 30 Racket 0x0005f2ec _scheme_apply_multi_from_native + 92 31 ??? 0x0037a962 0 + 3647842 32 Racket 0x0005c6aa scheme_do_eval + 10122 33 Racket 0x00078f62 call_with_values + 194 34 ??? 0x0037feb9 0 + 3669689 35 ??? 0x00398b90 0 + 3771280 36 Racket 0x0005c6aa scheme_do_eval + 10122 37 Racket 0x00079cda apply_k + 170 38 Racket 0x0007a69f scheme_top_level_do_worker + 783 39 Racket 0x0007b184 scheme_apply_thread_thunk + 116 40 Racket 0x00221031 start_child + 993 41 Racket 0x0022481b make_subprocess + 411 42 Racket 0x00224a56 scheme_thread_w_details + 326 43 ??? 0xbfff3040 0 + 3221172288 44 ??? 0x1d72bb18 0 + 494058264 45 ??? 0x0030 0 + 48 Thread 1: 0 libSystem.B.dylib 0x94a6dafa mach_msg_trap + 10 1 libSystem.B.dylib 0x94a6e267 mach_msg + 68 2 Racket 0x0024f042 exception_thread + 194 3 libSystem.B.dylib 0x94a9b259 _pthread_start + 345 4 libSystem.B.dylib 0x94a9b0de thread_start + 34 Thread 2: 0
Re: [racket-dev] Intermittent DrRacket crash
I tried 20 times and didn't get a crash. Thanks! On Fri, Aug 19, 2011 at 3:11 PM, Casey Klein clkl...@eecs.northwestern.edu wrote: OK, I'll try it out. On Fri, Aug 19, 2011 at 3:08 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Commit d7a996ee0bf393 is relevant. Let me know if you see any change after updating to the latest. At Wed, 17 Aug 2011 10:22:32 -0500, Casey Klein wrote: DrRacket crashes pretty routinely when I'm editing a Scribble document and hitting the Scribble HTML button. I don't know precisely what triggers it, but here's the stack trace, in case it's useful. Process: DrRacket [30831] Path: /Users/clklein/git/plt/DrRacket.app/Contents/MacOS/DrRacket Identifier: org.racket-lang.DrRacket Version: 5.1.1.5 (5.1.1.5) Code Type: X86 (Native) Parent Process: launchd [219] Date/Time: 2011-08-17 10:19:36.742 -0500 OS Version: Mac OS X 10.6.8 (10K540) Report Version: 6 Interval Since Last Report: 2498843 sec Crashes Since Last Report: 5 Per-App Interval Since Last Report: 2225316 sec Per-App Crashes Since Last Report: 4 Anonymous UUID: 30D5FBB7-E93E-4AE6-B690-46E1E1D29CB8 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 Racket 0x00222e14 scheme_do_close_managed + 308 1 Racket 0x00224dfd do_close_managed + 29 2 Racket 0x00224f0d check_scheduled_kills + 173 3 Racket 0x00221593 scheme_thread_block + 195 4 Racket 0x00224655 scheme_out_of_fuel + 37 5 Racket 0x00173b12 scheme_get_byte_string_unless + 2546 6 Racket 0x00174369 scheme_get_bytes + 89 7 Racket 0x001aead3 read_inner_inner + 29027 8 Racket 0x001b0c58 _internal_read + 1016 9 Racket 0x001b1407 scheme_internal_read_k + 247 10 Racket 0x0007a733 scheme_top_level_do_worker + 931 11 Racket 0x0007b1b8 scheme_top_level_do + 40 12 Racket 0x001b115e scheme_internal_read + 318 13 Racket 0x00183538 do_read_f + 376 14 ??? 0x00380748 0 + 3671880 15 Racket 0x0005c6aa scheme_do_eval + 10122 16 Racket 0x0007017c do_dyn_wind + 44 17 Racket 0x00076675 scheme_dynamic_wind + 805 18 Racket 0x00076c9e dynamic_wind + 318 19 ??? 0x0037a9c9 0 + 3647945 20 ??? 0x00381854 0 + 3676244 21 Racket 0x0005c6aa scheme_do_eval + 10122 22 Racket 0x00077ca8 scheme_finish_apply_for_prompt + 696 23 Racket 0x00077e60 scheme_apply_for_prompt + 112 24 Racket 0x00083838 call_with_prompt + 1208 25 ??? 0x0037a9c9 0 + 3647945 26 ??? 0x00380270 0 + 3670640 27 ??? 0x15a21cd4 0 + 362945748 28 ??? 0x003809b4 0 + 3672500 29 Racket 0x0005c6aa scheme_do_eval + 10122 30 Racket 0x0005f2ec _scheme_apply_multi_from_native + 92 31 ??? 0x0037a962 0 + 3647842 32 Racket 0x0005c6aa scheme_do_eval + 10122 33 Racket 0x00078f62 call_with_values + 194 34 ??? 0x0037feb9 0 + 3669689 35 ??? 0x00398b90 0 + 3771280 36 Racket 0x0005c6aa scheme_do_eval + 10122 37 Racket 0x00079cda apply_k + 170 38 Racket 0x0007a69f scheme_top_level_do_worker + 783 39 Racket 0x0007b184 scheme_apply_thread_thunk + 116 40 Racket 0x00221031 start_child + 993 41 Racket 0x0022481b make_subprocess + 411 42 Racket 0x00224a56 scheme_thread_w_details + 326 43 ??? 0xbfff3040 0 + 3221172288 44 ??? 0x1d72bb18 0 + 494058264 45 ??? 0x0030 0 + 48 Thread 1: 0 libSystem.B.dylib 0x94a6dafa mach_msg_trap + 10 1 libSystem.B.dylib 0x94a6e267 mach_msg + 68 2 Racket 0x0024f042 exception_thread + 194 3 libSystem.B.dylib
Re: [racket-dev] [plt] Push #23306: master branch updated
5 minutes ago, mfl...@racket-lang.org wrote: e61ea77 Matthew Flatt mfl...@racket-lang.org 2011-08-19 19:37 : | fix `path-element?' collision | | Is there a better name than `path-piece?'? Maybe `path-part?'? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23306: master branch updated
On Fri, Aug 19, 2011 at 9:55 PM, mfl...@racket-lang.org wrote: | Is there a better name than `path-piece?'? `path-component?' -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sporadic failure when building PLaneT docs
On Fri, Aug 19, 2011 at 12:50 PM, Eli Barzilay e...@barzilay.org wrote: Three hours ago, Robby Findler wrote: I'm not seeing anything when looking at your code that looks suspicious, but I'm not sure of the ins and outs of the sandbox protocols so I'm not sure who to blame here (well, probably the sandbox needs to be blamed since the error is not illuminating, but there may be other problems that that error is masking). One difference that I notice is that scribble's make-base-eval doesn't create the evaluator in the same way your code does; it uses a different argument to make-evaluator that puts the evaluator into a different mode somehow. That could be relevant. Maybe Eli can say more? I have no idea what the problem is, or how to get it without involving planet. I don't see why that should stop you. To spur you along, I've noticed that the sandbox creates a module with the name 'program from the use-lang function on line 518 which seems to be making its way over to the argument to evaluate-program (line 564) and from there the module is required but without, apparently, ever evaluating the module (or maybe evaluating it in a different namespace). This sure seems like something that someone who is familiar with how the sandbox code works could shed some light on. I tried working through the code a little bit this evening but find it difficult to read. For example, I think code like this: (when ns (set! ns (ns))) is bad style; when you're using ns for a variable to stand for namespace you should probably make sure it is bound to a namespace, or use something else. Also, it seems unwise to add that kind of imperative dependency to reasoning about what is going on with 'ns' and when it is (may be) created. I would have used two variables. I'll also note that this line seems like it can lead to a bug because shortly thereafter I see this: (when ns (current-namespace ns)) which looks like it can fail in the case that the limit-thunk does something to above the computation that does the set!. I can't tell for sure if this can happen because I got lost in the call-with-limits. I did notice that call-with-limits has this (let ([r #f]) ..stuff.. (define r ...) ...use r ...) in such a way that the outer binding of 'r' is never used which seems a little suspicious. At a min, that unused binding probably be removed, but maybe there is an actual bug there and those two 'r's are supposed to not shadow each other? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sporadic failure when building PLaneT docs
9 minutes ago, Robby Findler wrote: On Fri, Aug 19, 2011 at 12:50 PM, Eli Barzilay e...@barzilay.org wrote: Three hours ago, Robby Findler wrote: Maybe Eli can say more? I have no idea what the problem is, or how to get it without involving planet. I don't see why that should stop you. To spur you along, I've noticed that the sandbox creates a module with the name 'program from the use-lang function on line 518 which seems to be making its way over to the argument to evaluate-program (line 564) and from there the module is required but without, apparently, ever evaluating the module (or maybe evaluating it in a different namespace). This sure seems like something that someone who is familiar with how the sandbox code works could shed some light on. I tried working through the code a little bit this evening but find it difficult to read. I still don't know what this is referring to, besides some getting some vague idea that Danny's code has some problem. For example, I think code like this: (when ns (set! ns (ns))) is bad style; when you're using ns for a variable to stand for namespace you should probably make sure it is bound to a namespace, or use something else. Also, it seems unwise to add that kind of imperative dependency to reasoning about what is going on with 'ns' and when it is (may be) created. I would have used two variables. I'll also note that this line seems like it can lead to a bug because shortly thereafter I see this: (when ns (current-namespace ns)) That's something local to that code, basically: (let ([ns (if something (lambda () compute-some-namespace) #f)]) ... (when ns (set! ns (ns))) ... (when ns (current-namespace ns))) which looks like it can fail in the case that the limit-thunk does something to above the computation that does the set!. I'll add the condition, but it's not a problem since the code that I've seen used a trusted sandbox, which means that `limit-thunk' is not doing anything. (BTW, it's also not a problem in general, since `limit-thunk' can throw an error and kill the whole call.) I can't tell for sure if this can happen because I got lost in the call-with-limits. I did notice that call-with-limits has this (let ([r #f]) ..stuff.. (define r ...) ...use r ...) in such a way that the outer binding of 'r' is never used which seems a little suspicious. At a min, that unused binding probably be removed, but maybe there is an actual bug there and those two 'r's are supposed to not shadow each other? I'll look at that too, but again, with a trusted sandbox, it's all irrelevant to whatever problem Danny's having. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
