Zdalny węzeł znajduje się na innym komputerze.erlang: nie powiodło się (węzeł, zabawa): błąd badfun
I testu z lokalnego węzła:
$ erl -name foobar
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false]
Eshell V6.2 (abort with ^G)
([email protected])1> Aliyun='[email protected]'.
'[email protected]'
([email protected])2> spawn(Aliyun, fun() -> io:format("hello~n") end).
<6108.86.0>
([email protected])3>
=ERROR REPORT==== 4-Jul-2015::21:03:27 ===
Error in process <0.86.0> on node '[email protected]' with exit value: {{badfun,#Fun<erl_eval.20.90072148>},[{erlang,apply,2,[]}]}
([email protected])3> spawn(Aliyun, io, format, ["hello~n"]).
hello
<6108.87.0>
([email protected])4> net_adm:ping(Aliyun).
pong
Przekonani spawn(node,module,function,args)
prace, ale spawn(node,fun)
nie.
Wersja Erlang na zdalnym węźle to R15, a wersja na węźle lokalnym to R17. Czy to jest powód? Ponieważ format kodu jest inny? Nie jestem pewien, jak Erlang marnuje zabawny typ podczas przekazywania go do zdalnego węzła. W bajtode?
Pomoc, proszę!
Dlaczego jest ograniczony do tej samej wersji erl_eval? Dopóki zabawa jest kompatybilna z wersją docelową, tzn. Polecane funkcje i semantyka są kompatybilne, to powinna działać na docelowym Erlangu, który jest bardziej elastyczny, ponieważ można wymieniać dowolne zgodne kody między węzłami, oprócz gotowych modułów . – kingluo
W jaki sposób proponujesz weryfikację kompatybilności funkcji i semantyki modułu, aby dowolne anonimowe zabawy związane z tym modułem mogły być poprawnie wykonywane w różnych węzłach? Rozwiązanie tego problemu jest generalnie niepraktyczne. Środowisko wykonawcze Erlang sprawdza zatem sumę kontrolną MD5 modułu w celu sprawdzenia kompatybilności. –