Odd Behaviour in 1.9 Testing
Brought to you by:
axel77,
ronnystandtke
Menu
▾
▴
#71 Odd Behaviour in 1.9 Testing
closed
nobody
None
5
2014-08-22
2009-09-13
Anonymous
No
I was trying out the 1.9 testing version, and observed the following strange behaviour: I was repeating cards, and editing some of the cards as I was doing this. For one card, after I edited it during revision, it was shown again, and then a third time, before Pauker moved to another card. After revising all expired cards, I checked, and the card really exists only once. The really strange thing was that this one card ended up in batch number 9. The card was in batch number 6 and should have moved to batch number 7; I don't yet have a batch number 9 in this lesson (not for another year or so). What is also strange is that this happened to only one card, although I also edited others.
I have no idea if this is relevant, my settings for revising cards are to draw at random, and put the cards to the top in case of failure, and I repeat this lesson by remembering cards (not typing). This is on Windows XP, with all the patches (SP3) and the current version of Java. I have checked the lesson afterward, and everything appears to be fine. The lesson I was using is not the biggest lesson I have (thinking of memory limits, since this computer is some 5 years old).
Thanks for reporting this issue. Unfortunately, I am not able to reproduce it. Can you please attach an example lesson and exact steps to reproduce the issue?
I'm unable to reproduce this (it only happened once), but I've mostly been using 1.8 lately (too busy with work, so playing it safely). Perhaps you could close this bug.
I've just had this again in the latest testing version. I'll try to figure out more and report back. (don't close this bug just yet)
What I did was repeat expired cards. One of them I edited, and then chose that I knew it. It was moved to the next batch, but was shown as unlearned. I'm trying to find a consistent way to reproduce this behaviour.
I noticed that cards are added to the new batch first, then removed from the old one. (If the computer is busy with something else, I can see the numbers change separately.)
Might it be that if I repeat the next card before the old one (the one I edited) was actually removed, I end up with multiples?
I'm still puzzled how I had a card in batch 9 the other day, though... and cannot replicate this consistently.
P.S. This is on a different PC than when I first observed this (original report).
I think I got it. I used my largest lesson (6000) cards, because Pauker is generally slower with larger lessons. I review expired cards, and edited one as I was reviewing it (card k, in batch 7). The editing might be important because Pauker takes a while to update cards that are updated.
So I edit the card, and then choose "OK" as in that I knew the card. Now I just hit enter very quickly to review other cards (basically telling Pauker that I knew all of them). Card k is also reviewed (so Pauker has not set it as "learned" yet), and for each "OK" is moved to a higher batch.
I'll e-mail you a screen shot so that you can see the result.
I have also changed Pauker's settings from repeating expired cards at a "random order" to "oldest first", and this way it is easier to replicate this.
Rather than memory, it might be processor speed (first machine was old, this is a netbook).
Just to confirm that this bug is still present in 1.9 Beta 2.
and to confirm that this Bug also affects Linux
I finally managed to create a reproducible test case. This was really a hard nut to crack.
Hint for programmers (just in case a poor soul runs into the same problem and Google picks up this comment..) : Never EVER store mutable objects in a HashSet! The hashCode of the object is used when adding the object to the HashSet to place it into a certain HashTable index. When you later modify the object, it also changes the hashCode of the object. When you then try to remove the object, the HashSet uses again the hashCode to compute the HashTable index of the object. Because the hashCode is now completely different, the object can no longer be found and therefore can never be removed from the HashSet. Absolutely crazy.
This issue is now fixed in svn.