<div dir="ltr">Oh-- and this isn't about raco setup really, either-- raco setup is just the "middle man" that decides what to compile.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Feb 4, 2013 at 8:04 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <div> </div><div> 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.</div> <div> </div><div>Relatedly: raco setup run in a sandbox that limits read and write access doesn't work either.</div><div> </div><div>Robby</div></div><div class="HOEnZb"> <div class="h5"><div class="gmail_extra"> <div class="gmail_quote"> On Mon, Feb 4, 2013 at 7:27 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <div><div> On Mon, Feb 4, 2013 at 6:17 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> 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 <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> > 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 <<a href="mailto:dyoo@hashcollision.org" target="_blank">dyoo@hashcollision.org</a>> 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? >> >> > > </div></div><div>> _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> > </div><div><div>-- Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> "The glory of God is Intelligence" - D&C 93 </div></div></blockquote></div> </div> </div></div></blockquote></div> </div>