[racket-dev] raco dwim

2010-09-10 Thread Eli Barzilay
I'm revising my course content now, and I ran into the change that Robby committed a while ago to `raco setup' where it no longer installs plt files by default. I didn't know what would be the best thing to do with it, but I think that there's no problems keeping such instructions with setup-plt

Re: [racket-dev] raco dwim

2010-09-10 Thread Jay McCarthy
This seems like a coherent thing for it to do, but not something that I would personally use. I don't think I'd use it or like having it there because the more complicated the algorithm it uses to choose what to run, the more complicate the algorithm I run in my brain to predict what it will do

Re: [racket-dev] raco dwim

2010-09-10 Thread Eli Barzilay
On Sep 10, Jay McCarthy wrote: This seems like a coherent thing for it to do, but not something that I would personally use. I don't think I'd use it or like having it there because the more complicated the algorithm it uses to choose what to run, the more complicate the algorithm I run in my

[racket-dev] Shared-instantiation modules

2010-09-10 Thread John Clements
Seems like a FAQ, but: I want to associate a single sound player with a drscheme process. When student code runs, it needs to send messages to that sound player. I want to make sure there's only one running at a time. The first thing that pops into my head is some kind of shared-require

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread Ryan Culpepper
The way the rackunit tool does it (to make the rackunit gui DrRacket-aware) is to attach a module into the user namespace on every execution by overriding the 'reset-console' method of drracket:rep:text%. See rackunit/tool.rkt for the code. Then you can have a module/teachpack that just

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread Robby Findler
FWIW, this is one path that tools can use to circumvent DrRacket's property (well, the property we work towards anyways) that no program can cause DrRacket itself to crash or freeze. So if you do provide things to the user's program in this manner, please try to keep that invariant in mind. Robby

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread Ryan Culpepper
On 09/10/2010 04:04 PM, John Clements wrote: On Sep 10, 2010, at 1:48 PM, Ryan Culpepper wrote: The way the rackunit tool does it (to make the rackunit gui DrRacket-aware) is to attach a module into the user namespace on every execution by overriding the 'reset-console' method of

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread Robby Findler
On Fri, Sep 10, 2010 at 5:39 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: On 09/10/2010 04:04 PM, John Clements wrote: On Sep 10, 2010, at 1:48 PM, Ryan Culpepper wrote: The way the rackunit tool does it (to make the rackunit gui DrRacket-aware) is to attach a module into the user namespace

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread Eli Barzilay
On Sep 10, Robby Findler wrote: FWIW, this is one path that tools can use to circumvent DrRacket's property (well, the property we work towards anyways) that no program can cause DrRacket itself to crash or freeze. So if you do provide things to the user's program in this manner, please try to

Re: [racket-dev] Shared-instantiation modules

2010-09-10 Thread John Clements
On Sep 10, 2010, at 8:17 PM, Eli Barzilay wrote: On Sep 10, Robby Findler wrote: FWIW, this is one path that tools can use to circumvent DrRacket's property (well, the property we work towards anyways) that no program can cause DrRacket itself to crash or freeze. So if you do provide things