[racket] distributed places - throwing dcgm-type contract violation on *channel-get

This is just a shot in the dark, but do you have your SSH keys set up?
If you get a password prompt when you 'ssh remote-node-name', I think it
might not work.

(From the looks of things, since you're spawning a node on localhost, I
think you might have to get 'ssh localhost' working the same way. Maybe
something like cat .ssh/id_rsa >> .ssh/authorized_keys might help?)

Matthew Eric Bassett <mebassett at gegn.net> writes:
> Kevin,
>
> Thanks again for your time looking into this - hope the dissertation
> edits are going well. :)
>
> Some clarification after I tried it this morning:  Invoking racket (with
> "-W debug", thanks for the tip!) on your hello-world-place.rkt hangs at
> the following:
>
> SPAWNED-PROCESS:2865 (/usr/bin/ssh localhost /usr/local/bin/racket -lm
> racket/place/distributed/launch spawn 7000)
> try 0 waiting 1 sec to retry connection to localhost:7000
>
>  From the racket repl I tried the following:
>
>  >(define-values (node pl) (spawn-node-supervise-place-at "localhost"
> #:listen-port 7000 "hello-world-place.rkt" 'hello-world))
>  >(*channel-put pl "hello")
>  >(*channel-get pl)
> ; dcgm-type: contract violation
> ; expected: dcgm?
> ; context...: ;
> /usr/local/lib/racket/collects/racket/place/distributed.rkt:436:8: loop
> ; /usr/local/lib/racket/collects/xrepl/xrepl.rkt:1342:0
> ; /usr/local/lib/racket/collects/racket/private/misc.rkt:87:7
>
> Thanks,
>
> Matthew
>
>
>
> On 12/15/2012 10:22 PM, Matthew Eric Bassett wrote:
>> 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
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users