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 <ro...@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.mccar...@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 >> <ro...@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 < >> ro...@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 <d...@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 <j...@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
