[Pharo-project] Don't ever ever halt in #startUp:
â¦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.
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 <sebastian@flowingconcept.com>
â¦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 <https://about.me/sebastianconcept>
o/
PS: I've tried with startup.st with the code that removes that method but no luck.
You can build a VM and skip to the next bytecode ;) http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht... On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi@gmail.com> 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 <sebastian@flowingconcept.com>
â¦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.
-- Mariano http://marianopeck.wordpress.com
humm I actually already improved the startup quiet a bit to prevent stupid people like me to crash images ;) but the halt is not yet caught, I have to add that, then you'll simply get a warning at startup :P On 2012-11-08, at 22:34, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
You can build a VM and skip to the next bytecode ;) http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht...
On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi@gmail.com> 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 <sebastian@flowingconcept.com>
â¦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.
-- Mariano http://marianopeck.wordpress.com
https://code.google.com/p/pharo/issues/detail?id=6941 so that your experience will be last one :) On 2012-11-08, at 22:49, Camillo Bruni <camillobruni@gmail.com> wrote:
humm I actually already improved the startup quiet a bit to prevent stupid people like me to crash images ;)
but the halt is not yet caught, I have to add that, then you'll simply get a warning at startup :P
On 2012-11-08, at 22:34, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
You can build a VM and skip to the next bytecode ;) http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht...
On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi@gmail.com> 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 <sebastian@flowingconcept.com>
â¦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.
-- Mariano http://marianopeck.wordpress.com
Cool :-) This will be a default behaviour, or activated through a command-line switch? 2012/11/8 Camillo Bruni <camillobruni@gmail.com>
https://code.google.com/p/pharo/issues/detail?id=6941
so that your experience will be last one :)
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 <sebastian@flowingconcept.com> â¦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.
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 <sebastian@flowingconcept.com> 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 <sebastian@flowingconcept.com>
â¦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.
On 09.11.2012 13:36, Sebastian Nozzi wrote:
2012/11/9 Igor Stasenko <siguctua@gmail.com>:
My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself" How do you do this?
One could potentially build a tool to do it :) (with the caveat that one would need to be intimate with the image/object format) - Open a "dead" image file. - Find offsets for start of object space and symbol table (in the image header?) - Search for startUp/startUp:/halt in Symbol table, and record their object header adresses - Subtract the object space start start from these, and you'd have the oop's of these Symbols. - Scan the image for startUp(:) oops, check if it's the selector of a CompiledMethod instance, and that halt is one of it's literals. - If so, replace the first byte in the CM's bytecodes with that of returnself. If you want to do so manually, better get your Neo-goggles on, or be Igor :P Cheers, Henry
Better to replace symbol #halt with #yourself in the method litarray. Doing it uncoditionally in all compiled methods should not hurt. Easier and safer :-) Jan On 09/11/12 14:31, Henrik Sperre Johansen wrote:
On 09.11.2012 13:36, Sebastian Nozzi wrote:
2012/11/9 Igor Stasenko <siguctua@gmail.com>:
My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself" How do you do this?
One could potentially build a tool to do it :) (with the caveat that one would need to be intimate with the image/object format)
- Open a "dead" image file. - Find offsets for start of object space and symbol table (in the image header?) - Search for startUp/startUp:/halt in Symbol table, and record their object header adresses - Subtract the object space start start from these, and you'd have the oop's of these Symbols. - Scan the image for startUp(:) oops, check if it's the selector of a CompiledMethod instance, and that halt is one of it's literals. - If so, replace the first byte in the CM's bytecodes with that of returnself.
If you want to do so manually, better get your Neo-goggles on, or be Igor :P
Cheers, Henry
On 9 November 2012 09:36, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
2012/11/9 Igor Stasenko <siguctua@gmail.com>:
My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself"
How do you do this?
simply open "same" image and look for unique bytecode sequence among potential call stack in startup code. then "disable" the method by setting its first bytecode to "returnself" bytecode. -- Best regards, Igor Stasenko.
On 9 November 2012 21:32, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 November 2012 09:36, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
2012/11/9 Igor Stasenko <siguctua@gmail.com>:
My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself"
How do you do this?
simply open "same" image and look for unique bytecode sequence among potential call stack in startup code. then "disable" the method by setting its first bytecode to "returnself" bytecode.
err.. i mean, take similar image.. find method and then seek same bytecode sequence in image. if there is only one byte sequence in dead image, that should be the method which you need to disable. easy! :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Nov 8, 2012, at 10:12 PM, Sebastian Sastre <sebastian@flowingconcept.com> 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.
I don't think that this can work... What sven meant is to drag the .changes on your new image, it will open a special tool to browse the changes. Marcus -- Marcus Denker -- http://marcusdenker.de
okay happy ending. After many iterations to remove offending code it filed in all of it Thanks for the help guys sebastian o/ On Nov 9, 2012, at 8:21 AM, Marcus Denker wrote:
On Nov 8, 2012, at 10:12 PM, Sebastian Sastre <sebastian@flowingconcept.com> 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.
I don't think that this can work...
What sven meant is to drag the .changes on your new image, it will open a special tool to browse the changes.
Marcus
-- Marcus Denker -- http://marcusdenker.de
Sebastian You know we value code. So if this is a terrible problem for you, it may be wise to spend some evening listening cool music and hacking so that it is better. Because it will not magically happen. There is always a guy behind an improvement. Stef On Nov 8, 2012, at 10: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 <sebastian@flowingconcept.com> â¦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.
On 2012-11-09, at 20:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Sebastian
You know we value code. So if this is a terrible problem for you, it may be wise to spend some evening listening cool music and hacking so that it is better. Because it will not magically happen. There is always a guy behind an improvement.
already happened ;) https://code.google.com/p/pharo/issues/detail?id=6941 so this won't happen so easily again :)
Stef
On Nov 8, 2012, at 10:30 PM, Sebastian Nozzi wrote:
Could you debug the VM and alter the bytecodes? On Thu, Nov 8, 2012 at 10:51 AM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
â¦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 <https://about.me/sebastianconcept>
o/
PS: I've tried with startup.st with the code that removes that method but no luck.
participants (10)
-
blake -
Camillo Bruni -
Henrik Sperre Johansen -
Igor Stasenko -
Jan Vrany -
Marcus Denker -
Mariano Martinez Peck -
Sebastian Nozzi -
Sebastian Sastre -
Stéphane Ducasse