2016-07-18 18:26 GMT+02:00 Ben Coman <[email protected]>:
> 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)
