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 |
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. |
Administrator
|
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 |
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. > |
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. |
What about a Progressing Trait?
2012/6/22 Igor Stasenko <[hidden email]> btw, about human readable.., 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 |
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. > |
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. |
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. > |
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. >> |
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 |
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. > |
Administrator
|
Okay, great! Will these be included if users update though the world menu? Trust me, I definitely do now, lol! Sounds good 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 |
Free forum by Nabble | Edit this page |