I recommend using google's random op generator - Its quite good, and it obviously generates ops which are (spec-wise) correct.
I hooked it up by getting the op generator to create files with lists of ops & resultant documents and then ingested that using my testing code. I've been meaning to submit it into fedone, but the code would need a bit of a cleanup for that to happen. I've attached it anyway, if it helps. (drop it into the right directory in fedone, compile and run). -J On Fri, Aug 6, 2010 at 8:06 PM, Torben Weis <[email protected]> wrote: > Hi Joseph, > > thanks for your explanations. You are right. Seems it was too late in the > night for me :-) > In the meantime I found the following in the specs: > > ------------------------- > For deletion components, the old values in the annotations update match the > annotations of each item in the input document processed by the component, > and the new values match the annotations of the rightmost item generated so > far. All annotation keys that have different values in the processed item > and the rightmost item generated so far are present in the annotations > update. If no items have been generated so far, the new values are null, and > all annotation keys of the deleted items must be present in the annotations > update. > --------------- > > My random mutation generator did produce false mutations and the verifier > did not check for the correctness of the annotations around a delete. Will > fix this. > > Greetings > Torben > > 2010/8/6 Joseph Gentle <[email protected]> > > In this case, the delete op must also delete the annotation. If it didn't, >> the op wouldn't be invertable (if you apply the op then apply its inverse, >> you'll end up removing the annotation). >> >> Your example should look like: >> mutation1 := anno('bold': 'true' -> NULL), delete 'ab', anno(end 'bold'), >> retain 2 >> mutation2 := retain 2, insert 'x', retain 2 >> >> After transform, mutation1_t is the same as you suggested, but >> >> mutation2_t := anno ('bold': NULL -> true) insert 'x', anno (end 'bold'), >> retain 2 >> >> ... and you get the correct behaviour. >> >> -J >> >> >> On Fri, Aug 6, 2010 at 11:14 AM, Torben Weis <[email protected]>wrote: >> >>> Hi, >>> >>> I encountered a problem while unit testing my OT code. Either I just >>> found a major flaw in the OT algorithm (i.e. a flaw that is almost >>> impossible to repair) or I am too tired to see the solution. Here is the >>> problem: >>> >>> Let "A, B ,C" be BOLD letters, and "a, b, c" denote the same letters, but >>> not in bold. >>> Now imagine a simple document with the content >>> >>> doc := ABcd >>> >>> i.e. "ab" in bold and "cd" not in bold. Now two users edit the document >>> concurrently. >>> >>> mutation1 := delete:2, retain:2 >>> mutation2 := retain:2, insert:"x", retain:2 >>> >>> i.e. user1 sees "cd" and user2 sees "ABXcd". Notice that the "x" is bold >>> -> "X", because in word processors you inherit the style from the left. This >>> is important here! >>> >>> Now I transform both mutations and I get: >>> >>> mutation1_t := delete:2 retain:3 // I skip the inserted "x" -> >>> therefore retain2 >>> mutation2_t := insert"x", retain:2 // No need to skip "AB", because >>> they are already deleted >>> >>> Now user1 one applies mutation2_t and user2 applies mutation1_t. They >>> should end up in the same state. >>> >>> However, in the end user1 sees "xcd" and user2 sees "Xcd". The difference >>> is that x is not consistently annotated. >>> >>> As far as can see right now, the transformation function cannot do >>> anything because it needs style annotation that is only in the document but >>> not in the mutations. >>> >>> I hope that someone can enlighten me here, because otherwise the OT >>> algorithm is broken. >>> >>> Greetings >>> Torben >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Wave Protocol" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<wave-protocol%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/wave-protocol?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Wave Protocol" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<wave-protocol%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/wave-protocol?hl=en. >> > > > > -- > --------------------------- > Prof. Torben Weis > Universitaet Duisburg-Essen > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
RandomOpSerializer.java
Description: Binary data
