[squeak-dev] The Trunk: Exceptions-cmm.34.mcz

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 15 19:19:48 UTC 2011


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 ;)



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

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/d45cb1a6/attachment.htm


More information about the Squeak-dev mailing list