Re: [racket-dev] DrDr hung?
I kicked it. (I check every two nights, btw, and if you notice something, you can email me directly.) On Fri, Apr 4, 2014 at 10:51 PM, Eric Dobson wrote: > DrDr seems to be behind by about 8 pushes (in terms of what it is > showing in the UI) currently and is stuck running on push 28468 for 36 > hours. > _ > Racket Developers list: > http://lists.racket-lang.org/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
Altho if someone wanted to improve this somehow (make macro expansion faster? Find better ways to exploit parallel hardware?) then that would be really awesome. Robby On Sat, Apr 5, 2014 at 10:38 AM, Robby Findler wrote: > That sounds difficult. > > > On Saturday, April 5, 2014, Eric Dobson wrote: > >> Also this is a poor solution for me because `raco make` compiles all >> the dependencies serially. I have also tried doing 'raco setup -D' for >> the packages I am dependent on but that has the issue of compiling >> everything in those packages which is over kill (and thus slower than >> needed). >> >> My end goal is a very fast edit/test loop (~100ms), which may be >> impossible but I want to be aggressive. >> >> >> On Sat, Apr 5, 2014 at 8:14 AM, Robby Findler >> wrote: >> > Yes, Sam. I don't think anyone is happy with the status quo. >> > >> > Perhaps the tradeoffs have changed since last time a careful >> investigation >> > happened. >> > >> > Robby >> > >> > >> > On Saturday, April 5, 2014, Sam Tobin-Hochstadt >> > wrote: >> >> >> >> I don't think this is a good answer for Racket. Certainly the docs >> >> don't say that you need to always do this if you want your program to >> >> work right. If Racket doesn't work right in the presence of stale >> >> compiled filed, then it should just error in those cases, rather than >> >> doing the wrong thing. Of course it would be better to work correctly >> >> in that case, but this is a hard problem, and it's reasonable to not >> >> have a solution. But having the system act like it works when it >> >> doesn't is worse. >> >> >> >> Sam >> >> >> >> On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler >> >> wrote: >> >> > raco make x.rkt && racket x.rkt >> >> > >> >> > Robby >> >> > >> >> > >> >> > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson < >> eric.n.dob...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Great that explains it and with that information I was able to >> >> >> simplify my test case to >> >> >> >> >> >> tmp.rkt >> >> >> #lang racket >> >> >> >> >> >> (require "tmp2.rkt") >> >> >> >> >> >> (define-syntax (go stx) >> >> >> (foo)) >> >> >> >> >> >> (go) >> >> >> >> >> >> tmp2.rkt >> >> >> #lang racket >> >> >> >> >> >> (provide (for-syntax foo)) >> >> >> >> >> >> (begin-for-syntax >> >> >> (define (foo) #'3)) >> >> >> >> >> >> So now the question is how do I run my code so as to not be bit by >> >> >> this? I want a command to run my program that is both fast to run >> and >> >> >> correct with regards to my source. My previous assumption was that >> the >> >> >> zo file's logic was safe if I wasn't trying to break it but I now >> know >> >> >> better. Is my only option to either always compile or never compile? >> >> >> >> >> >> >> >> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt >> >> >> wrote: >> >> >> > If I understand the question: >> >> >> > >> >> >> > * With 34c3eed615, "pr12644.rkt" can compile and run. >> >> >> > >> >> >> > * With d29df205f7, "pr12644.rkt" fails to compile. >> >> >> > >> >> >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can >> >> >> > still >> >> >> >run in d29df205f7, because run-time support for "pr12644.rkt" >> >> >> > didn't >> >> >> >change. >> >> >> > >> >> >> > * When you tell `racket` to run "pr12644.rkt", it will use a >> ".zo" >> >> >> > for >> >> >> >each of "pr12644.rkt" and its dependencies as long each >> individual >> >> >> >".zo" file has a newer timestamp than its ".rkt" file. That is, >> >> >> > the >> >> >> >only timestamp comparisons are on individual ".rkt" and ".zo" >> >> >> > pairs. >> >> >> > >> >> >> > * When you tell `raco make` to build "pr12644.rkt", it checks >> >> >> >dependencies (via ".dep" file) and compares a ".rkt" file's >> >> >> >timestamp against the times of all of its dependencies, >> instead of >> >> >> >just checking individual ".rkt" and ".zo" pairs. That's why a< > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
That sounds difficult. On Saturday, April 5, 2014, Eric Dobson wrote: > Also this is a poor solution for me because `raco make` compiles all > the dependencies serially. I have also tried doing 'raco setup -D' for > the packages I am dependent on but that has the issue of compiling > everything in those packages which is over kill (and thus slower than > needed). > > My end goal is a very fast edit/test loop (~100ms), which may be > impossible but I want to be aggressive. > > > On Sat, Apr 5, 2014 at 8:14 AM, Robby Findler > wrote: > > Yes, Sam. I don't think anyone is happy with the status quo. > > > > Perhaps the tradeoffs have changed since last time a careful > investigation > > happened. > > > > Robby > > > > > > On Saturday, April 5, 2014, Sam Tobin-Hochstadt > > wrote: > >> > >> I don't think this is a good answer for Racket. Certainly the docs > >> don't say that you need to always do this if you want your program to > >> work right. If Racket doesn't work right in the presence of stale > >> compiled filed, then it should just error in those cases, rather than > >> doing the wrong thing. Of course it would be better to work correctly > >> in that case, but this is a hard problem, and it's reasonable to not > >> have a solution. But having the system act like it works when it > >> doesn't is worse. > >> > >> Sam > >> > >> On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler > >> wrote: > >> > raco make x.rkt && racket x.rkt > >> > > >> > Robby > >> > > >> > > >> > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson > > >> > wrote: > >> >> > >> >> Great that explains it and with that information I was able to > >> >> simplify my test case to > >> >> > >> >> tmp.rkt > >> >> #lang racket > >> >> > >> >> (require "tmp2.rkt") > >> >> > >> >> (define-syntax (go stx) > >> >> (foo)) > >> >> > >> >> (go) > >> >> > >> >> tmp2.rkt > >> >> #lang racket > >> >> > >> >> (provide (for-syntax foo)) > >> >> > >> >> (begin-for-syntax > >> >> (define (foo) #'3)) > >> >> > >> >> So now the question is how do I run my code so as to not be bit by > >> >> this? I want a command to run my program that is both fast to run and > >> >> correct with regards to my source. My previous assumption was that > the > >> >> zo file's logic was safe if I wasn't trying to break it but I now > know > >> >> better. Is my only option to either always compile or never compile? > >> >> > >> >> > >> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt > >> >> wrote: > >> >> > If I understand the question: > >> >> > > >> >> > * With 34c3eed615, "pr12644.rkt" can compile and run. > >> >> > > >> >> > * With d29df205f7, "pr12644.rkt" fails to compile. > >> >> > > >> >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can > >> >> > still > >> >> >run in d29df205f7, because run-time support for "pr12644.rkt" > >> >> > didn't > >> >> >change. > >> >> > > >> >> > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" > >> >> > for > >> >> >each of "pr12644.rkt" and its dependencies as long each > individual > >> >> >".zo" file has a newer timestamp than its ".rkt" file. That is, > >> >> > the > >> >> >only timestamp comparisons are on individual ".rkt" and ".zo" > >> >> > pairs. > >> >> > > >> >> > * When you tell `raco make` to build "pr12644.rkt", it checks > >> >> >dependencies (via ".dep" file) and compares a ".rkt" file's > >> >> >timestamp against the times of all of its dependencies, instead > of > >> >> >just checking individual ".rkt" and ".zo" pairs. That's why a< _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
Also this is a poor solution for me because `raco make` compiles all the dependencies serially. I have also tried doing 'raco setup -D' for the packages I am dependent on but that has the issue of compiling everything in those packages which is over kill (and thus slower than needed). My end goal is a very fast edit/test loop (~100ms), which may be impossible but I want to be aggressive. On Sat, Apr 5, 2014 at 8:14 AM, Robby Findler wrote: > Yes, Sam. I don't think anyone is happy with the status quo. > > Perhaps the tradeoffs have changed since last time a careful investigation > happened. > > Robby > > > On Saturday, April 5, 2014, Sam Tobin-Hochstadt > wrote: >> >> I don't think this is a good answer for Racket. Certainly the docs >> don't say that you need to always do this if you want your program to >> work right. If Racket doesn't work right in the presence of stale >> compiled filed, then it should just error in those cases, rather than >> doing the wrong thing. Of course it would be better to work correctly >> in that case, but this is a hard problem, and it's reasonable to not >> have a solution. But having the system act like it works when it >> doesn't is worse. >> >> Sam >> >> On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler >> wrote: >> > raco make x.rkt && racket x.rkt >> > >> > Robby >> > >> > >> > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson >> > wrote: >> >> >> >> Great that explains it and with that information I was able to >> >> simplify my test case to >> >> >> >> tmp.rkt >> >> #lang racket >> >> >> >> (require "tmp2.rkt") >> >> >> >> (define-syntax (go stx) >> >> (foo)) >> >> >> >> (go) >> >> >> >> tmp2.rkt >> >> #lang racket >> >> >> >> (provide (for-syntax foo)) >> >> >> >> (begin-for-syntax >> >> (define (foo) #'3)) >> >> >> >> So now the question is how do I run my code so as to not be bit by >> >> this? I want a command to run my program that is both fast to run and >> >> correct with regards to my source. My previous assumption was that the >> >> zo file's logic was safe if I wasn't trying to break it but I now know >> >> better. Is my only option to either always compile or never compile? >> >> >> >> >> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt >> >> wrote: >> >> > If I understand the question: >> >> > >> >> > * With 34c3eed615, "pr12644.rkt" can compile and run. >> >> > >> >> > * With d29df205f7, "pr12644.rkt" fails to compile. >> >> > >> >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can >> >> > still >> >> >run in d29df205f7, because run-time support for "pr12644.rkt" >> >> > didn't >> >> >change. >> >> > >> >> > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" >> >> > for >> >> >each of "pr12644.rkt" and its dependencies as long each individual >> >> >".zo" file has a newer timestamp than its ".rkt" file. That is, >> >> > the >> >> >only timestamp comparisons are on individual ".rkt" and ".zo" >> >> > pairs. >> >> > >> >> > * When you tell `raco make` to build "pr12644.rkt", it checks >> >> >dependencies (via ".dep" file) and compares a ".rkt" file's >> >> >timestamp against the times of all of its dependencies, instead of >> >> >just checking individual ".rkt" and ".zo" pairs. That's why a >> >> > `raco >> >> >make` in d29df205f7 tries to recompile "pr12644.rkt". >> >> > >> >> > At Thu, 3 Apr 2014 09:41:19 -0700, Eric Dobson wrote: >> >> >> I have seen multiple times changes in TR not getting properly >> >> >> propogated to TR programs in my debugging, and I finally have found >> >> >> a >> >> >> repeatable example. >> >> >> >> >> >> I am under the impression that if I compile a file and then change a >> >> >> (transitive) dependency of it, then it should have to be recompiled, >> >> >> but I am not seeing that. >> >> >> >> >> >> Steps to reproduce: >> >> >> git checkout 34c3eed6155765a1e457f69194786575128a13a5 >> >> >> raco setup -D typed-racket typed >> >> >> raco make >> >> >> >> >> >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> >> >> >> >> The test should run successfully and output '(6 7 8 9) >> >> >> >> >> >> Now make the change (rolling forward one commit): >> >> >> git checkout d29df205f7bb8347f60c82206b74e3e167e2de24 >> >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> >> raco make >> >> >> >> >> >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> >> >> >> >> The test runs the first time successfully but fails if you try to >> >> >> compile it again. Can someone explain why this is not working like I >> >> >> expect? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
Yes, Sam. I don't think anyone is happy with the status quo. Perhaps the tradeoffs have changed since last time a careful investigation happened. Robby On Saturday, April 5, 2014, Sam Tobin-Hochstadt wrote: > I don't think this is a good answer for Racket. Certainly the docs > don't say that you need to always do this if you want your program to > work right. If Racket doesn't work right in the presence of stale > compiled filed, then it should just error in those cases, rather than > doing the wrong thing. Of course it would be better to work correctly > in that case, but this is a hard problem, and it's reasonable to not > have a solution. But having the system act like it works when it > doesn't is worse. > > Sam > > On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler > wrote: > > raco make x.rkt && racket x.rkt > > > > Robby > > > > > > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson > > wrote: > >> > >> Great that explains it and with that information I was able to > >> simplify my test case to > >> > >> tmp.rkt > >> #lang racket > >> > >> (require "tmp2.rkt") > >> > >> (define-syntax (go stx) > >> (foo)) > >> > >> (go) > >> > >> tmp2.rkt > >> #lang racket > >> > >> (provide (for-syntax foo)) > >> > >> (begin-for-syntax > >> (define (foo) #'3)) > >> > >> So now the question is how do I run my code so as to not be bit by > >> this? I want a command to run my program that is both fast to run and > >> correct with regards to my source. My previous assumption was that the > >> zo file's logic was safe if I wasn't trying to break it but I now know > >> better. Is my only option to either always compile or never compile? > >> > >> > >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt > wrote: > >> > If I understand the question: > >> > > >> > * With 34c3eed615, "pr12644.rkt" can compile and run. > >> > > >> > * With d29df205f7, "pr12644.rkt" fails to compile. > >> > > >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can still > >> >run in d29df205f7, because run-time support for "pr12644.rkt" > didn't > >> >change. > >> > > >> > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" > for > >> >each of "pr12644.rkt" and its dependencies as long each individual > >> >".zo" file has a newer timestamp than its ".rkt" file. That is, the > >> >only timestamp comparisons are on individual ".rkt" and ".zo" > pairs. > >> > > >> > * When you tell `raco make` to build "pr12644.rkt", it checks > >> >dependencies (via ".dep" file) and compares a ".rkt" file's > >> >timestamp against the times of all of its dependencies, instead of > >> >just checking individual ".rkt" and ".zo" pairs. That's why a `raco > >> >make` in d29df205f7 tries to recompile "pr12644.rkt". > >> > > >> > At Thu, 3 Apr 2014 09:41:19 -0700, Eric Dobson wrote: > >> >> I have seen multiple times changes in TR not getting properly > >> >> propogated to TR programs in my debugging, and I finally have found a > >> >> repeatable example. > >> >> > >> >> I am under the impression that if I compile a file and then change a > >> >> (transitive) dependency of it, then it should have to be recompiled, > >> >> but I am not seeing that. > >> >> > >> >> Steps to reproduce: > >> >> git checkout 34c3eed6155765a1e457f69194786575128a13a5 > >> >> raco setup -D typed-racket typed > >> >> raco make > >> >> > >> >> > pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt > >> >> racket -l tests/typed-racket/succeed/pr12644 > >> >> > >> >> The test should run successfully and output '(6 7 8 9) > >> >> > >> >> Now make the change (rolling forward one commit): > >> >> git checkout d29df205f7bb8347f60c82206b74e3e167e2de24 > >> >> racket -l tests/typed-racket/succeed/pr12644 > >> >> raco make > >> >> > >> >> > pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt > >> >> > >> >> The test runs the first time successfully but fails if you try to > >> >> compile it again. Can someone explain why this is not working like I > >> >> expect? > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
I don't think this is a good answer for Racket. Certainly the docs don't say that you need to always do this if you want your program to work right. If Racket doesn't work right in the presence of stale compiled filed, then it should just error in those cases, rather than doing the wrong thing. Of course it would be better to work correctly in that case, but this is a hard problem, and it's reasonable to not have a solution. But having the system act like it works when it doesn't is worse. Sam On Sat, Apr 5, 2014 at 8:13 AM, Robby Findler wrote: > raco make x.rkt && racket x.rkt > > Robby > > > On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson > wrote: >> >> Great that explains it and with that information I was able to >> simplify my test case to >> >> tmp.rkt >> #lang racket >> >> (require "tmp2.rkt") >> >> (define-syntax (go stx) >> (foo)) >> >> (go) >> >> tmp2.rkt >> #lang racket >> >> (provide (for-syntax foo)) >> >> (begin-for-syntax >> (define (foo) #'3)) >> >> So now the question is how do I run my code so as to not be bit by >> this? I want a command to run my program that is both fast to run and >> correct with regards to my source. My previous assumption was that the >> zo file's logic was safe if I wasn't trying to break it but I now know >> better. Is my only option to either always compile or never compile? >> >> >> On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt wrote: >> > If I understand the question: >> > >> > * With 34c3eed615, "pr12644.rkt" can compile and run. >> > >> > * With d29df205f7, "pr12644.rkt" fails to compile. >> > >> > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can still >> >run in d29df205f7, because run-time support for "pr12644.rkt" didn't >> >change. >> > >> > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" for >> >each of "pr12644.rkt" and its dependencies as long each individual >> >".zo" file has a newer timestamp than its ".rkt" file. That is, the >> >only timestamp comparisons are on individual ".rkt" and ".zo" pairs. >> > >> > * When you tell `raco make` to build "pr12644.rkt", it checks >> >dependencies (via ".dep" file) and compares a ".rkt" file's >> >timestamp against the times of all of its dependencies, instead of >> >just checking individual ".rkt" and ".zo" pairs. That's why a `raco >> >make` in d29df205f7 tries to recompile "pr12644.rkt". >> > >> > At Thu, 3 Apr 2014 09:41:19 -0700, Eric Dobson wrote: >> >> I have seen multiple times changes in TR not getting properly >> >> propogated to TR programs in my debugging, and I finally have found a >> >> repeatable example. >> >> >> >> I am under the impression that if I compile a file and then change a >> >> (transitive) dependency of it, then it should have to be recompiled, >> >> but I am not seeing that. >> >> >> >> Steps to reproduce: >> >> git checkout 34c3eed6155765a1e457f69194786575128a13a5 >> >> raco setup -D typed-racket typed >> >> raco make >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> >> >> The test should run successfully and output '(6 7 8 9) >> >> >> >> Now make the change (rolling forward one commit): >> >> git checkout d29df205f7bb8347f60c82206b74e3e167e2de24 >> >> racket -l tests/typed-racket/succeed/pr12644 >> >> raco make >> >> >> >> pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt >> >> >> >> The test runs the first time successfully but fails if you try to >> >> compile it again. Can someone explain why this is not working like I >> >> expect? >> >> _ >> >> Racket Developers list: >> >> http://lists.racket-lang.org/dev >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile cache being incorrect
raco make x.rkt && racket x.rkt Robby On Fri, Apr 4, 2014 at 11:16 PM, Eric Dobson wrote: > Great that explains it and with that information I was able to > simplify my test case to > > tmp.rkt > #lang racket > > (require "tmp2.rkt") > > (define-syntax (go stx) > (foo)) > > (go) > > tmp2.rkt > #lang racket > > (provide (for-syntax foo)) > > (begin-for-syntax > (define (foo) #'3)) > > So now the question is how do I run my code so as to not be bit by > this? I want a command to run my program that is both fast to run and > correct with regards to my source. My previous assumption was that the > zo file's logic was safe if I wasn't trying to break it but I now know > better. Is my only option to either always compile or never compile? > > > On Fri, Apr 4, 2014 at 7:15 AM, Matthew Flatt wrote: > > If I understand the question: > > > > * With 34c3eed615, "pr12644.rkt" can compile and run. > > > > * With d29df205f7, "pr12644.rkt" fails to compile. > > > > * A bytecode form of "pr12644.rkt" compiled with 34c3eed615 can still > >run in d29df205f7, because run-time support for "pr12644.rkt" didn't > >change. > > > > * When you tell `racket` to run "pr12644.rkt", it will use a ".zo" for > >each of "pr12644.rkt" and its dependencies as long each individual > >".zo" file has a newer timestamp than its ".rkt" file. That is, the > >only timestamp comparisons are on individual ".rkt" and ".zo" pairs. > > > > * When you tell `raco make` to build "pr12644.rkt", it checks > >dependencies (via ".dep" file) and compares a ".rkt" file's > >timestamp against the times of all of its dependencies, instead of > >just checking individual ".rkt" and ".zo" pairs. That's why a `raco > >make` in d29df205f7 tries to recompile "pr12644.rkt". > > > > At Thu, 3 Apr 2014 09:41:19 -0700, Eric Dobson wrote: > >> I have seen multiple times changes in TR not getting properly > >> propogated to TR programs in my debugging, and I finally have found a > >> repeatable example. > >> > >> I am under the impression that if I compile a file and then change a > >> (transitive) dependency of it, then it should have to be recompiled, > >> but I am not seeing that. > >> > >> Steps to reproduce: > >> git checkout 34c3eed6155765a1e457f69194786575128a13a5 > >> raco setup -D typed-racket typed > >> raco make > >> > pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt > >> racket -l tests/typed-racket/succeed/pr12644 > >> > >> The test should run successfully and output '(6 7 8 9) > >> > >> Now make the change (rolling forward one commit): > >> git checkout d29df205f7bb8347f60c82206b74e3e167e2de24 > >> racket -l tests/typed-racket/succeed/pr12644 > >> raco make > >> > pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/pr12644.rkt > >> > >> The test runs the first time successfully but fails if you try to > >> compile it again. Can someone explain why this is not working like I > >> expect? > >> _ > >> Racket Developers list: > >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
