On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <[hidden email]> wrote: 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? |
Pay attention
Smalltalk at: -> Smalltalk globals at: Stef On Fri, Jan 12, 2018 at 3:15 PM, Mariano Martinez Peck <[hidden email]> wrote: > > > On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <[hidden email]> > 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 <[hidden email]>: >> > >> > >> > >> > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris >> > <[hidden email]> 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 |
In reply to this post by Mariano Martinez Peck
On 12 January 2018 at 22:15, Mariano Martinez Peck <[hidden email]> wrote:
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.
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
|
Free forum by Nabble | Edit this page |