[racket] distributed places - throwing dcgm-type contract violation on *channel-get
Kevin,
Many thanks for your response.
The only significant difference between your code and mine is the use of
localhost (which makes distributed places a lot less distributed) and
the port specification. In any case, I've tried your code verbatim on
two machines now. It also throws the same dcgm contract violation.
What OS are you running? Perhaps there's something funny about my
build? I don't know anything about distributed/places internals here,
I'm just guessing.
I've tested this on Fedora 17 x64, and on an amazon stock x64 ec2 machine.
Regards,
Matthew Eric
On 12/15/2012 04:05 AM, Kevin Tew wrote:
> The following thunk example works for me.
> Uncommenting the message-router line will pump back stdout and stderr
> from the remote node so you can see any errors that may be occurring
> at the remote-node.
> You will have to kill the message router by hitting CTRL-C when you
> want to end the program.
>
>
> EXAMPLE 1
> -----------------------------------------
> #lang racket
> (require racket/place/distributed)
> (define (hello-world)
> (place ch
> (printf/f "hello-world received: ~a\n" (place-channel-get ch))
> (place-channel-put ch "Hello World\n")
> (printf/f "hello-world sent: Hello World\n")))
> (provide hello-world)
>
> (module+ main
> (define-values (node pl) (spawn-node-supervise-place-at "localhost"
> #:listen-port 7000 "hello-world-place.rkt" 'hello-world #:thunk #t))
> (*channel-put pl "Hello bozo")
> (*channel-get pl)
> #;(message-router node)
> )
>
>
> Example 2 show how I would normally write distributed places code
> without using the #:thunk keyword argument.
>
> EXAMPLE 2
> --------------------------------------------
> #lang racket
> (require racket/place/distributed)
> (define (hello-world ch)
> (printf/f "hello-world received: ~a\n" (place-channel-get ch))
> (place-channel-put ch "Hello World\n")
> (printf/f "hello-world sent: Hello World\n"))
> (provide hello-world)
>
> (module+ main
> (define-values (node pl) (spawn-node-supervise-place-at "localhost"
> #:listen-port 7000 "hello-world-place.rkt" 'hello-world))
> (*channel-put pl "Hello bozo")
> (*channel-get pl)
> #;(message-router node)
> )
>
>
> On 12/15/2012 02:16 AM, Matthew Eric Bassett wrote:
>> Just to update, also tried this on v5.3.1 using
>> spawn-node-supervise-place-at with #:thunk set. same result.
>>
>> On 12/14/2012 03:31 PM, Matthew Eric Bassett wrote:
>>> Hey folks,
>>>
>>> I was playing around with distributed places and I ran into a some
>>> problems. I'm using racket v5.3 and am following the docs from the
>>> racket reference
>>> (http://docs.racket-lang.org/reference/distributed-places.html)
>>>
>>> Let's say we have an example just like the one in the reference.
>>>
>>> hello-world-place.rkt
>>> ----------------------
>>> (define (hello-world)
>>> (place ch (printf "hello-world received: ~a\n"
>>> (place-channel-get ch))
>>> (place-channel-put ch "Hello World\n")
>>> (printf "hello-world sent: Hello World\n")))
>>>
>>> Then from the racket xrepl we do
>>>
>>> >> (define-values (node pl)
>>> (spawn-node-supervise-dynamic-place-at remote-node
>>> "hello-world-place.rkt" 'hello-world))
>>> ; there's now a racket process running on my remote-node
>>> >> (*channel-put pl "hi")
>>> ; the remote node shuts down as we expect, giving the
>>> place-channel-get should have locked it until this point.
>>> >> (*channel-get pl)
>>> ; dcgm-type: contract violation
>>> ; expected: dcgm?
>>> ; given: #<eof>
>>> ; context...:
>>> ; /usr/local/lib/racket/collects/racket/place/distributed.rkt:442:8:
>>> loop
>>> ; /usr/local/lib/racket/collects/xrepl/xrepl.rkt:1341:0
>>> ; /usr/local/lib/racket/collects/racket/private/misc.rkt:87:7
>>>
>>> I've tried [naively] using place-channel-put/get instead of
>>> *channel-put/get, same result. Wrapping it in a message-router
>>> makes no difference.
>>>
>>> >> (message-router node (after-seconds 2 (*channel-put pl "hi!")
>>> (*channel-get pl)))
>>> ; gives same result as above.
>>>
>>> Any ideas what I'm doing wrong or what I'm missing?
>>>
>>> Many thanks,
>>>
>>>
>>
>>
>
--
Matthew Eric Bassett | http://mebassett.info