[Pharo-dev] Responsible development

phil at highoctane.be phil at highoctane.be
Tue Dec 3 04:28:59 EST 2013

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.


Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:phil at 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 -
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 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.
> > (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/51dd89d8/attachment-0002.html>

More information about the Pharo-dev mailing list