I don't remember seeing this before. We only had 2 or maybe 3 XOs on
that network. I don't have a way to reproduce this problem, but I would
start by looking at the code that draws the XOs and follow it backwards
to find possible paths that would duplicate the XO. I haven't looked at
the code, but it would be interesting to know if the collection of XO's
involved in an activity (the one used by the neighbourhood viewer) is a
Set or a List, and what the key is if it is a set. There are long
standing key error exceptions in shell.log which might be related.
This may be more effort than it is worth, but ignoring hard to reproduce
problems is probably what led to the neighbourhood's current reputation.
On 22/03/12 17:47, Deepak Muddha wrote:
Hi all
Can you explain the below mentioned defect more clearly. Any
suggestion on how to reproduce this?
Shared memorize on ivy on adhoc network and ended up with 6 ivy's
around the memorize activity! Not sure how this is possible, see:
https://picasaweb.google.com/lh/photo/_Oov9ppYnvvKIAHN1n0m8dMTjNZETYmyPJy0liipFm0?feat=directlink
Link for the above defect raised in OLPC-Au:
http://dev.laptop.org.au/issues/1167
Regards
Deepak
_______________________________________________
Testing mailing list
[email protected]
http://lists.laptop.org/listinfo/testing
