[Pharo-project] Processes, what are they doing?
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".. 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. Since i cannot tell, what each process doing on my machine.. i cannot control them. There's of course a solution: i should spend hours with google , read docs & manuals and in general, look for anywhere else, rather than simply ask a process: what are you doing, what is your responsibility and who runs you and why. Besides, if i cannot ask the process, my study of a system is more or less just a waste of time, because even if i learn everything, tomorrow it will be different OS version or different OS, where everything will be completely different, and there we starting over again: having a list of processes and no clue which is responsible for what and do you need it or not. 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 ] 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. -- Best regards, Igor Stasenko.
Or option #2. Issue a warning for now and deprecated #fork. This will give people some time to fix their code.  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
________________________________ From: Igor Stasenko <siguctua@gmail.com> To: Pharo Development <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, April 23, 2013 7:58:26 PM Subject: [Pharo-project] Processes, what are they doing?
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".. 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.
Since i cannot tell, what each process doing on my machine.. i cannot control them. There's of course a solution: i should spend hours with google , read docs & manuals and in general, look for anywhere else, rather than simply ask a process: what are you doing, what is your responsibility and who runs you and why.
Besides, if i cannot ask the process, my study of a system is more or less just a waste of time, because even if i learn everything, tomorrow it will be different OS version or different OS, where everything will be completely different, and there we starting over again: having a list of processes and no clue which is responsible for what and do you need it or not.
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 ]
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.
-- Best regards, Igor Stasenko.
On Tue, Apr 23, 2013 at 6:58 PM, Igor Stasenko <siguctua@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.
On Wed, Apr 24, 2013 at 11:58 AM, Igor Stasenko <siguctua@gmail.com> wrote:
In practice it means that one should not write: [ ... ] fork
but
[ ... ] forkWithDescription: 'i doing this that and there'
Was BlockContext>>forkNamed: removed from the image? Gulik -- http://gulik.pbwiki.com/
participants (4)
-
Benoit St-Jean -
Chris Muller -
Igor Stasenko -
Michael van der Gulik