Using the Distributed Debugger
The distributed debugger adheres closely to the normal Smalltalk debugger interface. As such, you might look at the Smalltalk User Guide or the Visual Programming User Guide for more information on how to run debuggers.
In spaces having debugger UI capabilities, the use of the distributed debugger can be enabled or disabled using the following expression:
SstDebugging useDistributedDebugger: true (or false)
This option can also be set using the SST menu choice Use Distributed Debugger.
With the distributed debugger enabled, a reported error process will be shown in the normal debugger UI but the debugger itself will attempt to find and display any remote stack frames. This behavior can present a problem when trying to debug your messaging infrastructure because the debugger will itself attempt to send remote messages. With the option disabled the debugger behaves as a standard Smalltalk debugger.
SST also allows errors to be reported to remote object spaces. The logical process model maintains the notion of a UI Handler. If remote error reporting is enabled and an error occurs, the current UI Handler is asked to report the error to you, typically by opening a debugger. This behavior is controlled using the following expression:
SstDebuggingSupport reportErrorsThroughUIHandler: true (or false)
This option can also be set using the SST menu choice Report Errors via UI Handler.
Although the distributed debugger has behavior nearly identical to the normal Smalltalk debugger, the following differences have been noted:
• Setting the attributes or instance variables of a process will affect only the local process. These changes are not propagated along the logical process chain.
• Stack frames from remote spaces are marked with [spaceName] at the end of their entry in the frame list.
• Currently, some Browse menu choices are not supported when remote frame is selected.
Last modified date: 07/24/2020