I agree. More generally, if running a program has the side effect of configuring DrRacket, then maybe it should not be allowed to run within DrRacket. That is, maybe DrRacket should install a security guard that prevents writing to installed collections.
Meanwhile, to install packages from within DrRacket, it's possible that DrRacket could arrange for function from the `planet2' module to run within DrRacket --- after, say, double-checking with the user via a dialog box. I think a more promising direction is for a programmer to use `require', for DrRacket notice when the `require' fails that a package installation would provide the package, and then for DrRacket to offer to install the package. At Mon, 4 Feb 2013 08:04:25 -0600, Robby Findler wrote: > Oh-- and this isn't about raco setup really, either-- raco setup is just > the "middle man" that decides what to compile. > > > On Mon, Feb 4, 2013 at 8:04 AM, Robby Findler > <ro...@eecs.northwestern.edu>wrote: > > > It isn't to do with drracket. It is to do with the fact that it is > > triggered in a context where, say, the reader doesn't behave the way it > > would with the default parameters. > > > > Long story short: there are lots and lots of parameters that affect how > > compilation and raco setup generally behave. If these are not set to > > well-known things, then raco setup doesn't work. That's what happened here. > > > > Relatedly: raco setup run in a sandbox that limits read and write access > > doesn't work either. > > > > Robby > > > > > > On Mon, Feb 4, 2013 at 7:27 AM, Jay McCarthy <jay.mccar...@gmail.com>wrote: > > > >> I'm not sure why it is a strange configuration, but maybe I missed > >> that part of the thread. > >> > >> More generally, why should running the function version of "raco > >> setup" behave differently in a DrRacket buffer than it does on the > >> command line? > >> > >> Jay > >> > >> On Mon, Feb 4, 2013 at 6:17 AM, Robby Findler > >> <ro...@eecs.northwestern.edu> wrote: > >> > Going back in this thread, I think that changing which files DrRacket > >> > compiles is not the right direction to go to solve the problem discussed > >> > here. The problem is that planet2 is running raco setup in a strange > >> > configuration. Avoiding compiling files will not solve this problem. > >> > > >> > Robby > >> > > >> > > >> > On Sat, Feb 2, 2013 at 4:31 PM, Robby Findler < > >> ro...@eecs.northwestern.edu> > >> > wrote: > >> >> > >> >> Planet 1 explicitly deals with this by having the runtime system give > >> it > >> >> access to the original parameterization, which it picks and chooses > >> >> parameters from to restore (to make sure that this kind of thing > >> doesn't > >> >> happen). > >> >> > >> >> Robby > >> >> > >> >> > >> >> On Sat, Feb 2, 2013 at 4:08 PM, Danny Yoo <d...@hashcollision.org> > >> wrote: > >> >>> > >> >>> >>> >> I'm not sure if this is a bug or not, so I'm bringing it up on > >> the > >> >>> >>> >> list. But when I do the following: > >> >>> >>> >> > >> >>> >>> >> #lang racket > >> >>> >>> >> (require compiler/cm) > >> >>> >>> >> (manager-compile-notify-handler displayln) > >> >>> >>> >> (managed-compile-zo > >> >>> >>> >> > >> >>> >>> >> > >> >>> >>> >> > >> "/home/samth/sw/plt/collects/tests/typed-racket/succeed/null-program.rkt") > >> >>> >>> >> > >> >>> >>> >> Then the compiler places the compiled files in the > >> >>> >>> >> `compiled/drracket/` directory, and looks for compiled files > >> there > >> >>> >>> >> as > >> >>> >>> >> well. > >> >>> > >> >>> > >> >>> Reviving this thread. This is exactly the root of the issue hitting > >> >>> Neil Toronto with that weird reader error with Optimization Coach. > >> >>> > >> >>> > >> >>> When we're installing PLaneT2 packages, part of the process reruns a > >> >>> raco setup. At that point, raco setup is running under a context of > >> >>> that customized bytecode compiler/module loader. In fact, it starts > >> >>> compiling the rest of the collects under that custom > >> >>> DrRacket-compiling context, and I see the following after executing: > >> >>> > >> >>> > >> >>> --- > >> >>> raco setup: version: 5.3.2 [3m] > >> >>> raco setup: variants: 3m > >> >>> raco setup: main collects: /Applications/Racket v5.3.2/collects > >> >>> raco setup: collects paths: > >> >>> raco setup: /Users/dyoo/Library/Racket/5.3.2/collects > >> >>> raco setup: /Applications/Racket v5.3.2/collects > >> >>> raco setup: --- pre-installing collections --- > >> >>> raco setup: --- compiling collections --- > >> >>> raco setup: making: racket > >> >>> raco setup: in racket > >> >>> raco setup: in racket/base/lang > >> >>> raco setup: in s-exp/lang > >> >>> raco setup: in syntax > >> >>> raco setup: in racket/contract > >> >>> raco setup: in racket/contract/private > >> >>> raco setup: in setup > >> >>> raco setup: in racket/private > >> >>> raco setup: in config > >> >>> raco setup: in compiler/private > >> >>> raco setup: in setup/private > >> >>> raco setup: in planet > >> >>> raco setup: in planet/private > >> >>> raco setup: in racket/unsafe > >> >>> raco setup: in syntax/private > >> >>> raco setup: in racket/private/lang > >> >>> raco setup: in mzlib > >> >>> raco setup: in mzscheme > >> >>> raco setup: in scheme > >> >>> raco setup: in mzscheme/lang > >> >>> raco setup: in mzlib/private > >> >>> raco setup: in syntax/parse > >> >>> raco setup: in syntax/parse/private > >> >>> raco setup: in compiler > >> >>> raco setup: in unstable > >> >>> raco setup: in syntax/parse/experimental > >> >>> raco setup: in racket/match > >> >>> raco setup: in syntax/parse/experimental/private > >> >>> raco setup: in racket/draw/private > >> >>> raco setup: in ffi/unsafe > >> >>> raco setup: in ffi > >> >>> raco setup: in racket/draw/unsafe > >> >>> raco setup: in file > >> >>> raco setup: in racket/draw > >> >>> raco setup: in rackunit > >> >>> raco setup: in rackunit/private > >> >>> raco setup: in racket/gui > >> >>> raco setup: in racket/place/private > >> >>> raco setup: in mred > >> >>> raco setup: in mred/private > >> >>> raco setup: in scheme/private/lang > >> >>> raco setup: in scheme/private > >> >>> raco setup: in scheme/base/lang > >> >>> raco setup: in racket/snip/private > >> >>> raco setup: in mred/private/wx > >> >>> raco setup: in mred/private/wx/common > >> >>> raco setup: in mred/private/wxme > >> >>> raco setup: in racket/lang > >> >>> raco setup: in scheme/private/provider/lang > >> >>> raco setup: in scheme/private/provider > >> >>> raco setup: in scheme/lang > >> >>> raco setup: in compatibility > >> >>> raco setup: --- parallel build using 4 processes --- > >> >>> raco setup: 3 making: > >> >>> /Users/dyoo/Library/Racket/5.3.2/pkgs/installed/sxml/sxml (sxml) > >> >>> raco setup: 2 making: scribblings/main/user > >> >>> raco setup: 3 making: > >> >>> /Users/dyoo/Library/Racket/5.3.2/pkgs/installed/sxml/sxml/scribblings > >> >>> raco setup: 3 making: > >> >>> /Users/dyoo/Library/Racket/5.3.2/pkgs/installed/sxml/sxml/ssax (ssax) > >> >>> raco setup: --- updating info-domain tables --- > >> >>> raco setup: updating: <user>/info-domain/compiled/cache.rktd > >> >>> raco setup: --- creating launchers --- > >> >>> raco setup: --- building documentation --- > >> >>> link: bad variable linkage; > >> >>> reference to a variable that has the wrong procedure or > >> structure-type > >> >>> shape > >> >>> reference phase level: 0 > >> >>> variable module: "/Applications/Racket > >> >>> v5.3.2/collects/syntax/location.rkt" > >> >>> variable phase: 0 > >> >>> reference in module: "/Applications/Racket > >> >>> v5.3.2/collects/racket/date.rkt" in: module-name-fixup > >> >>> --- > >> >>> > >> >>> > >> >>> At this point forward, I think the following is happening: it appears > >> >>> that once this happens, things are completely hosed because DrRacket > >> >>> is somehow loading both DrRacket-specific bytecode for some modules, > >> >>> and others with the standard bytecode. The mix leads to the linkage > >> >>> errors. > >> >>> > >> >>> Does this explanation sound plausible? > >> >> > >> >> > >> > > >> > > >> > _________________________ > >> > Racket Developers list: > >> > http://lists.racket-lang.org/dev > >> > > >> > >> > >> > >> -- > >> Jay McCarthy <j...@cs.byu.edu> > >> 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
