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

Oh-- and this isn't about raco setup really, either-- raco setup is just
the "middle man" that decides what to compile.


On Mon, Feb 4, 2013 at 8:04 AM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> 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.mccarthy at 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
>> <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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130204/498ae9d6/attachment-0001.html>