Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84
Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way?
The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification.
cheers, Mike
I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling. Could not SystemProgressMorph be modified to handle this? Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?) The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY? Regards, Ralph Boland
On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland@gmail.com> wrote:
I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. ?I need this information so I can make some planned changes to the ProgressDisplay package I released a while back.
-----------------------------------------------------------------------------------------------------------------
A SystemProgressMorph is used to display progress while some computation is being done. ?Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. ?In particular, String>>displayProgressAt:from:to:during: does:
ProgressInitiationException
display: self
at: aPoint from: minVal to: maxVal during: workBlock.
This method sets a few variables and then does:
^self signal
This signal is caught where upon a SystemProgressMorph is started or extended with an additional progress bar.
But I don't understand why sending a signal to a ProgressInitiationException is needed to get the ball rolling,
Can someone please explain why things are done the way they are?
Regards,
Ralph Boland
Hi Ralph, On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland@gmail.com> wrote:
Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way?
The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification.
cheers, Mike
I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling.
Could not SystemProgressMorph be modified to handle this?
Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?)
The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY?
I tried to answer your question the first time round but as I looked at the code I found that I didn't understand it, and so gave up on my explanation :). It seemed to me that the reason for using a signal was to handle nesting. One raises the progress initiation signal in the wrapper to the action block to get progress to display in the right progress bar. If the signal is uncaught then its defaultAction would open up a new progress bar with one progress strip and initiate processing of the progress block, providing a handler for the progress initiation signal. If the signal is caught (by the handler provided at the first level) then the existing progress bar is extended with a new progress strip for the nested progress. At least that's how I thought it worked but I couldn't work out how the handler worked. If I were writing it I would still use the signal to find if the progress was nested but I /would not/ put the code in the defaultAction. Instead the signal would answer if it was nested and all the code would be at the point where the signal is raised. For this one can use a simple Notification, using its tag to disambiguate it e.g. [Notification new tag: #progressBar; signal] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: true]. ex pass] true So e.g. outerBarOrNil := Notification new tag: #progressBar; signal. ... if nested add to the existing bar otherwise create a new bar ... [actionBlock value: bar] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: bar]. ex pass] my 2¢ If you can make the tests pass with simpler code then go for it! best Eliot
Regards,
Ralph Boland
On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland@gmail.com> wrote:
I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. ?I need this information so I can make some planned changes to the ProgressDisplay package I released a while back.
A SystemProgressMorph is used to display progress while some
computation
is being done. ?Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. ?In particular, String>>displayProgressAt:from:to:during: does:
ProgressInitiationException
display: self
at: aPoint from: minVal to: maxVal during: workBlock.
This method sets a few variables and then does:
^self signal
This signal is caught where upon a SystemProgressMorph is started or extended with an additional progress bar.
But I don't understand why sending a signal to a
ProgressInitiationException
is needed to get the ball rolling,
Can someone please explain why things are done the way they are?
Regards,
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
When I looked through the code I imagined one could implement the nesting by just maintaining a stack on the progress initiator sort of like ... On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Ralph,
On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland@gmail.com> wrote:
Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way?
The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification.
cheers, Mike
I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling.
Could not SystemProgressMorph be modified to handle this?
Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?)
The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY?
I tried to answer your question the first time round but as I looked at the code I found that I didn't understand it, and so gave up on my explanation :). It seemed to me that the reason for using a signal was to handle nesting. One raises the progress initiation signal in the wrapper to the action block to get progress to display in the right progress bar. If the signal is uncaught then its defaultAction would open up a new progress bar with one progress strip and initiate processing of the progress block, providing a handler for the progress initiation signal. If the signal is caught (by the handler provided at the first level) then the existing progress bar is extended with a new progress strip for the nested progress. At least that's how I thought it worked but I couldn't work out how the handler worked.
If I were writing it I would still use the signal to find if the progress was nested but I /would not/ put the code in the defaultAction. Instead the signal would answer if it was nested and all the code would be at the point where the signal is raised. For this one can use a simple Notification, using its tag to disambiguate it e.g.
[Notification new tag: #progressBar; signal] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: true]. ex pass] true
So e.g.
outerBarOrNil := Notification new tag: #progressBar; signal. ... if nested add to the existing bar otherwise create a new bar ... [actionBlock value: bar] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: bar]. ex pass]
my 2¢
If you can make the tests pass with simpler code then go for it!
best Eliot
Regards,
Ralph Boland
On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland@gmail.com> wrote:
I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. ?I need this information so I can make some planned changes to the ProgressDisplay package I released a while back.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --------------------------------------------------------------------
A SystemProgressMorph is used to display progress while some
computation
is being done. ?Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. ?In particular, String>>displayProgressAt:from:to:during: does:
ProgressInitiationException
display: self
at: aPoint from: minVal to: maxVal during: workBlock.
This method sets a few variables and then does:
^self signal
This signal is caught where upon a SystemProgressMorph is
started or
extended with an additional progress bar.
But I don't understand why sending a signal to a ProgressInitiationException is needed to get the ball rolling,
Can someone please explain why things are done the way they are?
Regards,
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sort of like Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | at different levels in the stack rather than letting the exception find the notifier each time you would do it explicitly. Perhaps there is a reason why that wouldn't work. Cheers mike On 13 Sep 2010, at 00:26, Michael Roberts <mike@mjr104.co.uk> wrote:
When I looked through the code I imagined one could implement the nesting by just maintaining a stack on the progress initiator sort of like
...
On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Ralph,
On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland@gmail.com> wrote:
Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way?
The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification.
cheers, Mike
I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling.
Could not SystemProgressMorph be modified to handle this?
Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?)
The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY?
I tried to answer your question the first time round but as I looked at the code I found that I didn't understand it, and so gave up on my explanation :). It seemed to me that the reason for using a signal was to handle nesting. One raises the progress initiation signal in the wrapper to the action block to get progress to display in the right progress bar. If the signal is uncaught then its defaultAction would open up a new progress bar with one progress strip and initiate processing of the progress block, providing a handler for the progress initiation signal. If the signal is caught (by the handler provided at the first level) then the existing progress bar is extended with a new progress strip for the nested progress. At least that's how I thought it worked but I couldn't work out how the handler worked.
If I were writing it I would still use the signal to find if the progress was nested but I /would not/ put the code in the defaultAction. Instead the signal would answer if it was nested and all the code would be at the point where the signal is raised. For this one can use a simple Notification, using its tag to disambiguate it e.g.
[Notification new tag: #progressBar; signal] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: true]. ex pass] true
So e.g.
outerBarOrNil := Notification new tag: #progressBar; signal. ... if nested add to the existing bar otherwise create a new bar ... [actionBlock value: bar] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: bar]. ex pass]
my 2¢
If you can make the tests pass with simpler code then go for it!
best Eliot
Regards,
Ralph Boland
On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland@gmail.com> wrote:
I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. ?I need this information so I can make some planned changes to the ProgressDisplay package I released a while back.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --------------------------------------------------------------------
A SystemProgressMorph is used to display progress while some
computation
is being done. ?Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. ?In particular, String>>displayProgressAt:from:to:during: does:
ProgressInitiationException
display: self
at: aPoint from: minVal to: maxVal during: workBlock.
This method sets a few variables and then does:
^self signal
This signal is caught where upon a SystemProgressMorph is
started or
extended with an additional progress bar.
But I don't understand why sending a signal to a ProgressInitiationException is needed to get the ball rolling,
Can someone please explain why things are done the way they are?
Regards,
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/12 Michael Roberts <mike@mjr104.co.uk>
Sort of like
Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar |
at different levels in the stack rather than letting the exception find the notifier each time you would do it explicitly. Perhaps there is a reason why that wouldn't work.
Simply because the progress indications occur in unrelated methods, not in a single method, so they can't be written this way. The issue is, when wanting to show a progress bar for some activity, whether there already exists an open progress bar in some outer activation. Essentially a signal is the most convenient way to do this if one wants to search the stack (a signal is an abstraction over stack searching). The other approach is to use a per-process variable (thread-local variable). Squeak uses the former style. But there's no reason why one can't cache the lookup of the first signal. I don't see any need for sending the signal on each increment of the progress indicator or each activation of the action block. cheers Eliot
Cheers mike
On 13 Sep 2010, at 00:26, Michael Roberts <mike@mjr104.co.uk> wrote:
When I looked through the code I imagined one could implement the nesting by just maintaining a stack on the progress initiator sort of like
...
On 11 Sep 2010, at 16:45, Eliot Miranda < <eliot.miranda@gmail.com> eliot.miranda@gmail.com> wrote:
Hi Ralph,
On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland < <rpboland@gmail.com><rpboland@gmail.com> rpboland@gmail.com> wrote:
Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way?
The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification.
cheers, Mike
I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling.
Could not SystemProgressMorph be modified to handle this?
Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?)
The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY?
I tried to answer your question the first time round but as I looked at the code I found that I didn't understand it, and so gave up on my explanation :). It seemed to me that the reason for using a signal was to handle nesting. One raises the progress initiation signal in the wrapper to the action block to get progress to display in the right progress bar. If the signal is uncaught then its defaultAction would open up a new progress bar with one progress strip and initiate processing of the progress block, providing a handler for the progress initiation signal. If the signal is caught (by the handler provided at the first level) then the existing progress bar is extended with a new progress strip for the nested progress. At least that's how I thought it worked but I couldn't work out how the handler worked.
If I were writing it I would still use the signal to find if the progress was nested but I /would not/ put the code in the defaultAction. Instead the signal would answer if it was nested and all the code would be at the point where the signal is raised. For this one can use a simple Notification, using its tag to disambiguate it e.g.
[Notification new tag: #progressBar; signal] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: true]. ex pass] true
So e.g.
outerBarOrNil := Notification new tag: #progressBar; signal. ... if nested add to the existing bar otherwise create a new bar ... [actionBlock value: bar] on: Notification do: [:ex| ex tag == #progressBar ifTrue: [ex resume: bar]. ex pass]
my 2¢
If you can make the tests pass with simpler code then go for it!
best Eliot
Regards,
Ralph Boland
On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland < <rpboland@gmail.com><rpboland@gmail.com> rpboland@gmail.com> wrote:
I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. ?I need this information so I can make some planned changes to the ProgressDisplay package I released a while back.
A SystemProgressMorph is used to display progress while some
computation
is being done. ?Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. ?In particular, String>>displayProgressAt:from:to:during: does:
ProgressInitiationException
display: self
at: aPoint from: minVal to: maxVal during: workBlock.
This method sets a few variables and then does:
^self signal
This signal is caught where upon a SystemProgressMorph is started or extended with an additional progress bar.
But I don't understand why sending a signal to a
ProgressInitiationException
is needed to get the ball rolling,
Can someone please explain why things are done the way they are?
Regards,
Ralph Boland
_______________________________________________ Pharo-project mailing list <Pharo-project@lists.gforge.inria.fr><Pharo-project@lists.gforge.inria.fr> Pharo-project@lists.gforge.inria.fr <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project><http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list <Pharo-project@lists.gforge.inria.fr>Pharo-project@lists.gforge.inria.fr <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Eliot Miranda -
Michael Roberts -
Ralph Boland