On Thu, Mar 31, 2011 at 5:47 PM, Yoshiki Ohshima <yoshiki at 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 at 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 at 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)>]
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110331/59564df1/attachment.htm