On Tue, Apr 23, 2013 at 6:58 PM, Igor Stasenko <siguc...@gmail.com> wrote: > Have you ever seen the list of processes running under your OS? > There's many, isn't? > The operating systems may be different, but i'd like to tell, what is > common between all of them: > - by looking at list of processes you have no idea what each of them > there for, nor what are they doing. > > For instance, my home windows machine has strange peaks of disk > activity (when it supposed to be idle, since it is not touched > more than a hour)... > now this is annoying that i cannot ask system in easy way, what is > going on and why such heavy disk activity is needed, > and disable such "very important feature"..
Under Linux you can.
> Today's systems grown too large and too clever, where user more and
> more feels like a passenger (which request to stop the train can be
> silently ignored), rather than driver of the train who can stop it at
> any moment.
>
> ...snip...
>
> Sure thing, i am not proposing to change the world and fix today's
> operating systems, but what i thought that at least in Pharo we have a
> good
> opportunity to fix that.
>
> I think it would be beneficial to establish a quality standard (or at
> least make an attempt to move closer to it):
> - each running process should have a description what its purpose and
> who/what running it, as well as how to terminate it in non-abrupt way.
>
> In practice it means that one should not write:
> [ ... ] fork
>
> but
>
> [ ... ] forkWithDescription: 'i doing this that and there'
>
> or even:
>
> [ ... ] forkWithDescription: 'i doing this that and there'
> toTerminateDo: [.. block for graciously terminating this process
> regardless in which state it currently is ]
When I want to name my process I simply avoid the fork shortcut:
[ ... ] newProcess
name: 'processing items' ;
resume
I think this is elegant enough to not need forkWithDescription:.
> So, my question are you with me or not? :)
> And how far?
>
> 0 - keep things as they are
> ...
> 1 - deprecate all protocols which allow anonymous process creation,
> and force developers to always put a description for every #fork in
> their code.
> (or simply refuse to #resume the process unless its description is not nil ;)
>
> There is already field in Process - name. But it is not enforced by
> system that it should be never nil. I am not sure if we need both name
> and description
> or we need just one field (which will serve for both). What i am sure
> about is that anonymous processes are BAD.
I think all caps overstates it a bit. Forcing the user into an
unnecessary API will not help achieve your goal of more lucidity in
the system.
Maybe a user just wants to open up a workspace and start playing
around with Smalltalk processes and show a stranger sitting next to on
a plane as a demo how easy it is. He makes some processes in some
workspace code and "naming" them via temp variables. So if he is
forced to type in a full descriptive name just to satisfy the API, it
is distracting so what is he gonna do? "xxx" will be the name of his
processes because he didn't want to be bothered with that. No
computer can force a human to be clean and organized.
I think this type of idea belongs more at an "App-Studio" level than
in the general-purpose programming kit (Pharo). That's why
MaClientProcess is part of the core-extensions package of the "Ma"
application suite. MaClientProcess provides app developers a nice
wrapper of a Process that handles name+description, current item being
worked, progress, pause, resume and graceful terminate. The only
requirement of the app is that it send #advance to the MaClientProcess
occasionally to support graceful pause/resume/cancel. Based on the
frequency the app sends #advance, MaClientProcess automatically
calculates the "rate" of processing items and, if its #taskSize: has
been specified, the calculated #timeRemaining.
<<attachment: MaClientProcess.png>>
