Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • trie-js-dumping protected
  • hitbox-boosting protected
  • model-metadata protected
  • lm-2-finetuning-whisperggml protected
  • lm-2-finetuning protected
  • lm-2 protected
  • language_model_experiments protected
  • 0.1.24.2 protected
  • 0.1.24.2-rc1 protected
  • 0.1.24.1 protected
  • 0.1.24.1-rc1 protected
  • 0.1.24 protected
  • 0.1.24-rc1 protected
  • 0.1.23.2 protected
  • 0.1.23.1 protected
  • 0.1.23 protected
  • 0.1.22 protected
  • 0.1.21 protected
  • 0.1.20 protected
  • 0.1.19 protected
  • 0.1.18 protected
  • 0.1.17 protected
  • 0.1.16 protected
  • 0.1.15 protected
  • 0.1.14.1 protected
  • 0.1.14 protected
  • 0.1.13 protected
28 results
Search by author
  • Any Author
  • Aleksandras Kostarevas Aleksandras Kostarevas alex
  • Dean Dean dean
  • Tom Folbrecht Tom Folbrecht tom
  • sameer sameer sameer
4 authors
  1. Oct 04, 2013
  3. Oct 02, 2013
  5. Sep 30, 2013
  7. Sep 26, 2013
  9. Sep 25, 2013
  11. Sep 19, 2013
  13. Sep 18, 2013
  15. Sep 13, 2013
  17. Sep 11, 2013
  19. Sep 09, 2013
  21. Sep 06, 2013
  23. Sep 05, 2013
  25. Aug 26, 2013
  27. Aug 22, 2013
  29. Aug 21, 2013
  31. Aug 19, 2013
  33. Aug 16, 2013
  35. Aug 15, 2013
  37. Aug 14, 2013
  39. Aug 13, 2013
  41. Aug 09, 2013
  43. Jul 24, 2013
  45. Jul 23, 2013
  47. Jul 17, 2013
  49. Apr 15, 2013
    • Jean Chalard's avatar
      Fix Binary dict tests · c2e9c511
      Jean Chalard authored 
      There are two problems here. The first one is the tests would send
an invalid unicode character. Although we could want dicttool to
handle this more gracefully, it's fine for now.

The second problem is much more serious. If a node has more than
128 children, then the java code will crash trying to read the
dictionary back because of a bug that this change fixes. In
theory, it's possible that happens when we try to load the user
history dictionary back from the disk - native code is not affected
so there is no other point that may cause a problem.
In the practice, that means you'd need to have 129 words with a
common prefix (including empty string) but all different after
this. It's almost impossible with Google Keyboard since there are
only so many keys on the keyboard that you can make a word out
of, and then again you'd have to do it repeatedly until it
actually enters the user history dictionary, wait for it to get
saved on the disk.
The bad news is, if you manage to get this far, the keyboard will
crash every time and won't be able to get up until you clear
data for the package.
The good news is, the dictionary itself is not corrupted and only
the reading code is wrong. So updating to a newer version would
actually even recover from this situation.

All in all, considering how almost-impossible this is to trigger,
I don't think even a single user actually did hit this bug.

Bug: 8583091
Change-Id: Iabb2a7f47cbd9ed3193d2a3487318d280753e071
      c2e9c511
  51. Jan 21, 2013
  53. Jan 07, 2013
    • Ken Wakasa's avatar
      Small code cleanups · b6ca3544
      Ken Wakasa authored 
      Multi-project commit with I249d5fbe

Change-Id: Ia28c4e970992aa1299a30e604eaa5d096655c3a5
      b6ca3544
  55. Dec 11, 2012
  57. Dec 06, 2012
  59. Oct 29, 2012
    • Jean Chalard's avatar
      Remove warnings · f41389a7
      Jean Chalard authored 
      Thanks Eclipse

Change-Id: I88e3979ed22be5d8be5a5accdde417c6b1a8bf2d
      f41389a7
  61. Oct 25, 2012