[racket-dev] Running in DrRacket changes behavior of the `compiler/cm` library

>>> >> 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?