Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser
Hello Matteo, are you using the ProtocolBrowser class that comes default with Pharo 5? (In the Spec-Examples package). This is different from what is in the booklet, the code in Pharo 5 is not up to date. For now, you should define a new protocol browser class (MyProtocolBrowser for example) and the other classes that are in that section. Sorry for that... -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 7, 2016, at 18:57, Matteo via Pharo-users <pharo-users@lists.pharo.org> wrote:
From: Matteo <matteob8@yahoo.it> Subject: SpecBooklet: Strange behavior of ProtocolBrowser Date: September 7, 2016 at 18:56:08 GMT-3 To: pharo-users@lists.pharo.org
Hi, I'm playing with the ProtocolBrowser class, as coded in the "SpecBooklet.pdf" document (release of the 3rd August 2016). I'm using Pharo 5.
I'm experiencing a strange behavior of the ProtocolBrowser instance: -if I open a ProtocolBrowser instance, and I click on a "api" item, I do not get any code in the text pane. -If I open another ProtocolBrowser instance then I do not see any code, even in the "api" protocol than the "api-events" one. -If I open a further instance then the widget works correctly, showing the "api" or "api-events" code in the text pane.
Please note that the ProtocolBrowser is instantiated as follow: (ProtocolBrowser new) openWithSpec
Could my Pharo image be faulty? Is there some problem with ProtocolBrowser>>initializePresenter?
Thanks, Matteo Bellotto
Hello Johan, I've coded all the examples manually, changing the names to avoid any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). But the result is the same. Things improve if all the "ifNil: [ text text: '' ]" get removed from the ProtcolFlipper>>initializePresenter method. Obviously the text pane is no more "cleaned" when deselecting an "api" or "api-event" row. I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively on the "api" and "event" instances, in the ProtocolBrowser >> initializePresenter method. In this way I found that "ifNil:" message is sent improperly, i.e. when a "api-event" row is selected then the message "ifNil:" of the "api" instance is triggered, and vice-versa. In some way this is correct: when a "api-event" row is selected then none of the "api" rows are selected... However I'm puzzled by the fact that the behavior seems random: creating 3 instances I can get 3 different behaviors. have you never experienced this? Maybe I'll check again my code... thanks, Matteo On 08/09/16 00:09, Johan Fabry wrote:
Hello Matteo,
are you using the ProtocolBrowser class that comes default with Pharo 5? (In the Spec-Examples package). This is different from what is in the booklet, the code in Pharo 5 is not up to date. For now, you should define a new protocol browser class (MyProtocolBrowser for example) and the other classes that are in that section. Sorry for that...
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 7, 2016, at 18:57, Matteo via Pharo-users <pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote:
*From: *Matteo <matteob8@yahoo.it <mailto:matteob8@yahoo.it>> *Subject: **SpecBooklet: Strange behavior of ProtocolBrowser* *Date: *September 7, 2016 at 18:56:08 GMT-3 *To: *pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org>
Hi, I'm playing with the ProtocolBrowser class, as coded in the "SpecBooklet.pdf" document (release of the 3rd August 2016). I'm using Pharo 5.
I'm experiencing a strange behavior of the ProtocolBrowser instance: -if I open a ProtocolBrowser instance, and I click on a "api" item, I do not get any code in the text pane. -If I open another ProtocolBrowser instance then I do not see any code, even in the "api" protocol than the "api-events" one. -If I open a further instance then the widget works correctly, showing the "api" or "api-events" code in the text pane.
Please note that the ProtocolBrowser is instantiated as follow: (ProtocolBrowser new) openWithSpec
Could my Pharo image be faulty? Is there some problem with ProtocolBrowser>>initializePresenter?
Thanks, Matteo Bellotto
Excellent, you found a bug in my code! What happens is that when one item is selected in a list, in the other list the currently selected item is de-selected. This causes *both* blocks (whenAPIChanged: and whenEventChanged:) to be executed, and depending on what order they are executed the behavior is different. (A classical concurrent programming problem.) This order apparently changes depending on how many windows you have open, et cetera, I guess because of how the announcement system is implemented. So, yes the easiest solution is to remove both ifNil: [â¦] lines. The UI will not work as cleanly, but it is a quick fix. Alternatively, and a bit more complicated, is to check if the selection in the other list is also empty before setting the text to the empty string. For the sake of the example, I will simply remove both ifNil: [â¦] lines from the documentation. Thanks for reporting this, and if you have further issues do not hesitate to tell us! -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 7, 2016, at 19:51, Matteo <matteob8@yahoo.it> wrote:
Hello Johan, I've coded all the examples manually, changing the names to avoid any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). But the result is the same.
Things improve if all the "ifNil: [ text text: '' ]" get removed from the ProtcolFlipper>>initializePresenter method. Obviously the text pane is no more "cleaned" when deselecting an "api" or "api-event" row.
I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively on the "api" and "event" instances, in the ProtocolBrowser >> initializePresenter method. In this way I found that "ifNil:" message is sent improperly, i.e. when a "api-event" row is selected then the message "ifNil:" of the "api" instance is triggered, and vice-versa. In some way this is correct: when a "api-event" row is selected then none of the "api" rows are selected...
However I'm puzzled by the fact that the behavior seems random: creating 3 instances I can get 3 different behaviors.
have you never experienced this?
Maybe I'll check again my code...
thanks, Matteo
Johan let me know if there is anything that I should do. Stef Le 8/9/16 à 01:11, Johan Fabry a écrit :
Excellent, you found a bug in my code!
What happens is that when one item is selected in a list, in the other list the currently selected item is de-selected. This causes *both* blocks (whenAPIChanged: and whenEventChanged:) to be executed, and depending on what order they are executed the behavior is different. (A classical concurrent programming problem.) This order apparently changes depending on how many windows you have open, et cetera, I guess because of how the announcement system is implemented.
So, yes the easiest solution is to remove both ifNil: [â¦] lines. The UI will not work as cleanly, but it is a quick fix. Alternatively, and a bit more complicated, is to check if the selection in the other list is also empty before setting the text to the empty string.
For the sake of the example, I will simply remove both ifNil: [â¦] lines from the documentation.
Thanks for reporting this, and if you have further issues do not hesitate to tell us!
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 7, 2016, at 19:51, Matteo <matteob8@yahoo.it> wrote:
Hello Johan, I've coded all the examples manually, changing the names to avoid any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). But the result is the same.
Things improve if all the "ifNil: [ text text: '' ]" get removed from the ProtcolFlipper>>initializePresenter method. Obviously the text pane is no more "cleaned" when deselecting an "api" or "api-event" row.
I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively on the "api" and "event" instances, in the ProtocolBrowser >> initializePresenter method. In this way I found that "ifNil:" message is sent improperly, i.e. when a "api-event" row is selected then the message "ifNil:" of the "api" instance is triggered, and vice-versa. In some way this is correct: when a "api-event" row is selected then none of the "api" rows are selected...
However I'm puzzled by the fact that the behavior seems random: creating 3 instances I can get 3 different behaviors.
have you never experienced this?
Maybe I'll check again my code...
thanks, Matteo
Thanks Stef ! There will be a new chapter for you to review soon ;-) -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 04:39, stepharo <stepharo@free.fr> wrote:
Johan
let me know if there is anything that I should do.
Stef
Le 8/9/16 à 15:14, Johan Fabry a écrit :
Thanks Stef ! There will be a new chapter for you to review soon ;-)
eagerly waiting :) Johan we should say that the booklet is for Pharo 60. Like that we have the time to finish it. Stef
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 04:39, stepharo <stepharo@free.fr> wrote:
Johan
let me know if there is anything that I should do.
Stef
thanks Jhoan for the explanation! Do you know some technique to intercept this kind bug? (...or to avoid them?) thanks Matteo On 08/09/16 01:11, Johan Fabry wrote:
Excellent, you found a bug in my code!
What happens is that when one item is selected in a list, in the other list the currently selected item is de-selected. This causes *both* blocks (whenAPIChanged: and whenEventChanged:) to be executed, and depending on what order they are executed the behavior is different. (A classical concurrent programming problem.) This order apparently changes depending on how many windows you have open, et cetera, I guess because of how the announcement system is implemented.
So, yes the easiest solution is to remove both ifNil: [â¦] lines. The UI will not work as cleanly, but it is a quick fix. Alternatively, and a bit more complicated, is to check if the selection in the other list is also empty before setting the text to the empty string.
For the sake of the example, I will simply remove both ifNil: [â¦] lines from the documentation.
Thanks for reporting this, and if you have further issues do not hesitate to tell us!
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 7, 2016, at 19:51, Matteo <matteob8@yahoo.it> wrote:
Hello Johan, I've coded all the examples manually, changing the names to avoid any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). But the result is the same.
Things improve if all the "ifNil: [ text text: '' ]" get removed from the ProtcolFlipper>>initializePresenter method. Obviously the text pane is no more "cleaned" when deselecting an "api" or "api-event" row.
I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively on the "api" and "event" instances, in the ProtocolBrowser >> initializePresenter method. In this way I found that "ifNil:" message is sent improperly, i.e. when a "api-event" row is selected then the message "ifNil:" of the "api" instance is triggered, and vice-versa. In some way this is correct: when a "api-event" row is selected then none of the "api" rows are selected...
However I'm puzzled by the fact that the behavior seems random: creating 3 instances I can get 3 different behaviors.
have you never experienced this?
Maybe I'll check again my code...
thanks, Matteo
Hi Matteo, glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 10:13, Matteo <matteob8@yahoo.it> wrote:
thanks Jhoan for the explanation! Do you know some technique to intercept this kind bug? (...or to avoid them?)
thanks Matteo
Hi Jhoan, Does static typing could fix these kind of bugs? [hahaha, just kidding ;) ] About the SpecBooklet, for now there's only 3 (really) small issues: at page 3 --> the phrase "You could can use the rest..." should be fixed; at page 5 --> to let the code work I had to substitute "self iconNamed: #thumbsUp" with "(Smalltalk ui icons iconNamed: #thumbsUp)",and so on for the other buttons. Is it a problem of my image? at page 14 --> there's a " ' " missing from the "instanceVariableNames:" of the #ProtocolMethodList subclassing message. Just a note to say that I'm very happy with the SpecBooklet: it would be **very** difficult to figure out how to effectively use Spec by simply reading the code. Further it is really well written, and contains a lot of useful/fundamental information: evidence of the great effort the Authors have spent to write it. Congrats for the very good job! thanks, Matteo On 08/09/16 15:28, Johan Fabry wrote:
Hi Matteo,
glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution.
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 10:13, Matteo <matteob8@yahoo.it> wrote:
thanks Jhoan for the explanation! Do you know some technique to intercept this kind bug? (...or to avoid them?)
thanks Matteo
Thanks for your kind words and also for the report of the issues, I will take care of that ASAP! -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 11:24, Matteo <matteob8@yahoo.it> wrote:
Hi Jhoan,
Does static typing could fix these kind of bugs? [hahaha, just kidding ;) ]
About the SpecBooklet, for now there's only 3 (really) small issues:
at page 3 --> the phrase "You could can use the rest..." should be fixed;
at page 5 --> to let the code work I had to substitute "self iconNamed: #thumbsUp" with "(Smalltalk ui icons iconNamed: #thumbsUp)",and so on for the other buttons. Is it a problem of my image?
at page 14 --> there's a " ' " missing from the "instanceVariableNames:" of the #ProtocolMethodList subclassing message.
Just a note to say that I'm very happy with the SpecBooklet: it would be **very** difficult to figure out how to effectively use Spec by simply reading the code.
Further it is really well written, and contains a lot of useful/fundamental information: evidence of the great effort the Authors have spent to write it.
Congrats for the very good job!
thanks, Matteo
On 08/09/16 15:28, Johan Fabry wrote:
Hi Matteo,
glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution.
-- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Sep 8, 2016, at 10:13, Matteo <matteob8@yahoo.it> wrote:
thanks Jhoan for the explanation! Do you know some technique to intercept this kind bug? (...or to avoid them?)
thanks Matteo
participants (3)
-
Johan Fabry -
Matteo -
stepharo