Did no find yet a way to reproduce QA concurrent access
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it. Stef
I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :) Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
I'm not complaining. I know that there is a good chance that we break the system when improving it. I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :) I'm just trying to help handling this problem. This is alpha with all the risks. Stef Le 7/9/15 00:46, Yuriy Tymchuk a écrit :
I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :)
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
On 07 Sep 2015, at 22:07, stepharo <stepharo@free.fr> wrote:
I'm not complaining. I know that there is a good chance that we break the system when improving it. I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :)
exactly. For me, Pharo was exactly that: Imagine instead of ânot doing anything because we could do betterâ we would just do, as trivial and wrong as it our limits allow, but then learn from the mistakes and repeat⦠and, important, this in a way that the improvement âfeeds backâ into the system to have a direct impact on the next iteration. There are multiple feedback loops: - you only learn when you do. And most when you do it wrong. When you do the next thing it will be with more understanding and knowledge. If you do nothing because what you can do might be not perfect, you will just end with nothing. - As we improve the system we use, every tiny improvement has an impact on the next improvement. The âThis is just a 2% boring improvementâ is part of an exponential growth process if it happens in such a feedback loop. - The artefact that you see is not the goal. Itâs just a stepping stone towards. It will be ugly and imperfect, it will contain parts that are even not meant to be ever âniceâ as they are just scaffolding. They are there to help us build something else. â¦.. Marcus
Iâm happy to get feedback. Just wanted to know that I care about the issues :)
On 07 Sep 2015, at 22:07, stepharo <stepharo@free.fr> wrote:
I'm not complaining. I know that there is a good chance that we break the system when improving it. I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :) I'm just trying to help handling this problem. This is alpha with all the risks. Stef
Le 7/9/15 00:46, Yuriy Tymchuk a écrit :
I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :)
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding. Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
Just open Nautilus on class "Model" and add an instance. 2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding.
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
"and add an instance *variable*" :) 2015-09-07 12:01 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
Just open Nautilus on class "Model" and add an instance.
2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding.
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
Yes, I know, but Stef was referring to deleting a method. Also I donât really know how I can fix the stuff with instance variable. I need to have a separate process in order not to slow down the browsing in Nautilus. Uko
On 07 Sep 2015, at 12:01, Nicolai Hess <nicolaihess@web.de> wrote:
"and add an instance *variable*" :)
2015-09-07 12:01 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>:
Just open Nautilus on class "Model" and add an instance.
2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding.
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
may be this is the same. Le 7/9/15 12:32, Yuriy Tymchuk a écrit :
Yes, I know, but Stef was referring to deleting a method.
Also I donât really know how I can fix the stuff with instance variable. I need to have a separate process in order not to slow down the browsing in Nautilus.
I have the impression that we see that the reflective should be thread safe :) No? May be you could check what is used and have a threadsafe wrapper (not since the rules can use many different infromation I guess that this is not practical to do it. In any case this is a really interested case. Food for thoughts as they say.
Ok I will do it. Le 7/9/15 00:56, Yuriy Tymchuk a écrit :
Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding.
Uko
On 06 Sep 2015, at 22:17, stepharo <stepharo@free.fr> wrote:
I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it.
Stef
participants (4)
-
Marcus Denker -
Nicolai Hess -
stepharo -
Yuriy Tymchuk