Re: [Pharo-project] Don't ever ever halt in #startUp:
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 sebast...@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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
On Nov 8, 2012, at 10:12 PM, Sebastian Sastre sebast...@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
Re: [Pharo-project] Don't ever ever halt in #startUp:
On 09.11.2012 13:36, Sebastian Nozzi wrote: 2012/11/9 Igor Stasenko siguc...@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
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 siguc...@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
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 sebast...@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
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
On 2012-11-09, at 20:10, Stéphane Ducasse stephane.duca...@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:
Re: [Pharo-project] Don't ever ever halt in #startUp:
On 9 November 2012 09:36, Sebastian Nozzi sebno...@gmail.com wrote: 2012/11/9 Igor Stasenko siguc...@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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
On 9 November 2012 21:32, Igor Stasenko siguc...@gmail.com wrote: On 9 November 2012 09:36, Sebastian Nozzi sebno...@gmail.com wrote: 2012/11/9 Igor Stasenko siguc...@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.
[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. And 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 classstartUp: 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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
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.html On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi sebno...@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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 marianop...@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.html On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi sebno...@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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 camillobr...@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 marianop...@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.html On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi sebno...@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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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
Re: [Pharo-project] Don't ever ever halt in #startUp:
Could you debug the VM and alter the bytecodes? On Thu, Nov 8, 2012 at 10:51 AM, Sebastian Sastre sebast...@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. And 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 classstartUp: 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.
Re: [Pharo-project] Don't ever ever halt in #startUp:
Cool :-) This will be a default behaviour, or activated through a command-line switch? 2012/11/8 Camillo Bruni camillobr...@gmail.com https://code.google.com/p/pharo/issues/detail?id=6941 so that your experience will be last one :)
Re: [Pharo-project] Don't ever ever halt in #startUp:
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 MorphdrawnOn:. 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 sebast...@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. And 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 classstartUp: 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.
