On 4 August 2012 04:11, Ben Coman <[email protected]> wrote: > As probably many newbies do from time to time, I am learning the system > splattering 'self halt' around, and once again slipped one into the wrong > place where I should have used 'haltOnce' and had a massive number of > pre-debugger windows come up. I managed to get it back this time with the > user interrupt - but not always - and anyhow clearing so many debug windows > is a pain. So..... could 'self halt' be made to monitor the rate that the > halt windows appear, and when more than some value from one of them (say > five per second) it starts getting ignored and shows a dialog asking the > user if they really meant this and enable danger mode, or if they screwed up > and want to revert the method containing the suspect 'halt'. > > Advanced features > + button to close all debugger windows.
i think there already such.. ( Camillo did that today before my eyes, with the shortcut only he knows ;) > + display the method showing the suspect 'self halt' > > Another thought, it would be useful to be able to see a list of 'self halts' > throughout the system and the timestamp of when they were insert, and > perhaps distinguish whether they were inserted by the user or came when the > package was loaded - and so providing more functionality than just using the > Finder to 'search source'. > IMO, there should be no senders of #halt except from debugging purposes.. of course if package doesn't overrides it for own purposes.. (but i doubt that even if one needs that, it is good idea) > Another thought, are there any plans for a "breakpoint" facility, so that I > don't dirty a package by only inserting 'self halt' to aid debugging. The > effect would be just the same as a 'self halt' and even be compiled in to > the bytecode as if it was but the source code remains pristine. This could > be represented by a symbol that could be dragged through a code window to > anywhere immediately following a statement separator. Perhaps the statement > separator itself gets special significance as a point that could be > activated as a debug point - and displayed using a big red font when it is > active. > Opal... we need opal. so we can hack the method's bytecode without need to recompile the method . Also, there is other tools like method wrappers.. but they are not come as part of pharo by default. If we look from user's perspective (not machine perspective), apparently it is pointless to throw so many messages at the user's face, because he cannot deal with them in meaningful manner at such rate. So, i think there should be something like following: - if exception requires a user interaction, we do show the popup, but meanwhile remember the exception which initiated it. - if there's next exception incoming and also asks UI manager to show it to user, we queue it, letting user to deal with first one.. (or we delay the popup , say 1 each 5 seconds). and finally, a queue should have some reasonable limit, after which we stop queuing , because again, user certainly won't be willing to waste his time dealing with 10000000 exceptions of same kind one by one. It doesn't makes sense anyways. In such case we can just ignore halt and let program continue (but increment some counter to show user how many of them are there). If exception is different (an Error) then on queue overflow, i think it should terminate the process with exception (but of course, special care must be taken if process is UI process). Of course making it too smart is pointless, because it is impossible to predict whether it is good idea to terminate process or letting it continue to run in case of exception. But for that we can have settings and options, to tune that at user's discretion, as well as default settings on a per-exception class base. > anyhow, just musing.... -ben > i know by myself how annoying it can be (up to unresponsive image) and i think most of us is facing such situation time to time (heh.. just yesterday we had it with Camillo while hacking ocompletion stuff). i learned to be careful and avoid such situations.. but sometimes it is hard and better tooling support will be helpful, no doubt. -- Best regards, Igor Stasenko.
