On Wed, Jun 15, 2011 at 1:30 PM, Levente Uzonyi <leves at elte.hu> wrote:

> On Wed, 15 Jun 2011, Eliot Miranda wrote:
>
>  On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <asqueaker at gmail.com>
>> 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 <eliot.miranda at gmail.com
>>> >
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <asqueaker at gmail.com>
>>>>
>>> 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 <
>>>>>
>>>> eliot.miranda at gmail.com>
>>>
>>>> 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, <commits at source.squeak.org> 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'
>>>>>>>               ].
>>>>>>>
>>>>>>>  !
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110615/41dfc55f/attachment.htm