At Wed, 8 Nov 2017 10:55:13 -0800, Matthew Butterick wrote:
> > On Nov 8, 2017, at 9:17 AM, Matthew Flatt <> wrote:
> > 
> > DrRacket tries not to interfere with programs in a detectable way.
> Hmm ... so if DrRacket adopts a different set of environment variables from 
> command-line `racket` — which I assume is the correct and just policy — isn't 
> that naturally going to lead to detectable differences, for a program that 
> depends on those variables?

As others have said, both `racket` and `DrRacket` just accept the
environment variables that the environment gives them, and Finder and
bash set up different environments.

> > Is there something more general that you want to test for DrRacket ---
> > some effect on the execution environment that might be due to DrRacket
> > or some other tool/configuration? If so, it could make sense to set up
> > some way of communicating that to a program.
> In this case I was trying to configure a web servlet to run in differently 
> when launched from DrRacket (in terms of its port and servlet-path) to better 
> approximate Apache / htaccess conditions that exist on the live web server. 

I wonder whether a submodule is a better approach here. DrRacket
implicitly runs a `test` submodule, while `racket` doesn't, and you
could add more submodules to the list in DrRacket. But that approach
doesn't work if the conditional adjustment goes in a library, instead
of the main module.

Maybe DrRacket should let you configure environment variables for a
program in the same way that it lets you provide command-line
arguments, and maybe it does make sense to have a default environment
variable that means "running in development mode".

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to