Am 28.11.2023 03:07:36 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

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 <squeak-dev@lists.squeakfoundation.org> 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 <eliot.miranda@gmail.com>:

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