[Pharo-dev] Responsible development

kilon alios kilon.alios at gmail.com
Tue Dec 3 05:40:24 EST 2013


looks like your post to the mailing list was not as pointless as you
thought ;)

Great work Benjamin


On Tue, Dec 3, 2013 at 12:38 PM, Yuriy Tymchuk <yuriy.tymchuk at me.com> wrote:

>
> On 03 Dec 2013, at 11:08, Benjamin <Benjamin.VanRyseghem.Pharo at gmail.com>
> wrote:
>
> On 03 Dec 2013, at 10:01, Stéphane Ducasse <stephane.ducasse at inria.fr>
> wrote:
>
>
> On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo at gmail.com>
> wrote:
>
> On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse at 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.
>
>
> It should not freeze your image anymore, only its own thread
>
>
> Wow, that was fast
>
>
> Ben
>
>
> (why cache by the way ?)
>
>
> I thought the discussion was about speeding up nautilus when performing
> start up actions.
>
>
> Ben
>
>
> Stef
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131203/a66447e3/attachment-0002.html>


More information about the Pharo-dev mailing list