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
