[squeak-dev] Progress bar design pattern

Martin Dias tinchodias at gmail.com
Thu Mar 31 21:56:25 UTC 2011


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 at gmail.com> wrote:

>
> 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/31e768a6/attachment.htm


More information about the Squeak-dev mailing list