-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(common/models): move core trie-compilation code into common/models/templates 📖 #12083
refactor(common/models): move core trie-compilation code into common/models/templates 📖 #12083
Conversation
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
} | ||
trieCollator.sort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still calls sortTrie
, just via the object's member function. (See line 162 of trie-builder.ts.)
…on/models/templates We'll likely want to dynamically build a Trie to represent user-specific entries made available by the active OS. We'll then blend _that_ with the 'static' distributed model.
f28f7b9
to
54bdf73
Compare
* Unicode will never assign semantics to these characters, as they are | ||
* intended to be used internally as sentinel values. | ||
*/ | ||
const INTERNAL_VALUE = '\uFDD0'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This exactly matches the value of SENTINEL_CODE_UNIT
in common/models/templates
, so I replaced all migrated instances of it with SENTINEL_CODE_UNIT
.
@@ -88,12 +98,26 @@ export class TrieTraversal implements LexiconTraversal { | |||
return traversal; | |||
} | |||
|
|||
private sortNodeIfNeeded(node: Node) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found this by referencing the original original implementation:
keyman/developer/src/kmc-model/src/build-trie.ts
Lines 207 to 208 in dd12e73
// The following trie implementation has been (heavily) derived from trie-ing | |
// by Conrad Irwin. |
// See: https://github.com/ConradIrwin/trie-ing/blob/df55d7af7068d357829db9e0a7faa8a38add1d1d/LICENSE |
This may seem "pulled up a tad bit too early", but there's a reason. If we 'construct' the Trie while live, modifications can make part of the Trie unsorted. We want to track that and correct for that.
The followup then changes this block, integrating it within the Trie traversal structure. Pulling it in early like this allows for code comparison between the two approaches.
Keyman Core test failures:
Yeah, that tracks. I probably forgot to set a dependency link. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One important dependency change required (otherwise I suspect this will break at runtime)
…to refactor/common/models/trie-construction
…mon/models/trie-construction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Note: this only moves
Trie
construction code, rather thanTrieModel
construction code.In support of #10973.
At runtime - be it within the worker or within a separate process hosted by the mobile apps - we'll want a way to collate and/or compile user-specific words and names into a model that we can use for correction and prediction. The simplest such model is a wordlist... and we already know how to build those.
The key detail here is that we need Trie compilation code, at a minimum, to become common code. I believe we can no longer limit its use to within Developer.
@keymanapp-test-bot skip