New System Progress Bar

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

New System Progress Bar

Sean P. DeNigris
Administrator
To help explain the changes, here's a snippet from the fix to "Issue 6099: Deprecate #value: for system progress (was red cross during updates)" (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable.

The slice in the inbox for this issue should fix the "red cross during updates" problem...

MOTIVATION:
The old system progress worked like this (for example)...

        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
                1 to: 100 do: [ :x |
                        bar value: x.
                        bar value: 'On iteration ', x asString.
                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ].

* The work block ([ :bar | ... ] above) would accept one argument
* That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above:
  - #value: aNumber; where aNumber is between the min and max of the progress range -> Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete
  - #value: aString -> Set the label of the progress morph to aString

This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes:

        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
                1 to: 100 do: [ :x |
                        bar current: x.
                        bar label: 'On iteration ', x asString.
                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ].
       
As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'.

One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example:
        informUserDuring: aBlock
                aBlock value: [:string | ].

Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so:
        informUserDuring: aBlock
                aBlock value: DummySystemProgressItem new.

Where DummySystemProgressItem simply ignores all messages without signaling an error
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Schwab,Wilhelm K
Events are preferable to exceptions for updating the bar.  Exceptions should be reserved for things that are exceptional :)

Event registrations should be weak so that one *can* set and forget, but one should also be able to explicitly unregister if desired/needed.  I will also take this opportunity to re-assert that weak collections should be inherently thread-safe and self-repairing.  Pharo's weaklings do not measure up to Dolphin's in these areas.

 Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]]
Sent: Thursday, June 21, 2012 10:14 AM
To: [hidden email]
Subject: [Pharo-project] New System Progress Bar

To help explain the changes, here's a snippet from the fix to "Issue 6099:
Deprecate #value: for system progress (was red cross during updates)"
(http://code.google.com/p/pharo/issues/detail?id=6099). The API (see
SystemProgressItemMorph) is not set in stone, but it's already much less
confusing than the old pseudo-class implementation. Ultimately, I'd like to
move to announcements instead of exceptions to signal progress, and decouple
the progress model/view - maybe just [un]registering the progress morph to
enable/disable.

The slice in the inbox for this issue should fix the "red cross during
updates" problem...

MOTIVATION:
The old system progress worked like this (for example)...

        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
                1 to: 100 do: [ :x |
                        bar value: x.
                        bar value: 'On iteration ', x asString.
                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
what's going on" ] ].

* The work block ([ :bar | ... ] above) would accept one argument
* That argument (:bar above) would be a block, that would act as a
pseudo-class. Depending on what was passed to #value:, it would perform
different functions. Two are illustrated above:
  - #value: aNumber; where aNumber is between the min and max of the
progress range -> Set the bar's current progress mark to that position. For
example, 'bar value: 50' above would show the operation half complete
  - #value: aString -> Set the label of the progress morph to aString

This was very confusing, so we created a real class,
SystemProgressItemMorph, which now gets passed to the work block, and has a
real API. So, for example, the following becomes:

        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
                1 to: 100 do: [ :x |
                        bar current: x.
                        bar label: 'On iteration ', x asString.
                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
what's going on" ] ].

As you can see, '#value: newValue' has become '#current: newValue', and
'#value: newLabel' has become '#label: newLabel'.

One wrinkle is that some users were passing a nil-like block instead of the
the pseudo-class to suppress the system progress bar. For example:
        informUserDuring: aBlock
                aBlock value: [:string | ].

Above, [:string | ] would now cause a DNU when sent, for example, #current:,
which obviously blocks don't understand. So, these cases were changed like
so:
        informUserDuring: aBlock
                aBlock value: DummySystemProgressItem new.

Where DummySystemProgressItem simply ignores all messages without signaling
an error

--
View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Sean P. DeNigris
Administrator
Schwab,Wilhelm K wrote
Exceptions should be reserved for things that are exceptional :)
Yes :) Although, with humans, progress is an exceptional condition ;-)

Also, it'd be *great* if this fix is reviewed quickly because it touches quite a few packages and will rot quickly

- S
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Stéphane Ducasse
In reply to this post by Sean P. DeNigris
Thanks sean!
Thanks thanks! I never the too smart aspect of the value:
And I already removed broken code that performed animation inside :)
Looking at your changes now.

Stef

On Jun 21, 2012, at 4:14 PM, Sean P. DeNigris wrote:

> To help explain the changes, here's a snippet from the fix to "Issue 6099:
> Deprecate #value: for system progress (was red cross during updates)"
> (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see
> SystemProgressItemMorph) is not set in stone, but it's already much less
> confusing than the old pseudo-class implementation. Ultimately, I'd like to
> move to announcements instead of exceptions to signal progress, and decouple
> the progress model/view - maybe just [un]registering the progress morph to
> enable/disable.
>
> The slice in the inbox for this issue should fix the "red cross during
> updates" problem...
>
> MOTIVATION:
> The old system progress worked like this (for example)...
>
> SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
> 1 to: 100 do: [ :x |
> bar value: x.
> bar value: 'On iteration ', x asString.
> (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
> what's going on" ] ].
>
> * The work block ([ :bar | ... ] above) would accept one argument
> * That argument (:bar above) would be a block, that would act as a
> pseudo-class. Depending on what was passed to #value:, it would perform
> different functions. Two are illustrated above:
>  - #value: aNumber; where aNumber is between the min and max of the
> progress range -> Set the bar's current progress mark to that position. For
> example, 'bar value: 50' above would show the operation half complete
>  - #value: aString -> Set the label of the progress morph to aString
>
> This was very confusing, so we created a real class,
> SystemProgressItemMorph, which now gets passed to the work block, and has a
> real API. So, for example, the following becomes:
>
> SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
> 1 to: 100 do: [ :x |
> bar current: x.
> bar label: 'On iteration ', x asString.
> (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
> what's going on" ] ].
>
> As you can see, '#value: newValue' has become '#current: newValue', and
> '#value: newLabel' has become '#label: newLabel'.
>
> One wrinkle is that some users were passing a nil-like block instead of the
> the pseudo-class to suppress the system progress bar. For example:
> informUserDuring: aBlock
> aBlock value: [:string | ].
>
> Above, [:string | ] would now cause a DNU when sent, for example, #current:,
> which obviously blocks don't understand. So, these cases were changed like
> so:
> informUserDuring: aBlock
> aBlock value: DummySystemProgressItem new.
>
> Where DummySystemProgressItem simply ignores all messages without signaling
> an error
>
> --
> View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Igor Stasenko
btw, about human readable..,
i don't understand, why we don't have something as simple as:

collection do: [... ] showingProgress: 'Processing collection'
(1 to: 100) do: [ ...] showingProgress: 'Processing '

1 to: 100 do: [ ...] showingProgress: 'Processing '

i don't care what happens inside, but this interface is IMO much simpler
and straightforward:
a user just adds showingProgress: at the end, and voila, his silent block
now showing a progress.

--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

philippeback
What about a Progressing Trait?

2012/6/22 Igor Stasenko <[hidden email]>
btw, about human readable..,
i don't understand, why we don't have something as simple as:

collection do: [... ] showingProgress: 'Processing collection'
(1 to: 100) do: [ ...] showingProgress: 'Processing '

1 to: 100 do: [ ...] showingProgress: 'Processing '

i don't care what happens inside, but this interface is IMO much simpler
and straightforward:
a user just adds showingProgress: at the end, and voila, his silent block
now showing a progress.

--
Best regards,
Igor Stasenko.




--
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be

High Octane SPRL
rue cour Boisacq 101
1301 Bierges
Belgium
Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Camillo Bruni-3
In reply to this post by Igor Stasenko
You already have that igor (not as complete as you want, but it's there)

Collection >> #do:displayingProgress:


On 2012-06-22, at 02:37, Igor Stasenko wrote:

> btw, about human readable..,
> i don't understand, why we don't have something as simple as:
>
> collection do: [... ] showingProgress: 'Processing collection'
> (1 to: 100) do: [ ...] showingProgress: 'Processing '
>
> 1 to: 100 do: [ ...] showingProgress: 'Processing '
>
> i don't care what happens inside, but this interface is IMO much simpler
> and straightforward:
> a user just adds showingProgress: at the end, and voila, his silent block
> now showing a progress.
>
> --
> Best regards,
> Igor Stasenko.
>


Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Igor Stasenko
On 22 June 2012 09:46, Camillo Bruni <[hidden email]> wrote:
> You already have that igor (not as complete as you want, but it's there)
>
> Collection >> #do:displayingProgress:
>
>
ah, good to know

> On 2012-06-22, at 02:37, Igor Stasenko wrote:
>
>> btw, about human readable..,
>> i don't understand, why we don't have something as simple as:
>>
>> collection do: [... ] showingProgress: 'Processing collection'
>> (1 to: 100) do: [ ...] showingProgress: 'Processing '
>>
>> 1 to: 100 do: [ ...] showingProgress: 'Processing '
>>
>> i don't care what happens inside, but this interface is IMO much simpler
>> and straightforward:
>> a user just adds showingProgress: at the end, and voila, his silent block
>> now showing a progress.
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Pavel Krivanek-3
In reply to this post by Sean P. DeNigris
It seems that the new progress bar doesn't work well with DummyUIManager, see
https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%202.0/139/console

-- Pavel

On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <[hidden email]> wrote:

> To help explain the changes, here's a snippet from the fix to "Issue 6099:
> Deprecate #value: for system progress (was red cross during updates)"
> (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see
> SystemProgressItemMorph) is not set in stone, but it's already much less
> confusing than the old pseudo-class implementation. Ultimately, I'd like to
> move to announcements instead of exceptions to signal progress, and decouple
> the progress model/view - maybe just [un]registering the progress morph to
> enable/disable.
>
> The slice in the inbox for this issue should fix the "red cross during
> updates" problem...
>
> MOTIVATION:
> The old system progress worked like this (for example)...
>
>        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
>                1 to: 100 do: [ :x |
>                        bar value: x.
>                        bar value: 'On iteration ', x asString.
>                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
> what's going on" ] ].
>
> * The work block ([ :bar | ... ] above) would accept one argument
> * That argument (:bar above) would be a block, that would act as a
> pseudo-class. Depending on what was passed to #value:, it would perform
> different functions. Two are illustrated above:
>  - #value: aNumber; where aNumber is between the min and max of the
> progress range -> Set the bar's current progress mark to that position. For
> example, 'bar value: 50' above would show the operation half complete
>  - #value: aString -> Set the label of the progress morph to aString
>
> This was very confusing, so we created a real class,
> SystemProgressItemMorph, which now gets passed to the work block, and has a
> real API. So, for example, the following becomes:
>
>        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
>                1 to: 100 do: [ :x |
>                        bar current: x.
>                        bar label: 'On iteration ', x asString.
>                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
> what's going on" ] ].
>
> As you can see, '#value: newValue' has become '#current: newValue', and
> '#value: newLabel' has become '#label: newLabel'.
>
> One wrinkle is that some users were passing a nil-like block instead of the
> the pseudo-class to suppress the system progress bar. For example:
>        informUserDuring: aBlock
>                aBlock value: [:string | ].
>
> Above, [:string | ] would now cause a DNU when sent, for example, #current:,
> which obviously blocks don't understand. So, these cases were changed like
> so:
>        informUserDuring: aBlock
>                aBlock value: DummySystemProgressItem new.
>
> Where DummySystemProgressItem simply ignores all messages without signaling
> an error
>
> --
> View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Pavel Krivanek-3
http://code.google.com/p/pharo/issues/detail?id=6123

On Fri, Jun 22, 2012 at 11:27 AM, Pavel Krivanek
<[hidden email]> wrote:

> It seems that the new progress bar doesn't work well with DummyUIManager, see
> https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%202.0/139/console
>
> -- Pavel
>
> On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <[hidden email]> wrote:
>> To help explain the changes, here's a snippet from the fix to "Issue 6099:
>> Deprecate #value: for system progress (was red cross during updates)"
>> (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see
>> SystemProgressItemMorph) is not set in stone, but it's already much less
>> confusing than the old pseudo-class implementation. Ultimately, I'd like to
>> move to announcements instead of exceptions to signal progress, and decouple
>> the progress model/view - maybe just [un]registering the progress morph to
>> enable/disable.
>>
>> The slice in the inbox for this issue should fix the "red cross during
>> updates" problem...
>>
>> MOTIVATION:
>> The old system progress worked like this (for example)...
>>
>>        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
>>                1 to: 100 do: [ :x |
>>                        bar value: x.
>>                        bar value: 'On iteration ', x asString.
>>                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
>> what's going on" ] ].
>>
>> * The work block ([ :bar | ... ] above) would accept one argument
>> * That argument (:bar above) would be a block, that would act as a
>> pseudo-class. Depending on what was passed to #value:, it would perform
>> different functions. Two are illustrated above:
>>  - #value: aNumber; where aNumber is between the min and max of the
>> progress range -> Set the bar's current progress mark to that position. For
>> example, 'bar value: 50' above would show the operation half complete
>>  - #value: aString -> Set the label of the progress morph to aString
>>
>> This was very confusing, so we created a real class,
>> SystemProgressItemMorph, which now gets passed to the work block, and has a
>> real API. So, for example, the following becomes:
>>
>>        SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar |
>>                1 to: 100 do: [ :x |
>>                        bar current: x.
>>                        bar label: 'On iteration ', x asString.
>>                        (Delay forMilliseconds: 20) wait "Just to slow it down so we can see
>> what's going on" ] ].
>>
>> As you can see, '#value: newValue' has become '#current: newValue', and
>> '#value: newLabel' has become '#label: newLabel'.
>>
>> One wrinkle is that some users were passing a nil-like block instead of the
>> the pseudo-class to suppress the system progress bar. For example:
>>        informUserDuring: aBlock
>>                aBlock value: [:string | ].
>>
>> Above, [:string | ] would now cause a DNU when sent, for example, #current:,
>> which obviously blocks don't understand. So, these cases were changed like
>> so:
>>        informUserDuring: aBlock
>>                aBlock value: DummySystemProgressItem new.
>>
>> Where DummySystemProgressItem simply ignores all messages without signaling
>> an error
>>
>> --
>> View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>

Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Sean P. DeNigris
Administrator
The fix is good. Made a slice and marked it FixToInclude...

Pavel,
I understand we probably don't want progress in the kernel, but can you live with it for a bit while we figure out what to do about progress? There is a lot of discussion on the dev list... Otherwise, I could put the Dummy in it's own package or whatever you suggest. Really, all it's doing is ignoring all messages via DNU, so it could be any object that does that... This was just a patch so Jenkins would start working again while we discuss and clean and enhance...

HTH,
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Pavel Krivanek-3


22. 6. 2012 v 15:44, "Sean P. DeNigris" <[hidden email]>:

>
> Pavel Krivanek-3 wrote
>>
>> http://code.google.com/p/pharo/issues/detail?id=6123
>>
>
> The fix is good. Made a slice and marked it FixToInclude...
>
> Pavel,
> I understand we probably don't want progress in the kernel, but can you live
> with it for a bit while we figure out what to do about progress? There is a
> lot of discussion on the dev list... Otherwise, I could put the Dummy in
> it's own package or whatever you suggest. Really, all it's doing is ignoring
> all messages via DNU, so it could be any object that does that... This was
> just a patch so Jenkins would start working again while we discuss and clean
> and enhance...
>
> HTH,
> Sean

I already included the fix into the build scripts so the Jenkins job is working again and we can put other temporary fixes there too. Simply have the alternative UI managers in mind while progress bar redesign :-) I think that classes like that should be in the same package as DummyUIManager. However ignoring of messages by DNU doesn't look as good design to me :-)

 -- Pavel




> --
> View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912p4636154.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: New System Progress Bar

Sean P. DeNigris
Administrator
Pavel Krivanek-3 wrote
I already included the fix into the build scripts so the Jenkins job is working again and we can put other temporary fixes there too.
Okay, great! Will these be included if users update though the world menu?

Pavel Krivanek-3 wrote
Simply have the alternative UI managers in mind while progress bar redesign :-)
Trust me, I definitely do now, lol!

Pavel Krivanek-3 wrote
I think that classes like that should be in the same package as DummyUIManager.
Sounds good to me...

Pavel Krivanek-3 wrote
However ignoring of messages by DNU doesn't look as good design to me :-)
Absolutely, it's total rubbish! But (from the vision)...
"One step at a time.
Perfection can kill movement.
Quality is a emerging property."
Cheers,
Sean