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:phil@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.ducasse@inria.fr> wrote:

On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:

> On 02 Dec 2013, at 20:27, St�phane Ducasse <stephane.ducasse@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
>
>