Bug: SoundService default is not a class

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug: SoundService default is not a class

Nicolas Cellier
Hi Marcel, Tobias,
I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).

Why?
Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown.
It used to work.

But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.

Thus, when we play the tests, we can no more play the sounds...

I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.


Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

David T. Lewis
Nicolas,

It is really good to see those Mantis issues being addressed. Thank you!

Dave

> Hi Marcel, Tobias,
> I encountered a bug, when playing a sound, the default SoundService (class
> inst var) was not a class (BasedSoundService) but an instance (a
> BasedSoundService).
>
> Why?
> Because, there is a TileMorphTest>>setUp that remember which is the
> default, then tries to restore it in tearDown.
> It used to work.
>
> But, in between, SoundService default and defaultOrNil have been
> re-defined
> so as to answer an instance rather than a class.
>
> Thus, when we play the tests, we can no more play the sounds...
>
> I hesitate to open a Mantis issue, no one read nor close them, so the bug
> report is only here for the moment.
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Nicolas Cellier
Hi David,
Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables ;)

My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
Fortunately, there are not so much of them.

Then I would close all the rest (resolution = timeout).
Other teams including Pharo have such a policy.

Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts.
There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check.
There is no such thing as gift-support-service.

But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.

If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
But there's no hurry, the Augean stables had to wait 30 years...

2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
Nicolas,

It is really good to see those Mantis issues being addressed. Thank you!

Dave

> Hi Marcel, Tobias,
> I encountered a bug, when playing a sound, the default SoundService (class
> inst var) was not a class (BasedSoundService) but an instance (a
> BasedSoundService).
>
> Why?
> Because, there is a TileMorphTest>>setUp that remember which is the
> default, then tries to restore it in tearDown.
> It used to work.
>
> But, in between, SoundService default and defaultOrNil have been
> re-defined
> so as to answer an instance rather than a class.
>
> Thus, when we play the tests, we can no more play the sounds...
>
> I hesitate to open a Mantis issue, no one read nor close them, so the bug
> report is only here for the moment.
>
>






Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Nicolas Cellier
Back to the original bug, I've fixed it in trunk.

Repairing broken SoundService default requires a new script (done).
Now I don't remember, should I create an update map to make sure that this script is evaluated?

2018-04-06 22:20 GMT+02:00 Nicolas Cellier <[hidden email]>:
Hi David,
Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables ;)

My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
Fortunately, there are not so much of them.

Then I would close all the rest (resolution = timeout).
Other teams including Pharo have such a policy.

Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts.
There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check.
There is no such thing as gift-support-service.

But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.

If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
But there's no hurry, the Augean stables had to wait 30 years...

2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
Nicolas,

It is really good to see those Mantis issues being addressed. Thank you!

Dave

> Hi Marcel, Tobias,
> I encountered a bug, when playing a sound, the default SoundService (class
> inst var) was not a class (BasedSoundService) but an instance (a
> BasedSoundService).
>
> Why?
> Because, there is a TileMorphTest>>setUp that remember which is the
> default, then tries to restore it in tearDown.
> It used to work.
>
> But, in between, SoundService default and defaultOrNil have been
> re-defined
> so as to answer an instance rather than a class.
>
> Thus, when we play the tests, we can no more play the sounds...
>
> I hesitate to open a Mantis issue, no one read nor close them, so the bug
> report is only here for the moment.
>
>







Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Tobias Pape

> On 06.04.2018, at 23:12, Nicolas Cellier <[hidden email]> wrote:
>
> Back to the original bug, I've fixed it in trunk.

OK :)
thanks
        -t

>
> Repairing broken SoundService default requires a new script (done).
> Now I don't remember, should I create an update map to make sure that this script is evaluated?
>
> 2018-04-06 22:20 GMT+02:00 Nicolas Cellier <[hidden email]>:
> Hi David,
> Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables ;)
>
> My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
> Fortunately, there are not so much of them.
>
> Then I would close all the rest (resolution = timeout).
> Other teams including Pharo have such a policy.
>
> Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts.
> There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check.
> There is no such thing as gift-support-service.
>
> But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
> - either the issue is important, and it must/will be reopened
> - or no one cares and the issue can be closed.
>
> If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
> But there's no hurry, the Augean stables had to wait 30 years...
>
> 2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
> Nicolas,
>
> It is really good to see those Mantis issues being addressed. Thank you!
>
> Dave
>
> > Hi Marcel, Tobias,
> > I encountered a bug, when playing a sound, the default SoundService (class
> > inst var) was not a class (BasedSoundService) but an instance (a
> > BasedSoundService).
> >
> > Why?
> > Because, there is a TileMorphTest>>setUp that remember which is the
> > default, then tries to restore it in tearDown.
> > It used to work.
> >
> > But, in between, SoundService default and defaultOrNil have been
> > re-defined
> > so as to answer an instance rather than a class.
> >
> > Thus, when we play the tests, we can no more play the sounds...
> >
> > I hesitate to open a Mantis issue, no one read nor close them, so the bug
> > report is only here for the moment.
> >
> >
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Ben Coman
In reply to this post by Nicolas Cellier
On 7 April 2018 at 04:20, Nicolas Cellier
<[hidden email]> wrote:

> Hi David,
> Just a small brook for washing yet another
> https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables
> ;)
>
> My advice would be to inspect the entries updated these last two years, and
> if still relevant confirm (or fix) else close.
> Fortunately, there are not so much of them.
>
> Then I would close all the rest (resolution = timeout).
> Other teams including Pharo have such a policy.

Note that this is done by a bot, so there is no judgement of the
importance of the issue.
The judgement comes from the initiator re-opening it.

>
> Generally, I hate when my opened issues are closed like that, because I
> mostly don't use Pharo, so I consider these as pure gifts.
> There is a side effect that I'm not encouraged to report anymore, and I
> rarely reopen them, because I have no time to check.
> There is no such thing as gift-support-service.

Personally, when my Pharo issues are auto-closed
sometimes I think "Whoops, I really do mean to get back to that" and re-open it,
and othertimes I think "Nah! It never happened to me twice, not
*really* important" and I leave it closed.
The latter doesn't discourage me from logging issues.  Its there to be
found if its a common issue
and it gains additional comments indicating it should be reopened if
no-one yet dealt with it.

cheers -ben

>
> But, in the end, Pharo team is right: accumulation of rotten issues is not
> sustainable
> - either the issue is important, and it must/will be reopened
> - or no one cares and the issue can be closed.

>
> If Heracles himself wants to inspect and resolve the timed-out issues, he
> would just have to set a filter with a few clicks.
> But there's no hurry, the Augean stables had to wait 30 years...
>
> 2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
>>
>> Nicolas,
>>
>> It is really good to see those Mantis issues being addressed. Thank you!
>>
>> Dave
>>
>> > Hi Marcel, Tobias,
>> > I encountered a bug, when playing a sound, the default SoundService
>> > (class
>> > inst var) was not a class (BasedSoundService) but an instance (a
>> > BasedSoundService).
>> >
>> > Why?
>> > Because, there is a TileMorphTest>>setUp that remember which is the
>> > default, then tries to restore it in tearDown.
>> > It used to work.
>> >
>> > But, in between, SoundService default and defaultOrNil have been
>> > re-defined
>> > so as to answer an instance rather than a class.
>> >
>> > Thus, when we play the tests, we can no more play the sounds...
>> >
>> > I hesitate to open a Mantis issue, no one read nor close them, so the
>> > bug
>> > report is only here for the moment.
>> >
>> >
>>
>>
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Nicolas Cellier


Le sam. 7 avr. 2018 à 05:51, Ben Coman <[hidden email]> a écrit :
On 7 April 2018 at 04:20, Nicolas Cellier
<[hidden email]> wrote:
> Hi David,
> Just a small brook for washing yet another
> https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables
> ;)
>
> My advice would be to inspect the entries updated these last two years, and
> if still relevant confirm (or fix) else close.
> Fortunately, there are not so much of them.
>
> Then I would close all the rest (resolution = timeout).
> Other teams including Pharo have such a policy.

Note that this is done by a bot, so there is no judgement of the
importance of the issue.
The judgement comes from the initiator re-opening it.

>
> Generally, I hate when my opened issues are closed like that, because I
> mostly don't use Pharo, so I consider these as pure gifts.
> There is a side effect that I'm not encouraged to report anymore, and I
> rarely reopen them, because I have no time to check.
> There is no such thing as gift-support-service.

Personally, when my Pharo issues are auto-closed
sometimes I think "Whoops, I really do mean to get back to that" and re-open it,
and othertimes I think "Nah! It never happened to me twice, not
*really* important" and I leave it closed.
The latter doesn't discourage me from logging issues.  Its there to be
found if its a common issue
and it gains additional comments indicating it should be reopened if
no-one yet dealt with it.

cheers -ben

Hi Ben,
That's the right attitude. But remember that I'm emotional, it helps to perceive things or obscure others when it gets personal.

>
> But, in the end, Pharo team is right: accumulation of rotten issues is not
> sustainable
> - either the issue is important, and it must/will be reopened
> - or no one cares and the issue can be closed.

>
> If Heracles himself wants to inspect and resolve the timed-out issues, he
> would just have to set a filter with a few clicks.
> But there's no hurry, the Augean stables had to wait 30 years...
>
> 2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
>>
>> Nicolas,
>>
>> It is really good to see those Mantis issues being addressed. Thank you!
>>
>> Dave
>>
>> > Hi Marcel, Tobias,
>> > I encountered a bug, when playing a sound, the default SoundService
>> > (class
>> > inst var) was not a class (BasedSoundService) but an instance (a
>> > BasedSoundService).
>> >
>> > Why?
>> > Because, there is a TileMorphTest>>setUp that remember which is the
>> > default, then tries to restore it in tearDown.
>> > It used to work.
>> >
>> > But, in between, SoundService default and defaultOrNil have been
>> > re-defined
>> > so as to answer an instance rather than a class.
>> >
>> > Thus, when we play the tests, we can no more play the sounds...
>> >
>> > I hesitate to open a Mantis issue, no one read nor close them, so the
>> > bug
>> > report is only here for the moment.
>> >
>> >
>>
>>
>>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

David T. Lewis
In reply to this post by Nicolas Cellier
On Fri, Apr 06, 2018 at 10:20:12PM +0200, Nicolas Cellier wrote:
> Hi David,
> Just a small brook for washing yet another
> https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables
> ;)
>

LOL!

And you are right.

Dave


> My advice would be to inspect the entries updated these last two years, and
> if still relevant confirm (or fix) else close.
> Fortunately, there are not so much of them.
>
> Then I would close all the rest (resolution = timeout).
> Other teams including Pharo have such a policy.
>
> Generally, I hate when my opened issues are closed like that, because I
> mostly don't use Pharo, so I consider these as pure gifts.
> There is a side effect that I'm not encouraged to report anymore, and I
> rarely reopen them, because I have no time to check.
> There is no such thing as gift-support-service.
>
> But, in the end, Pharo team is right: accumulation of rotten issues is not
> sustainable
> - either the issue is important, and it must/will be reopened
> - or no one cares and the issue can be closed.
>
> If Heracles himself wants to inspect and resolve the timed-out issues, he
> would just have to set a filter with a few clicks.
> But there's no hurry, the Augean stables had to wait 30 years...
>
> 2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
>
> > Nicolas,
> >
> > It is really good to see those Mantis issues being addressed. Thank you!
> >
> > Dave
> >
> > > Hi Marcel, Tobias,
> > > I encountered a bug, when playing a sound, the default SoundService
> > (class
> > > inst var) was not a class (BasedSoundService) but an instance (a
> > > BasedSoundService).
> > >
> > > Why?
> > > Because, there is a TileMorphTest>>setUp that remember which is the
> > > default, then tries to restore it in tearDown.
> > > It used to work.
> > >
> > > But, in between, SoundService default and defaultOrNil have been
> > > re-defined
> > > so as to answer an instance rather than a class.
> > >
> > > Thus, when we play the tests, we can no more play the sounds...
> > >
> > > I hesitate to open a Mantis issue, no one read nor close them, so the bug
> > > report is only here for the moment.
> > >
> > >
> >
> >
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

marcel.taeumel
In reply to this post by Nicolas Cellier
Hi Nicolas,

thank you. I think I will also override #default: to ensure that only behaviors are stored. At the moment, the meaning of #default changed without taking take of #default: so that "self default: self default" still works. No updateMap/script should be required if we make sure that ReleaseBuilder also resets all AppRegistries.

Best,
Marcel

Am 06.04.2018 23:12:43 schrieb Nicolas Cellier <[hidden email]>:

Back to the original bug, I've fixed it in trunk.

Repairing broken SoundService default requires a new script (done).
Now I don't remember, should I create an update map to make sure that this script is evaluated?

2018-04-06 22:20 GMT+02:00 Nicolas Cellier <[hidden email]>:
Hi David,
Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables ;)

My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
Fortunately, there are not so much of them.

Then I would close all the rest (resolution = timeout).
Other teams including Pharo have such a policy.

Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts.
There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check.
There is no such thing as gift-support-service.

But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.

If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
But there's no hurry, the Augean stables had to wait 30 years...

2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
Nicolas,

It is really good to see those Mantis issues being addressed. Thank you!

Dave

> Hi Marcel, Tobias,
> I encountered a bug, when playing a sound, the default SoundService (class
> inst var) was not a class (BasedSoundService) but an instance (a
> BasedSoundService).
>
> Why?
> Because, there is a TileMorphTest>>setUp that remember which is the
> default, then tries to restore it in tearDown.
> It used to work.
>
> But, in between, SoundService default and defaultOrNil have been
> re-defined
> so as to answer an instance rather than a class.
>
> Thus, when we play the tests, we can no more play the sounds...
>
> I hesitate to open a Mantis issue, no one read nor close them, so the bug
> report is only here for the moment.
>
>







Reply | Threaded
Open this post in threaded view
|

Re: Bug: SoundService default is not a class

Nicolas Cellier
+1,
Nice to see that my exact thoughts are already in trunk, it's magic ;)

2018-04-08 11:46 GMT+02:00 Marcel Taeumel <[hidden email]>:
Hi Nicolas,

thank you. I think I will also override #default: to ensure that only behaviors are stored. At the moment, the meaning of #default changed without taking take of #default: so that "self default: self default" still works. No updateMap/script should be required if we make sure that ReleaseBuilder also resets all AppRegistries.

Best,
Marcel

Am 06.04.2018 23:12:43 schrieb Nicolas Cellier <[hidden email]>:

Back to the original bug, I've fixed it in trunk.

Repairing broken SoundService default requires a new script (done).
Now I don't remember, should I create an update map to make sure that this script is evaluated?

2018-04-06 22:20 GMT+02:00 Nicolas Cellier <[hidden email]>:
Hi David,
Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stables ;)

My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
Fortunately, there are not so much of them.

Then I would close all the rest (resolution = timeout).
Other teams including Pharo have such a policy.

Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts.
There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check.
There is no such thing as gift-support-service.

But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.

If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
But there's no hurry, the Augean stables had to wait 30 years...

2018-04-06 21:58 GMT+02:00 David T. Lewis <[hidden email]>:
Nicolas,

It is really good to see those Mantis issues being addressed. Thank you!

Dave

> Hi Marcel, Tobias,
> I encountered a bug, when playing a sound, the default SoundService (class
> inst var) was not a class (BasedSoundService) but an instance (a
> BasedSoundService).
>
> Why?
> Because, there is a TileMorphTest>>setUp that remember which is the
> default, then tries to restore it in tearDown.
> It used to work.
>
> But, in between, SoundService default and defaultOrNil have been
> re-defined
> so as to answer an instance rather than a class.
>
> Thus, when we play the tests, we can no more play the sounds...
>
> I hesitate to open a Mantis issue, no one read nor close them, so the bug
> report is only here for the moment.
>
>