New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proceed button disabled in pre-debuggers invoked from lower-priority processes #92
Comments
We did this to avoid strange debugger chains. The mere construction of a tool via
Well, you cannot always guard against client code invoking UI stuff in a forked process. Your example is just similar to |
Note that |
I checked. Having the tool builder construct (and open) debuggers from a non-UI process (in the case of Morphic) is to prevent debugger chains and have a more reliable detection of recursive errors. In this issue/regression here, it is about a mere UI glitch. Inconvenient, but not a serious bug. It's a trade-off. Having a reliable detection of recursive errors is more important than this. Still, the following items should be addressed in the future:
Well, both cases could be addressed my doing UI stuff only in the Morphic UI process but might then cause those endless debugger chains again if UI code is involved. I think we should leave it as is for now. That low-priority-process issue here could be addressed with a hack. Not sure it is worth it. |
Thank you for looking at this. From a user perspective, I would still like to fix this issue through a hack. Other than a UIManager/Morphic invocation, exceptions are a pretty UI-agnostic mechanism that should work in any process. IMHO it would be a pity to formally support termination and debugging only for low-priority processes but no direct resumption. The above comment documents a real instance of this issue in one of my projects. While this is just an extra click for experts, I imagine confusion in beginners. |
This here works as expected:
but this one has a UI glitch:
The proceed button is disabled and you have open the full debugger before being able to proceed.
This has worked in Squeak 6.0, so my first guess is that it this could be a regression from Tools-mt.1184 & Co.? @marceltaeumel?
See
Debugger>>#openWithLabel:contents:fullView:
. At a first look, it seems that prior to that refactoring, the debugger UI was built on the UI process but now is no longer. Without knowing the details, this looks suspicious to me - at least in Morphic, all UI code should happen in the UI process, alone for the reason of avoiding concurrency issues.(Note that the same expectation is violated for
[(self inform: 'foo') inspect] forkAt: 30
as well, but this is a different story and I hope that we can ultimately solve this with the introduction ofRequestException
.)The text was updated successfully, but these errors were encountered: