On 27 August 2012 17:44, Ben Coman <b...@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?
yes, just open .changes file in a file browser. this is what i meant to say.. Or, if you look at ChangeSet (or ChangeBrowser - don't remember the name) code, at class side you can find the methods which actually allow you to browse contents of a .changes file. and you can specify what file to open. you just need to do some research :) > >> 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. > maybe.. i don't know. need to think about it. >> On 25 August 2012 03:42, Ben Coman <b...@openinworld.com> wrote: >> >>> >>> Igor Stasenko wrote: >>> >>>> >>>> On 4 August 2012 04:11, Ben Coman <b...@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 regards, Igor Stasenko.
