On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman <btc@openinworld.com> wrote:
Igor Stasenko wrote:
you can open .changes file in another image to rescue your code.
Thanks Igor. I gave that a go but couldn't work it out. I tried the following: Unzipped a fresh image, copied the .changes file into the folder to overwrite the existing .changes file, then after starting the image tried (World > Tools > Recover lost changes...) but I get "Information: this image has never been saved since changes were compressed." Saving the image seems to empty the .changes file. I could not find another way. Is there something else I should be doing?
Ben, your changes were in the .changes file that you overwrote. You should have either a) unpacked the second image/changes in a different directory b) renamed the changes file you wanted to recover before unpacking the second image/changes c) unpacked the second image/changes with different names d) anything else that avoids overwriting the changes file you wanted to recover. its gone now unless you have a recent backup also you can patch the image's bytecode to avoid entering an offending
method (like a method which enters the drawing , just see its bytecode in another image, and the find same byte sequence in crashing image, and put return self bytecode)
Thanks, but that is beyond my capability at the moment. Probably wishing for too much, but ideally some mechanism might use info from the debug.log to do this automatically.
On 25 August 2012 03:42, Ben Coman <btc@openinworld.com> wrote:
Igor Stasenko wrote:
On 4 August 2012 04:11, Ben Coman <btc@openinworld.com> 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'.
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.
Another use case that just happened to me. This is not 'halt' related but just a typo... (which suddenly makes the whole system feel a bit fragile) Working on a small new feature in the drawing loop of Roassal, I would guess "all" that I did was leave out a full stop at the end a line. So the image locked and crashed after about 20 seconds. Unfortunately now the image is crashing every time I try to open it. Some mechanism to throttle and temporarily ignore the error to allow me to rectify the problem would have been immensely useful. In this case, perhaps something like blocking the main UI loop and presenting a modal window of a very basic self contained text editor on the offending method. At this moment, another immensely useful tool would be able to diff the source code between a running image and an offline image, and import the changes. Is there any other way I might recover recent changes? Previously I have not had much luck mixing a new image with the changes file fromt he crashed image.
regards -ben
[Debug logs deleted]
-- best, Eliot