On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman <[email protected]> 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 <[email protected]> wrote: >> >> >>> Igor Stasenko wrote: >>> >>> >>>> 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'. >>>>> >>>>> >>>>> >>>>> >>>> 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
