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?
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]

Reply via email to