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
