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 .
>
> 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
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>> *From: *Matteo <[hidden email] <mailto:[hidden email]>>
>> *Subject: **SpecBooklet: Strange behavior of ProtocolBrowser*
>> *Date: *September 7, 2016 at 18:56:08 GMT-3
>> *To: *[hidden email] <mailto:[hidden email]>
>>
>>
>> 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
>>
>>
>>
>>
>>
>

> On Sep 7, 2016, at 19:51, Matteo <[hidden email]> 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

> 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 <[hidden email]> 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
>
>

> 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 <[hidden email]> 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
>

> On Sep 8, 2016, at 04:39, stepharo <[hidden email]> wrote:
>
> Johan
>
>
> let me know if there is anything that I should do.
>
>
> Stef
>

> 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 <[hidden email]> wrote:
>>
>> thanks Jhoan for the explanation!
>> Do you know some technique to intercept this kind bug? (...or to avoid
>> them?)
>>
>> thanks
>> Matteo
>

> On Sep 8, 2016, at 11:24, Matteo <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> thanks Jhoan for the explanation!
>>> Do you know some technique to intercept this kind bug? (...or to avoid
>>> them?)
>>>
>>> thanks
>>> Matteo
>>
>
>

>
> --
> 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 <[hidden email]> wrote:
>>
>> Johan
>>
>>
>> let me know if there is anything that I should do.
>>
>>
>> Stef
>>
>
>