Re: [Pharo-users] OT: Re: Open Debugger, Save and Quit
On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuchel@objektfabrik.de> wrote:
Ben,
(this is a bit off-topic)
do you happen to know the purpose of that pre-debug-window? I must say that I find it annoying every time I get it in Pharo or VA? Why doesn't the debugger show up immediately?
I disabled that in all my images (via a startup setting). See #*alwaysOpenFullDebugger *below: "Define some settings/preferences for GTDebugger" (Smalltalk at: #GTGenericStackDebugger) perform: #enableDebuggerWindowDistinctColor: with: true. (Smalltalk at: #GTGenericStackDebugger) perform: #enableStackColoring: with: true. *(Smalltalk at: #GTGenericStackDebugger) perform: #alwaysOpenFullDebugger: with: true.* Cheers, But your suggestion is a good one, imo. In the startup phase of an image,
the image might not be ready to provide any means of reacting to a problem, so why bother showing errors that early?
What you describe should be quite easy to achieve with a handler that records and resumes errors during startup.
Joachim
Am 08.11.2017 03:54 schrieb Ben Coman <btc@openinworld.com>:
On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean@clipperadams.com>
wrote:
In a headless image, I'd like to do the following: if there's any error, arrange to have a debugger open on the next (headful) launch, and then
save
and quit.
I'm drawing a blank - how would I do that?
I explored various dead ends, the culmination of which was the image-breaking: actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] fork. Halt now ]
Thanks!
Sorry not a solution, but you sparked a side-thought... To avoid sometimes being swamped by Pre-Debug windows. Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into. This "Error Queue Viewer" would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window. In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened. The same error-queue might provide a similar interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected.
cheers -ben
-- Mariano http://marianopeck.wordpress.com
Pay attention Smalltalk at: -> Smalltalk globals at: Stef On Fri, Jan 12, 2018 at 3:15 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuchel@objektfabrik.de> wrote:
Ben,
(this is a bit off-topic)
do you happen to know the purpose of that pre-debug-window? I must say that I find it annoying every time I get it in Pharo or VA? Why doesn't the debugger show up immediately?
I disabled that in all my images (via a startup setting). See #alwaysOpenFullDebugger below:
"Define some settings/preferences for GTDebugger" (Smalltalk at: #GTGenericStackDebugger) perform: #enableDebuggerWindowDistinctColor: with: true. (Smalltalk at: #GTGenericStackDebugger) perform: #enableStackColoring: with: true. (Smalltalk at: #GTGenericStackDebugger) perform: #alwaysOpenFullDebugger: with: true.
Cheers,
But your suggestion is a good one, imo. In the startup phase of an image, the image might not be ready to provide any means of reacting to a problem, so why bother showing errors that early?
What you describe should be quite easy to achieve with a handler that records and resumes errors during startup.
Joachim
Am 08.11.2017 03:54 schrieb Ben Coman <btc@openinworld.com>:
On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
In a headless image, I'd like to do the following: if there's any error, arrange to have a debugger open on the next (headful) launch, and then save and quit.
I'm drawing a blank - how would I do that?
I explored various dead ends, the culmination of which was the image-breaking: actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] fork. Halt now ]
Thanks!
Sorry not a solution, but you sparked a side-thought... To avoid sometimes being swamped by Pre-Debug windows. Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into. This "Error Queue Viewer" would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window. In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened. The same error-queue might provide a similar interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected.
cheers -ben
-- Mariano http://marianopeck.wordpress.com
On 12 January 2018 at 22:15, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuchel@objektfabrik.de> wrote:
Ben,
(this is a bit off-topic)
Sorry I didn't reply earlier. For some reason you email from 8 Nov didn't show up in my inbox until the same time just now that Mariano's did.
do you happen to know the purpose of that pre-debug-window? I must say that I find it annoying every time I get it in Pharo or VA? Why doesn't the debugger show up immediately?
I don't know, but could speculate that it performs the function of an error message - with some additional context seeing the top of the call stack. cheers -ben I disabled that in all my images (via a startup setting). See #*alwaysOpenFullDebugger
*below:
"Define some settings/preferences for GTDebugger" (Smalltalk at: #GTGenericStackDebugger) perform: # enableDebuggerWindowDistinctColor: with: true. (Smalltalk at: #GTGenericStackDebugger) perform: #enableStackColoring: with: true. *(Smalltalk at: #GTGenericStackDebugger) perform: #alwaysOpenFullDebugger: with: true.*
Cheers,
But your suggestion is a good one, imo. In the startup phase of an image,
the image might not be ready to provide any means of reacting to a problem, so why bother showing errors that early?
What you describe should be quite easy to achieve with a handler that records and resumes errors during startup.
Joachim
Am 08.11.2017 03:54 schrieb Ben Coman <btc@openinworld.com>:
On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <
sean@clipperadams.com> wrote:
In a headless image, I'd like to do the following: if there's any
error,
arrange to have a debugger open on the next (headful) launch, and then save and quit.
I'm drawing a blank - how would I do that?
I explored various dead ends, the culmination of which was the image-breaking: actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] fork. Halt now ]
Thanks!
Sorry not a solution, but you sparked a side-thought... To avoid sometimes being swamped by Pre-Debug windows. Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into. This "Error Queue Viewer" would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window. In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened. The same error-queue might provide a similar interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected.
cheers -ben
-- Mariano http://marianopeck.wordpress.com
participants (3)
-
Ben Coman -
Mariano Martinez Peck -
Stephane Ducasse