Re: [racket-dev] A strange problem with namespaces
On Wed, May 7, 2014 at 11:57 AM, Matthew Flatt wrote: > I see. The errors are about the modules that require "evaluator.rkt". > That is, the modules that use `phase1-phase0-eval` need to be > available, not just "evaluator.rkt", so that transformer bindings in > those modules can be used. > > So, ... Thanks, that works. Sadly, I guess that's means we can't add an option to `namespace-anchor->namespace` to do this correctly. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
I see. The errors are about the modules that require "evaluator.rkt". That is, the modules that use `phase1-phase0-eval` need to be available, not just "evaluator.rkt", so that transformer bindings in those modules can be used. So, (define (prep! varref) (define p (variable-reference->resolved-module-path varref)) (when p (parameterize ([current-namespace namespace]) (dynamic-require p 0 ... (define-syntax phase1-phase0-eval (syntax-parser [(_ form:expr ...) #'(begin (prep! (#%variable-reference)) (eval-syntax ))])) (define-syntax phase1-eval (syntax-parser [(_ form:expr ...) #'(begin (prep! (#%variable-reference)) (phase1-phase0-eval ))])) A way to look at it is that you want an anchor in each module that uses `phase1-phase0-eval`, and `(#%variable-reference)` is the primitive form of an anchor. At Wed, 7 May 2014 11:43:39 -0400, Sam Tobin-Hochstadt wrote: > On Wed, May 7, 2014 at 11:07 AM, Sam Tobin-Hochstadt > wrote: > > Great, thanks! > > Also, can you say more about when this trick is needed? When I try to > use it in the actual code that I want to run, I end up with the same > error, or about other submodules that are missing. > > More specifically, I added `prep!` to > `tests/typed-racket/unit-tests/evaluator.rkt` and then ran this > program: > > #lang racket > (define ns (make-base-namespace)) > (current-namespace ns) > ((dynamic-require 'tests/typed-racket/main 'go/text) > (dynamic-require 'tests/typed-racket/main 'unit-tests)) > > It produces lots of errors, of the same form that `weird.rkt` had > before the `prep!` fix. You get the same errors if you take out the > namespace. > > However, there aren't any other uses of namespace anchors in that > code, so I'm not sure what to try to fix. > > Sam > > > > > > On Wed, May 7, 2014 at 10:58 AM, Matthew Flatt wrote: > >> I think the right change might be > >> > >> (module evaluator racket > >> > >>(define (prep!) > >> (parameterize ([current-namespace namespace]) > >>(dynamic-require (variable-reference->module-path-index > >> (#%variable-reference)) > >> 0))) > >> > >>(define-syntax phase1-phase0-eval > >> (syntax-parser > >> [(_ form:expr ...) > >>#'(begin > >>(prep!) > >>(eval-syntax .))]))) > >> > >> The `prep!` function ensures that the enclosing module is available. > >> > >> At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: > >>> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works > >>> when line 33 is uncommented, otherwise it gives the error: > >>> > >>> ?: module mismatch; > >>> attempted to use a module that is not available > >>> possible cause: > >>>using (dynamic-require #f) > >>>but need (dynamic-require 0) > >>> module: (submod "weird.rkt" evaluator) > >>> phase: 0 > >>> in: phase1-phase0-run > >>> context...: > >>>weird.rkt: [running body] > >>> > >>> From reading the docs on `dynamic-require`, I can see that > >>> `(dynamic-require m 'f)` doesn't make anything available for higher > >>> phases. However, the actual `dynamic-require` in the program is just > >>> for a function -- the need for higher phases is an implementation > >>> detail that's leaking in because it doesn't behave like a regular > >>> value wrt `dynamic-require`. > >>> > >>> Is there something I can change in the implementation of the internals > >>> of `f` so that clients of `f` don't need to do the extra > >>> `(dynamic-require m 0)` in order for `f` to work? > >>> > >>> Sam > >>> _ > >>> Racket Developers list: > >>> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
On Wed, May 7, 2014 at 11:07 AM, Sam Tobin-Hochstadt wrote: > Great, thanks! Also, can you say more about when this trick is needed? When I try to use it in the actual code that I want to run, I end up with the same error, or about other submodules that are missing. More specifically, I added `prep!` to `tests/typed-racket/unit-tests/evaluator.rkt` and then ran this program: #lang racket (define ns (make-base-namespace)) (current-namespace ns) ((dynamic-require 'tests/typed-racket/main 'go/text) (dynamic-require 'tests/typed-racket/main 'unit-tests)) It produces lots of errors, of the same form that `weird.rkt` had before the `prep!` fix. You get the same errors if you take out the namespace. However, there aren't any other uses of namespace anchors in that code, so I'm not sure what to try to fix. Sam > > On Wed, May 7, 2014 at 10:58 AM, Matthew Flatt wrote: >> I think the right change might be >> >> (module evaluator racket >> >>(define (prep!) >> (parameterize ([current-namespace namespace]) >>(dynamic-require (variable-reference->module-path-index >> (#%variable-reference)) >> 0))) >> >>(define-syntax phase1-phase0-eval >> (syntax-parser >> [(_ form:expr ...) >>#'(begin >>(prep!) >>(eval-syntax .))]))) >> >> The `prep!` function ensures that the enclosing module is available. >> >> At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: >>> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >>> when line 33 is uncommented, otherwise it gives the error: >>> >>> ?: module mismatch; >>> attempted to use a module that is not available >>> possible cause: >>>using (dynamic-require #f) >>>but need (dynamic-require 0) >>> module: (submod "weird.rkt" evaluator) >>> phase: 0 >>> in: phase1-phase0-run >>> context...: >>>weird.rkt: [running body] >>> >>> From reading the docs on `dynamic-require`, I can see that >>> `(dynamic-require m 'f)` doesn't make anything available for higher >>> phases. However, the actual `dynamic-require` in the program is just >>> for a function -- the need for higher phases is an implementation >>> detail that's leaking in because it doesn't behave like a regular >>> value wrt `dynamic-require`. >>> >>> Is there something I can change in the implementation of the internals >>> of `f` so that clients of `f` don't need to do the extra >>> `(dynamic-require m 0)` in order for `f` to work? >>> >>> Sam >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
No, the `evaluator` module wasn't available anywhere. I'll work on the definition of "available" in the docs. "Available at phase 0" implies that you can use macros that are bound at phase 0 and whose implementations live at phase 1. At Wed, 7 May 2014 10:03:25 -0500, Robby Findler wrote: > Oh! So the evaluator module is available in phase 0 in 'ns', but not > in 'namespace'. Is that right? > > Robby > > On Wed, May 7, 2014 at 9:58 AM, Matthew Flatt wrote: > > I think the right change might be > > > > (module evaluator racket > > > >(define (prep!) > > (parameterize ([current-namespace namespace]) > >(dynamic-require (variable-reference->module-path-index > > (#%variable-reference)) > > 0))) > > > >(define-syntax phase1-phase0-eval > > (syntax-parser > > [(_ form:expr ...) > >#'(begin > >(prep!) > >(eval-syntax .))]))) > > > > The `prep!` function ensures that the enclosing module is available. > > > > At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: > >> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works > >> when line 33 is uncommented, otherwise it gives the error: > >> > >> ?: module mismatch; > >> attempted to use a module that is not available > >> possible cause: > >>using (dynamic-require #f) > >>but need (dynamic-require 0) > >> module: (submod "weird.rkt" evaluator) > >> phase: 0 > >> in: phase1-phase0-run > >> context...: > >>weird.rkt: [running body] > >> > >> From reading the docs on `dynamic-require`, I can see that > >> `(dynamic-require m 'f)` doesn't make anything available for higher > >> phases. However, the actual `dynamic-require` in the program is just > >> for a function -- the need for higher phases is an implementation > >> detail that's leaking in because it doesn't behave like a regular > >> value wrt `dynamic-require`. > >> > >> Is there something I can change in the implementation of the internals > >> of `f` so that clients of `f` don't need to do the extra > >> `(dynamic-require m 0)` in order for `f` to work? > >> > >> Sam > >> _ > >> 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] A strange problem with namespaces
Adding an option to `namespace-anchor->empty-namespace` makes sense. I'm not sure that it should be the default behavior, and so I lean toward keeping the default behavior the same as it is. At Wed, 7 May 2014 11:07:32 -0400, Sam Tobin-Hochstadt wrote: > Great, thanks! > > Is there a reason that this shouldn't be part of the behavior of > `namespace-anchor->empty-namespace`? > > Sam > > On Wed, May 7, 2014 at 10:58 AM, Matthew Flatt wrote: > > I think the right change might be > > > > (module evaluator racket > > > >(define (prep!) > > (parameterize ([current-namespace namespace]) > >(dynamic-require (variable-reference->module-path-index > > (#%variable-reference)) > > 0))) > > > >(define-syntax phase1-phase0-eval > > (syntax-parser > > [(_ form:expr ...) > >#'(begin > >(prep!) > >(eval-syntax .))]))) > > > > The `prep!` function ensures that the enclosing module is available. > > > > At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: > >> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works > >> when line 33 is uncommented, otherwise it gives the error: > >> > >> ?: module mismatch; > >> attempted to use a module that is not available > >> possible cause: > >>using (dynamic-require #f) > >>but need (dynamic-require 0) > >> module: (submod "weird.rkt" evaluator) > >> phase: 0 > >> in: phase1-phase0-run > >> context...: > >>weird.rkt: [running body] > >> > >> From reading the docs on `dynamic-require`, I can see that > >> `(dynamic-require m 'f)` doesn't make anything available for higher > >> phases. However, the actual `dynamic-require` in the program is just > >> for a function -- the need for higher phases is an implementation > >> detail that's leaking in because it doesn't behave like a regular > >> value wrt `dynamic-require`. > >> > >> Is there something I can change in the implementation of the internals > >> of `f` so that clients of `f` don't need to do the extra > >> `(dynamic-require m 0)` in order for `f` to work? > >> > >> Sam > >> _ > >> Racket Developers list: > >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
Great, thanks! Is there a reason that this shouldn't be part of the behavior of `namespace-anchor->empty-namespace`? Sam On Wed, May 7, 2014 at 10:58 AM, Matthew Flatt wrote: > I think the right change might be > > (module evaluator racket > >(define (prep!) > (parameterize ([current-namespace namespace]) >(dynamic-require (variable-reference->module-path-index > (#%variable-reference)) > 0))) > >(define-syntax phase1-phase0-eval > (syntax-parser > [(_ form:expr ...) >#'(begin >(prep!) >(eval-syntax .))]))) > > The `prep!` function ensures that the enclosing module is available. > > At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: >> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >> when line 33 is uncommented, otherwise it gives the error: >> >> ?: module mismatch; >> attempted to use a module that is not available >> possible cause: >>using (dynamic-require #f) >>but need (dynamic-require 0) >> module: (submod "weird.rkt" evaluator) >> phase: 0 >> in: phase1-phase0-run >> context...: >>weird.rkt: [running body] >> >> From reading the docs on `dynamic-require`, I can see that >> `(dynamic-require m 'f)` doesn't make anything available for higher >> phases. However, the actual `dynamic-require` in the program is just >> for a function -- the need for higher phases is an implementation >> detail that's leaking in because it doesn't behave like a regular >> value wrt `dynamic-require`. >> >> Is there something I can change in the implementation of the internals >> of `f` so that clients of `f` don't need to do the extra >> `(dynamic-require m 0)` in order for `f` to work? >> >> Sam >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
Oh! So the evaluator module is available in phase 0 in 'ns', but not in 'namespace'. Is that right? Robby On Wed, May 7, 2014 at 9:58 AM, Matthew Flatt wrote: > I think the right change might be > > (module evaluator racket > >(define (prep!) > (parameterize ([current-namespace namespace]) >(dynamic-require (variable-reference->module-path-index > (#%variable-reference)) > 0))) > >(define-syntax phase1-phase0-eval > (syntax-parser > [(_ form:expr ...) >#'(begin >(prep!) >(eval-syntax .))]))) > > The `prep!` function ensures that the enclosing module is available. > > At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: >> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >> when line 33 is uncommented, otherwise it gives the error: >> >> ?: module mismatch; >> attempted to use a module that is not available >> possible cause: >>using (dynamic-require #f) >>but need (dynamic-require 0) >> module: (submod "weird.rkt" evaluator) >> phase: 0 >> in: phase1-phase0-run >> context...: >>weird.rkt: [running body] >> >> From reading the docs on `dynamic-require`, I can see that >> `(dynamic-require m 'f)` doesn't make anything available for higher >> phases. However, the actual `dynamic-require` in the program is just >> for a function -- the need for higher phases is an implementation >> detail that's leaking in because it doesn't behave like a regular >> value wrt `dynamic-require`. >> >> Is there something I can change in the implementation of the internals >> of `f` so that clients of `f` don't need to do the extra >> `(dynamic-require m 0)` in order for `f` to work? >> >> Sam >> _ >> 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] A strange problem with namespaces
I think the right change might be (module evaluator racket (define (prep!) (parameterize ([current-namespace namespace]) (dynamic-require (variable-reference->module-path-index (#%variable-reference)) 0))) (define-syntax phase1-phase0-eval (syntax-parser [(_ form:expr ...) #'(begin (prep!) (eval-syntax .))]))) The `prep!` function ensures that the enclosing module is available. At Wed, 7 May 2014 10:11:49 -0400, Sam Tobin-Hochstadt wrote: > This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works > when line 33 is uncommented, otherwise it gives the error: > > ?: module mismatch; > attempted to use a module that is not available > possible cause: >using (dynamic-require #f) >but need (dynamic-require 0) > module: (submod "weird.rkt" evaluator) > phase: 0 > in: phase1-phase0-run > context...: >weird.rkt: [running body] > > From reading the docs on `dynamic-require`, I can see that > `(dynamic-require m 'f)` doesn't make anything available for higher > phases. However, the actual `dynamic-require` in the program is just > for a function -- the need for higher phases is an implementation > detail that's leaking in because it doesn't behave like a regular > value wrt `dynamic-require`. > > Is there something I can change in the implementation of the internals > of `f` so that clients of `f` don't need to do the extra > `(dynamic-require m 0)` in order for `f` to work? > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A strange problem with namespaces
Yes, I've read those docs many times. :) I'll also note that changing the require in 'f' to this doesn't help, which seems suspicious: (require (submod ".." evaluator) (for-meta 0 (submod ".." evaluator)) (for-meta 1 (submod ".." evaluator)) (for-meta 2 (submod ".." evaluator)) (for-meta 3 (submod ".." evaluator)) (for-meta 4 (submod ".." evaluator)) (for-meta 5 (submod ".." evaluator)) (for-meta -1 (submod ".." evaluator)) (for-meta -2 (submod ".." evaluator)) (for-meta -3 (submod ".." evaluator)) (for-meta -4 (submod ".." evaluator)) (for-meta -5 (submod ".." evaluator))) On Wed, May 7, 2014 at 9:31 AM, Sam Tobin-Hochstadt wrote: > Well, to quote from the docs for `dynamic-require`: > > "When provided is a symbol, the value of the module’s export with the > given name is returned, and still the module is not visited or made > available in higher phases." > > That's why I think the extra line is needed. > > You're right that the error message refers to phase 0, but I'm not > sure who's phase 0 that is. > > Sam > > On Wed, May 7, 2014 at 10:27 AM, Robby Findler > wrote: >> When I look at this code I can't figure out why (submod "weird.rkt" >> evaluator) _isn't_ available at phase 0! Could this be a bug? >> >> Robby >> >> On Wed, May 7, 2014 at 9:11 AM, Sam Tobin-Hochstadt >> wrote: >>> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >>> when line 33 is uncommented, otherwise it gives the error: >>> >>> ?: module mismatch; >>> attempted to use a module that is not available >>> possible cause: >>>using (dynamic-require #f) >>>but need (dynamic-require 0) >>> module: (submod "weird.rkt" evaluator) >>> phase: 0 >>> in: phase1-phase0-run >>> context...: >>>weird.rkt: [running body] >>> >>> From reading the docs on `dynamic-require`, I can see that >>> `(dynamic-require m 'f)` doesn't make anything available for higher >>> phases. However, the actual `dynamic-require` in the program is just >>> for a function -- the need for higher phases is an implementation >>> detail that's leaking in because it doesn't behave like a regular >>> value wrt `dynamic-require`. >>> >>> Is there something I can change in the implementation of the internals >>> of `f` so that clients of `f` don't need to do the extra >>> `(dynamic-require m 0)` in order for `f` to work? >>> >>> Sam >>> _ >>> 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] A strange problem with namespaces
Well, to quote from the docs for `dynamic-require`: "When provided is a symbol, the value of the module’s export with the given name is returned, and still the module is not visited or made available in higher phases." That's why I think the extra line is needed. You're right that the error message refers to phase 0, but I'm not sure who's phase 0 that is. Sam On Wed, May 7, 2014 at 10:27 AM, Robby Findler wrote: > When I look at this code I can't figure out why (submod "weird.rkt" > evaluator) _isn't_ available at phase 0! Could this be a bug? > > Robby > > On Wed, May 7, 2014 at 9:11 AM, Sam Tobin-Hochstadt > wrote: >> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >> when line 33 is uncommented, otherwise it gives the error: >> >> ?: module mismatch; >> attempted to use a module that is not available >> possible cause: >>using (dynamic-require #f) >>but need (dynamic-require 0) >> module: (submod "weird.rkt" evaluator) >> phase: 0 >> in: phase1-phase0-run >> context...: >>weird.rkt: [running body] >> >> From reading the docs on `dynamic-require`, I can see that >> `(dynamic-require m 'f)` doesn't make anything available for higher >> phases. However, the actual `dynamic-require` in the program is just >> for a function -- the need for higher phases is an implementation >> detail that's leaking in because it doesn't behave like a regular >> value wrt `dynamic-require`. >> >> Is there something I can change in the implementation of the internals >> of `f` so that clients of `f` don't need to do the extra >> `(dynamic-require m 0)` in order for `f` to work? >> >> Sam >> _ >> 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] A strange problem with namespaces
When I look at this code I can't figure out why (submod "weird.rkt" evaluator) _isn't_ available at phase 0! Could this be a bug? Robby On Wed, May 7, 2014 at 9:11 AM, Sam Tobin-Hochstadt wrote: > This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works > when line 33 is uncommented, otherwise it gives the error: > > ?: module mismatch; > attempted to use a module that is not available > possible cause: >using (dynamic-require #f) >but need (dynamic-require 0) > module: (submod "weird.rkt" evaluator) > phase: 0 > in: phase1-phase0-run > context...: >weird.rkt: [running body] > > From reading the docs on `dynamic-require`, I can see that > `(dynamic-require m 'f)` doesn't make anything available for higher > phases. However, the actual `dynamic-require` in the program is just > for a function -- the need for higher phases is an implementation > detail that's leaking in because it doesn't behave like a regular > value wrt `dynamic-require`. > > Is there something I can change in the implementation of the internals > of `f` so that clients of `f` don't need to do the extra > `(dynamic-require m 0)` in order for `f` to work? > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] A strange problem with namespaces
This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works when line 33 is uncommented, otherwise it gives the error: ?: module mismatch; attempted to use a module that is not available possible cause: using (dynamic-require #f) but need (dynamic-require 0) module: (submod "weird.rkt" evaluator) phase: 0 in: phase1-phase0-run context...: weird.rkt: [running body] >From reading the docs on `dynamic-require`, I can see that `(dynamic-require m 'f)` doesn't make anything available for higher phases. However, the actual `dynamic-require` in the program is just for a function -- the need for higher phases is an implementation detail that's leaking in because it doesn't behave like a regular value wrt `dynamic-require`. Is there something I can change in the implementation of the internals of `f` so that clients of `f` don't need to do the extra `(dynamic-require m 0)` in order for `f` to work? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] "lab notebook on learning process" (was: Re: Macros baffle me)
2014-05-06 23:48 GMT+02:00 Stephen Chang : >> How about an extra button, a "Run Benchmark" button? > > You can already get this with the "benchmark" package, from pkg.racket-lang. A builtin button will hopefully make it obvious even for non-DrRacket users, that Run is not intended for benchmarks. For those shopping around for a language or an implementation it needs to be painfully clear, what to do in order to get a fair measurement. /Jens Axel >> 2014-05-06 19:43 GMT+02:00 Sam Tobin-Hochstadt : >>> On Tue, May 6, 2014 at 12:14 PM, Matthias Felleisen >>> wrote: > > Why does he think "Performance sucks"? > > Because here's the list of things that are slow DrRacket is an operating system running on top of your other OS to make life for Racket developers simple. It was originally developed for beginners, but I eat my own dog food, and I find it good (tm) for every day Racket work. To evaluate performance, run the programs at the command line. Measure there. Compare with other dynamically typed languages and report back what you find. If you still report performance problems, try to be precise. We are proud of Matthew and how far he has pushed Racket's performance on real software, the kind you use on a daily basis, not just minibenchmarks. >>> >>> I think ultimately that this answer isn't enough. If everyone who >>> tries out Racket in the way we suggest comes away with the impression >>> that it's really slow, suggestions on the mailing list to measure >>> differently won't eliminate the negative first impression, let alone >>> for all the people who _don't_ ask about it. >>> >>> Could we >>> - warn people when they use `time` in DrRacket? >>> - provide a "performance" mode that runs programs out-of-process, or >>> just in another place? >>> - something else? >>> >>> Sam >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> >> >> >> -- >> -- >> Jens Axel Søgaard >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev -- -- Jens Axel Søgaard _ Racket Developers list: http://lists.racket-lang.org/dev
