At Fri, 1 Apr 2011 12:33:36 +0400,
Denis Kudriashov wrote:
> 
> 2011/4/1 Yoshiki Ohshima <yoshiki at 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