On 12 January 2018 at 22:15, Mariano Martinez Peck <marianop...@gmail.com> wrote:
> > > On Wed, Nov 8, 2017 at 1:45 AM, Joachim Tuchel <jtuc...@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 <b...@openinworld.com>: >> > >> > >> > >> > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris < >> s...@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 >
