<div dir="ltr">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.<div> </div><div>Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Feb 2, 2013 at 4:31 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<div> </div><div>Robby</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"> <div class="gmail_quote">On Sat, Feb 2, 2013 at 4:08 PM, Danny Yoo <<a href="mailto:dyoo@hashcollision.org" target="_blank">dyoo@hashcollision.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>>>> >> 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. </div>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? </blockquote></div> </div> </div></div></blockquote></div> </div>