Hi Ben.

2016-07-18 14:46 GMT+02:00 Ben Coman <btc@openinworld.com>:

Cool stuff Dennis.�� Does it utilise the remote image's DebuggerUI, or
DebuggerSession directly?�� i.e. Is the aim to remotely debug a
headless/UI-less image?�� This could open up some great possibilities
running a minimal image on embedded hardware.

Local debugger is opened on remote process. No UI needed to work with remote image.��

Also there is command line option to start image with running server:

./pharo PharoWithServer.image debuggerServer --port=40423

With Marcus we played with beaglebon device. It works fine like in my demo.��

��

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.

It was simplest strategy for error handling and in future it is probably possible to implement real smalltalk semantics over distributed errors.��

��

An interesting proof demonstration would be when setting up the server
image do...
�� Smalltalk at: #whoami put: #IAmTheServer

then in the client do...
�� debugger evaluate: [ Smalltalk at: #whoami ]

It works exactly like you want. Evaluation scripts transfer block to remote side by value. And for blocks "by value" means transfer all literals as "well known objects" (which are known on remote side). If globals not exist on remote side then error will be returned. Some literals could be transferred by reference. For example workspace variables.

��

although maybe its hard to bind to the remote Smalltalk rather than
the local one?
What is the tradeoff of the #evaluate: parameter being a string rather
than a block?

In this case you can't execute scripts which reference local objects like self, temps or workspace variables. Also it would be impossible to implement non local return with regular semantics.

��

Without having looked at the Seamless mechanism, intuitively there
would seem some benefit having the remote system compile the string to
bind to the remote�� classes.

There is scenario which needs to be covered: debugging images which has no compiler. I probably will work on it at some point.

Another interesting demo might be remotely evaluating...
�� Object inform: 'Test'
and the notification showing up on the remote (if indeed that is the
desired behaviour)

Yes, it works:��https://youtu.be/Aop7KOGOFN0

��

> and watch demo at https://youtu.be/SgFjgQpo_nU.

I got a bit lost which one was client and which remote.�� Maybe the
next demo you could have the server and client side by side.�� A bit of
overlap should be okay but it would be useful for the debug
notification appearing in the client to be immediately visible when an
error is is caused in the server image.�� It would be intuitive if the
web browser fully overlapped the server image it connected to.