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

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

Ok I will do it.


Le 7/9/15 00:56, Yuriy Tymchuk a écrit :

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 :

may be this is the same.

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.

> On 07 Sep 2015, at 22:07, stepharo <[hidden email]> 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 :)