The main issue I do face when doing Pharo dev at the moment is that there is always this feeling of risking getting locked out of the image.
It happens every once in a while for weird reasons. Now, with configurations, Monticello and some changes file drag and drops, it is tolerable. But there is that fear of getting the image to freeze. The Cmd + . not working at all times add to that impression. Things like Oz and a remote browser to an image may alleviate that at one point in the future. Now, Xcode also freezes at times, and good luck for finding what's wrong. The ability to regain control is really what could be a great plus to the platform. As far as I am concerned, as a developer, I hate not having control on what's going on when coding. That may be a psychological trait. And yes, OO isn't about understanding it all before doing anything. But facing a frozen image with no way to get it back is really deeply frustrating. Especially with no way to understand why it went dark. That's where Oz is very interesting (as is Spoon with the remote browser - no matter how unfinished that is). So, I end up saving my image like XXX_yyyymmdd_hhmm with one workspace a day (workspaceProjectYYYYMMDD). This takes a lot of disk space, but that is cheap now. It all is rooted in the fear of getting a freeze. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Dec 3, 2013 at 10:01 AM, Stéphane Ducasse <stephane.duca...@inria.fr > wrote: > > On Dec 2, 2013, at 8:37 PM, Benjamin <benjamin.vanryseghem.ph...@gmail.com> > wrote: > > > On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.duca...@inria.fr> > wrote: > > > >>>>> We try now to have responsive UIs in the sense the tools like > Nautilus try to > >>>>> run things in a separate thread. > >>>>> > >>>>> I will do an experiment and fork each Nautilus opening to see if it > can save my ass :P > >>>> :) > >>>> > >>>> personnally I would be really against because just forking is just a > way to have a lot more mess in the future. > >>> > >>> Why ? > >> > >> Because you do not know when you invariants should hold. Normally you > expect them to hold once the system is loaded. > >> Because loading for example act as an atomic action when you modify the > system. Now if your thread can see and modify > >> different versions of the state be prepared to have really strange and > difficult bugs to find. > >> > >> I prefer to have cache than to have forked processes around. > > > > Cache will not help you killing Nautilus when it freezes your image > > fork neither. > > > (why cache by the way ?) > > I thought the discussion was about speeding up nautilus when performing > start up actions. > > > > Ben > > > >> > >> Stef > > > > > > >
