Am 17.12.2023 18:41:25 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Christoph,
> On Dec 16, 2023, at 1:32 PM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
>
> Hi Eliot,
>
> I'm a bit late to the party, but I hope you will hear me anyway. :-)
>
> First, thank you for the perspective on CompilationCue as a public parameter object. Since all *cue* selectors on Compiler are on the instance side in a private protocol, I always assumed that you should not create and pass a CompilationCue to the compiler
from the outside. But I like to do that. I would like to make the compileCue: protocol public and replicate it on the class side of Compiler. What do you think?
Seems like a good idea to me.
> Second, I agree with Marcel that the process-to-debug could be a parameter object itself but also see that it would be cleaner to keep the invocation details extrinsic state (outside of the process). However, there is a second possible parameter object which
already exists, which is the Error/Warning of a process that brought up a debugger. Let's finally give the debugger access to that important context. It could check that exception for BCR to determine #interruptedProcessShouldResume.
Exactly. The way things are now the debugger can’t access relevant information about how it was invoked. It needs this information to know what the valid proceed options are. A cue object is the right thing to hold the information if the information doesn’t
really belong in a process. For me, I don’t want to make Process any heavier than it needs to be; having process creation being inexpensive is important. Hence use a cue object for debugger invocation; if applies only to the relatively rare case of a process
getting into problems (the vast majority of processes run without exceptions et al, it’s just that the debuggers are literally in our face).
> Someone already proposed on the list a few years ago to make debugger buttons exception-aware: right now, the Create button is hardcoded to match certain selectors on the stack. anException debuggerActions would be a much nicer and generic way for such use
cases and allow us to unfold the full potential of custom exception resumptions on the UI level.
Another argument in favour of a debugger cue object.
> Regarding DebuggerInvocationCue, I don't have a too strong opinion: I think - and hope - that this object should not grow significantly but we can store most information in the process or exception instead. On the other hand, even for four parameters, it
simplifies the invocation a lot, which is pretty nice. :-)
Right.
> Best,
> Christoph
_,,,^..^,,,_ (phone)
> ---
> Sent from Squeak Inbox Talk
>
>> On 2023-11-28T09:38:20+00:00, marcel.taeumel@hpi.de wrote:
>>
>> Hi Eliot --
>>
>> Done. See Tools-mt.1241 and System-mt.1436.
>>
>> To make use of this new possibility, see senders of #todoDebugger.
>>
>> StandardToolSet class >> #handleError:
>> StandardToolSet class >> #handleWarning:
>> Debugger class >> #openOnCue:
>>
>> Put new stuff into DebuggerInvocationCue in #handleError: and/or #handleWarning: and extract it in the debugger's #openOnCue:.
>>
>> Happy Squeaking! :-)
>>
>> Best,
>> Marcel
>>
>> Am 28.11.2023 09:17:46 schrieb Marcel :
>>
>> Hi Eliot --
>>
>> Let me rephrase my previous observation:
>>> No, I am against implementing yet another debugger-specific protocol
>>> like you proposed with that "invocation cue" idea. That's feels like overkill.
>>> I am sure that we can easily implement what you proposed with what we
>>> already have.
>>
>> I think I am starting to understand why the current process-to-debug cannot
>> quite be the "debugger invocation cue" object you are proposing.
>>
>> The current control flow between exception-toolset-process-project is
>> still correct and important, though.
>>
>> I think that the pattern you are looking for is "parameter object" :-)
>>
>> Best,
>> Marcel
>>
>> Am 28.11.2023 08:38:11 schrieb Marcel :
>>
>> ... I do like the idea of keeping the exception object around when debugging a process. We should just put it into the process-to-debug's environment. Not that difficult and possible with what we already have. :-)
>>
>> Best,
>> Marcel
>>
>> Am 28.11.2023 08:30:45 schrieb Marcel :
>>
>> Hi Eliot --
>>
>> We already have that special "cue object": it is the process itself through its environment.
>>
>> That's what the following protocol was designed for just recently:
>>
>> Project >> #prepareProcessForDebugger:
>> Project >> #suspendProcessSafely:
>> Project >> #resumeProcessSafely:
>>
>> We do not want to spoil any more specifics into the Debugger class directly to make it safely replaceable with custom tool sets.
>>
>> We already used this protocol to implement the Morphic-specific UI process:
>>
>> MorphicProject >> #suspendProcessSafely:
>> MorphicProject >> #resumeProcessSafely:
>>
>> There is no need to pass along any extra parameters via extra method parameters. Just store them into the process' environment.
>>
>> No, I am against implementing yet another debugger-specific protocol like you proposed with that "invocation cue" idea. That's feels like overkill. I am sure that we can easily implement what you proposed with what we already have.
>>
>> Yes, I can explain to you the improvements we have made around exception-process-toolset-project. The Debugger class must remain easily replaceable. TooSet, Project, Process/Context, and Exception are the only concepts we should focus on to handle the beef.
>>
>> Best,
>> Marcel
>>
>> Am 28.11.2023 03:07:36 schrieb Eliot Miranda :
>>
>> Hi Marcel,
>>
>> not specifically. I want to allow passing arbitrary parameters along the chain to an opening debugger. In Jaromir’s work with cannot return we want to
>> a) prevent continuing from a block cannot return exception, which happens at a return instruction
>> b) allow the debugger to highlight the return expression that cannot return
>>
>> To do a) we must nil the block context’s pc (a nil pc is the standard way of marking a context dead, and a block that cannot return should be marked dead). But this loses the pc information for the debugger.
>>
>> We now capture the offending pc when we create the BlockCannotReturn exception, just before nilling the context’s pc. But now the issue is getting that information to the debugger.
>>
>> Currently any parameters from an exception that are available to the debugger are passed as explicit parameters along the chain of methods such as debugProcess:context:label:contents:full view:, etc. Adding a pc: keyword/parameter to this is possible, but
inelegant. What happens when some other situation arises when another parameter is needed? In general these long, complex, selectors that include a set of optional parameters, are unwieldy. If you remember, this used to be the case with invoking the compiler.
Some invocations were for doits, some for method compilation, some for formatting, some doits were in the context of a debugger, etc. Colin Putney cut through the chaff by adding CompilationCue. Now there are two compilation invocation selectors, rather than
many, and they take a CompilationCue instance instead of a sequence of partially optional parameters. Much better. More concise; more flexible; more easy to extend.
>>
>> So I am proposing we do the same for invoking debuggers. Instead of a lot of different complex selectors through the exception via toolset to handler chain, we cut them down to two, one for exceptions, and one for debugging doits from the start (where there
is no exception) and that we bundle up all the parameters in a single object that functions like CompilationCue. I’m not sure what the name is, but it is to do with debugging more than anything else. DebuggingInvocationCue would be an acceptable name.
>>
>> Am I clear enough yet?
>>
>> Eliot
>> _,,,^..^,,,_ (phone)
>>
>> On Nov 27, 2023, at 6:06 AM, Taeumel, Marcel via Squeak-dev
wrote:
>>
>>
>> Hi Eliot --
>>
>> Do you want to debug the exception at hand but continue control flow in the process you are currently in? If so, try ToolSet class >> debugException:.
>>
>> Here is an example:
>>
>> [self halt]
>> on: Halt
>> do: [:ex | ToolSet debugException: ex].
>> self inform: 'Hello, Squeak!'.
>>
>> We re-did the plumbing last year and it seems to work well for the currently known use cases. :-) Maybe we overlooked something. Fiddling with processes can be ... icky ... ;-)
>>
>> Best,
>> Marcel
>>
>> Am 21.11.2023 23:27:50 schrieb Eliot Miranda :
>>
>> Hi Jaromir, Hi All,
>>
>> in trying to pass the exception raising an error to the debugger (so that it can highlight the relevant return expression) I'm running into the clumsy plumbing from errors to debuggers, i.e. debugProcess:context:label:contents:fullView:, debugWithTitle:full:contents:,
debugException:, debugContext:title:full:contents: et al.
>>
>> I think we urgently need to do to this interface what Colin Putney did to the compiler, introducing CompilerCue to hold all the state, including optional state, for a compilation invocation. We need ErrorHandlerCue, or DebuggerCue, or some such. It can take
all the parameters of the above, plus any extras we want to add, and then we can reduce the above selectors to
>>
>> handleErrorCue: anErrorCue or handleDebuggerCue: aDebuggerCue
>>
>> and then easily add additional state, such as the exception, to handlers such as the debugger.
>>
>> Anybody willing to pick up that bucket of whitewash and paint the fence?
>> _,,,^..^,,,_
>> best, Eliot
>