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

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
<robby at 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 <robby at 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 <dyoo at 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 <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93