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

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/a3221bd0/attachment.html>