I'm seeing if Seaside can load & run in the 6.1 trunk image. So far there are some issues -
When trying one example operation Seaside offered to open a Debugger in-image. Initially that trapped on a deprecation warning Process>>#debug:title:full:contents: triggered from GRPharoPlatform>>#openDebuggerOn:
The obvious first question is why the deprecation and what would we prefer to see used? The intent of the #openDebuggerOn: is to debug a specific context rather than simply the suspended context; so the Process>>#debugWithTitle:full:contents: seems inappropriate. One could simply fudge-in the use of ToolSet debugProcess... but there was clearly some considerable thought about this and I have no wish to trample like around like a Heffalump on double-espressos. Marcel & CT - you guys have your IDs on much of this stuff recently, what do you think?
The actual error that triggered this was a dNU on #isImmediateObject, which is a moderately recent Pharo thing. It looks pretty reasonable to me (see https://github.com/pharo-project/pharo/pull/7594/commits/9688140be284c3ce2f6...) and come from Marcus Denker, who is pretty good at this stuff. It's really a short-circuit on asking an object if its class isImmediateClass. The question is whether we like the idea enough to embrace it, or does one leave it to Seaside support categories?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A hacker does for love what others would not do for money.
Hi Tim, Hi Marcel,
so our commentary in the revised debugging protocol [1] was still not yet extensive enough. :-)
I don't have access to the source of GRPharoPlatform>>#openDebuggerOn:, but the general idea of our refactoring was that you either ask a (non-active) process to debug itself from its top or ask Processor to debug the active process. I unfortuntately can't remember why we specifically deprecated Process>>#debug:title:full:contents: but it might be related to not expose the suspendend context. Note that there is ProcessorScheduler>>#debugContextThat:title:full: which encapsulates the suspended context; maybe we need the same on Process? Marcel, can you maybe shed a light on this decision?
Anyway, I can confirm to you, Tim, that the currently recommended way for your intended behavior seems indeed to be "ToolSet debugProcess...".
Sorry for not being more helpful ...
Best, Christoph
[1] https://lists.squeakfoundation.org/archives/list/squeak-dev@lists.squeakfoun...
--- Sent from Squeak Inbox Talk
On 2023-10-24T16:37:17-07:00, tim@rowledge.org wrote:
I'm seeing if Seaside can load & run in the 6.1 trunk image. So far there are some issues -
When trying one example operation Seaside offered to open a Debugger in-image. Initially that trapped on a deprecation warning Process>>#debug:title:full:contents: triggered from GRPharoPlatform>>#openDebuggerOn:
The obvious first question is why the deprecation and what would we prefer to see used? The intent of the #openDebuggerOn: is to debug a specific context rather than simply the suspended context; so the Process>>#debugWithTitle:full:contents: seems inappropriate. One could simply fudge-in the use of ToolSet debugProcess... but there was clearly some considerable thought about this and I have no wish to trample like around like a Heffalump on double-espressos. Marcel & CT - you guys have your IDs on much of this stuff recently, what do you think?
The actual error that triggered this was a dNU on #isImmediateObject, which is a moderately recent Pharo thing. It looks pretty reasonable to me (see https://github.com/pharo-project/pharo/pull/7594/commits/9688140be284c3ce2f6...) and come from Marcus Denker, who is pretty good at this stuff. It's really a short-circuit on asking an object if its class isImmediateClass. The question is whether we like the idea enough to embrace it, or does one leave it to Seaside support categories?
tim
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim A hacker does for love what others would not do for money.
On 2023-10-26, at 5:51 AM, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote: so our commentary in the revised debugging protocol [1] was still not yet extensive enough. :-)
I think not; I didn't find it very clear!
I don't have access to the source of GRPharoPlatform>>#openDebuggerOn:,
openDebuggerOn: anError | process | process := Processor activeProcess. "If we are running in the UI process, we don't want to suspend the active process. The error was presumably triggered while stepping in the Debugger. If we simply immediately signal an UnhandledError, the debugger will catch this and display the signaling context. It isn't perfect or pretty but it works." (ProcessBrowser isUIProcess: process) ifTrue: [ UnhandledError signalForException: anError ] ifFalse: [ WorldState addDeferredUIMessage: [ process debug: anError signalerContext title: anError description full: true ]. process suspend ]
It's working on the active process and checking for the uiprocess, then debugging the error signaler. Our now-deprecated Process>>#debug:title:full:contents: would then check the suspended context is in the call stack before actually building the debugger.
So far as I can discern today, making a GRSqueakPlatform replacement GRSqueakPlatform>>#openDebuggerOn: openDebuggerOn: anError "Squeak variant based on the Pharo platform code, intended to avoid the deprecated #debug:title:full: message"
| process | process := Processor activeProcess. "If we are running in the UI process, we don't want to suspend the active process. The error was presumably triggered while stepping in the Debugger. If we simply immediately signal an UnhandledError, the debugger will catch this and display the signaling context. It isn't perfect or pretty but it works." process == Project uiProcess ifTrue: [UnhandledError signalForException: anError ] ifFalse: [WorldState addDeferredUIMessage: [Processor debugContext: anError signalerContext title: anError description full: true contents: nil]. process suspend]
... seems to do The Right Thing. It looks like the context is checked for being in the process within ProcessorScheduler>>#debugContext:title:full:contents:
Anybody object to this?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim What passes for common sense is always revisable
I would just use the ToolSet here:
openDebuggerOn: anError
ToolSet handleError: anError.
Best, Marcel Am 31.10.2023 00:39:27 schrieb Tim Rowledge tim@rowledge.org:
On 2023-10-26, at 5:51 AM, wrote: so our commentary in the revised debugging protocol [1] was still not yet extensive enough. :-)
I think not; I didn't find it very clear!
I don't have access to the source of GRPharoPlatform>>#openDebuggerOn:,
openDebuggerOn: anError | process | process := Processor activeProcess. "If we are running in the UI process, we don't want to suspend the active process. The error was presumably triggered while stepping in the Debugger. If we simply immediately signal an UnhandledError, the debugger will catch this and display the signaling context. It isn't perfect or pretty but it works." (ProcessBrowser isUIProcess: process) ifTrue: [ UnhandledError signalForException: anError ] ifFalse: [ WorldState addDeferredUIMessage: [ process debug: anError signalerContext title: anError description full: true ]. process suspend ]
It's working on the active process and checking for the uiprocess, then debugging the error signaler. Our now-deprecated Process>>#debug:title:full:contents: would then check the suspended context is in the call stack before actually building the debugger.
So far as I can discern today, making a GRSqueakPlatform replacement GRSqueakPlatform>>#openDebuggerOn: openDebuggerOn: anError "Squeak variant based on the Pharo platform code, intended to avoid the deprecated #debug:title:full: message"
| process | process := Processor activeProcess. "If we are running in the UI process, we don't want to suspend the active process. The error was presumably triggered while stepping in the Debugger. If we simply immediately signal an UnhandledError, the debugger will catch this and display the signaling context. It isn't perfect or pretty but it works." process == Project uiProcess ifTrue: [UnhandledError signalForException: anError ] ifFalse: [WorldState addDeferredUIMessage: [Processor debugContext: anError signalerContext title: anError description full: true contents: nil]. process suspend]
... seems to do The Right Thing. It looks like the context is checked for being in the process within ProcessorScheduler>>#debugContext:title:full:contents:
Anybody object to this?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim What passes for common sense is always revisable
squeak-dev@lists.squeakfoundation.org