2016-07-18 18:26 GMT+02:00 Ben Coman <btc@openinworld.com>:
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.
Do you have link to BBB? (google not helps with such 3 letters).
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:
Here is screen which shows "evaluate: [1/0]": âNo remote stack here. And on remote side there is no waiting process. In future real exception semantics could be supported. In that case "evaluate: [1/0]" will open debugger with half stack from local process (doIt from workspace) and half from remote process (where ZeroDivide happens). ("debugger evaluateAsync: [1/0]" will never show any error because result is not supposed to be returned for async)
