The Trunk: Exceptions-cmm.34.mcz
Locked
 
|
Chris Muller uploaded a new version of Exceptions to project The Trunk:
http://source.squeak.org/trunk/Exceptions-cmm.34.mcz ==================== Summary ==================== Name: Exceptions-cmm.34 Author: cmm Time: 15 June 2011, 11:13:51.392 am UUID: f0144460-f227-7b43-bee2-019786f35a4e Ancestors: Exceptions-nice.33 First step toward preferredProgressBarPosition preference. =============== Diff against Exceptions-nice.33 =============== Item was changed: Exception subclass: #ProgressInitiationException instanceVariableNames: 'workBlock maxVal minVal aPoint progressTitle' + classVariableNames: 'PreferredProgressBarPosition' - classVariableNames: '' poolDictionaries: '' category: 'Exceptions-Kernel'! !ProgressInitiationException commentStamp: '<historical>' prior: 0! I provide a way to alter the behavior of the old-style progress notifier in String. See examples in: ProgressInitiationException testWithout. ProgressInitiationException testWith. ! Item was changed: ----- Method: ProgressInitiationException class>>display:at:from:to:during: (in category 'signalling') ----- + display: aString at: aPoint from: minVal to: maxVal during: workBlock - display: aString at: aPoint from: minVal to: maxVal during: workBlock - ^ self new + display: aString + at: (aPoint ifNil: [ self preferredProgressBarPoint ]) + from: minVal + to: maxVal + during: workBlock! - display: aString at: aPoint from: minVal to: maxVal during: workBlock! Item was added: + ----- Method: ProgressInitiationException class>>display:from:to:during: (in category 'signalling') ----- + display: aString from: minVal to: maxVal during: workBlock + ^ self + display: aString + at: nil + from: minVal + to: maxVal + during: workBlock! Item was added: + ----- Method: ProgressInitiationException class>>preferredProgressBarPoint (in category 'accessing') ----- + preferredProgressBarPoint + ^ self preferredProgressBarPosition = #cursorPoint + ifTrue: [ Sensor cursorPoint ] + ifFalse: [ UIManager default screen perform: self preferredProgressBarPosition ]! Item was added: + ----- Method: ProgressInitiationException class>>preferredProgressBarPosition (in category 'accessing') ----- + preferredProgressBarPosition + ^ PreferredProgressBarPosition ifNil: [ #center ]! Item was added: + ----- Method: ProgressInitiationException class>>preferredProgressBarPosition: (in category 'accessing') ----- + preferredProgressBarPosition: aSymbol + "Specify any of: #center, #topCenter, #bottomCenter, #leftCenter, #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or #cursorPoint." + ^ PreferredProgressBarPosition! Item was changed: ----- Method: ProgressInitiationException class>>testInnermost (in category 'examples and tests') ----- testInnermost "test the progress code WITHOUT special handling" ^'Now here''s some Real Progress' + displayProgressFrom: 0 - displayProgressAt: Sensor cursorPoint - from: 0 to: 10 during: [ :bar | 1 to: 10 do: [ :x | bar value: x. (Delay forMilliseconds: 500) wait. x = 5 ifTrue: [1/0]. "just to make life interesting" ]. 'done' ]. ! |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
Hi Chris,
just because ProgressInitiationException is an exception doesn't imply it belongs in exceptions. Surely it belongs in the same package as the progress bar. best
Eliot
On Wed, Jun 15, 2011 at 9:13 AM, <[hidden email]> wrote: Chris Muller uploaded a new version of Exceptions to project The Trunk: |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
If, by "the progress bar" you mean SystemProgressMorph, I disagree,
since that would create a dependency on Morphic. ProgressInitiationException allows domain-level code to signal that something worth indicating progress is occurring, and different UI frameworks can capture that notification (or not) and render it each in their own way. - Chris On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda <[hidden email]> wrote: > Hi Chris, > just because ProgressInitiationException is an exception doesn't imply > it belongs in exceptions. Surely it belongs in the same package as the > progress bar. > best > Eliot > > On Wed, Jun 15, 2011 at 9:13 AM, <[hidden email]> wrote: >> >> Chris Muller uploaded a new version of Exceptions to project The Trunk: >> http://source.squeak.org/trunk/Exceptions-cmm.34.mcz >> >> ==================== Summary ==================== >> >> Name: Exceptions-cmm.34 >> Author: cmm >> Time: 15 June 2011, 11:13:51.392 am >> UUID: f0144460-f227-7b43-bee2-019786f35a4e >> Ancestors: Exceptions-nice.33 >> >> First step toward preferredProgressBarPosition preference. >> >> =============== Diff against Exceptions-nice.33 =============== >> >> Item was changed: >> Exception subclass: #ProgressInitiationException >> instanceVariableNames: 'workBlock maxVal minVal aPoint >> progressTitle' >> + classVariableNames: 'PreferredProgressBarPosition' >> - classVariableNames: '' >> poolDictionaries: '' >> category: 'Exceptions-Kernel'! >> >> !ProgressInitiationException commentStamp: '<historical>' prior: 0! >> I provide a way to alter the behavior of the old-style progress notifier >> in String. See examples in: >> >> ProgressInitiationException testWithout. >> ProgressInitiationException testWith. >> ! >> >> Item was changed: >> ----- Method: ProgressInitiationException >> class>>display:at:from:to:during: (in category 'signalling') ----- >> + display: aString at: aPoint from: minVal to: maxVal during: workBlock >> - display: aString at: aPoint from: minVal to: maxVal during: workBlock >> - >> ^ self new >> + display: aString >> + at: (aPoint ifNil: [ self preferredProgressBarPoint ]) >> + from: minVal >> + to: maxVal >> + during: workBlock! >> - display: aString at: aPoint from: minVal to: maxVal >> during: workBlock! >> >> Item was added: >> + ----- Method: ProgressInitiationException class>>display:from:to:during: >> (in category 'signalling') ----- >> + display: aString from: minVal to: maxVal during: workBlock >> + ^ self >> + display: aString >> + at: nil >> + from: minVal >> + to: maxVal >> + during: workBlock! >> >> Item was added: >> + ----- Method: ProgressInitiationException >> class>>preferredProgressBarPoint (in category 'accessing') ----- >> + preferredProgressBarPoint >> + ^ self preferredProgressBarPosition = #cursorPoint >> + ifTrue: [ Sensor cursorPoint ] >> + ifFalse: [ UIManager default screen perform: self >> preferredProgressBarPosition ]! >> >> Item was added: >> + ----- Method: ProgressInitiationException >> class>>preferredProgressBarPosition (in category 'accessing') ----- >> + preferredProgressBarPosition >> + ^ PreferredProgressBarPosition ifNil: [ #center ]! >> >> Item was added: >> + ----- Method: ProgressInitiationException >> class>>preferredProgressBarPosition: (in category 'accessing') ----- >> + preferredProgressBarPosition: aSymbol >> + "Specify any of: #center, #topCenter, #bottomCenter, #leftCenter, >> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or >> #cursorPoint." >> + ^ PreferredProgressBarPosition! >> >> Item was changed: >> ----- Method: ProgressInitiationException class>>testInnermost (in >> category 'examples and tests') ----- >> testInnermost >> >> "test the progress code WITHOUT special handling" >> >> ^'Now here''s some Real Progress' >> + displayProgressFrom: 0 >> - displayProgressAt: Sensor cursorPoint >> - from: 0 >> to: 10 >> during: [ :bar | >> 1 to: 10 do: [ :x | >> bar value: x. (Delay forMilliseconds: 500) >> wait. >> x = 5 ifTrue: [1/0]. "just to make life >> interesting" >> ]. >> 'done' >> ]. >> >> ! >> >> > > > > > |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <[hidden email]> wrote: If, by "the progress bar" you mean SystemProgressMorph, I disagree, This sounds even worse. Are you implying that you're going to pepper the system with "ProgressInitiationException signal"s just in case there's a progress morph waiting to update? That's absurd, a) on performance grounds, an unhandled exception is an expensive thing (an entire stack walk to discover there's no handler), b) on neatness/complexity grounds, littering the system with dependencies, yuck. The Exceptions package is for the exceptions machinery and core exceptions, /not/ for every conceivable exception, notification or warning imaginable. I haven't been keeping up, so could you outline the usage model here and give some examples? I think there needs to be very careful thought on the interface between domain code and progress; a) where separation can't be obtained something analogous to MVC where changed messages are cheap if a Model has no dependents, b) where separation can be obtained (the traditional showProgessWhile: aBlock form) the progress additions are nicely encapsulated within the showProgressWhile: form.
best Eliot
|
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
> This sounds even worse. Are you implying that you're going to pepper the
> system with "ProgressInitiationException signal"s just in case there's a > progress morph waiting to update? ProgressInitiationException was put into Squeak (presumably, in the Exceptions package) back in 2000 - before I ever started using Squeak. The main entry point for its creation all these years has been through String>>#displayProgressAt:from:to:during: - which includes a comment with an example, and for which there are senders are all throughout the system. I am not going to pepper anything except my English breakfast. :) > That's absurd, a) on performance grounds, > an unhandled exception is an expensive thing (an entire stack walk to > discover there's no handler), There's only one signal which occurs only for the _initiation_, not every update. The exception is instantiated with a workBlock, which takes one argument which is the bar that the client-code can then update (via #value:). An unhandled exception may be expensive (still usually well under 1 second though, right?), but it's just one signal for something that the domain thinks is going to take long enough anyway to consider needing to initiate a progress bar.. - Chris On Wed, Jun 15, 2011 at 12:07 PM, Eliot Miranda <[hidden email]> wrote: > > > On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <[hidden email]> wrote: >> >> If, by "the progress bar" you mean SystemProgressMorph, I disagree, >> since that would create a dependency on Morphic. >> ProgressInitiationException allows domain-level code to signal that >> something worth indicating progress is occurring, and different UI >> frameworks can capture that notification (or not) and render it each >> in their own way. > > the system with dependencies, yuck. The Exceptions package is for the > exceptions machinery and core exceptions, /not/ for every conceivable > exception, notification or warning imaginable. I haven't been keeping up, > so could you outline the usage model here and give some examples? I think > there needs to be very careful thought on the interface between domain code > and progress; a) where separation can't be obtained something analogous to > MVC where changed messages are cheap if a Model has no dependents, b) where > separation can be obtained (the traditional showProgessWhile: aBlock form) > the progress additions are nicely encapsulated within the showProgressWhile: > form. > best > Eliot >> >> - Chris >> >> >> On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda <[hidden email]> >> wrote: >> > Hi Chris, >> > just because ProgressInitiationException is an exception doesn't >> > imply >> > it belongs in exceptions. Surely it belongs in the same package as the >> > progress bar. >> > best >> > Eliot >> > >> > On Wed, Jun 15, 2011 at 9:13 AM, <[hidden email]> wrote: >> >> >> >> Chris Muller uploaded a new version of Exceptions to project The Trunk: >> >> http://source.squeak.org/trunk/Exceptions-cmm.34.mcz >> >> >> >> ==================== Summary ==================== >> >> >> >> Name: Exceptions-cmm.34 >> >> Author: cmm >> >> Time: 15 June 2011, 11:13:51.392 am >> >> UUID: f0144460-f227-7b43-bee2-019786f35a4e >> >> Ancestors: Exceptions-nice.33 >> >> >> >> First step toward preferredProgressBarPosition preference. >> >> >> >> =============== Diff against Exceptions-nice.33 =============== >> >> >> >> Item was changed: >> >> Exception subclass: #ProgressInitiationException >> >> instanceVariableNames: 'workBlock maxVal minVal aPoint >> >> progressTitle' >> >> + classVariableNames: 'PreferredProgressBarPosition' >> >> - classVariableNames: '' >> >> poolDictionaries: '' >> >> category: 'Exceptions-Kernel'! >> >> >> >> !ProgressInitiationException commentStamp: '<historical>' prior: 0! >> >> I provide a way to alter the behavior of the old-style progress >> >> notifier >> >> in String. See examples in: >> >> >> >> ProgressInitiationException testWithout. >> >> ProgressInitiationException testWith. >> >> ! >> >> >> >> Item was changed: >> >> ----- Method: ProgressInitiationException >> >> class>>display:at:from:to:during: (in category 'signalling') ----- >> >> + display: aString at: aPoint from: minVal to: maxVal during: workBlock >> >> - display: aString at: aPoint from: minVal to: maxVal during: workBlock >> >> - >> >> ^ self new >> >> + display: aString >> >> + at: (aPoint ifNil: [ self preferredProgressBarPoint ]) >> >> + from: minVal >> >> + to: maxVal >> >> + during: workBlock! >> >> - display: aString at: aPoint from: minVal to: maxVal >> >> during: workBlock! >> >> >> >> Item was added: >> >> + ----- Method: ProgressInitiationException >> >> class>>display:from:to:during: >> >> (in category 'signalling') ----- >> >> + display: aString from: minVal to: maxVal during: workBlock >> >> + ^ self >> >> + display: aString >> >> + at: nil >> >> + from: minVal >> >> + to: maxVal >> >> + during: workBlock! >> >> >> >> Item was added: >> >> + ----- Method: ProgressInitiationException >> >> class>>preferredProgressBarPoint (in category 'accessing') ----- >> >> + preferredProgressBarPoint >> >> + ^ self preferredProgressBarPosition = #cursorPoint >> >> + ifTrue: [ Sensor cursorPoint ] >> >> + ifFalse: [ UIManager default screen perform: self >> >> preferredProgressBarPosition ]! >> >> >> >> Item was added: >> >> + ----- Method: ProgressInitiationException >> >> class>>preferredProgressBarPosition (in category 'accessing') ----- >> >> + preferredProgressBarPosition >> >> + ^ PreferredProgressBarPosition ifNil: [ #center ]! >> >> >> >> Item was added: >> >> + ----- Method: ProgressInitiationException >> >> class>>preferredProgressBarPosition: (in category 'accessing') ----- >> >> + preferredProgressBarPosition: aSymbol >> >> + "Specify any of: #center, #topCenter, #bottomCenter, >> >> #leftCenter, >> >> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or >> >> #cursorPoint." >> >> + ^ PreferredProgressBarPosition! >> >> >> >> Item was changed: >> >> ----- Method: ProgressInitiationException class>>testInnermost (in >> >> category 'examples and tests') ----- >> >> testInnermost >> >> >> >> "test the progress code WITHOUT special handling" >> >> >> >> ^'Now here''s some Real Progress' >> >> + displayProgressFrom: 0 >> >> - displayProgressAt: Sensor cursorPoint >> >> - from: 0 >> >> to: 10 >> >> during: [ :bar | >> >> 1 to: 10 do: [ :x | >> >> bar value: x. (Delay forMilliseconds: >> >> 500) >> >> wait. >> >> x = 5 ifTrue: [1/0]. "just to make >> >> life >> >> interesting" >> >> ]. >> >> 'done' >> >> ]. >> >> >> >> ! >> >> >> >> >> > >> > >> > >> > >> > >> > > > > > |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
In reply to this post by commits-2
On 15 June 2011 17:13, <[hidden email]> wrote:
> Chris Muller uploaded a new version of Exceptions to project The Trunk: > http://source.squeak.org/trunk/Exceptions-cmm.34.mcz > > ==================== Summary ==================== > > Name: Exceptions-cmm.34 > Author: cmm > Time: 15 June 2011, 11:13:51.392 am > UUID: f0144460-f227-7b43-bee2-019786f35a4e > Ancestors: Exceptions-nice.33 > > First step toward preferredProgressBarPosition preference. > > =============== Diff against Exceptions-nice.33 =============== > > Item was changed: > Exception subclass: #ProgressInitiationException > instanceVariableNames: 'workBlock maxVal minVal aPoint progressTitle' > + classVariableNames: 'PreferredProgressBarPosition' > - classVariableNames: '' > poolDictionaries: '' > category: 'Exceptions-Kernel'! Perhaps this should rather subclass Notification? (Which might be a separate commit, seeing as ProgressInitiationException's been around a good while as an Exception.) frank |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
In reply to this post by Chris Muller-3
On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <[hidden email]> wrote:
So if that remains the main entry-point (and I think it's poor; one on UIManager would be better) the exception belongs in Collections, along side String. Btu since progress is a UI function, there needs to be an entry-point there, and personally I think that either ToolBuilder or a generic UI package would be the place for both the entry-points such as #displayProgressAt:from:to:during:, and for the exception. Just because something's been the way its been for 1 years doesn't mean it's right ;)
If the signal is only raised in the context of a progress-epcific entry-point then that's fine. Form your initial response to my question it seemed that you were talking about something much less contained. An unhandled exception is likely to cost significantly less than opening a progress widget, so the cost is acceptable.
And I agree with Frank that the progress exception should inherit from Notification. cheers, Eliot
|
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On Wed, 15 Jun 2011, Eliot Miranda wrote:
> On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <[hidden email]> wrote: > >>> This sounds even worse. Are you implying that you're going to pepper the >>> system with "ProgressInitiationException signal"s just in case there's a >>> progress morph waiting to update? >> >> ProgressInitiationException was put into Squeak (presumably, in the >> Exceptions package) back in 2000 - before I ever started using Squeak. >> The main entry point for its creation all these years has been >> through String>>#displayProgressAt:from:to:during: - which includes a >> comment with an example, and for which there are senders are all >> throughout the system. I am not going to pepper anything except my >> English breakfast. :) >> > > So if that remains the main entry-point (and I think it's poor; one on > UIManager would be better) the exception belongs in Collections, along side > String. Btu since progress is a UI function, there needs to be an > entry-point there, and personally I think that either ToolBuilder or a > generic UI package would be the place for both the entry-points such > as #displayProgressAt:from:to:during:, and for the exception. Just because > something's been the way its been for 1 years doesn't mean it's right ;) Right, UIManager seems to be a good place. The only value I see in using an exception is that it can be caught, so code can avoid showing the progress, but that feature seems to be rarely used and it can be solved in another way with UIManager. > > > >>> That's absurd, a) on performance grounds, >>> an unhandled exception is an expensive thing (an entire stack walk to >>> discover there's no handler), >> >> There's only one signal which occurs only for the _initiation_, not >> every update. The exception is instantiated with a workBlock, which >> takes one argument which is the bar that the client-code can then >> update (via #value:). An unhandled exception may be expensive (still >> usually well under 1 second though, right?), but it's just one signal >> for something that the domain thinks is going to take long enough >> anyway to consider needing to initiate a progress bar.. >> > > If the signal is only raised in the context of a progress-epcific > entry-point then that's fine. Form your initial response to my question it > seemed that you were talking about something much less contained. An > unhandled exception is likely to cost significantly less than opening a > progress widget, so the cost is acceptable. > > > And I agree with Frank that the progress exception should inherit from > Notification. The word Notification (along with Warning and Error) sounds like a system event. It's nothing more than an Exception with the #defaultAction implemented as ^nil. I wonder what it's original purpose was besides marking Exceptions which implement #defaultAction. Levente > > cheers, > Eliot > >> >> - Chris >> >> >> On Wed, Jun 15, 2011 at 12:07 PM, Eliot Miranda <[hidden email]> >> wrote: >>> >>> >>> On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <[hidden email]> >> wrote: >>>> >>>> If, by "the progress bar" you mean SystemProgressMorph, I disagree, >>>> since that would create a dependency on Morphic. >>>> ProgressInitiationException allows domain-level code to signal that >>>> something worth indicating progress is occurring, and different UI >>>> frameworks can capture that notification (or not) and render it each >>>> in their own way. >>> >> b) on neatness/complexity grounds, littering >>> the system with dependencies, yuck. The Exceptions package is for the >>> exceptions machinery and core exceptions, /not/ for every conceivable >>> exception, notification or warning imaginable. I haven't been keeping >> up, >>> so could you outline the usage model here and give some examples? I >> think >>> there needs to be very careful thought on the interface between domain >> code >>> and progress; a) where separation can't be obtained something analogous >> to >>> MVC where changed messages are cheap if a Model has no dependents, b) >> where >>> separation can be obtained (the traditional showProgessWhile: aBlock >> form) >>> the progress additions are nicely encapsulated within the >> showProgressWhile: >>> form. >>> best >>> Eliot >>>> >>>> - Chris >>>> >>>> >>>> On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda < >> [hidden email]> >>>> wrote: >>>>> Hi Chris, >>>>> just because ProgressInitiationException is an exception doesn't >>>>> imply >>>>> it belongs in exceptions. Surely it belongs in the same package as >> the >>>>> progress bar. >>>>> best >>>>> Eliot >>>>> >>>>> On Wed, Jun 15, 2011 at 9:13 AM, <[hidden email]> wrote: >>>>>> >>>>>> Chris Muller uploaded a new version of Exceptions to project The >> Trunk: >>>>>> http://source.squeak.org/trunk/Exceptions-cmm.34.mcz >>>>>> >>>>>> ==================== Summary ==================== >>>>>> >>>>>> Name: Exceptions-cmm.34 >>>>>> Author: cmm >>>>>> Time: 15 June 2011, 11:13:51.392 am >>>>>> UUID: f0144460-f227-7b43-bee2-019786f35a4e >>>>>> Ancestors: Exceptions-nice.33 >>>>>> >>>>>> First step toward preferredProgressBarPosition preference. >>>>>> >>>>>> =============== Diff against Exceptions-nice.33 =============== >>>>>> >>>>>> Item was changed: >>>>>> Exception subclass: #ProgressInitiationException >>>>>> instanceVariableNames: 'workBlock maxVal minVal aPoint >>>>>> progressTitle' >>>>>> + classVariableNames: 'PreferredProgressBarPosition' >>>>>> - classVariableNames: '' >>>>>> poolDictionaries: '' >>>>>> category: 'Exceptions-Kernel'! >>>>>> >>>>>> !ProgressInitiationException commentStamp: '<historical>' prior: 0! >>>>>> I provide a way to alter the behavior of the old-style progress >>>>>> notifier >>>>>> in String. See examples in: >>>>>> >>>>>> ProgressInitiationException testWithout. >>>>>> ProgressInitiationException testWith. >>>>>> ! >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: ProgressInitiationException >>>>>> class>>display:at:from:to:during: (in category 'signalling') ----- >>>>>> + display: aString at: aPoint from: minVal to: maxVal during: >> workBlock >>>>>> - display: aString at: aPoint from: minVal to: maxVal during: >> workBlock >>>>>> - >>>>>> ^ self new >>>>>> + display: aString >>>>>> + at: (aPoint ifNil: [ self preferredProgressBarPoint >> ]) >>>>>> + from: minVal >>>>>> + to: maxVal >>>>>> + during: workBlock! >>>>>> - display: aString at: aPoint from: minVal to: maxVal >>>>>> during: workBlock! >>>>>> >>>>>> Item was added: >>>>>> + ----- Method: ProgressInitiationException >>>>>> class>>display:from:to:during: >>>>>> (in category 'signalling') ----- >>>>>> + display: aString from: minVal to: maxVal during: workBlock >>>>>> + ^ self >>>>>> + display: aString >>>>>> + at: nil >>>>>> + from: minVal >>>>>> + to: maxVal >>>>>> + during: workBlock! >>>>>> >>>>>> Item was added: >>>>>> + ----- Method: ProgressInitiationException >>>>>> class>>preferredProgressBarPoint (in category 'accessing') ----- >>>>>> + preferredProgressBarPoint >>>>>> + ^ self preferredProgressBarPosition = #cursorPoint >>>>>> + ifTrue: [ Sensor cursorPoint ] >>>>>> + ifFalse: [ UIManager default screen perform: self >>>>>> preferredProgressBarPosition ]! >>>>>> >>>>>> Item was added: >>>>>> + ----- Method: ProgressInitiationException >>>>>> class>>preferredProgressBarPosition (in category 'accessing') ----- >>>>>> + preferredProgressBarPosition >>>>>> + ^ PreferredProgressBarPosition ifNil: [ #center ]! >>>>>> >>>>>> Item was added: >>>>>> + ----- Method: ProgressInitiationException >>>>>> class>>preferredProgressBarPosition: (in category 'accessing') ----- >>>>>> + preferredProgressBarPosition: aSymbol >>>>>> + "Specify any of: #center, #topCenter, #bottomCenter, >>>>>> #leftCenter, >>>>>> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or >>>>>> #cursorPoint." >>>>>> + ^ PreferredProgressBarPosition! >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: ProgressInitiationException class>>testInnermost (in >>>>>> category 'examples and tests') ----- >>>>>> testInnermost >>>>>> >>>>>> "test the progress code WITHOUT special handling" >>>>>> >>>>>> ^'Now here''s some Real Progress' >>>>>> + displayProgressFrom: 0 >>>>>> - displayProgressAt: Sensor cursorPoint >>>>>> - from: 0 >>>>>> to: 10 >>>>>> during: [ :bar | >>>>>> 1 to: 10 do: [ :x | >>>>>> bar value: x. (Delay forMilliseconds: >>>>>> 500) >>>>>> wait. >>>>>> x = 5 ifTrue: [1/0]. "just to make >>>>>> life >>>>>> interesting" >>>>>> ]. >>>>>> 'done' >>>>>> ]. >>>>>> >>>>>> ! >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >> >> > |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On Wed, Jun 15, 2011 at 1:30 PM, Levente Uzonyi <[hidden email]> wrote:
The distinction is between an exception which if uncaught stops execution (an exception) and one which if uncaught has no effect (a notification). So ProgressInitiationException is definitely a Notification (IMO :) ).
best, Eliot
|
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
It's all done folks. Bert, we no longer access the #screen. Eliot,
the methods and Exception have been moved to ToolBuilder-Kernel. Frank, it now inherits from Notification. Thanks all for your feedback. On Wed, Jun 15, 2011 at 3:34 PM, Eliot Miranda <[hidden email]> wrote: > > > On Wed, Jun 15, 2011 at 1:30 PM, Levente Uzonyi <[hidden email]> wrote: >> >> On Wed, 15 Jun 2011, Eliot Miranda wrote: >> >>> On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <[hidden email]> >>> wrote: >>> >>>>> This sounds even worse. Are you implying that you're going to pepper >>>>> the >>>>> system with "ProgressInitiationException signal"s just in case there's >>>>> a >>>>> progress morph waiting to update? >>>> >>>> ProgressInitiationException was put into Squeak (presumably, in the >>>> Exceptions package) back in 2000 - before I ever started using Squeak. >>>> The main entry point for its creation all these years has been >>>> through String>>#displayProgressAt:from:to:during: - which includes a >>>> comment with an example, and for which there are senders are all >>>> throughout the system. I am not going to pepper anything except my >>>> English breakfast. :) >>>> >>> >>> So if that remains the main entry-point (and I think it's poor; one on >>> UIManager would be better) the exception belongs in Collections, along >>> side >>> String. Btu since progress is a UI function, there needs to be an >>> entry-point there, and personally I think that either ToolBuilder or a >>> generic UI package would be the place for both the entry-points such >>> as #displayProgressAt:from:to:during:, and for the exception. Just >>> because >>> something's been the way its been for 1 years doesn't mean it's right ;) >> >> Right, UIManager seems to be a good place. The only value I see in using >> an exception is that it can be caught, so code can avoid showing the >> progress, but that feature seems to be rarely used and it can be solved in >> another way with UIManager. >> >>> >>> >>> >>>>> That's absurd, a) on performance grounds, >>>>> an unhandled exception is an expensive thing (an entire stack walk to >>>>> discover there's no handler), >>>> >>>> There's only one signal which occurs only for the _initiation_, not >>>> every update. The exception is instantiated with a workBlock, which >>>> takes one argument which is the bar that the client-code can then >>>> update (via #value:). An unhandled exception may be expensive (still >>>> usually well under 1 second though, right?), but it's just one signal >>>> for something that the domain thinks is going to take long enough >>>> anyway to consider needing to initiate a progress bar.. >>>> >>> >>> If the signal is only raised in the context of a progress-epcific >>> entry-point then that's fine. Form your initial response to my question >>> it >>> seemed that you were talking about something much less contained. An >>> unhandled exception is likely to cost significantly less than opening a >>> progress widget, so the cost is acceptable. >>> >>> >>> And I agree with Frank that the progress exception should inherit from >>> Notification. >> >> The word Notification (along with Warning and Error) sounds like a system >> event. It's nothing more than an Exception with the #defaultAction >> implemented as ^nil. I wonder what it's original purpose was besides marking >> Exceptions which implement #defaultAction. > > The distinction is between an exception which if uncaught stops execution > (an exception) and one which if uncaught has no effect (a notification). So > ProgressInitiationException is definitely a Notification (IMO :) ). > best, > Eliot >> >> >> Levente >> >>> >>> cheers, >>> Eliot >>> >>>> >>>> - Chris >>>> >>>> >>>> On Wed, Jun 15, 2011 at 12:07 PM, Eliot Miranda >>>> <[hidden email]> >>>> wrote: >>>>> >>>>> >>>>> On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <[hidden email]> >>>> >>>> wrote: >>>>>> >>>>>> If, by "the progress bar" you mean SystemProgressMorph, I disagree, >>>>>> since that would create a dependency on Morphic. >>>>>> ProgressInitiationException allows domain-level code to signal that >>>>>> something worth indicating progress is occurring, and different UI >>>>>> frameworks can capture that notification (or not) and render it each >>>>>> in their own way. >>>>> >>>> b) on neatness/complexity grounds, littering >>>>> >>>>> the system with dependencies, yuck. The Exceptions package is for the >>>>> exceptions machinery and core exceptions, /not/ for every conceivable >>>>> exception, notification or warning imaginable. I haven't been keeping >>>> >>>> up, >>>>> >>>>> so could you outline the usage model here and give some examples? I >>>> >>>> think >>>>> >>>>> there needs to be very careful thought on the interface between domain >>>> >>>> code >>>>> >>>>> and progress; a) where separation can't be obtained something analogous >>>> >>>> to >>>>> >>>>> MVC where changed messages are cheap if a Model has no dependents, b) >>>> >>>> where >>>>> >>>>> separation can be obtained (the traditional showProgessWhile: aBlock >>>> >>>> form) >>>>> >>>>> the progress additions are nicely encapsulated within the >>>> >>>> showProgressWhile: >>>>> >>>>> form. >>>>> best >>>>> Eliot >>>>>> >>>>>> - Chris >>>>>> >>>>>> >>>>>> On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda < >>>> >>>> [hidden email]> >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> just because ProgressInitiationException is an exception doesn't >>>>>>> imply >>>>>>> it belongs in exceptions. Surely it belongs in the same package as >>>> >>>> the >>>>>>> >>>>>>> progress bar. >>>>>>> best >>>>>>> Eliot >>>>>>> >>>>>>> On Wed, Jun 15, 2011 at 9:13 AM, <[hidden email]> wrote: >>>>>>>> >>>>>>>> Chris Muller uploaded a new version of Exceptions to project The >>>> >>>> Trunk: >>>>>>>> >>>>>>>> http://source.squeak.org/trunk/Exceptions-cmm.34.mcz >>>>>>>> >>>>>>>> ==================== Summary ==================== >>>>>>>> >>>>>>>> Name: Exceptions-cmm.34 >>>>>>>> Author: cmm >>>>>>>> Time: 15 June 2011, 11:13:51.392 am >>>>>>>> UUID: f0144460-f227-7b43-bee2-019786f35a4e >>>>>>>> Ancestors: Exceptions-nice.33 >>>>>>>> >>>>>>>> First step toward preferredProgressBarPosition preference. >>>>>>>> >>>>>>>> =============== Diff against Exceptions-nice.33 =============== >>>>>>>> >>>>>>>> Item was changed: >>>>>>>> Exception subclass: #ProgressInitiationException >>>>>>>> instanceVariableNames: 'workBlock maxVal minVal aPoint >>>>>>>> progressTitle' >>>>>>>> + classVariableNames: 'PreferredProgressBarPosition' >>>>>>>> - classVariableNames: '' >>>>>>>> poolDictionaries: '' >>>>>>>> category: 'Exceptions-Kernel'! >>>>>>>> >>>>>>>> !ProgressInitiationException commentStamp: '<historical>' prior: 0! >>>>>>>> I provide a way to alter the behavior of the old-style progress >>>>>>>> notifier >>>>>>>> in String. See examples in: >>>>>>>> >>>>>>>> ProgressInitiationException testWithout. >>>>>>>> ProgressInitiationException testWith. >>>>>>>> ! >>>>>>>> >>>>>>>> Item was changed: >>>>>>>> ----- Method: ProgressInitiationException >>>>>>>> class>>display:at:from:to:during: (in category 'signalling') ----- >>>>>>>> + display: aString at: aPoint from: minVal to: maxVal during: >>>> >>>> workBlock >>>>>>>> >>>>>>>> - display: aString at: aPoint from: minVal to: maxVal during: >>>> >>>> workBlock >>>>>>>> >>>>>>>> - >>>>>>>> ^ self new >>>>>>>> + display: aString >>>>>>>> + at: (aPoint ifNil: [ self preferredProgressBarPoint >>>> >>>> ]) >>>>>>>> >>>>>>>> + from: minVal >>>>>>>> + to: maxVal >>>>>>>> + during: workBlock! >>>>>>>> - display: aString at: aPoint from: minVal to: maxVal >>>>>>>> during: workBlock! >>>>>>>> >>>>>>>> Item was added: >>>>>>>> + ----- Method: ProgressInitiationException >>>>>>>> class>>display:from:to:during: >>>>>>>> (in category 'signalling') ----- >>>>>>>> + display: aString from: minVal to: maxVal during: workBlock >>>>>>>> + ^ self >>>>>>>> + display: aString >>>>>>>> + at: nil >>>>>>>> + from: minVal >>>>>>>> + to: maxVal >>>>>>>> + during: workBlock! >>>>>>>> >>>>>>>> Item was added: >>>>>>>> + ----- Method: ProgressInitiationException >>>>>>>> class>>preferredProgressBarPoint (in category 'accessing') ----- >>>>>>>> + preferredProgressBarPoint >>>>>>>> + ^ self preferredProgressBarPosition = #cursorPoint >>>>>>>> + ifTrue: [ Sensor cursorPoint ] >>>>>>>> + ifFalse: [ UIManager default screen perform: self >>>>>>>> preferredProgressBarPosition ]! >>>>>>>> >>>>>>>> Item was added: >>>>>>>> + ----- Method: ProgressInitiationException >>>>>>>> class>>preferredProgressBarPosition (in category 'accessing') ----- >>>>>>>> + preferredProgressBarPosition >>>>>>>> + ^ PreferredProgressBarPosition ifNil: [ #center ]! >>>>>>>> >>>>>>>> Item was added: >>>>>>>> + ----- Method: ProgressInitiationException >>>>>>>> class>>preferredProgressBarPosition: (in category 'accessing') ----- >>>>>>>> + preferredProgressBarPosition: aSymbol >>>>>>>> + "Specify any of: #center, #topCenter, #bottomCenter, >>>>>>>> #leftCenter, >>>>>>>> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or >>>>>>>> #cursorPoint." >>>>>>>> + ^ PreferredProgressBarPosition! >>>>>>>> >>>>>>>> Item was changed: >>>>>>>> ----- Method: ProgressInitiationException class>>testInnermost (in >>>>>>>> category 'examples and tests') ----- >>>>>>>> testInnermost >>>>>>>> >>>>>>>> "test the progress code WITHOUT special handling" >>>>>>>> >>>>>>>> ^'Now here''s some Real Progress' >>>>>>>> + displayProgressFrom: 0 >>>>>>>> - displayProgressAt: Sensor cursorPoint >>>>>>>> - from: 0 >>>>>>>> to: 10 >>>>>>>> during: [ :bar | >>>>>>>> 1 to: 10 do: [ :x | >>>>>>>> bar value: x. (Delay forMilliseconds: >>>>>>>> 500) >>>>>>>> wait. >>>>>>>> x = 5 ifTrue: [1/0]. "just to make >>>>>>>> life >>>>>>>> interesting" >>>>>>>> ]. >>>>>>>> 'done' >>>>>>>> ]. >>>>>>>> >>>>>>>> ! >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> > > > > > |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On Wed, Jun 15, 2011 at 1:51 PM, Chris Muller <[hidden email]> wrote: It's all done folks. Bert, we no longer access the #screen. Eliot, It was heart0warming to see the commit messages go by. Thanks for your efforts. IMO you've done the right thing (tm) and we're all better off. Thank you again!
best, Eliot
|
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
In reply to this post by Chris Muller-3
On 15.06.2011, at 13:51, Chris Muller wrote:
> Eliot, the methods and Exception have been moved to ToolBuilder-Kernel. That means it's now essentially impossible to unload ToolBuilder. One nice thing about progress display being implemented in String+Exception was that it was completely decoupled from any UI framework. - Bert - |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On Wed, Jun 15, 2011 at 1:58 PM, Bert Freudenberg <[hidden email]> wrote:
Surely if the String entry-point is moved into ToolBuilder then things are OK, right? Anything that wants to display progress is going to have a dependency on the UI and hence ToolBuilder. The remaining bug IMO is that String>>displayProgress... is not in the UI (a progress package or in ToolBuilder at a pinch).
best, Eliot
|
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
On 15.06.2011, at 14:05, Eliot Miranda wrote:
That's not the case traditionally. There are many senders of displayProgressAt:from:to:during: in low-level methods of the system, which often happens to be a natural place to put it. Which is okay as long as they work even without a UI being present. - Bert - |
Re: The Trunk: Exceptions-cmm.34.mcz
|
|
>> That means it's now essentially impossible to unload ToolBuilder. One nice
>> thing about progress display being implemented in String+Exception was that >> it was completely decoupled from any UI framework. > > Surely if the String entry-point is moved into ToolBuilder then things are > OK, right? Anything that wants to display progress is going to have a > dependency on the UI and hence ToolBuilder. > > That's not the case traditionally. There are many senders > of displayProgressAt:from:to:during: in low-level methods of the system, > which often happens to be a natural place to put it. Which is okay as long > as they work even without a UI being present. Hmm.. I think Bert has a good point. ToolBuilder is about this particular _windowing framework_ we use for browsers - not "UI" in general (which was the basis for moving it there). And yet, there are lots of things that may want to indicate Progress that do not use ToolBuilder. Just see senders of String>>#displayProgressAt:from:to:during: - we have, for example, PositionableStream>>#fileInAnnouncing:, among others. Sigh. Someone else please chime in. This is probably still pretty easy to move back to Exceptions or Collections. - Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |