I'm sorry; I was wrong. I don't see the behavior you're seeing, tho. If I add parens around 'all-defined-out', and save the file in tmp.rkt, then this is the behavior I see at the command-line racket:
Welcome to Racket v5.1.3.6. > (require "tmp.rkt") > (super-simple) 5 and I see similar behavior in DrRacket: Welcome to DrRacket, version 5.1.3.6--2011-08-25(7bb8c6c4/d) [3m]. Language: racket; memory limit: 128 MB. > (super-simple) 5 > FWIW, in 5.1.3, I get an error that's surprising to me, as I don't see how the sandbox gets involved in this program, but here it is: car: expects argument of type <pair>; given '#((module program racket/base)) === context === /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:572:17: ns /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:584:20 /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:334:0: call-with-limits /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:564:0: evaluate-program /Applications/Racket v5.1.3/collects/racket/private/more-scheme.rkt:151:2: call-with-break-parameterization /Applications/Racket v5.1.3/collects/racket/sandbox.rkt:704:2: user-process /Applications/Racket v5.1.3/collects/mred/private/wx/common/queue.rkt:430:6 /Applications/Racket v5.1.3/collects/mred/private/wx/common/queue.rkt:470:32 Robby On Mon, Aug 29, 2011 at 8:55 PM, David Mitchell <d...@fallingcanbedeadly.com> wrote: > You might have to unpack that a little bit more for me, as I don't see how > that's the case. Additionally, why would it work from Terminal and not > DrRacket? > > -- Dave (on the iPhone) > > On Aug 29, 2011, at 6:32 PM, Robby Findler <ro...@eecs.northwestern.edu> > wrote: > >> I think what's happening is that you're creating a place whose first >> action is to create that same place again (over and over). >> >> Robby >> >> On Mon, Aug 29, 2011 at 8:17 PM, David Mitchell >> <d...@fallingcanbedeadly.com> wrote: >>> I've been trying to experiment with racket/place, but it seems to have >>> significant incompatibilities with DrRacket. I've defined a module based on >>> a code snippet in http://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf >>> that looks like this: >>> >>> #lang racket >>> (provide all-defined-out) >>> (define (fib n) >>> (define (fib-inner n-remaining i i+1) >>> (if (= n-remaining 1) >>> i+1 >>> (fib-inner (- n-remaining 1) i+1 (+ i i+1)))) >>> (if (<= n 0) >>> 0 >>> (fib-inner n 0 1))) >>> (define (start-fib n) >>> (define p >>> (place ch >>> (define n (place-channel-get ch)) >>> (place-channel-put ch (fib n)))) >>> (place-channel-put p n) >>> p) >>> (define (super-simple) >>> (define p >>> (place ch >>> (place-channel-put ch 5))) >>> (place-channel-get p)) >>> >>> If I run racket in my Terminal and load this module, I'm able to use >>> start-fib and super-simple as expected. However, if I define this module in >>> the DrRacket editor and access the functions through the repl, attempts to >>> receive data from either place appear to hang. I'm running OS X Lion, and >>> I've tried both the 64-bit and 32-bit versions of 5.1.3, as well as the >>> 64-bit version of the latest nightly build (5.1.3.6--2011-08-28(46a0fe9/a)). >>> I posted a question about this to the IRC channel last night, and one other >>> user (jonrafkind) indicated that that the issue could be reproduced on >>> 32-bit Linux, so it seems unlikely to be a platform issue. This user also >>> indicated, "it seems places keeps reloading the current module." >>> (Unfortunately, I am quite new to racket, so I have only a vague idea what >>> this means, and no idea at all as to how one would go about discovering such >>> a thing) >>> Does anyone have any insight as to why this might be failing and/or how I >>> might work around it (without abandoning the GUI)? >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/users >>> > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
