My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself"
- run the image, recompile that method. done On 8 November 2012 22:11, Sebastian Sastre <[email protected]> wrote: > I'm currently trying Sven idea: > > 1. use a fresh pharo image (same base version your screwed one's changes is) > 2. rename (a copy of) the changes file as .cs > 3. open file browser and try to file in that .cs > > The first try didn't work because some compilation error. > > I've removed the offending code editing manually and trying again > > It's slow because is a lot of code > > lets see how it ends. > > sebastian > > o/ > > PS: about this I won't blame smalltalk at all. This is piece of cake for > TimeMachine. Problem is that "coincidentally" I've neglected mcz commits for > the code of this image. The blame is all mine > > > > On Nov 8, 2012, at 7:30 PM, Sebastian Nozzi wrote: > > Hey there Sebastian, > > I feel your pain. Unfortunately there seem to be *many* places / situations > where "halting" is a very bad idea and renders your image unusable. > > That's why I think it would be a good idea to have a "list" of these places > (in the documentation and in the Pharo "welcome" Workspace), and maybe the > technical reasons behind them. > > Something that I did a couple (!!) of times until I learnt the lesson was to > halt withing a Morph>>drawnOn:. If you do, then there goes your UI > painting/event processing thread (solution: debug your Morph from outside, > passing a NullCanvas). > > It was also possible for me, more than once, to "hang" the image beyond > recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200) > wait) within the UI thread in an infinite recursion (by mistake). > > As for "rescuing it"... can the "recent changes" help you? In your case you > would be directly reading the ".changes" file... Not really rescuing your > image, but extracting and saving your work... (and migrating to a new > image). > > This is very annoying, I know. Been there a couple of times (although with > less serious work than yours). In my opinion something needs to change in > this area. These are huge productivity losses, and I fear that many new > users (*) would at this point turn their backs on Smalltalk never to look > back again. > > Best regards, > > Sebastian N. > > (*) or senior developers evaluating the possibility to use Pharo in their > companies. > > > 2012/11/8 Sebastian Sastre <[email protected]> >> >> …I mean ever. >> >> Because you'll screw your image. >> >> Mostly when you also are on OS X but, for some crazy reason of the >> Universe, your TimeMachine was not operating normally on your laptop while >> coding. >> >> Aaaaand you weren't committing in the monticello repo because it was work >> in progress and you were expecting to reach some goal. >> >> Ever. >> >> So… >> >> I'm in that situation with an image now :( >> >> I've the false good idea of putting a halt in an SomeApp class>>startUp: >> method and now, when I open the image, it tries to, stays for about 2 >> seconds and crashes. >> >> Any of you guys have a workaround/hack to rescue it? >> >> sebastian >> >> o/ >> >> PS: I've tried with startup.st with the code that removes that method but >> no luck. >> >> >> > > -- Best regards, Igor Stasenko.
