On Wed, Jun 15, 2011 at 1:51 PM, Chris Muller <asqueaker at gmail.com> wrote:

> 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.
>

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


> Thanks all for your feedback.
>
> On Wed, Jun 15, 2011 at 3:34 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> >
> > 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/96b06183/attachment.htm