> 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 <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'
>> >>                ].
>> >>
>> >>  !
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
>
>