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

I agree.

More generally, if running a program has the side effect of configuring
DrRacket, then maybe it should not be allowed to run within DrRacket.
That is, maybe DrRacket should install a security guard that prevents
writing to installed collections.

Meanwhile, to install packages from within DrRacket, it's possible that
DrRacket could arrange for function from the `planet2' module to run
within DrRacket --- after, say, double-checking with the user via a
dialog box. I think a more promising direction is for a programmer to
use `require', for DrRacket notice when the `require' fails that a
package installation would provide the package, and then for DrRacket
to offer to install the package.

At Mon, 4 Feb 2013 08:04:25 -0600, Robby Findler wrote:
> 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
> >>
> >
> >
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev