Commit graph

3 commits

Author SHA1 Message Date
Kurt Partridge
403c423940 [Rlog56] Buffer words before pushing out LogUnit
Previously, a logbuffer only held an n-gram.  Data went in and out of it, FIFO, until privacy
conditions were met (i.e. data not collected too frequently), and then an n-gram was saved.
E.g., if n=2, and only 10% of data is collected, then 18 words went through the logbuffer before
it captured the next 2 words.

However, if a user then went back and edited the n-gram, these edits were not captured.

This change changes the logbuffer size to temporarily hold data about words that are not recorded,
so that if the user backs up over them, the edits to an n-gram that we do eventually capture are
stored.  If the example above, instead of a logbuffer holding 2 words, it holds 20.  The system
waits until all the words not needed for the n-gram have been gathered (i.e. the buffer is full),
so the user has adequate time to edit, before shifting out the n-gram.  The buffer is still flushed
when the user closes the IME.  See the comment for MainLogBuffer for an explanation.

multi-project commit with I45317bc95eeb859adc1b35b24d0478f2df1a67f3

Change-Id: I4ffd95d08c6437dcf650d866ef9e24b6af512334
2013-01-09 21:09:19 -08:00
Kurt Partridge
3b95eaf70b [Rlog50] capture bigrams properly even with deletions
multi-project commit with Ia4ec213e8356897807cb6a278fccdbaa945732f0

Change-Id: Ib3fe886dc889954a31586ab81d00a21d8d55efd2
2013-01-09 16:02:37 -08:00
Kurt Partridge
f77dd424b0 [Rlog27] Refactor LogBuffer
Cleanup and prepare for replaying

Change-Id: Ie09e912c6e9c0d7375168c575ccf1cfd9375dd31
2013-01-03 16:36:32 -08:00