- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Sebastian Nozzi

Cool :-) This will be a default behaviour, or activated through a command-line switch? 2012/11/8 Camillo Bruni <camillobruni(a)gmail.com> > https://code.google.com/p/pharo/issues/detail?id=6941 > > so that your experience will be last one :)

Nov. 9, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by blake

Could you debug the VM and alter the bytecodes? On Thu, Nov 8, 2012 at 10:51 AM, Sebastian Sastre < sebastian(a)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. > > > >

Nov. 8, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Camillo Bruni

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(a)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(a)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.h… >> >> On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi(a)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(a)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 >> >

Nov. 8, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Camillo Bruni

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(a)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.h… > > On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi(a)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(a)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 >

Nov. 8, 2012

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

by Mariano Martinez Peck

On Thu, Nov 8, 2012 at 10:41 PM, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > This "tip" is very welcome, didn't know that you could import changes made > from another image. http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/ title "Recovering lost code:" I paste it here: *- Recovering lost code: Probably, one of the things Smalltalkers are always proud of saying is âIn Smalltalk you never lose codeâ hehhehe. Soâ¦ your vm crashed and you didnât save your code? Well, there are different ways of recovering the code. 1) Tools -> Recover lost changes. There you can select the date from where to start watching the changes. Once you select a point in time, you can go item by item seeing what you want to recover. What I usually do is multi-select all the ones I want to recover and then I click on âfile in selectionsâ. That will install back those lost changes. Notice that this is thanks to the .changes file so you need it in order to recover changes. Also notice that even Do-Its are saved. 2) If your image does not even start, are you screwed up? No! You can even browse the changes and recover your lost data in ANOTHER image. Just open another image and then drag and drop the .changes of the image you lost the data. Then repeat the option 1). 3) You can always take your prefer text editor, open the .changes file and copy paste * Should definitely be included in the section "recovering > lost changes" in the Pharo book (in case it isn't there already ;-). > > Also very welcome is a new "description of changes". Without knowing its > details, may I make a suggestion? > > When recovering lost changes what we need is to quickly distinguish (i.e. > "filter-out") operations on classes/methods and everything else. Having to > look through all the do-its in order to see if they are "Workspace > experiments" or important is very time-consuming, and there is always the > possibility to miss some important "do it", and then the whole "import" is > stopped. > > So it would be great if there were different "filters", and if the changes > were more explicit. > > Other than that, when I needed it, I was grateful that this functionality > existed at all :-) > > Cheers, > > Sebastian > > > 2012/11/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> >> On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: >> >> > Hi, >> > >> > One of the cool things of Smalltalk's images/changes file is that you >> > can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of >> > your code in case your image/OS/machine suddenly crashed or you forgot to >> > save your image or commit your Monticello packages. >> > >> > But we all have encountered the situation where the image is broken, >> > saved in such a state that it no longer starts up properly. In that case >> > your code might seem lost forever. >> > >> > No, it is not ! >> > >> > Two days ago I had this problem myself and I remembered something Marcus >> > said some time ago: you can access the changes file of one (in casu your >> > broken image) from another (working) image to select/recover the changes you >> > want. It worked perfectly. >> > >> > The easiest procedure it to copy the .changes file from the broken image >> > and rename its extension to .cs and then open it from a World Menu > Tools > >> > File Browser and open a Changes browser on it. >> >> We should add a recover from another image shortcut. >> > >> > I found this very useful. This is a really important technique to be >> > aware of. >> > >> > Sven >> > >> > [1] Sadly, not everything is logged in the changes file: creation of new >> > classes, method deletions are not recorded. >> >> Yes we should change that. >> Ezequiel started to work on a new description of changes. >> >> > >> > -- >> > Sven Van Caekenberghe >> > http://stfx.eu >> > Smalltalk is the Red Pill >> > >> > >> > >> > >> >> > -- Mariano http://marianopeck.wordpress.com

Nov. 8, 2012

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

by Sebastian Nozzi

This "tip" is very welcome, didn't know that you could import changes made from another image. Should definitely be included in the section "recovering lost changes" in the Pharo book (in case it isn't there already ;-). Also very welcome is a new "description of changes". Without knowing its details, may I make a suggestion? When recovering lost changes what we need is to quickly distinguish (i.e. "filter-out") operations on classes/methods and everything else. Having to look through all the do-its in order to see if they are "Workspace experiments" or important is very time-consuming, and there is always the possibility to miss some important "do it", and then the whole "import" is stopped. So it would be great if there were different "filters", and if the changes were more explicit. Other than that, when I needed it, I was grateful that this functionality existed at all :-) Cheers, Sebastian 2012/11/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > > > Hi, > > > > One of the cool things of Smalltalk's images/changes file is that you > can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of > your code in case your image/OS/machine suddenly crashed or you forgot to > save your image or commit your Monticello packages. > > > > But we all have encountered the situation where the image is broken, > saved in such a state that it no longer starts up properly. In that case > your code might seem lost forever. > > > > No, it is not ! > > > > Two days ago I had this problem myself and I remembered something Marcus > said some time ago: you can access the changes file of one (in casu your > broken image) from another (working) image to select/recover the changes > you want. It worked perfectly. > > > > The easiest procedure it to copy the .changes file from the broken image > and rename its extension to .cs and then open it from a World Menu > Tools > > File Browser and open a Changes browser on it. > > We should add a recover from another image shortcut. > > > > I found this very useful. This is a really important technique to be > aware of. > > > > Sven > > > > [1] Sadly, not everything is logged in the changes file: creation of new > classes, method deletions are not recorded. > > Yes we should change that. > Ezequiel started to work on a new description of changes. > > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > > > > > >

Nov. 8, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Mariano Martinez Peck

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.h… On Thu, Nov 8, 2012 at 10:30 PM, Sebastian Nozzi <sebnozzi(a)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(a)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

Nov. 8, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Sebastian Nozzi

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(a)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. > > > >

Nov. 8, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by StÃ©phane Ducasse

On Nov 8, 2012, at 9:13 PM, Sven Van Caekenberghe wrote: > > On 08 Nov 2012, at 20:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I told you several time, do you think that a guy do not understand what is a pointer because he does not know how to write it >> in C? >> Give a chance to professionals to learn. We are not talking about explaining what is a pointer, but explaining the >> potential problems and challenges >> >> With your reasoning, I should stop programming because there are so many things that I did not learn in school >> and I would not have no chance to learn from this community. So with that reasoning I should better stop working in Smalltalk >> and look for another language! > > I think he meant it as a general warning ;-) yes I know > > The things is, as long as its pure Smalltalk, you are protected by a very good dynamic type system that cannot really be broken, i.e. the object illusion is kept (bounds checking, blah blah â¦) indeed but this means that with a little care we should be able to explain points. I do not see them as difficult, just full of little details. > But once you start using C pointers, you can very easily do something wrong. It might be a very subtle error and it might not manifest itself immediately, alas there won't be a Debugger popping up, just a coredump. > > Pharo is actually pretty/very stable in day to day use, it should stay that way. oh! yes! Stef > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Nov. 8, 2012

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

by Sven Van Caekenberghe

On 08 Nov 2012, at 21:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > >> Hi, >> >> One of the cool things of Smalltalk's images/changes file is that you can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of your code in case your image/OS/machine suddenly crashed or you forgot to save your image or commit your Monticello packages. >> >> But we all have encountered the situation where the image is broken, saved in such a state that it no longer starts up properly. In that case your code might seem lost forever. >> >> No, it is not ! >> >> Two days ago I had this problem myself and I remembered something Marcus said some time ago: you can access the changes file of one (in casu your broken image) from another (working) image to select/recover the changes you want. It worked perfectly. >> >> The easiest procedure it to copy the .changes file from the broken image and rename its extension to .cs and then open it from a World Menu > Tools > File Browser and open a Changes browser on it. > > We should add a recover from another image shortcut. Yes! Good idea. >> I found this very useful. This is a really important technique to be aware of. >> >> Sven >> >> [1] Sadly, not everything is logged in the changes file: creation of new classes, method deletions are not recorded. > > Yes we should change that. > Ezequiel started to work on a new description of changes. OK.

Nov. 8, 2012