DEPRECATED (Cloud Haskell Platform) in favor of distributed-process-extras, distributed-process-async, distributed-process-client-server, distributed-process-registry, distributed-process-supervisor, distributed-process-task and distributed-process-execution
[Imported from JIRA. Reported by Tim Watson [Administrator] @hyperthunk) as DPP-96 on 2014-02-26 17:40:35]
The idea is that we add something akin to OTP's system messages and put special handling into the gen-process loops to work with these. We might also want to add a {{handleDebug :: Maybe (s -> Process DebugInfo)}} API to the process definition.
This might look like {{data DebugInfo = DebugInfo String}} or something, but the idea is that for debugging, the process has an opportunity to turn its state into some kind of useful (printable?) information and pass that back (or on) to the debugging control plane.
Another option here is to have some kind of debugging sink into which the processes are expected to write whatever useful info they have. That sink might, by default, just write to the {{SystemLog}}, and of course the user will need to register formatters for the relevant data structures in order for them to be printed usefully.
Finally, debug/trace is just one kind of system message. Statistics is another (probably quite useful) one, and that might be handled at the managed process level (providing start time, throughput info, etc) plus give the process the option of adding additional stats info (e.g., supervisor might want to add {{SupervisorStats}} to the data that gets given back to the system client).
[Imported from JIRA. Reported by Tim Watson [Administrator] @hyperthunk) as DPP-96 on 2014-02-26 17:40:35] The idea is that we add something akin to OTP's system messages and put special handling into the gen-process loops to work with these. We might also want to add a {{handleDebug :: Maybe (s -> Process DebugInfo)}} API to the process definition.
This might look like {{data DebugInfo = DebugInfo String}} or something, but the idea is that for debugging, the process has an opportunity to turn its state into some kind of useful (printable?) information and pass that back (or on) to the debugging control plane.
Another option here is to have some kind of debugging sink into which the processes are expected to write whatever useful info they have. That sink might, by default, just write to the {{SystemLog}}, and of course the user will need to register formatters for the relevant data structures in order for them to be printed usefully.
Finally, debug/trace is just one kind of system message. Statistics is another (probably quite useful) one, and that might be handled at the managed process level (providing start time, throughput info, etc) plus give the process the option of adding additional stats info (e.g., supervisor might want to add {{SupervisorStats}} to the data that gets given back to the system client).