I've been meaning to get a BBB.�� I looks like bit better platform for
an industrial controller / robotics than the Rpi - in particular its
Programming Realtime Unit.�� ��Knowing someone else has one maybe I'll
get one now. In the back of my mind I've been considering whether its
PRU could be modelled as a CPU target for Slang , so Slang could be
re-purposed from just compiling VM, to compiling embedded programs for
the PRU, developed from within Pharo and loaded on the fly into the
PRU.

>>
>> When I read "Async evaluation ... does not wait for a result" I wonder
>> if there a particular need for the fork is used here?...
>>�� �� ��debugger evaluateAsync: [ [1/0] fork ].
>>
>
> Yes, it looks strange. Now all remote requests are executed such way that
> errors will be returned as SeamlessRemoteException and server signaller
> process will die. So instead of debugger with failed remote expression you
> will see debugger with local process which performed remote message send
> (but in case of async evaluation no result will returned to client and error
> will be just ignored). To escape such "exception handler" fork is needed.
> Fork will lead to unhanded error which will ask registered remote debugger
> to debug it.

Could you not just fork at the remote side?
Perhaps the invocation would be #evaluateFork: