Hello
I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs.
The progress bar should be pluggable and decoupled of the algorithms.
I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way.
The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published.
Thanks, Martin
Hello
I have idea about "meta approach" for implementation of progress tracking of arbitrary method execution.
Progress tracking (progress bar stuff) is really ortogonal functionallity for method execution. And it would be cool if we have framework for describing tracking of method execution stuff (like it progress). This framework should run block of code in background and periodically analize state of this background process stack. And show this state for user. And so this framework allow track execution of arbitrary code. Analizing state can search running loops in stack for example and show user status of loop counters.
I think it is not very hard to implement. But maybe this approach can't be implemented when code jitted
2011/3/30 Martin Dias tinchodias@gmail.com
Hello
I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs.
The progress bar should be pluggable and decoupled of the algorithms.
I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way.
The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published.
Thanks, Martin
Please excuse the naivety of a newbie.
Could it simply be a stepped morph?
Each (model) class using a process bar could implement a progress accessor message, returning a fraction. The message could be used by any UI framework such as Seaside, VW or Dolphin. If someone needs it, a
progress: #selector
message could be offered.
Hello
On Wed, Mar 30, 2011 at 4:24 AM, Denis Kudriashov dionisiydk@gmail.comwrote:
Hello
I have idea about "meta approach" for implementation of progress tracking of arbitrary method execution.
Progress tracking (progress bar stuff) is really ortogonal functionallity for method execution. And it would be cool if we have framework for describing tracking of method execution stuff (like it progress). This framework should run block of code in background and periodically analize state of this background process stack. And show this state for user. And so this framework allow track execution of arbitrary code. Analizing state can search running loops in stack for example and show user status of loop counters.
I think it is not very hard to implement. But maybe this approach can't be implemented when code jitted
I like the "meta approach"... but it doesn't look easy to implement for me! Have you seen something like that implemented? or some paper written?
2011/3/30 Martin Dias tinchodias@gmail.com
Hello
I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs.
The progress bar should be pluggable and decoupled of the algorithms.
I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way.
The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published.
Thanks, Martin
I don't understand the problem. Let us say we start from the example in the method:
-------------------- 'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]]. --------------------
and your "algorithm" here would be:
1 to: 10 do: [:x | "do something here" (Delay forMilliseconds: 500) wait].
It is already reasonably decoupled to me, but I take that you want to keep the "algorithm" really prestine and don't want to have "bar value: x" call in there, and completely get rid of anything from "do something here". Is this the case?
There still have to have some way to tell how much percent of work done from the "algorithm" to the progress notification mechanism. In the possible meta approach (which would not be that hard at all), I'd make an instance variable for the object that represents your algorithm state, and the algorithm assigns a value to the instance variable, and the progress bar displayer that is running in a separate thread looks at the variable periodically and update the screen.
However, in this senario, you would have to have an assignment to that variable at "do something here":
----------------- 1 to: 10 do: [:x | progress := x. (Delay forMilliseconds: 500) wait]. -----------------
But is "progress := x" any better than "bar value: x"?
Somebody suggested announcements. So your algorithm would look like:
----------------- 1 to: 10 do: [:x | self announce: (ProgressAnnouncement value: x). (Delay forMilliseconds: 500) wait]. -----------------
And a stepping morph surely does not work. If something was started from a do-it in workspace, next time the morph gets #step message is after the do-it is completed.
The "bar" block could be stored in an instance variable of the algorithm object, and your algorithm may do:
----------------- 1 to: 10 do: [:x | bar ifNotNil: [bar value: x]. (Delay forMilliseconds: 500) wait]. -----------------
This may be just as good as it gets without complicating anything else.
Note that your algorithm may not be a loop. It is totally legitimate to write:
algorithm self doA. bar value: 0.33. self doB. bar value: 0.66. self doC.
where doA, doB, doC are long running computation. So, really generic way to view the progress of something from outside without the knowledge of where to look at and how to interpret these values are not going to fly.
-- Yoshiki
At Thu, 31 Mar 2011 17:10:58 -0300, Martin Dias wrote:
Hello
On Wed, Mar 30, 2011 at 4:24 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hello I have idea about "meta approach" for implementation of progress tracking of arbitrary method execution. Progress tracking (progress bar stuff) is really ortogonal functionallity for method execution. And it would be cool if we have framework for describing tracking of method execution stuff (like it progress). This framework should run block of code in background and periodically analize state of this background process stack. And show this state for user. And so this framework allow track execution of arbitrary code. Analizing state can search running loops in stack for example and show user status of loop counters. I think it is not very hard to implement. But maybe this approach can't be implemented when code jitted
I like the "meta approach"... but it doesn't look easy to implement for me! Have you seen something like that implemented? or some paper written?
2011/3/30 Martin Dias <tinchodias@gmail.com> Hello I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs. The progress bar should be pluggable and decoupled of the algorithms. I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way. The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published. Thanks, Martin
[2 <text/plain; us-ascii (7bit)>]
On Thu, Mar 31, 2011 at 5:47 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
I don't understand the problem. Let us say we start from the example in the method:
'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]].
and your "algorithm" here would be:
1 to: 10 do: [:x | "do something here" (Delay forMilliseconds: 500) wait].
It is already reasonably decoupled to me, but I take that you want to keep the "algorithm" really prestine and don't want to have "bar value: x" call in there, and completely get rid of anything from "do something here". Is this the case?
There still have to have some way to tell how much percent of work done from the "algorithm" to the progress notification mechanism. In the possible meta approach (which would not be that hard at all), I'd make an instance variable for the object that represents your algorithm state, and the algorithm assigns a value to the instance variable, and the progress bar displayer that is running in a separate thread looks at the variable periodically and update the screen.
However, in this senario, you would have to have an assignment to that variable at "do something here":
1 to: 10 do: [:x | progress := x. (Delay forMilliseconds: 500) wait].
But is "progress := x" any better than "bar value: x"?
Somebody suggested announcements. So your algorithm would look like:
1 to: 10 do: [:x | self announce: (ProgressAnnouncement value: x). (Delay forMilliseconds: 500) wait].
And a stepping morph surely does not work. If something was started from a do-it in workspace, next time the morph gets #step message is after the do-it is completed.
The "bar" block could be stored in an instance variable of the algorithm object, and your algorithm may do:
1 to: 10 do: [:x | bar ifNotNil: [bar value: x]. (Delay forMilliseconds: 500) wait].
This may be just as good as it gets without complicating anything else.
Note that your algorithm may not be a loop. It is totally legitimate to write:
algorithm self doA. bar value: 0.33. self doB. bar value: 0.66. self doC.
What you sent makes me think...
I am not convinced of this other solution, but with announcements could be:
algorithm self doA. self announce: (WorkAnnoucement finished: #doA). self doB. self announce: (WorkAnnoucement finished: #doB). self doC. self announce: (WorkAnnoucement finished: #doC).
and the specific observer subscribed to this algorithm knows what percentage corresponds to each selector. And you could easily plug an observer that logs to Transcript.
The announcement can also know
algorithm
self doA. self announce: (WorkAnnoucement finished: #doA).
where doA, doB, doC are long running computation. So, really generic way to view the progress of something from outside without the knowledge of where to look at and how to interpret these values are not going to fly.
-- Yoshiki
At Thu, 31 Mar 2011 17:10:58 -0300, Martin Dias wrote:
Hello
On Wed, Mar 30, 2011 at 4:24 AM, Denis Kudriashov dionisiydk@gmail.com
wrote:
Hello I have idea about "meta approach" for implementation of progress
tracking of arbitrary method execution.
Progress tracking (progress bar stuff) is really ortogonal
functionallity for method execution. And it would be cool
if we have framework for describing tracking of method execution
stuff (like it progress).
This framework should run block of code in background and
periodically analize state of this background process
stack. And show this state for user. And so this framework allow
track execution of arbitrary code.
Analizing state can search running loops in stack for example and
show user status of loop counters.
I think it is not very hard to implement. But maybe this approach
can't be implemented when code jitted
I like the "meta approach"... but it doesn't look easy to implement for
me!
Have you seen something like that implemented? or some paper written?
2011/3/30 Martin Dias <tinchodias@gmail.com> Hello I have a couple of algorithms and I want to show the progress
while they run. I played with the progress bar and
it's okay for my needs. The progress bar should be pluggable and decoupled of the
algorithms.
I am writing to you to ask about good designs for my problem. I
hope I haven't expressed the problem in a too
abstract way. The design I have in mind is a kind of observer pattern: the
serialization algorithm publishes information about
the run; a specific listener implements the progress bar for that
serialization algorithm, interpreting the
information published. Thanks, Martin
[2 <text/plain; us-ascii (7bit)>]
MISPRINT:
In the last part when says:
"The announcement can also know
algorithm
self doA. self announce: (WorkAnnoucement finished: #doA)."
shouldn't go!
Cheers, Martin
On Thu, Mar 31, 2011 at 6:53 PM, Martin Dias tinchodias@gmail.com wrote:
On Thu, Mar 31, 2011 at 5:47 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
I don't understand the problem. Let us say we start from the example in the method:
'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]].
and your "algorithm" here would be:
1 to: 10 do: [:x | "do something here" (Delay forMilliseconds: 500) wait].
It is already reasonably decoupled to me, but I take that you want to keep the "algorithm" really prestine and don't want to have "bar value: x" call in there, and completely get rid of anything from "do something here". Is this the case?
There still have to have some way to tell how much percent of work done from the "algorithm" to the progress notification mechanism. In the possible meta approach (which would not be that hard at all), I'd make an instance variable for the object that represents your algorithm state, and the algorithm assigns a value to the instance variable, and the progress bar displayer that is running in a separate thread looks at the variable periodically and update the screen.
However, in this senario, you would have to have an assignment to that variable at "do something here":
1 to: 10 do: [:x | progress := x. (Delay forMilliseconds: 500) wait].
But is "progress := x" any better than "bar value: x"?
Somebody suggested announcements. So your algorithm would look like:
1 to: 10 do: [:x | self announce: (ProgressAnnouncement value: x). (Delay forMilliseconds: 500) wait].
And a stepping morph surely does not work. If something was started from a do-it in workspace, next time the morph gets #step message is after the do-it is completed.
The "bar" block could be stored in an instance variable of the algorithm object, and your algorithm may do:
1 to: 10 do: [:x | bar ifNotNil: [bar value: x]. (Delay forMilliseconds: 500) wait].
This may be just as good as it gets without complicating anything else.
Note that your algorithm may not be a loop. It is totally legitimate to write:
algorithm self doA. bar value: 0.33. self doB. bar value: 0.66. self doC.
What you sent makes me think...
I am not convinced of this other solution, but with announcements could be:
algorithm self doA. self announce: (WorkAnnoucement finished: #doA). self doB. self announce: (WorkAnnoucement finished: #doB). self doC. self announce: (WorkAnnoucement finished: #doC).
and the specific observer subscribed to this algorithm knows what percentage corresponds to each selector. And you could easily plug an observer that logs to Transcript.
The announcement can also know
algorithm
self doA. self announce: (WorkAnnoucement finished: #doA).
where doA, doB, doC are long running computation. So, really generic way to view the progress of something from outside without the knowledge of where to look at and how to interpret these values are not going to fly.
-- Yoshiki
At Thu, 31 Mar 2011 17:10:58 -0300, Martin Dias wrote:
Hello
On Wed, Mar 30, 2011 at 4:24 AM, Denis Kudriashov dionisiydk@gmail.com
wrote:
Hello I have idea about "meta approach" for implementation of progress
tracking of arbitrary method execution.
Progress tracking (progress bar stuff) is really ortogonal
functionallity for method execution. And it would be cool
if we have framework for describing tracking of method execution
stuff (like it progress).
This framework should run block of code in background and
periodically analize state of this background process
stack. And show this state for user. And so this framework allow
track execution of arbitrary code.
Analizing state can search running loops in stack for example and
show user status of loop counters.
I think it is not very hard to implement. But maybe this approach
can't be implemented when code jitted
I like the "meta approach"... but it doesn't look easy to implement for
me!
Have you seen something like that implemented? or some paper written?
2011/3/30 Martin Dias <tinchodias@gmail.com> Hello I have a couple of algorithms and I want to show the progress
while they run. I played with the progress bar and
it's okay for my needs. The progress bar should be pluggable and decoupled of the
algorithms.
I am writing to you to ask about good designs for my problem. I
hope I haven't expressed the problem in a too
abstract way. The design I have in mind is a kind of observer pattern: the
serialization algorithm publishes information about
the run; a specific listener implements the progress bar for
that serialization algorithm, interpreting the
information published. Thanks, Martin
[2 <text/plain; us-ascii (7bit)>]
At Thu, 31 Mar 2011 18:53:29 -0300, Martin Dias wrote:
What you sent makes me think...
I am not convinced of this other solution, but with announcements could be:
algorithm self doA. self announce: (WorkAnnoucement finished: #doA). self doB. self announce: (WorkAnnoucement finished: #doB). self doC. self announce: (WorkAnnoucement finished: #doC).
and the specific observer subscribed to this algorithm knows what percentage corresponds to each selector. And you could easily plug an observer that logs to Transcript.
Well, say self has an inst var called progress, which may be nil or something that understands #value:.
algorithm self doA. progress ifNotNil: [progress value: #doA]. self doB. progress ifNotNil: [progress value: #doB]. self doC. progress ifNotNil: [progress value: #doC].
All you have to do is to assign a block that looks like:
[:v | Transcript print: v; cr].
to progress to get Transcript. Or, you can assign the bar block from displayProgress: and get UI update. Or, the block can have some #announce: if you want to get multiple parties to get notified.
#value: is generic. A block understands it but also you can just create a class with #value: and let it do anything you want. Again, if the original goal it to "decouple" the algorithm from progress notification, complicating the entire thing with announcement is backward.
-- Yoshiki
2011/4/1 Yoshiki Ohshima yoshiki@vpri.org
I don't understand the problem. Let us say we start from the example in the method:
'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]].
and your "algorithm" here would be:
1 to: 10 do: [:x | "do something here" (Delay forMilliseconds: 500) wait].
It is already reasonably decoupled to me, but I take that you want to keep the "algorithm" really prestine and don't want to have "bar value: x" call in there, and completely get rid of anything from "do something here". Is this the case?
There still have to have some way to tell how much percent of work done from the "algorithm" to the progress notification mechanism. In the possible meta approach (which would not be that hard at all), I'd make an instance variable for the object that represents your algorithm state, and the algorithm assigns a value to the instance variable, and the progress bar displayer that is running in a separate thread looks at the variable periodically and update the screen.
You dont really need to convert some temp to instance variables. You can track some current context temp variable value (context of concrete process which executes algorithm). So you need meta description to specify what peace of code in process context provide progress information
Note that your algorithm may not be a loop. It is totally legitimate
to write:
algorithm self doA. bar value: 0.33. self doB. bar value: 0.66. self doC.
where doA, doB, doC are long running computation. So, really generic way to view the progress of something from outside without the knowledge of where to look at and how to interpret these values are not going to fly.
It's not problem. We have algorithm:
MyClass>>algorithm self doA. self doB. self doC.
And with meta description we can write like:
Progress for: MyClass>>algorithm when: [:desc | desc for: MyClass>>doB value: 0.33. desc for: MyClass>>doC value: 0.66 ]
And doA/B/C can doing some inner loops which we can track with extra meta descriptions.
On 01.04.2011, at 10:33, Denis Kudriashov wrote:
We have algorithm:
MyClass>>algorithm self doA. self doB. self doC.
And with meta description we can write like:
Progress for: MyClass>>algorithm when: [:desc | desc for: MyClass>>doB value: 0.33. desc for: MyClass>>doC value: 0.66 ]
And doA/B/C can doing some inner loops which we can track with extra meta descriptions.
This is basically how MessageTally works. It's a neat idea and certainly could be done, but seems too "magical" for my taste.
I had to implement progress display for a complex file importer once. It had many different stages, like reading the file, parsing, generating objects, optimizing the structure etc. We wanted a continuous, but optional, progress display.
The main idea was to track progress as fractions. Each subtask would track progress from 0.0 to 1.0, and each higher task would scale that to a proportion of the subtask.
An inner loop would look like
1 to: total do: [:i | ... do something ... progress ifNotNil: [progress value: i / total] ].
A subtask might do something like
done := 0. total := items size asFloat. items do: [:each | each processInforming: (progress ifNotNil: [ [:fraction | progress value: (done + fraction) / total]]). done := done + 1].
So it scales each individual fraction to cover part of the total. The cool thing is that these can be arbitrarily nested because each individual progress again goes from 0 to 1.
The outer-most loop looked like
self displayProgress: title from: 1 to: 4 during: [:bar | bar value: 1. X doSomethingInforming: [:fraction | bar value: 1.0 + fraction]. bar value: 2. Y doSomethingElseInforming: [:fraction | bar value: 2.0 + fraction]. bar value: 3. Z doYetMoreInforming: [:fraction | bar value: 3.0 + fraction]. bar value: 4].
This pattern works well if you can roughly estimate in advance how long each subtask will take. If not, then something more like the project loader's ComplexProgressIndicator might be better suited.
If you don't like passing the progress block explicitly, it can be implemented with Notifications, too. But it would still be the work load reporting its progress, rather than peeking from the outside to guess what's going on.
- Bert -
At Fri, 1 Apr 2011 12:33:36 +0400, Denis Kudriashov wrote:
2011/4/1 Yoshiki Ohshima yoshiki@vpri.org
I don't understand the problem. Let us say we start from the example in the method: -------------------- 'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]]. -------------------- and your "algorithm" here would be: 1 to: 10 do: [:x | "do something here" (Delay forMilliseconds: 500) wait]. It is already reasonably decoupled to me, but I take that you want to keep the "algorithm" really prestine and don't want to have "bar value: x" call in there, and completely get rid of anything from "do something here". Is this the case? There still have to have some way to tell how much percent of work done from the "algorithm" to the progress notification mechanism. In the possible meta approach (which would not be that hard at all), I'd make an instance variable for the object that represents your algorithm state, and the algorithm assigns a value to the instance variable, and the progress bar displayer that is running in a separate thread looks at the variable periodically and update the screen.
You dont really need to convert some temp to instance variables. You can track some current context temp variable value (context of concrete process which executes algorithm). So you need meta description to specify what peace of code in process context provide progress information
Well, as Bert wrote, it is somewhat like spyOn: (and as I wrote it is not that hard) to support one kind of it, but I was talking more about the actual benefit of doing it in that way. (Except to keep the "algorithm" absolutely pristine and you can spend time to write the meta description for each and every different kind of algorithms (say, one may want to use the product of temp vars "x" and "y"). Or, if you don't mind exposing the internal of the "algorithm", which happened to be implemented as the sequence of doA, doB, and doC but may change in the future.
Note that your algorithm may not be a loop. It is totally legitimate to write: algorithm self doA. bar value: 0.33. self doB. bar value: 0.66. self doC. where doA, doB, doC are long running computation. So, really generic way to view the progress of something from outside without the knowledge of where to look at and how to interpret these values are not going to fly.
It's not problem. We have algorithm:
MyClass>>algorithm self doA. self doB. self doC.
And with meta description we can write like:
Progress for: MyClass>>algorithm when: [:desc | desc for: MyClass>>doB value: 0.33. desc for: MyClass>>doC value: 0.66 ]
And doA/B/C can doing some inner loops which we can track with extra meta descriptions.
You'd want to specify the sampling rate (as it has to work the chain of contexts to find where it is often), make sure the meta description is in sync, etc.
-- Yoshiki
Hello
I like the "meta approach"... but it doesn't look easy to implement for me!
Have you seen something like that implemented? or some paper written?
No. I dont see something similar. But I know that it is possible to inspect full contexts chain of any process. So I think analizing of process execution can be done
squeak-dev@lists.squeakfoundation.org